Re: [DNA] IMPORTANT: Combined DNA Solution draft

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

Hi Mohan,

Thanks for reviewing the draft.  I'll try to respond to your'
comments in-line:

Mohan.Parthasarathy@nokia.com wrote:
> Hi,
> 
> Here are some comments and questions on the draft. This comes
> from someone who has read the archives from time to time but
> never been involved in the discussion here. Sorry if some
> of them have been discussed/answered before.
> 
> The draft size was mere 26 pages and i thought this should
> be an easy read. The draft is well written but the first
> impression was that it had too many options.
> 
> 	- Landmark Option
> 	- Complete RA
> 	- link-ID
> 	- Fast RA, rate control,ranking
> 	- Learned Prefix Option
> 
> It is not clear as to why you would need both Complete RA and link-ID ?
> Link-ID is present in multicast RA (6.1.9) and also in unicast RA
> (6.1.5).
> 
> 	- Section 6.1.9 says "MAY" for complete RA when scheduling
> 	  unsolicited RA. So, one can avoid implementing complete RA if
>        not for unicast part ? (which also means that you don't need
>        LPO because LPO itself is used only by routers (hosts don't
>        care where the prefixes appear i guess) to form a complete RA.

Hosts need to understand the LPO in order to extract the prefixes from
it.  Regarding "if not for the unicast part", I think the unicast part
is the most important part.  Multicast RAs need to be separated by
MIN_DELAY_BETWEEN_RAS, so if a router has just sent an RA, it is then
unable to respond immediately to RSes for some time.

"LinkID" is perhaps a poor term for this draft since it is unused by
hosts and so may be misleading.  In a side conversation, Syam
suggested perhaps "Common Prefix".
> 
> 	- Section 6.1.5 says SHOULD for generating a complete RA. We
> 	  have Landmark option and link-ID. Why is this a SHOULD here ?

Sending a complete RA means that the host immediately has the complete
set of prefixes in use on the link.  This means that if the host then
subsequently moves to a link that has no DNA routers, it is prepared to
use CPL logic to make a correct movement decision based on the first RA
it receives.

> 
> Some specific comments..
> 
> - Section 4.1
> 
>     The protocol handles this quite well during graceful renumbering 
>    (when the valid lifetime of the prefix is allowed to decrease to
>     zero before it is removed and perhaps reassigned to a different
>     link), however, it can also cope with "flash" renumbering and
>     reassignment but not in an optimized fashion.
> 
>   Is section 6.1.10 talking about "flash" renumbering ? Because this
>   term is used here (without prior definition) and i could not find
>   out whether the discussion in section 6.1.10 pertains to this ?

OK.  I need to define that, and perhaps refine the text in 4.1 a liitle.
6.1.10 and 6.1.11 describe what needs to be done when renumbering and
reassigning respectively, in order to not cause any incorrect decisions
to be made.  If these are ignored then there may be some incorrect
movement decisions made, but within 90 minutes things will be restored
to the point where all is well again.
> 
> - section 5.1
> 
> 	Complete (C)
> 
>       The Complete (C) bit indicates that the Router Advertisement
>       contains PIOs for all prefixes explicitly configured on the
>       sending router, and, if other routers on the link are advertising
>       additional prefixes, a Learned Prefix Option containing all
>       additional prefixes that the router has heard from other routers
>       on the link.
> 
>   The definition only requires that if "C" is set, that
>   the RA contains "additional" prefixes than what is configured on
>   the router. Section 6.1.6 says "C" flag can be set when it includes
>   all the leanred prefix in the LPO option. Section 6.1.3 talks about
>   bootstrap where "DNA" options are omitted. There is no guidance on
>   when the router can start setting the "C" bit. Can it set if it has
>   learned at least one other prefix that is not configured on itself ?
>   Can it set the "C" bit if all the routers have been configured with
>   the same prefix ? (i guess no for this as per the definition).

Good point.  6.1.3 should say that the C flag MUST NOT be set during
bootstrap.  6.1.6 should also state that the C flag MUST NOT be set
if there are known to be prefixes that are not included in the RA.
> 
>   A related nit i have is that "Complete" is "Almost complete" because
>   you may never know for *sure* when it is really complete i guess :-)

The intent was "Complete to the best my knowledge" and only asserted
when the router is in a reasonable position to have that knowledge (i.e.
not during bootstrap).

> 
> 5.2  Landmark Option
> 
>   Do we really need two bits "Y" and "N" ? or just one bit that can
>   be set to 1 or 0 ? 

