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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Feb 2015 17:03:24 +1300

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."

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 think the draft is fine, but the writeup is kind of strange as
a result. draft-nordmark-6man-rs-refresh tackles a different problem,
namely reducing multicast usage on multicast-capable links.

(FYI I did not track these discussions in 6man at all.)

---

From: Ole Troan <[email-masked]>
Date: Sat, 7 Feb 2015 11:49:27 +0100

Brian,

thank you very much for the review.

> IETF LC End Date: 2015-02-16

that came up in 6man review as well, and I believe we agreed to remove that sentence.
this issue is solved in 6man-rs-refresh.

> will indeed work if RAs are both unicast and solicited).

section 2.1 only describes it for the ISATAP case. it would work for any link-layer that did multicast emulation (thereby not being a non-multicast capable link), or where the link-layer addresses are pre-configured (as in the ISATAP case).

it might be less confusing to remove the second paragraph of 2.1.

> namely reducing multicast usage on multicast-capable links.

this draft in combination with nordmark-6man-rs-refresh would allow for unicast RA only operation (still on multicast capable links).
t

> (FYI I did not track these discussions in 6man at all.)

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 10 Feb 2015 05:41:50 +0000

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

> 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.

>> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Feb 2015 07:44:50 +1300

> 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

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 Feb 2015 12:43:52 +0100

Suresh, Brian,

> deliberately turned off unsolicited RA sending.

using ISATAP as an example isn't very representative. ND isn't generally supported on ISATAP links.
ISATAP does a very limited form of router discovery where the link-layer addresses of the routers to be discovered are preconfigured by the hosts.

ISATAP was not the topic of discussion in the working group.

> let me know what you prefer.

I'll leave the writeup as is, it is worthwhile getting IESGs opinion on the inconsistencies pointed out.

cheers,
Ole

---

From: Brian Haberman <[email-masked]>
Date: Wed, 11 Feb 2015 08:19:42 -0500

Ole,

> I'll leave the writeup as is, it is worthwhile getting IESGs opinion on the inconsistencies pointed out.

I agree with Suresh that the writeup should be updated with the proposed
text...

Unless you want this to be some sort of experiment to see which ADs read
the shepherd writeup. :)

Regards,
Brian