Subject: RtgDir review:draft-ietf-6man-resilient-rs-04

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 16 Feb 2015 10:08:55 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-6man-resilient-rs-04<https://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/>

Reviewer: Les Ginsberg

Review Date: February 16, 2015

IETF LC End Date: February 16, 2015

Intended Status: Standard

Summary:  This document is basically ready for publication, but has one substantive issue that would require some text changes prior to publication.

Major Issues: None

Minor Issues: I admit to not having followed the progress of this document prior to my review - but I have read the email archives and do understand that the scope of this document has been deliberately limited and there has been significant "wordsmithing" of the document to reflect the limited scope. I am therefore a bit reluctant to suggest further changes - but I thought this might be worth discussing.

The mechanism defined in this document allows a host to send RSs beyond what is defined in RFC 4861. Use of this mechanism is optional. The only MUST which this document imposes is that if a host chooses to use the mechanism defined it MUST use the backoff algorithm defined in Section 2 of this document. However, Section 2 explicitly states that a host is free to cease sending RSs whenever

"it is willing to accept that no router exists"

I therefore find the following sentence in Section 2.1 inappropriate:

"If an RA is recieved from a router and it does not result in a default route (i.e. Router Lifetime is zero) the host MUST continue retransmitting the RSs."

I think this sentence should be removed. I believe the intent of the sentence is to indicate that the reception of an RA provides positive indication that IPv6 is enabled on the interface and therefore it is useful to continue to utilize the mechanism - but the introduction of a MUST here is in contradiction to the earlier quote from Section 2 (see above). It also raises the unanswered question as to how long a host MUST continue to send RSs once it has received an RA.

Nits:

Should you decide to keep the above sentence in Section 2.1 note that "recieved" is misspelled. :-)

   Les

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 17 Feb 2015 23:39:10 -0500

Hi Les,
   Thanks a lot for your review. Please find my responses inline.

On 02/16/2015 05:09 AM, Les Ginsberg (ginsberg) wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and
> sometimes on special request. The purpose of the review is to provide
> assistance to the Routing ADs. For more information about the Routing
> Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them throug
> discussion or by updating the draft.
>
> Document: draft-ietf-6man-resilient-rs-04
> <https://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/>
>
> Reviewer: Les Ginsberg
>
> Summary:  This document is basically ready for publication, but has one
> substantive issue that would require some text changes prior to publication.
>
> Major Issues: None
>
> Minor Issues: I admit to not having followed the progress of this
> document prior to my review - but I have read the email archives and do
> understand that the scope of this document has been deliberately limited
> and there has been significant "wordsmithing" of the document to reflect
> the limited scope. I am therefore a bit reluctant to suggest further
> changes - but I thought this might be worth discussing.
>
> The mechanism defined in this document allows a host to send RSs beyond
> what is defined in RFC 4861. Use of this mechanism is optional. The only
> MUST which this document imposes is that if a host chooses to use the
> mechanism defined it MUST use the backoff algorithm defined in Section 2
> of this document. However, Section 2 explicitly states that a host is
> free to cease sending RSs whenever
>
> "If an RA is recieved from a router and it does not result in a default
> route (i.e. Router Lifetime is zero) the host MUST continue
> retransmitting the RSs."
>
> I think this sentence should be removed. I believe the intent of the
> sentence is to indicate that the reception of an RA provides positive
> indication that IPv6 is enabled on the interface and therefore it is
> useful to continue to utilize the mechanism - but the introduction of a
> MUST here is in contradiction to the earlier quote from Section 2 (see
> above). It also raises the unanswered question as to how long a host
> MUST continue to send RSs once it has received an RA.

The exception text was added to allow such hosts to turn off soliciting 
on IPv4-only links. Once an RA is received from a router (even when the 
router is not willing to the default router), it signals to the host 
that the link is not an IPv4-only link. Hence the MUST for the host to 
continue sending the RSes. Does that make sense?

> "recieved" is misspelled. :-)

Will fix. Thanks.

Regards
Suresh

---

From: James Woodyatt <[email-masked]>
Date: Wed, 18 Feb 2015 10:49:20 -0800

The inference that a link is not IPv4-only after receiving an ICMPv6 Route
Advertisement message with zero lifetime is interesting.

