Subject: [DNA] Comments on DNAv6 (draft-dnadt-dna-protocol-00.txt)

From: Subba Reddy <[email-masked]>
Date: Wed, 01 Jun 2005 15:59:47 +0530

Hi,
   
   few comments and questions on the DNAv6 draft.

1. In Section 3.2

"....    In the case when the landmark prefix is unknown to the responding
   router, the host will receive a "No" answer to its landmark question,
   and also the information it needs to configure itself for the new
   link.  The routers try to include as much information as possible in
                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   such messages, so that the host can be informed of all the prefixes
   assigned to the new link as soon as possible."

but as per section 5.1.5, DNAO for learned prefixes must not be added in the unicast RAs.
i.e, we are not adding as much information as possible.

2. While bootstrapping DNA data structures(section 5.1.3), 
     a) will the router reply for RSs without landmark option (may be sent by other routers)
     b) will the router reply for RSs that contains landmark option (may be sent by DNA host)

3. While a router is in multicast sender state (during 3 seconds), will it increase the token count or will it consider the token count as MaxUnicastRABurst?

4. In section 5.2.4, 

 ".....If the unicast Router Advertisement contains a Landmark option
      that matches the Landmark Option in the last transmitted Router
      Solicitation ....."

Is a case where, a unicast router advertisement comes without landmark option is possible? (DNA routers which are bootstrapping may just send RA) If possible, some text which tells what to do in such cases may need to be added. 

5. To deal with amplification effect, what about having a threshold on number of routers sending fast RA? For example, only first 5 routers (as per the fast RA rankings) only will reply for RSs (in addition to the method specified in the draft)

Here are some typo errors
1. In section 5.1.1

"   The routers maintain a set of conceptual data structures for each
   interface to track the prefixes advertised by other routers on the
   link, and also the set of DNA routers (the routers that will quickly
   respond to RAs) on the link.  For each interface, routers maintain a
   ^^^^^^^^^^^^^^^^
   list of all prefixes advertised on the link.  The list will be
   referred to in this document as "DNAPrefixList".  For each prefix the
   router MUST store the following information:"

  I think it is either "the routers that will quickly respond with RAs" or 
"the routers that will quickly respond to RSs"

2. In section 5.1.4
"   When a router receives a Router Advertisement, it first validates the
   RA per the rules in RFC 2461, and then performs the actions specified
  ^^^^^^^^
   in RFC 2461."

"RA as per"

Thanks & Regards,
Subba Reddy

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Jun 2005 11:11:58 -0700

> few comments and questions on the DNAv6 draft.

Thanks for the comments.

> 1. In Section 3.2
> 
> "....    In the case when the landmark prefix is unknown to the
> responding router, the host will receive a "No" answer to its
> landmark question, and also the information it needs to configure
> itself for the new link.  The routers try to include as much
> information as possible in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ such
> messages, so that the host can be informed of all the prefixes 
> but as per section 5.1.5, DNAO for learned prefixes must not be added
> in the unicast RAs. i.e, we are not adding as much information as
> possible.

Well, sending DNAOs to hosts when responding yes or no to a landmark 
question doesn't actually provide the host with any (useful) 
information. In order to provide information to the host in a "no" 
landmark RA, the DNAO would have to include the prefix lifetimes and the 
flags.

> 2. While bootstrapping DNA data structures(section 5.1.3), a) will
> the router reply for RSs without landmark option (may be sent by
> other routers) b) will the router reply for RSs that contains
> landmark option (may be sent by DNA host)

I think the current text says that it will not respond at all. This is a 
bit suboptimal when multiple routers boot at the same time.
I suspect we need to figure out how to tweak this.
Suggestions?

> 3. While a router is in multicast sender state (during 3 seconds),
> will it increase the token count or will it consider the token count
> as MaxUnicastRABurst?

The token bucket gets tokens added periodically independently of whether 
its in multicast state or not, as long as the bucket isn't full (already 
at MaxUnicastRABurst)

> Is a case where, a unicast router advertisement comes without
> landmark option is possible? (DNA routers which are bootstrapping may
> just send RA) If possible, some text which tells what to do in such
> cases may need to be added.

