Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication
draft-ietf-bess-mvpn-bidir-ingress-replication-04
Yes
(Alvaro Retana)
No Objection
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 03 and is now closed.
Alvaro Retana Former IESG member
Yes
Yes
(for -03)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(2015-10-14 for -03)
Unknown
This is not an easy document to read. If it gave reasons, examples, and explained what it was accomplishing with the information exchanged, that would probably help.
Barry Leiba Former IESG member
No Objection
No Objection
(2015-10-14 for -03)
Unknown
A very small point, and not a big deal: The abstract says, "This specification updates RFC 6514," presumably to meet the I-D nits question. But it doesn't say what, specifically, is updated, and I don't get that clearly from reading the rest of the document either (I presume that someone who knows 6514 well would understand; I think the explanation is in the paragraph in the introduction that mentions Ingress Replication tunnels, and there's a paragraph in the middle of Section 3.1...). Can the sentence be expanded just a little (keeping it as one sentence) to summarise what the update is? I'm thinking along the line of, "This specification updates RFC 6514 by [changing the procedures with respect to [whatever]]."
Ben Campbell Former IESG member
No Objection
No Objection
(for -03)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2015-10-14 for -03)
Unknown
Here is Warren Kumari's OPS DIR review. Summary: Ready, typo / grammar nits. General: I found this document to be very dense. At some point my brain started dribbling out my ears and I largely gave up on trying to understand the mechanism. This seems to be very much a niche application, and my IP multicast and deep MPLS knowledge isn't up to the level of finding issues with the logic. Nits: Abstract: This document specifiess how [O] specifiess [P] specifies [R] spelling 1: Introduction: With these two methods, all PEs of a particular VPN are separated [O] all PEs [P] all PEs (Provider Edge router) [R] first use of acronym. The document does say it assumed familiarity with terminology from [RFC5015], [RFC6513], [RFC6514], and [RFC7582], but this is before that, and also expanding PE here will help people understand if they want to continue reading...
Brian Haberman Former IESG member
No Objection
No Objection
(2015-10-15 for -03)
Unknown
I have to agree with Alia's comments and Warren's review. Very dense. No clear justification. No examples.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-10-13 for -03)
Unknown
warren kumari did the opsdir review
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-10-15 for -03)
Unknown
I have one less and two more serious comments... - Less seriously, "MP2MP tunnel" seems like a strange use of language, I wondered if it might be better to call these an MP2MP warren (as in rabbit warren, and of course bearing in mind the ops-dir review:-) - More seriously, this is another draft that simply has too many acronyms and uses those too densely. For example, I just find it really hard to believe that "If a PE, say PEx, is connected to a site of a given VPN, and PEx's next hop interface to some C-RPA is a VRF interface, then PEx MUST advertises a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of whether it has any local Bidir-PIM join states corresponding to the C-RPA learned from its CEs" is a useful sentence to implementers. IMO enough folks have commented on this aspect that the wg would be wise to seriously consider the readibility of their output. I've worked on enough EU-funded projects that had write-only documents to be worried if the IETF starts to produce those. (This is not a discuss since I've been assured that this is not a problem for implementers, and while I do accept that, I also continue to worry about it.) - I am simply not in a position to evaluate section 4. And nor was the assigned secdir reviewer. The same point about density and that making any secdir review hard to impossible was noted by the secdir reviewer for draft-ietf-bess-mvpn-bidir. I don't think it'd be valid for me to put on a discuss on the basis that nothing this complex has "no new security issues" but it was tempting. Overall, I think it would be best if this were returned to the wg asking for significant improvement in clarity for readers.
Terry Manderson Former IESG member
No Objection
No Objection
(for -03)
Unknown