[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Comments on Combined DNA Solution draft
Hi Brett,
> > 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.
ok
>
> > 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)
If the prefix P1 is learned prefix for R1, then it will advertise P1 in LPO.
Host (H) will not be receiving life time in the RA sent by R1. If H has not
received
any RA with P1 in PIO within 15 seconds, it will not delete P1 from
DNAHostPrefixList for the next 1.5 hours.
> >
> > 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.
>
ok
> >
> > 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?
ok.
>
> >
> > 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.
ok.
>
> >
> > 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.
ok
>
> > 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.
ok
> >
> > 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?
This is fine.
Thanks & Regards,
Subba Reddy