No, probably not.  It is useful to have an explicit "NO" for when a
complete RA is not possible, but I guess a single flag can still do
that.  We would need to explain that the flag has no meaning when the
option is in an RS.

> 5.3 Learned Prefix Option
> 
>     It is not clear to me whether a host itself cares whether a prefix
>     appears in PIO or LPO. Routers care about it to create
>     DNARouterPrefix list. Hosts do look at both (section 6.2.5) but
>     do they care ? This is more of a clarification.

 From a DNA perspective, hosts don't care - I should make this explicit.
Prefixes in an LPO can't be used for SAA, however.

> 6.1.1 Data structures
> 
> 	The list will be referred to in this
>      document as "DNARouterPrefixList".  Prefixes are learned by their
>      reception within Prefix Information Options [3] in Router
>      Advertisements.  Prefixes in Learned Prefix Options (see Section
> 5.3)
>      MUST NOT update the contents of DNARouterPrefixList
> 
>   Why is there a "MUST NOT" ? I understand that the LPO itself may
>   contain the prefixes of the router processing the RA from a different
>   router. But so does the PIO. As DNARouterPrefixList contains just
>   the prefixes not configured on this router, you need to filter both
>   from PIO and LPO, right ?

This is to make sure that when an administrator pulls a prefix out, that
it will in fact go away, and not just kept being readvertised by the
other routers on the link.  Basically we only want prefixes to be
learned by routers from routers where the prefix has been explicitly
configured.

> 6.1.2
> 
> 	MulticastRADelay
> 
>       The delay to be introduced when scheduling a multicast RA in
>       response to a RS message when the token bucket is empty.
> 
>    You also schedule a multicast RA when the RS comes in with
> unspecified
>    address, not just when the token bucket is empty i guess.

Yes, but that doesn't necessarily have to be delayed.  This delay is
there because if the token bucket is empty, a burst of RSes is
underway and it is likely that there are more to come, and so by
delaying, the multicast RA will answer all of those in one go.
> 
> 6.1.5
> 
>    If a unicast send token is available AND the source address of the
>    Router Solicitation is NOT the unspecified address (::), then a token
>    is removed and the Router Advertisement is scheduled for transmission
>    as specified in Section 6.1.8.
> 
>    If this is not the case AND there is no multicast RA scheduled for
> 
> "If this is not the case" means either the token is not available or
> the RS has unspecified address i guess. Perhaps, need better wording
> here.

OK.

>    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.
> 
>    If neither of these conditions is true and there is already a
> 
> Also, here, what does "neither of these" refer to ?

The conditions in the two paragraphs above.  It sounds like this
needs to be made explicit as well.  I'll do that.
> 
>    multicast RA scheduled for transmission in the next MulticastRADelay,
>    then the Router Solicitation MUST be dropped.
>     
> Section 6.2.5
> 
> 	 If the RA includes any prefixes in either a PIO or LPO then the
>       host can conclude that no link change has occurred and current
>       configuration can be assumed to still be current.
> 
>       should read
> 
>       "If the RA includes any prefixes in either a PIO or
>       LPO that matches the prefix in DNAHostPrefixList, then..."

Correct.  I'll fix that up.

> Section 7.0
> 
> 	 why isn't there a discussion about DNA Router and non-DNA
>       router coexisting ? Non-DNA routers behave as though the
>       DNA routers don't exist or they still process the messages
>       as per rfc 2461. I can't see how it can cause problems,
>       but something should be said here i guess..

Yes, good point.  I also don't see any problems with that, but it's
worth mentioning.

> 
> section 8.1
> 
> 	With N routers on a link, each RS message sent on the link will
> have
>      N RA responses sent on the link within (N-1) * RASeparation time.
>      The rate control mechanism specified by this memo only controls the
>      rate of RA messages generated by each of the routers
> 
>   Section 6.1.8 talks about scheduling Fast RAs. FastRAThreshold
> (defined
>   to be 3) controls how many routers send unicast/Fast RA. And
>   rest of the RA are multicast. Though the token bucket controls the
>   individual router, doesn't FastRAThreshold control how many routers
>   respond ? Even if there is a non-DNA router, it is controlled by
>   multicast RA as per RFC 2461. What am i missing i.e how does this
>   specification alter anything that is specified in rfc 2461 ?

Yes, you're right.  This was text from a version before that
FastRAThreshold was put in.

Thanks again for the detailed review.
Brett.