Neighbor Unreachability Detection Is Too Impatient
draft-ietf-6man-impatient-nud-07

[Ballot comment]
I support the comments from other ADs about precision in language. I
think you would be well advised to tighten the specification.

---

The proposed new state machine entry is:

  PROBE          Retransmit timeout,    Increase timeout  UNREACHABLE
                  N or more              Send multicast NS
                  retransmissions.

How is it possible for the event of "more than N retransmissions" to
happen in PROBE state? You probably need:

  PROBE          Retransmit timeout,    Increase timeout  UNREACHABLE
                  Nth retransmission      Send multicast NS

---

Although you have retained the garbage collection from 4861, you say:

  A node MAY garbage collect a Neighbor Cache Entry at any time as
  specified in RFC 4861.  This does not change with the introduction of
  the UNREACHABLE state in the conceptual model.

I would have thought that the garbage collection LRU scheme should
consider a trade between LRU and UNREACHABLE state? Which would you
discard: not used for 29 seconds or unreachable and not used for 28
seconds? Or is this too much fine-tuning?

[Ballot comment]
I found the chatty style at odds with the demands of a precise definition of the operation of a state machine.

Please can you look at the following:

"Giving up after three packets spaced one second apart..."

You need to say what you are "giving up", but in any case I am not sure "giving up" is the right term.

+++

"from implementations that try for a long time"
Try what?

+++

"link-layer address of the destination has changed"

Isn't that the LL addr of the neighbor?

+++

"we will instead transition"

I imagine the node will rather than the authors

+++

"then it makes sense to stop.."

Don't you mean: "it is RECOMMENDED"

+++

"but it MUST switch to multicast Neighbor Solicitations sooner or later."

Do you really mean "when it can be bothered" which is what the statement says?


====

A few nits that might usefully be addressed if you are re-spinning the draft:

"If implementations" I think that should be "If an implementation"

[Ballot comment]
I'm just short of a DISCUSS on this because there was no response to the appsdir review, which did raise a couple of minor things apart from the many editorial comments in it.  I know that Erik isn't happy with the level of editorial commenting in the directorate reviews, but we have to accept that thorough reviewers feel the need to do that.

Please do address Murray's comments (and my reply to it) that go beyond mere editorial stuff.

-- Section 3 --
  A node MAY unicast the first few Neighbor Solicitation messages even
  while in UNREACHABLE state, but it MUST switch to multicast Neighbor
  Solicitations sooner or later.

This was brought up in the appsdir review: "first few" and "sooner or later" are sufficiently inspecific that it calls the need for a 2119 MUST into question.  How is the operation of the protocol affected if the node interprets "first few" to be 3?  How about 12?  What about 3,141,592?  Is it OK if I decide that "sooner or later" amounts to "just before the Rapture"?

It would probably better here to say what the problem is that the switch to multicast will address, and it's most likely better to skip the 2119 words on that.  Something on the order of this:

  A node can unicast the first few Neighbor Solicitation messages even
  while in UNREACHABLE state, but [this bad stuff will happen] until it
  switches to multicast Neighbor Solicitations.


Other comments; no need to respond to these. Take them or modify them
as you please:

-- Section 1 --

nit: "These short can be" -> "These short timeouts can be"

The last sentence of the first paragraph is punctuated oddly, and I'm not quite sure what it really means:

  In these cases, when NUD fails,
  the host will try the alternative neighbor; the next router in the
  Default Router List, or discard the NCE which will also send using a
  different router.

Is the semicolon just wrong, and there are meant to be three items in the list of what can happen when NUD fails?  If so:

NEW
  In these cases, when NUD fails
  the host will try the alternative neighbor, try the next router in
  the Default Router List, or discard the NCE which will also send
  using a different router.

(You need to repeat the verb "try" because the third item in the list has a different verb.)

Still on that sentence, what does the last item mean?:

  discard the NCE which will also send using a different router.

