Subject: RE: [DNA] IMPORTANT: Combined DNA Solution draft

From: [email-masked]
Date: Fri, 04 Nov 2005 12:52:05 -0800

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.

	- Section 6.1.5 says SHOULD for generating a complete RA. We
	  have Landmark option and link-ID. Why is this a SHOULD here ?

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 ?

- 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).

  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 :-)

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 ? 

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.

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 ?

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.

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.

   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 ?

   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..."

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..

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 ?

-mohan

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>ext Suresh Krishnan
>Sent: Monday, October 31, 2005 9:08 AM
>To: Dna
>Subject: [DNA] IMPORTANT: Combined DNA Solution draft
>
>Hi Folks,
>   At the last dna WG meeting at IETF63 in Paris, the WG could 
>not achieve consensus on picking one of the two competing DNA 
>solution proposals. The proposals were described in
>
>*) draft-pentland-dna-protocol-00 : using Landmarks and Complete RA
>*) draft-jinchoi-dna-protocol2-00 : using Link ID
>
>The WG, however, achieved consensus that the proposals were 
>similar enough that the ideas from both the proposals could be 
>merged into a single combined solution which would combine the 
>positive aspects of both of the original proposals. The 
>authors of the above mentioned proposals have worked hard 
>together behind the scenes and have come up with a combined 
>solution. Thanks to Brett for volunteering to put together the 
>document and to the original authors for resolving their 
>differences. The combined solution has been submitted and is 
>available at
>
>http://www.ietf.org/internet-drafts/draft-pentland-dna-protocol3-00.txt
>
>Please take some time to read the document before the meeting 
>as we would like to call for consensus during the dna meeting 
>in Vancouver. 
>Direct any issues and/or comments to the mailing list. As 
>usual, if you think the draft is perfect and ready to go, 
>please say so explicitly as well.
>
>Thanks
>Suresh & Greg
>

---

From: Brett Pentland <[email-masked]>
Date: Mon, 07 Nov 2005 07:39:17 +1100

Hi Mohan,

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

>        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".
> 	  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.

>   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.
>   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.
>   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).

>   Do we really need two bits "Y" and "N" ? or just one bit that can

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.

>     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.

>   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.

>    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.
> the RS has unspecified address i guess. Perhaps, need better wording

OK.

> 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.
>       LPO that matches the prefix in DNAHostPrefixList, then..."

Correct.  I'll fix that up.

>       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.

>   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.