[RTG-DIR] RtgDir review:draft-ietf-6man-resilient-rs-04

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 16 February 2015 10:09 UTC

From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" <draft-ietf-6man-resilient-rs@tools.ietf.org>
Thread-Topic: RtgDir review:draft-ietf-6man-resilient-rs-04
Thread-Index: AdBJz78tCrJKA7UwQdqpDGt39BqknA==
Date: Mon, 16 Feb 2015 10:08:55 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F4EF24693@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F4EF24693xmbalnx02ciscoc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/RZ1GeeBuMIMxgN2IwttFU4BCc8g>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "ot@cisco.com" <ot@cisco.com>
Subject: [RTG-DIR] RtgDir review:draft-ietf-6man-resilient-rs-04
Precedence: list

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

[RTG-DIR] RtgDir review:draft-ietf-6man-resilient… Les Ginsberg (ginsberg)
Re: [RTG-DIR] RtgDir review:draft-ietf-6man-resil… Suresh Krishnan
Re: [RTG-DIR] RtgDir review:draft-ietf-6man-resil… James Woodyatt
Re: [RTG-DIR] RtgDir review:draft-ietf-6man-resil… Les Ginsberg (ginsberg)