Ingress Replication Tunnels in Multicast VPN
draft-ietf-bess-ir-05

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

Deborah Brungard (was No Objection) Yes

Comment (2016-08-18)
No email
send info
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

Alvaro Retana Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2016-08-18)
No email
send info
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.

(Alia Atlas) No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Joel Jaeggli) No Objection

Comment (2016-08-16)
No email
send info
Qin Wu <bill.wu@huawei.com> reviewed this document for the opsdir

Suresh Krishnan No Objection

Mirja K├╝hlewind No Objection

Alexey Melnikov No Objection

(Kathleen Moriarty) No Objection

(Terry Manderson) Abstain

Comment (2016-08-17)
No email
send info
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.