Subject: Re: [DNA] comments on draft-ietf-dna-routers-01.txt

From: Nicolas Montavont <[email-masked]>
Date: Wed, 08 Feb 2006 11:22:17 +0100

Dear Mohan,

Thank you very much for you review.
The modified version of the draft can be found at

http://jules.nautilus6.org/~montavont/draft-ietf-dna-routers-01.txt

I have some questions, please see below (I removed the comments in this 
response for which we modified the draft)

[email-masked] wrote:

 >Hi,
 >
 >I reviewed the draft-ietf-dna-routers-01.txt. I did not find any
 >major issues. Just a few technical comments/questions and Editorials.
 >
 >Technical
 >---------
 >
...

 >The stated disadvantage for unicast RA is that the router will not
 >be able to aggregate its response from multiple hosts. But there
 >is also the rate of unicast RAs and number of unicast RAs when there
 >are lot of routers on the link. This is taken care of by the
 >recommendation in section 3.2 by limiting to 3 routers per link
 >though the rate is still left open. Perhaps, worth adding something.
 >
The fact that routers on a link respond with either unicast or multicast 
RA to RS does not change the number of RAs that are sent on the link, if 
there are multiple routers. So I don't see why this is a dis-advantage 
of using unicast RA. Am I missing something?

 >
 >-In section 2.2,
 >
 >  Where hosts have changeable connectivity, there may be a number of
 >  prefixes or routers stored in the host's memory, which are no longer
 >  directly reachable.  This additional storage may make movement
 >  detection slower where hosts rapidly pass through networks, or pass
 >  through networks which have very long advertised timeouts.
 >
 >I read it a few times. But can't guess why it is here in this section ?
 >
This is to introduce a context where routers advertising valid and 
preferred lifetimes is usefull. It is particularly needed when hosts are 
highly mobile and frequently change IPv6 links. It allows for the hosts 
to keep up-to-date information.

 >
 >-In section 3.2,
 >
 >     If using advertising intervals lower than those specified in IPv6
 >     Neighbour Discovery, only one router MAY advertise at the elevated
 >     rate.
 >
 >  Not sure i understand this. We are already allowing 3 routers on
 >  a link and also unicast RA in response to RS. Why do we need this
 >  additional thing ? I can see it is a MAY..hmm..
 >
This is to reduce the bandwidth consumed by RA. Reducing the frequency 
of one router is enough for rapid link detection. Do you think we need 
to add an explanation?

 >
 >- In section 4.1,
 >
 >     Where a Router Advertisement is sent by a router, it SHOULD contain
 >     sufficient information to prove that the router is on the same link
 >     as previously seen advertisers, or is indeed the same router.  This
 >     may prevent expensive checks by hosts which will not need to
 >     immediately test the authenticity of the router through signature
 >     verification, or additional transmissions.
 >
 >  So, we recommend SEND (just below) and we say that we want other
 >  insecure ways to detect routers faster. Not sure i understand what
 >  the intent of this paragraph is.
 >
 >     As described in section Section 3.2,  advertising common prefixes
 >     achieves this goal.
 >
 >  This should be combined with the previous paragraph i guess.
 >
 >     Routers supporting DNA SHOULD provide secured router discovery
 >     services using SEND [4].
 >
 >  The use of word "DNA" here (and perhaps other places) is confusing.
 >  The intent here is to say "Routers supporting the recommendations
 >  in this draft ...".  Also, note that draft-ietf-dna-hosts does not
 >  recommend using SEND though it says one should prefer secured ones
 >  to unsecured. Note that the recommendations made here are to improve
 >  the 2461 behaviour for DNA. Even 2461bis does not recommend SEND.
 >  So, SEND here seems a bit too much..
 >
I removed some sentences. Please check if it is fine now.

 >
 >- I see little value for the Appendix A.
 >

Do you think we should ask the WG to remove this appendix?

Thanks again for your review.

Nicolas