We should probably say what to do in any case, since an existing RFC 
2461 router is free to unicast RAs (even if the RFC suggests to always 
multicast them)

> 5. To deal with amplification effect, what about having a threshold
> on number of routers sending fast RA? For example, only first 5
> routers (as per the fast RA rankings) only will reply for RSs (in
> addition to the method specified in the draft)

That might make sense.

I assume the 6+ ranked routers would not be completely quiet, but 
instead schedule a 3 second multicast RA. This is needed in the case 
that the routers annouce different prefixes, and also to make the host 
discover that it has >5 default routers.

    Erik

---

From: Greg Daley <[email-masked]>
Date: Thu, 02 Jun 2005 10:56:15 +1000

Hi Erik,

I think we should fall back to RFC2461 ND behaviour in the bootstrap and
responding router load cases.

Please see below for my reasoning.

> Subba Reddy wrote:
[cut]
> I suspect we need to figure out how to tweak this.

If we respond as if we have an RFC2461 host, then any problems
experienced will be the same as if a host has transitioned to
a network not supporting DNA (except that it will have a
link-layer hint to distinguish).

It's a short0lived transient situation though.

The additional trouble of blocking out responses can hamper
initialization after failures.  This is already well covered
for fixed hosts within 2461 and should be taken advantage of.

[cut]
> discover that it has >5 default routers.

I think that we want to not make the system worse
in the face of bogus routers.

The existing RFC2461 behaviour is to perform random delay (0-500ms),
multicast, and induce additional delay if the minimum multicast
advertisement interval has not passed.

I guess that's actually as effective as the Nth router 3 second delay,
and is robust to fake routers.

Greg

---

From: Subba Reddy <[email-masked]>
Date: Thu, 02 Jun 2005 10:13:16 +0530

Hi Erik,

Thanks for input.

Please see below...

> I suspect we need to figure out how to tweak this.

I think, it may be better to reply with normal RA (like RFC 2461) during
bootstrapping.
With this, If more than one router is bootstrapping, routers can know each
others prefixes.
It may help even the hosts to learn the prefixes of the new router fast.

> 2461 router is free to unicast RAs (even if the RFC suggests to always

Yes. It may be better to add the text for this case.

> discover that it has >5 default routers.

Yes. 6+ ranked routers need to schedule the multicast even though token
is available.

Thanks & Regards,
Subba Reddy

---

From: Greg Daley <[email-masked]>
Date: Thu, 02 Jun 2005 17:01:08 +1000

Hi Subba,

Subba Reddy wrote:
[cut]
> Yes. 6+ ranked routers need to schedule the multicast even though token

I guess it would be a host configurable threshold.

In general, I can't see a use for more than three
Fast RAs (unless there are problems with the timing
of the first three RAs - for example due to SEND
signature computation).

How about we have fastra_threshold defaulting to
FASTRA_THRESHOLD (3).

if fastra_threshold < Rank (given that Rank starts
at #0), then a Fast RA is scheduled at Rank * RASeparation.

Otherwise, the token is put back in the bucket and
a multicast RA is scheduled?

Greg

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 02 Jun 2005 13:11:45 +0530

Hi Greg,

> I guess it would be a host configurable threshold.

You mean Router configurable threshold?

> How about we have fastra_threshold defaulting to

I think 3 is good enough. And anyway we can make it configurable.

> at #0), then a Fast RA is scheduled at Rank * RASeparation.

Small correction,

 if  Rank < fastra_threshold  (given that Rank starts
 at #0), then a Fast RA is scheduled at Rank * RASeparation.

---

From: Subba Reddy <[email-masked]>
Date: Thu, 02 Jun 2005 13:14:39 +0530

Hi Greg,

Please see below.

> How about we have fastra_threshold defaulting to

I just gave 5 as an example for threshold.
As you said 3 may be ok for default value (FASTRA_THRESHOLD).

> a multicast RA is scheduled?

Yes. I think we need to put the token back in the bucket.

---

From: Greg Daley <[email-masked]>
Date: Fri, 03 Jun 2005 09:24:07 +1000

> at #0), then a Fast RA is scheduled at Rank * RASeparation.

Oops.

I'm glad you read between the lines there.

Greg