Skip to main content

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.