Ingress Replication Tunnels in Multicast VPN
draft-ietf-bess-ir-05
Yes
(Alvaro Retana)
No Objection
(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Ben Campbell)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
Abstain
Note: This ballot was opened for revision 04 and is now closed.
Alvaro Retana Former IESG member
Yes
Yes
(for -04)
Unknown
Deborah Brungard Former IESG member
(was No Objection)
Yes
Yes
(2016-08-18)
Unknown
Considering the discussion among the IESG, I wanted to give a strong endorsement for this document. Yes, the document is "complex" to read as it updates RFC6513/6514, and both of these documents required the reader to have normatively understood many other RFCs. Yes, the subject is complex for a non-subject expert reader. This document provides the "additional details" to implement complex capabilities (e.g. multi-vendor interoperability make before break procedures) these vendors (and the WG as noted by the Acknowledgements and list discussion) have found lacked in clarity in the original RFCs. I thank the authors and WG for taking the time to write this RFC as this additional work on implementation aspects after an RFC is rubber-stamped is critical. On many of the questions raised, a good discussion can be found on the list, especially Thomas's and Eric's thread: https://mailarchive.ietf.org/arch/msg/bess/AydZrp0Lf9fUohKrgVHG9kzbycY
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
()
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
()
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2016-08-18)
Unknown
I think the document is hard to read, for a number of reasons (the complexity of the underlying tech, plenty of options in it, incremental patch style to specification, and so on). I don't think any of the underlying reasons left much choice for the WG to produce something more easily analysable and understandable. However, while it has been difficult for me and Gen-ART reviewers to review it, I've been convinced that there's been enough other people who have reviewed it. I *am* however nervous that we're missing some cases or corner cases, but the world is certainly a better place with this document published than not. Thanks for your hard work on this.
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-08-16)
Unknown
Qin Wu <bill.wu@huawei.com> reviewed this document for the opsdir
Kathleen Moriarty Former IESG member
No Objection
No Objection
()
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -04)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
()
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
()
Unknown
Terry Manderson Former IESG member
Abstain
Abstain
(2016-08-17)
Unknown
I have some concerns about this document that I don't believe can be easily fixed. This document is extremely hard to read and understand, and therefore comprehend if there are any implications to the information provided. I'm really not sure that this can be addressed here without a significant rewrite. (that might be because the topic itself is deep) A second is related to how the document positions itself. Its status is for Standards Track, yet in the introduction it says: In this document, we provide a clearer and more explicit conceptual model for IR P-tunnels, clarifying the relationship between an IR P-tunnel and the unicast tunnels that are used for data transmission along the IR P-tunnel. and This document does not provide any new protocol elements, or any fundamentally new procedures; its purpose is to make explicit just how a router is to use the protocol elements and procedures of [RFC6513] and [RFC6514] to identify an IR P-tunnel, to join an IR P-tunnel, and to prune itself from an IR P-tunnel. Which to me screamed out informational, while then updating 6513 and 6514. However there are parts of the document that imply a semantic change in the use of fields or labels. Eg sect 10, use of timers when switching Upstream Multicast Hop.. so strongly suggesting a standards position. It feels like this document started out to do one thing, eg clarify the model of IR P-Tunnels and then acquired an extended set of tasks in dealing with MPLS label allocation policies. As I can't see a way to make a clear assessment of this document, I am taking an ABSTAIN position, and I will not block publication.