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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, February 17, 2015 8:39 PM
> To: Les Ginsberg (ginsberg); [e-mail]; draft-ietf-6man-resilient-
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: RtgDir review:draft-ietf-6man-resilient-rs-04
> 
> 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
> >
> > 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.
> 
> 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:
> >
> > Should you decide to keep the above sentence in Section 2.1 note that
> > "recieved" is misspelled. :-)
> 
> Will fix. Thanks.
> 
> Regards
> Suresh