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

[Mohan.Parthasarathy@nokia.com]

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

-In section 1.2,

      Host wishes to identify if their current prefix is still valid on
      a link before the prefix expires.  Existing IPv6 Neighbour
      Discovery procedures make this difficult.  If the host can
      determine that the target router is still reachable through a
      NS/NA exchange, it does not mean that the prefix is still valid.

  Perhaps, the reason (link-local address) as to why the prefix is not
  valid can be stated here.

-In section 1.3,

      Routers should include all advertised prefixes within the same RA
      and indicate whether a previous advertised prefix is not valid
      anymore.  Multiple prefixes advertised in different RAs by a
      single router may lead to host configurations errors.

  This section discusses the Router Issues related to RFC 2461 that
  affects DNA. This parargaph is not talking about the issue but
  a solution.

- Section 1.4 looks more like applicability statement than Summary.
  It does not seem to be summarizing anything :-)

-In section 2.1,

   While IPv6 Neighbour Discovery assumes that responses to
   solicitations will be sent multicast, the specification allows any
   router to respond to RS message with a unicast RA if it desires [1].

 The phrase "if it desires" sounds odd. It should be removed.

 Also, i am assuming that the unicast response is sent subject to
 MAX_RA_DELAY constraint as specified in RFC 2461. Perhaps, this
 should be stated to make it more clear.

     Routers SHOULD respond to a RS message with unicast RS message.

  s/unicast RS message/unicast RA message/

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.

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

  Where hosts with ongoing transactions, or well known services (such
  as DNS) are present on a network, this duration SHOULD be greater
  than the maximum expected outage time (for example 9 hours for 0.999
  uptime, with a single outage/year).

What do you mean by hosts with ongoing transactions ? Do you mean
long connections ? Also is the time recommendation for valid or
preferred ?

-I don't understand how section 3.1 affects DNA. At least it is not
 obvious. Some clarifying text needed.

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

- 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 see little value for the Appendix A.

Editorial
---------
In Introduction,

   It should be noted that many already deployed routers will not
   support these recommendations, and that hosts SHOULD NOT rely on
   their being in place, unless they have particular reason to do so.

s /will not/ may not/

In Introduction,

   Several network-side factors may impact on the effectiveness and
   speed of DNA procedures.  This document provides guidelines embodying

s/on/ /

In section 1.2,

      Host wishes to identify if their current prefix is still valid on

  s/Host wishes/Hosts need/

In section 1.2,

      Discovery procedures make this difficult.  If the host can
      determine that the target router is still reachable through a
      NS/NA exchange, it does not mean that the prefix is still valid.

s /prefix is still valid/ prefix is still valid on that link/

In section 2.0,

   Routers which are being deployed to support hosts' change detection
   procedures should attempt to use appropriate configurations, which

s/to support hosts' change detection procedures/to aid


In section 2.2,

     Where hosts have changeable connectivity, there may be a number of

s/where hosts have changeable connectivity/When hosts are nomadic or
mobile,
(or something different)

-mohan