Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-impatient-nud-02.txt>

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Oct 2012 16:06:32 -0700

Hemant,
Thanks for your comments.

On 9/9/12 2:43 PM, Hemant Singh (shemant) wrote:
> I support this document - it's important work and the document is really close to ship to the IESG.
>
> I thought this document should be on Standards Track but the document does not say anything about the Intended Status of the document.  Please fix that so that document includes Intended Status.  Additionally, if the document is on Standards Track, do we have at least one implementation of the protocol changes covered in the document?  Or the protocol changes are deemed minor and one does not need at least one implementation?

Fixed.

> Comments included below.
>
> COMMENTS:
>
> 1.  In the first paragraph of the Protocol Update section, please replace "route" by "router".  At least all of RFC 4861 works with a default router not a default route.

Fixed.

> 2. I think the following text in the Protocol Update section can be removed because the text is redundant with RFC 4861.
>
> [The UNREACHABLE state is conceptual and not a required part of this
> specification.  A node merely needs to satisfy the externally
> observable behavior of this specification.]

I instead expanded on it to say that this is consistent with the 4861 - 
I wanted to keep the statement in there to make it clear that this 
expansion with an additional state might not be that cumbersome since it 
depends on the implementation.

I've also taken care of the editorial comments below. All included in 
-04 of the draft.

Thanks again,
    Erik

>
> Editorial comments:
>
> 1. In the first paragraph of the Introduction section, please add a space between the two words shown below.
>
> [reachable.The].
>
> 2. In the Protocol Update section, change
>
> "Cache Entry as any time"
>
> to
>
> "Cache Entry at any time"
>
> In the same section change
>
> "no IPv6 packets"
>
> To
>
> "no IPv6 packet"
>
>
> 3. In the Example Algorithm section, do we need to change
>
> "An Implementation"
>
> to
>
> "An implementation"?
>
>
> 4. In the Security Considerations section, "belived" is misspelled.
>
> Regards,
>
> Hemant
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Tuesday, September 04, 2012 1:28 PM
> To: [email-masked] Mailing List
> Cc: Bob Hinden
> Subject: 6MAN WG Last Call: <draft-ietf-6man-impatient-nud-02.txt>
>
> All,
>
> This message starts a two week 6MAN Working Group on advancing:
>
> 	Title           : Neighbor Unreachability Detection is too impatient
> 	Author(s)       : Erik Nordmark
>                            Igor Gashinsky
> 	Filename        : draft-ietf-6man-impatient-nud-02.txt
> 	Pages           : 8
> 	Date            : 2012-07-31
>
>          http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02
>
> as Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on September 18, 2012.
>
> Regards,
> Ole Troan & Bob Hinden
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Oct 2012 16:44:46 -0700

Tina,

Thank you for your comments.

>>> Hi Erik and Igor,
>>>
>>> The draft is well explained in regards to the case when there is no alternative default router in the lest of default routers.
>>>
>>> I wanted some clarification in the content below:
>>>
>>> In the draft,
>>> The recommended behavior is to have 5 attempts, with timing spacing
>>>   of 0 (initial request), 1 second later, 3 seconds later, then 9, and
>>>   then 27, and switch to UNREACHABLE after 3 transmissions, which
>>>   represents:-------after the initial request, we transmit a packet after 1 sec, then another after 3 seconds, then another after 9 seconds and finally after 27 secs right?

The times in the example are relatively to the previous 
(re)transmission. I've expanded the example to also show the cumulative 
time since the first transmission. As part of doing that I also 
formalized the cap on the exponential backoff (suggested in the text as 
60 seconds) by introducing a MAX_RETRANS_TIMER.

Your questions below indicate to me that the text is confused since in 
some places we say that we switch to multicast and mark UNREACHABLE at 
the same time. But the example was intended to show a case when those 
occur at different times.

>>>      MAX_UNICAST_SOLICIT=5----This would imply 5 attempts?

Yes, 5 unicasts.

>>>      RETRANS_TIMER=1 (default)
>>>
>>>      BACKOFF_MULTIPLE=3
>>>
>>>      MARK_UNREACHABLE=3------Do we mark it unreachable after 9 secs OR 4 secs 0r 27 secs?

After 1 transmission plus 2 retransmissions. With the recommended timer 
and backoff values that occurs at 4 seconds since the initial transmission.

>>> After marking unreachable, multicast NS will be send instead of Unicast NS right?

The (non-normative) example is slightly more sophisticated in that it 
first marks as unreachable and later switches to multicast. That allows 
for more quickly switching to an alternate (e.g., in a case with 
multiple default routers), while reducing the impact of multicast packets.
The downside of this is that it takes longer to detect a node (host or 
router) which keeps its IPv6 address while changing its MAC address.

>>> Since there will be 5 attempts, would it imply it will wait 27 seconds before declaring it unreachable?

No, in the example (which was confusing and contradictory) it was 
supposed to be after 4 seconds, while discarding the NCE (implicitly 
switching to multicast NS) after 40 seconds after the initial transmission.

I think I finally got this right in version 05 that I just posted.
I'd appreciate if you can look it over for clarity on these matters.

Thanks,
    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 23 Oct 2012 11:06:53 +0000

Erik,

Your responses and closure sounds good to me.  The document looks good to send to the IESG.

Thanks,

Hemant

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Monday, October 22, 2012 7:07 PM
To: Hemant Singh (shemant)
Cc: Bob Hinden; [email-masked] Mailing List
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-impatient-nud-02.txt>

Hemant,

Fixed.

Fixed.

Thanks again,
    Erik