RE: [DNA] IMPORTANT: Combined DNA Solution draft

[Mohan.Parthasarathy@nokia.com]

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: owner-dna@ecselists.eng.monash.edu.au 
>[mailto:owner-dna@ecselists.eng.monash.edu.au] 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
>