Skip to main content

IPv6 Backbone Router
RFC 8929

Yes

(Suresh Krishnan)

No Objection

(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)

Note: This ballot was opened for revision 16 and is now closed.

Alvaro Retana No Objection

Comment (2020-02-19 for -16)
This document should be tagged as replacing draft-thubert-6lo-backbone-router.

Roman Danyliw (was Discuss) No Objection

Comment (2020-03-21 for -19)
Thanks for addressing my DISCUSS points.

Éric Vyncke No Objection

Comment (2020-02-20 for -16)
Thank you for the work put into this document. It is really easy to read with very nice ASCII art figures.

Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
As my esteemed colleague from East US Coast, I liked the introduction but I would prefer to have the EARO acronym expanded.


-- Section 2.3 --
I wonder whether using "6LBBR" would be more readable and consistent (with "6LN" and "6LBR") than using "6BBR"

-- Section 3 --
Should the method to achieve "ensure that the Address is not duplicated over the Backbone" be specified? E.g., DAD ?

-- Section 3.2 --
"The RS sent initially by the 6LN(STA) is transmitted as a multicast
   but since it is intercepted by the 6BBR, it is never effectively
   broadcast."
Perhaps worth mentioning "layer-3 multicast" hence "layer-2 broadcast"... And "never... broadcast" it would important to mention the scope of the broadcast. This ambiguity about layer & scope happens quite often in the document. Knowledgeable readers will understand of course but what about less knowledgeable ones?


== NITS ==

I found the use of acronyms a little too heavy, complicating the reading for little benefits: e.g., ODAD = Optimistic DAD, SLLAO = Source LLA Option. On the contrary, well-known acronyms are not used :-) E.g., multiple instance of "Link Local addresses" rather than the well-known "LLA".

In the same vein, it is sometimes "Layer 2 Address" and other times "MAC address"

(Suresh Krishnan; former steering group member) Yes

Yes (for -16)

                            

(Adam Roach; former steering group member) No Objection

No Objection (2020-02-19 for -16)
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.

(Alexey Melnikov; former steering group member) No Objection

No Objection (2020-02-18 for -16)
The introduction is hard to read for an non expert like me. It reads “blah blah ... excessive traffic generated, can be optimised”. I think it can be made shorter and crisper.

(Alissa Cooper; former steering group member) No Objection

No Objection (2020-02-19 for -16)
I'm curious if what is specified in this document affects any of the considerations discussed in RFC 8505 Section 8 about how addresses should be formed. RFC 8505 discourages the use of EUI-64 to form IIDs, while this spec seems to incentivize or at least make possible use cases where the 6LBR has to store MAC addresses in order to serve as a mapping server. Should this document discuss the privacy considerations associated with Bridging Proxy mode?

(Barry Leiba; former steering group member) No Objection

No Objection (2020-02-18 for -16)
For what it's worth, I disagree with my distinguished colleague from London: I find the extensive background given in the Introduction to be readable and useful.

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2020-03-22 for -19)
Thank you for all the updates for my Discuss and Comment points!

(Deborah Brungard; former steering group member) No Objection

No Objection (for -16)

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection (for -16)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -16)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2020-02-19 for -16)
Thanks for quickly addressing the TSV-ART review (and thanks Kyle for the review!)!