Here's why an interesting thing to me: on my home network, the Nest Protect
and Nest Learning Thermostats periodically send RA messages with zero
lifetime, so they can inform hosts of the ULA prefix assigned for what we
call their "fabric" (an application protocol concept).  Therefore, under
the requirement language in this draft, hosts that implement Resilient
Router Solicitation on links where Nest devices are present, which are
otherwise functionally IPv4-only, will never stop sending their RS
messages. So, the objective here— allowing hosts to turn off soliciting on
IPv4-only links— seems like it might be difficult to achieve on networks
where RA messages are only ever used for local prefix distribution and no
IPv6 default router is actually deployed.

I actually think the more problematic sentence is the first one Mr.
Ginsberg quoted, not the second one.  I don't think hosts can easily infer
that a link is IPv4-only, and the sentence that says hosts may stop sending
RS messages when "it is willing to accept that no [IPv6 default] router
exists [or will exist in the foreseeable future]" is the one that's loaded
with too much ambiguity [see my bracketed assumptions, which may be wrong].

I'm not sure what to say about this except that maybe allowing hosts to
stop sending RS messages because they have inferred that the network is
IPv4-only is an unnecessary concession to legacy deployments. Perhaps it
would be better to define a new DHCPv4 option that dual-stack hosts may use
as an explicit signal that IPv6 Resilient Router Solicitation is unwelcome
on the link.

On Tue, Feb 17, 2015 at 8:39 PM, Suresh Krishnan <
[email-masked]> wrote:

> The exception text was added to allow such hosts to turn off soliciting on
> IPv4-only links. Once an RA is received from a router (even when the router
> is not willing to the default router), it signals to the host that the link
> is not an IPv4-only link. Hence the MUST for the host to continue sending
> the RSes. Does that make sense?
>
>
>> Nits:
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 18 Feb 2015 22:14:53 +0000

Suresh -

My comment was in part motivated by my review of the WG discussion on this draft where it seemed there was a concern as regards to the bandwidth consumption these periodic RSs might consume. I thought this concern was addressed by:

  o Specifying the backoff algorithm in a sufficiently conservative manner
  o Allowing hosts to stop sending RSs whenever they chose to do so

Perhaps I misinterpreted the conclusion of that discussion?

But currently the language in the draft is at odds. It allows a host to stop sending RSs arbitrarily (first paragraph of Section 2) - but then specifies in Section 2.1 conditions under which a host is not allowed to stop sending RSs until success is achieved. If the intent is to say that a host MUST continue sending whenever it has reason to believe that the link is IPv6 enabled then the current text needs to state that less ambiguously.

   Les

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2015 8:39 PM
> To: Les Ginsberg (ginsberg); [email-masked]; draft-ietf-6man-resilient-
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: RtgDir review:draft-ietf-6man-resilient-rs-04
> 
> Hi Les,
> > Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> > Although these comments are primarily for the use of the Routing ADs,
> > it would be helpful if you could consider them along with any other
> > IETF Last Call comments that you receive, and strive to resolve them
> > throug discussion or by updating the draft.
> >
> > Summary:  This document is basically ready for publication, but has
> > one substantive issue that would require some text changes prior to
> publication.
> >
> > Major Issues: None
> >
> > document prior to my review - but I have read the email archives and
> > do understand that the scope of this document has been deliberately
> > limited and there has been significant "wordsmithing" of the document
> > to reflect the limited scope. I am therefore a bit reluctant to
> > suggest further changes - but I thought this might be worth discussing.
> >
> > The mechanism defined in this document allows a host to send RSs
> > beyond what is defined in RFC 4861. Use of this mechanism is optional.
> > The only MUST which this document imposes is that if a host chooses to
> > use the mechanism defined it MUST use the backoff algorithm defined in
> > Section 2 of this document. However, Section 2 explicitly states that
> > a host is free to cease sending RSs whenever
> >
> > "If an RA is recieved from a router and it does not result in a
> > default route (i.e. Router Lifetime is zero) the host MUST continue
> > retransmitting the RSs."
> >
> > useful to continue to utilize the mechanism - but the introduction of
> > a MUST here is in contradiction to the earlier quote from Section 2
> > (see above). It also raises the unanswered question as to how long a
> > host MUST continue to send RSs once it has received an RA.
> 
> is not willing to the default router), it signals to the host that the link is not an
> IPv4-only link. Hence the MUST for the host to continue sending the RSes.
> Does that make sense?
> 
> >
> > Nits:
> >