Re: [Gen-art] Gen-ART Last Call review of draft-ietf-6man-resilient-rs-04

[Suresh Krishnan <[e-mail]>]

Hi Brian,
   Thanks for the review. Ole, thanks for the quick followup. Please 
find comments inline.

On 02/07/2015 05:49 AM, Ole Troan wrote:
> Brian,
>
> thank you very much for the review.
>
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-6man-resilient-rs-04.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2015-02-07
>> IETF LC End Date: 2015-02-16
>> IESG Telechat date:
>>
>> Summary: Ready
>> --------
>>
>> Minor issues:
>> -------------
>>
>> The writeup says "There was significant discussion if this document
>> should be extended to support links without multicast RAs
>> altogether. The consensus in the WG was to not do that in this
>> document."
>>
>> But the Abstract says "Furthermore, on some links, unsolicited multicast
>> Router Advertisements are never sent and the mechanism in this
>> document is intended to work even in such scenarios."
>
> that came up in 6man review as well, and I believe we agreed to remove that sentence.

This sentence still applies to the NBMA links such as ISATAP that do not 
send unsolicited mulicast RAs. The part that I thought the wg agreed to 
remove was related to support for *multicast capable links* that have 
deliberately turned off unsolicited RA sending.

This resulted in removing example b in the Introduction of supported 
networks

"b.    Access networks/links that turn off periodic RAs and only send
        RAs in response to RSs.  In this case, if the link between the
        Access Point (AP) and the host comes up before the link between
        the AP and the Controller/Router, the host will never be able to
        connect.  This technique of turning off periodic RAs is commonly
        used in several wireless LAN and datacenter networks to reduce
        the amount of multicast traffic."

and the subsequent removal of the associated RS sending behavior in 
Section 2.1

"Hosts MAY continue retransmitting
  the RSs even after router discovery is successful.  If the host
  continues to retransmit RSs, it is RECOMMENDED that such
  retransmissions be rate-limited to one every MRT."

This change was done from -03 to -04.


> this issue is solved in 6man-rs-refresh.
>
>> These two statements are inconsistent. Also, section 2.1 describes
>> specific behaviour on non-multicast links (which as far as I can see,
>> will indeed work if RAs are both unicast and solicited).

I personally think the writeup should be updated :-) to say

"There was significant discussion if this document should be extended to 
support multicast-capable links that have turned off multicast RAs 
altogether. The consensus in the WG was to not do that in this document."

but I am fine with removing the sentence from the abstract too. Please 
let me know what you prefer.

Thanks
Suresh