Re: [DNA] Comments on Combined DNA Solution draft

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

Hi Subba,

Subba Reddy wrote:
> Hi Brett,
> 
>         It is good to see combined solution.
> Overall draft is good.

Thankyou.

> Here are few comments/questions.
> 
> 1. Is the fast RA mechanism is applicable for all the RS's (not only
> for DNA RS's) that a router receives
> (with source address as unicast link local address)?

All, including those with the unspecified address as the source - those
ones will all get their responses from routers in the same order.

> 2. Consider the following case.
> Router R1 (of Link1) is sending Prefix P1 whose life time is 15 seconds.
> A host H came to Link1 and included P1 in DNAHostPrefixList.
> P1 expired gracefully and assigned to Link2. If H moves to Link2 and
> receives complete RA, it will find the match in DNAHostPrefixList and
> will assume same link. Host will not delete P1 since expiry time for entries
> in DNAHostPrefixList is 1.5 hours.

No, the host will expire P1 at its expiry time as indicated by the
liftime it learned in the RA it received on Link1.  (see 6.2.1, para 3)
> 
> 3. It may be better to mention, how to populate DNAHostPrefixList.
> Only reference to this is, last paragraph of section 6.2.5

Yes, good point.  6.2.5 needs a paragraph that says when to add prefixes
to DNAHostPrefixList.

> 
> 4. This comment is regarding "whether a host needs to know whether
> a particulat prefix is common prefix (LinkID) or not?"
> If a host stores all the prefixes of a link, it does not matter whether RA
> has included LinkID or not. If a host cannot store all the prefixes
> ( may be because of maximum bound), there is a probability that host
> may not store LinkID. In that case there may not be any use in including
> LinkID without mentioning it as LinkID.  If the prefix is mentioned as
> LinkID and if we mandate a host to store that common prefix,
> this problem may not come.
> 
> Am I missing something?

What's a reasonable number of prefixes for a link?  Even if it's a few
tens, do we need to worry that hosts won't be able to store that many?
If so, I guess hosts could use the same logic as routers to pick the
LinkID prefix out of the advertised list.  I'm not sure that this is
necessary.  What do others think?

> 
> 5. From Section 2, Section 4.2 LinkID and Landmark are optional
> 
> Section 2,
> " ... Aspects of prefix-based LinkID and
>    Requested Landmark are optionally included to allow for a decrease in
>    the packet sizes associated with Complete RA."
> 
> Section 4.2,
> "   Frequently, all routers on a link will advertise the same set of
>    prefixes and so this technique will incur no space penalty.  However,
>    on links where routers advertise different sets of prefixes, packets
>    may be larger.  To combat this, two optional mechanisms are defined."
> 
> But in some places, LinkID and Landmark are mentioned as MUST.

Yes, in an earlier thread with Jari, I think we agreed that LinkID is
a MUST for routers.  I forgot about section 2.  I think I should just
remove the work "optionally" from there.  The only MUST I can see
related to Landmarks is that 6.2.1 says that hosts MUST maintain
a Landmark prefix.  Perhaps this should be a SHOULD since hosts aren't
REQUIRED to send a Landmark option.

> 
> Section 6.1.5
> "   In order to respond to a Router Solicitation, the router SHOULD
>    generate a Complete RA as specified in Section 6.1.6.  The Router
>    Advertisement MUST include the LinkID, as described in Section 6.1.7."
> 
> Section 6.1.6
> "   Note that although it may not be possible to fit all of the prefixes
>    into an RA, the LinkID prefix MUST be included."
> 
> Section 6.1.9
> "      They MAY be Complete RAs or MAY include only a subset of the
>       configured prefixes, but MUST include the LinkID prefix."
> 
> Section 6.2.1
> "   Hosts MUST also maintain a "Landmark Prefix" as described in
>    Section 6.2.3."
> 
> 6. LinkID is sent in unsolicited RAs as per section 4.2  We may need to send
> LinkID in solicited RAs also in case of incomplete RAs.
> 
> From Section 4.2
> "  A second mechanism for reducing packet sizes applies to unsolicited
>    Router Advertisements. By selecting one prefix on the link to be the
>    "link identifier", and making sure that it is included in every
>    advertisement, it is possible to omit some prefixes. "
> 
> LinkID is sent is solicited RAs as per section 6.1.5
> From Section 6.1.5
> "  In order to respond to a Router Solicitation, the router SHOULD
>    generate a Complete RA as specified in Section 6.1.6.  The Router
>    Advertisement MUST include the LinkID, as described in Section 6.1.7."
> 
> 7. This is comment is raised by others also.
> Do we need two bits Y and N in Landmark Option?
> I think, one bit may serve the purpose.

See my response to Mohan.

> 8. From Section 6.1.5
> "   In order to respond to a Router Solicitation, the router SHOULD
>    generate a Complete RA as specified in Section 6.1.6.  The Router
>    Advertisement MUST include the LinkID, as described in Section 6.1.7."
> 
> For RAs with Landmark option with "Y" bit set, we may not include
> LinkId.

Yes, this exception should be noted.

> 9. Since LinkID and Landmark are optional (Section 2),
> different implementations are possible.
> Router side:-
>     a) Complete RA
>     b) Complete RA + Landmark
>     c) Complete RA + LinkID
>     d) Complete RA + Landmark + LinkID
> 
> Host side:-
>     a) Complete RA
>     b) Complete RA + Landmark
> 
> As per my understanding all the combinations of router and host
> implementations will co-work fine.
> If Landmark & LinkID are also part of the solution
> (instead of optional), these many possibilities may not be there. It may
> be easy to understand and implement.  If this is already discussed by
> design team, please ignore this comment.

As mentioned earlier, LinkID is not optional for routers (I'll fix that
text) so there are not so many combinations.  There does seem to be
interest in making Landmark support manditory.
> 
> Editorial:
> 
> 1. From Section 6.1.5,
> "   If this is not the case AND there is no multicast RA scheduled for
>    transmission in the next MulticastRADelay, then the RA MUST be sent
>    to the link-scoped *all-hosts multicast address* at the current time
>    plus MulticastRADelay."
> 
> I think, generally we use the term "all-nodes multicast address" instead
> of "all-hosts multicast address"

OK.

> 2. From Section 6.1.4
> "   Regardless of the state of the DNA flag, each PIO in the RA is
>    examined.  If the prefix is not in the router's DNARouterPrefixList
>    *or* AdvPrefixList [3], it is added to the DNARouterPrefixList, and its
>    expiry time is set."
> 
> From Section 6.1.6
> 
> "   If it is not possible to generate a Complete RA but the Router
>    Solicitation that this Router Advertisement is in response to, if
>    any, includes a Landmark Option containing a prefix that is not in
>    DNARouterPrefixList *or* AdvPrefixList then the router SHOULD include a
>    Landmark Option with the "N" flag set."
> 
> I think, "or" may need to be replaced with *and"

I think that "or" is correct as it's written, but I see what you mean.
Maybe it would be clearer if it said:

"If the prefix is not in the router's DNARouterPrefixList and not in the
router's AdvPrefixList"...

How's that?

> 3. From Section 6.2.4
> "   Hosts SHOULD include a Landmark Option (LO) in the RS message with
>    the landmark prefix chosen based on the rules in *section*
>    *Section* 6.2.3."
> 
> "section" is repeated.

OK, I'll fix it.

Thanks for your review.
Brett.