[DNA] About draft-ietf-dna-cpl-00.txt

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Dear Erik and JinHyeock, 

I've recently read through CPL, and am pleased with how it is
shaping up. 

While reading through, I noticed some minor issues which 
may need to be considered:

Section 2.1, 3rd paragraph:

"...
   This works because each and every valid global prefix on a link must
   not be used on any other link thus the sets of global prefixes on
   different links must be disjoint.
..."

Please consider adding a reference to RFC3513 here, so that people
know that there's a reason for this rule.

Section 2.2, Third paragraph:

"...
   We also assume that when a host changes its attachment point, the DNA
   module will be notified of the event using some form of 'link UP'
   event notification, and that the DNA module determine which RAs
   arrived before the event and which arrived after the event.  This
   assumption places some requirements on the host implementation, but
   does not place any assumptions on the layer 2 protocol.
..."

Please consider placing a reference (informative) to draft-ietf-dna-
link-information

Section 2.3, Third Paragraph:

"...
   If the IP stack is notified by the link layer when a new attachment
   is established (e.g., when associating to a different access point in
   802.11), this will serve as such a hint.  It helps to reduce the risk
   that the assignment of an additional prefix to a link will be
   misinterpreted as being attached to a different link.  Note that this
   hint is merely a local notification and does not require any protocol
   changes.  For instance, in many implementations this would be a
   notification passed from a link-layer device driver to the IP layer.
..."

Please note that The link-information draft describes how the 
association may
not be the best indication of link-up in 802.11 if RSN/802.11i is 
available.
A reference (informative) to draft-ietf-dna-link-information at the end 
of the
paragraph would help here.


Second Last paragraph on Page 6 (Section 2.3):

"...
   Otherwise, to make matters certain, the host may need at least to
   wait for more than the first RAs, or additionally, perform multiple
   RS/ RA exchanges after the hint.  The first level of trying harder is
   to, after the RS transmission,  wait for all RAs that would have been
   triggered by the RS.  The second level of trying harder is to send
   multiple RSs (and waiting for the resulting RAs).
..."

I think that this paragraph needs to be more direct:

Suggest:

"...
   Otherwise, to make matters certain, the host may need to attempt 
further
   procedures.  A first step to clarify link identity is to wait for 
all RAs
   which would have been sent in response to the RS.   A further step 
is to send
   multiple RSs (and wait for the resulting RAs).
..."

Third Paragraph of Page 8 (section 3.1):


"...
   To ascertain whether its existing prefix list is complete or not, the
   host can set its own policy.  The host may take into consideration
   the packet loss rate of the link and the number of RAs it received or
   should have received from each router while it was attached to the
   link.  Per [1] each router should multicast a RA at least every 1800
   seconds.  Furthermore, [5] defines a Advertisement Interval option,
   which the host can use to determine how often it should receive RAs.
..."

the packet loss rate for a link which has never been visited is unknown.

s/the packet loss rate/the estimated packet loss rate/


Fourth Paragraph of Page 8 (section 3.1):

s/For example, the host may keep track of how RAs it has received from/
For example, the host may keep track of how many RAs it has received 
from/


Section 3.3 paragraph 1:

"...
   When a host receives a hint that indicates a possible link change, it
   initiates DNA procedure to determine whether it still remains at the
   same link or not.  At this time, the complete prefix generation may
   or may not be finished.
..."

I think that the complete prefix _list_ is to be generated.

s/complete prefix generation/complete prefix list generation/

Section 3.3 paragraph 2:  

"...
   First, if the host has finished the complete prefix list generation
   and can be reasonably sure of its completeness, the receipt of a
   single RA (with at least one valid prefix) is enough to detect the
   identify of the currently attached link.
..." 

Two uses of the word complete(ness) in the same sentence.

s/identify/identity/


Suggest:

"...
   First, if the host has finished prefix list generation
   and can be reasonably sure of its completeness, the receipt of a
   single RA (with at least one valid prefix) is enough to detect the
   identity of the currently attached link.
..."

Section 4.4:

After the last paragraph, it is not clear if the link-layer
indications reset the number of router solicitations for
MAX_RTR_SOLICITATIONS comparison.

I'd consider adding the following paragraph.

"...
 
   Note that if link-layer indications are reliable, a host can
   reset the number of sent Router Solicitations to 0, while still
   maintaining RTR_SOLICITATION_INTERVAL between RSs.

..."

Page 15 Paragraph 2, Section 4.5:


"...
   Otherwise, if the received RA contains one or more prefixes which is
   part of the prefix list in some retained Candidate Link object, then
   the host has most likely moved back to that link.  In this case the
   host will retain the content of the CCL for future matching, but
   switch the CCL to be that matching object.  The, now new, CCL should
   be updated based on the information in the RA.  Then the DNA module
   informs the Neighbor Discovery module to replace the old information
   with the information in the new CCL as specified in Section 4.6.
..."

s/prefixes which is/prefixes which are/

(since is now a multiple, and non specific)
s/part of the existing prefix list/part of an existing prefix list/
 
 (retaining the CCL is a caching operation, should be optional:)
