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

[Brian E Carpenter <[e-mail]>]

On 10/02/2015 18:41, Suresh Krishnan wrote:
> 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.

As a reviewer I have no strong opinion - it was just the inconsistency
between the writeup and the draft that bothered me.

As a 6man participant, I think that the draft is fine so I would suggest
tuning the writeup to be more precise.

    Brian