It looks like this is saying that the third option is to discard the NCE, and a result of that will be a switch to a different router.  Is that right?  If so, re-wording a little will help; "will send using a different router" makes me think that there's some noun missing after "send".  Maybe, "discard the NCE (which also results in the use of a different router)."

-- Section 3 --

  Packets should be sent
  following the next-hop selection algorithm in section 5.2 in
  [RFC4861] which disregards NCEs that are not reachable.

There's nothing at all wrong with this, but I want to note that if you write it this way:

...algorithm in [RFC4861], Section 5.2, which...

then the tool that converts the RFCs to HTML will generate a link to the correct section directly.  Otherwise, the link will just go to the top of 4861.

[Ballot comment]
I like this document. It's short and clear. I do have one comment I'm hoping you'll consider.

In this text: 4.  Example Algorithm

  This section is NOT normative, but specifies a simple implementation
  which conforms with this document.

I'm seeing the "NOT normative" statement, which is fine, but I'm also seeing several occurrences of "recommended" in the following paragraphs. I'm not confused by the use of "recommended" in lower case. My issue is that I'm not sure where the recommendation is coming from - whether it's in the context of this example algorithm, or from somewhere else.

If I'm guessing right, and the context is this example algorithm, would it be easier to understand if you replace "recommended behavior" with something like "behavior used by this implementation"?

  The recommended behavior is to have 5 attempts, with timing spacing
  of 0 (initial request), 1 second later, 3 seconds after the first
  retransmission, then 9, then 27, and switch to UNREACHABLE after the
  first three transmissions.  Thus relative to the time of the first
  transmissions the retransmissions would occur at 1 second, 4 seconds,
  13 seconds, and finally 40 seconds.  At 4 seconds from the first
  transmission the NCE would be marked UNREACHABLE.  That recommended
  behavior corresponds to:

      MAX_UNICAST_SOLICIT=5

      RETRANS_TIMER=1 (default)

      MAX_RETRANS_TIMER=60

      BACKOFF_MULTIPLE=3

      MARK_UNREACHABLE=3

  After 3 retransmissions the implementation would mark the NCE
  UNREACHABLE.  That results in trying an alternative neighbor, such as
  another default router or ignoring a redirect as specified in
  [RFC4861].  With the above recommended values that would occur after
  4 seconds after the first transmission compared to the 2 seconds
  using the fixed scheme in [RFC4861].  That additional delay is small
  compared to the default 30,000 milliseconds ReachableTime.

  After 5 transmissions, i.e., 40 seconds after the initial
  transmission, the recommended behavior is to switch to multicast NUD
  probes.  In the language of the state machine in [RFC4861] that
  corresponds to the action "Discard entry".  Thus any attempts to send
  future packets would result in sending multicast NS packets.  An
  implementation MAY retain the backoff value as it switches to
  multicast NUD probes.  The potential downside of deferring switching
  to multicast is that it would take longer for NUD to handle a change
  in a link-layer address i.e., the case when a host or a router
  changes their link-layer address while keeping the same IPv6 address.
  However, [RFC4861] says that a node MAY send unsolicited NS to handle
  that case, which is rather infrequent in operational networks.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-impatient-nud-06, which is currently
in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Neighbor Unreachability Detection is too impatient) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Neighbor Unreachability Detection is too impatient'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-05-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.
  That function is very useful when a host has an alternative neighbor,
  for instance when there are multiple default routers, since it allows
  the host to switch to the alternative neighbor in short time.  This
  time is 3 seconds after the node starts probing by default.  However,
  if there are no alternative neighbors, this is far too impatient.
  This document specifies relaxed rules for Neighbor Discovery
  retransmissions that allow an implementation to choose different
  timeout behavior based on whether or not there are alternative
  neighbors.  This document updates RFC 4861.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud/ballot/


No IPR declarations have been submitted directly on this I-D.