s/the host will retain the content/the host may retain the content/


Page 15 Paragraph 2, Section 4.5:

"...
   It is possible that the above comparison will result in matching
   multiple Candidate Link objects.  For example, if the RA contains the
   prefixes P1 and P2, and there is one Candidate Link object with P1
   and P3 and other Candidate Link object with P2 and P4.  This should
   not happen during normal operation, but if links have been renumbered
   or physically separate links have been made into one link (before the
   lifetimes in the Candidate Link objects expired), then the host could
   observe this.  The most sensible action would be for the host to
   merge all such matching Candidate Link objects together with the
   information in the receive RA and make this the new CCL.  Doing this
   merging correctly probably requires that each Candidate Link object
   contains the time it was last updated by a RA, so that more recent
   information can override older information.  Note that this case is
   one reason one needs to be concerned about security issues when
   Candidate Link objects are shared across multiple interfaces
..."

* "The most sensible action would be for " is actually debatable, since
  this may lead to false detection in the case that existing CCLs hold
  out-of-date information (if a no-longer present prefix is retained).

s/The most sensible action would be for/One possible action would be 
for/

* If strict ordering for CCL is required, then that reduces the risk of 
  false information being added to the CCL, so we can remove probably:

s/merging correctly probably requires/merging correctly requires/


* There's a sentence at the bottom of the paragraph:
  "Note that this case is one reason ...multiple interfaces"

This is inappropriate given the location, and the fact that sharing
between interfaces has already been prohibited due to security
reasons (which override the later consideration).  The sentence
should be deleted to ensure that people don't get distracted
from the main content.


Page 15 Paragraph 4+5, Section 4.5:

"...
   The easy cases of staying on the same link or moving to a previously
   visited link have been handled above.  The harder case is when the
   first RA after a link UP notification contains prefixes that are new
   to the host.  In this case it isn't obvious whether the host has
   moved or not, because a new prefix could have been added to the
   existing link instead of being associated with a different link.  In
   order to distinguish those to cases the host needs to do some extra
   work.  The host handles this by creating a new Candidate Link object
   which it initializes with the information in the received RA, and
   makes this object the CCL.  However, it does not yet treat this as a
   new link; it is merely a candidate.  Thus it MUST NOT perform the
   actions in Section 4.6.

   Then the host waits for more RA messages.  At a minimum it waits for
   4 seconds, that is, it starts a timer and RAs that are received
   during that time interval are processed as specified above.  This
   processing might result in finding a prefix in common between a
   Candidate Link object and the CCL, in which case the host knows
   whether and to which link it has moved.  But should the 4 seconds
   expire without any common prefix, then it will conclude that it has
   moved to a new link and inform the rest of the host of the movement
   (Section 4.6.)  Note that the arrival of a new link UP notification
   during the 4 second timer must prevent the timer from firing.  In
   this case the host might yet again have moved so it is necessary to
   restart the process of inspecting the RAs.
   
..."

  The first paragraph is incorrect since it forgets (or misstates) when 
the
  CCL is complete that any received RA should be treated as from a
  separate link if there are no prefixes in common with the CCL.

  Suggested Text (including paragraph boundary movement):

"...
   When the first RA afte a link UP notification contains prefixes 
which 
   are disjoint from those in the CCL, it may not be immediately obvious
   whether the host has moved or not.   Where the CCL is believed to be
   complete, though, any advertisement which arrives that does not 
contain
   common prefixes with the CCL can be assumed to be a link change in 
   accordance with section 4.6.  Otherwise, the host needs to create a
   new CCL with the new router's advertisement.  This CCL should not
   yet be treated  as if it belongs to a new link though, and the
   operations defined in 4.6 should not yet occur.  Instead, the host
   waits a minimum it waits for 4 seconds, and RAs that are received 
during
   that time interval are processed as specified above.

   This processing might result in finding a prefix in common between a
   Candidate Link object and the CCL, in which case the host knows
   whether and to which link it has moved.  But should the 4 seconds
   expire without any common prefix, then it will conclude that it has
   moved to a new link and inform the rest of the host of the movement
   (Section 4.6.)  Note that the arrival of a new link UP notification
   during the 4 second timer must prevent the timer from firing.  In
   this case the host might yet again have moved so it is necessary to
   restart the process of inspecting the RAs.
..."

   
Page 16 Last paragrpah of section 4.5:


"...
   Subject to local policy, and perhaps also the host's knowledge of the
   packet loss characteristics of the interface or type of L2
   technology, the host can try harder than just waiting for 4 seconds.
   It is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS
   messages spaced RTR_SOLICITATION_INTERVAL apart.  In the most
   conservative approach this means a 12 second delay until the host
   will declare that is has moved to a new link.  Just as above, this
   process should be terminated should a new link UP notification arrive
   during the 12 seconds.
..."

   This text needs to be made more direct:

s/can try harder than just waiting for 4 seconds./can send Router 
Solicitations in
order to gather information./

Section 5, paragraph 7.

s/examplified/exemplified/

Section 11:

Open issues.  

We can discuss these on-list, and attempt to resolve them.


All in all though, it looks OK.

Greg