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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
