Extranet Multicast in BGP/IP MPLS VPNs
Note: This ballot was opened for revision 04 and is now closed.
Alvaro Retana Yes
(Jari Arkko) No Objection
Comment (2015-12-17 for -04)
I agree with Christer's Gen-ART review in that what is being updated should be clearer documented.
(Alia Atlas) No Objection
Comment (2015-12-15 for -04)
This is quite a detailed read and despite the clarity of each section, hard to truly put together into a larger understanding. I was hoping for a section that would be Applicability or a table that gave the different dimensions and the options for each. I think adding such a section early in the document would really help with understanding what the different trade-offs and likely sets of choices might be. I also realize that many readers will be more familiar with the base technology and be able to work through the details with repeated readings.
Deborah Brungard No Objection
Ben Campbell No Objection
Comment (2015-12-16 for -04)
I share some of the concerns that the draft organization makes it harder to understand than it needs to be. For example, the overview doesn't start until page 9, and has quite a bit of dense technical material ahead of it. (But, as others have already said, I am not the style police.)
(Benoit Claise) (was Discuss) No Objection
Editorial suggestions: Summary: In general the authors provide dense English text to describe this rules. In general the English text contains valid complex sentences. However, a few things should be suggested: 1) PTA – define it in a definition section or spell out the abbreviation 2) Phrases like “the RT RT-R” become overly dense. Use “Route Target RT-R”. 3) Breaking up section 6.2.1 – with subjection and subtitles would make it more readable, 4) P. 36 second paragraph. The reason for the “MUST” in 1st full paragraph is a bit vague. It seems logical, but the reasoning is just vague in the text. 5) paragraph 2 in page 47 (section 7.3.1) is awkward, please reword. 6) Paragraph 5 in page 47 (section 7.3.1) – does not explain why the condition should hold. The authors have done this in eac other case, so it seems inconsistent. 7) Page 53 – section 7.4.5 paragraph 3 “VRF route Import EC” – please spell out first usage and give abbreviation (VRF Route Import Extended Community (EC).
Alissa Cooper No Objection
Spencer Dawkins No Objection
(Joel Jaeggli) (was Discuss) No Objection
Thank you for the frank discussion in buenos Aires and the proposed edits. I think they address the concerns raised in the opsdir review. was: Discuss Sue Hares performed the opsdir review. benoit holds the discuss for the points she raised. Status: Not ready, three major concerns and two editorial nits: Major concerns: 1) Specification of the Extranet Source Extended Community and Extra Source extended Community Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2, and 3.3. was discuss After further discussion related to the ops dir review, I'm going to have to echo Benoit and the Opsdir reviewers concern. 2) Why is there no Deployment considerations section? The whole draft is a set of rules for handling policy, BGP A-D routes, tunnel set-up, and PIM Join/leaves in the case of an intra net. Unless these rules are followed exactly, traffic may flow into a VPN it is not suppose to. If the customer and the SP must coordinate on setting up filters, the procedure is outside the document. An error in any of these set-ups is considered a “security violation”. Milo Medin stated “with enough trust” a rock can fly to the moon. However, the NASA flights were fragile and risky. In the journey to the moon, there was no other choice. Instrumentation has 4-5 backups. In this set-up, one has to ask “is there another choice” to this whole design that seem fragile addition of extranets to an intra-AS multicast design. If the design is not fragile, then there should be a deployment section indicating how to manage the RTs, RDs, and policy set-up. Perhaps experience with the Intra-As has shown deployment tips that would make this less fragile. If so, it would be good to include an operations consideration section. If a new class of tools provides monitoring or provisioning, mentioning these would be useful. If yang modules are being developed, that would be useful. Places that indicate issues with violated constraint: p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25 last paragraph (violation of constraints will cause things to not work. However, only policy can control), p. 27 4.2.2 (1st paragraph, Route Reflector must not change), p. 31 (5.1, first paragraph), 3) Is security section really a security section? It seems more like “do this policy” or this will fail. It should get a stronger review from the security directorate
(Barry Leiba) No Objection
Terry Manderson No Objection
Comment (2015-12-15 for -04)
This is a comprehensive document. Kudos for writing it. However, is there a WG rationale as to why this document is structured as it is? It struck me when reading it there are 4 distinct books here on the various aspects of extranet multicast VPNs. Being: Overview and overlap/ambiguity w/prevention, Transmission models, Route distribution and communities (where the IANA req for the 2 communities ,ight live), and Control Plane concerns. Would that make it easier to implementers to comprehend? I don't agree with the document shepherd in that "I found the document (relatively) not hard to follow, if you read it end-to-end" - for me it made review a marathon. That said, I'm not the style police, so balloting no objection. I only saw one typo along the way ie VRFS instead of VRFs (page 9 second para)
(Kathleen Moriarty) (was Discuss) No Objection
Comment (2015-12-22 for -05)
Thanks for adding text to clearly state there is no session encryption in the security considerations section.
(Martin Stiemerling) No Objection
(Brian Haberman) Abstain
Comment (2015-12-16 for -04)
I have to assume that there are vendors shipping this functionality... and, presumably, customers using it in some limited fashion. However, I find that this work has managed to make inter-domain IP multicast look simple and easy. I don't see any justification for why this approach is preferable to using native IP multicast approaches for what appears to be pre-provisioned distribution of multicast content between a small set of independent networks. That being said, I am not going to stand in the way of the publication of this document. That horse is out of the barn.