Multicast in Virtual Private LAN Service (VPLS)
Note: This ballot was opened for revision 15 and is now closed.
( Stewart Bryant ) Yes
( Adrian Farrel ) Yes
Jari Arkko No Objection
( Gonzalo Camarillo ) No Objection
Spencer Dawkins No Objection
Stephen Farrell (was Discuss) No Objection
Comment (2013-11-21 for -15)
- 5.4: This is based on rfc 6074, the security considerations of which say that automated security mechanisms are recommended as a future work item. Did that happen? If so, should there be a reference to the results? If not, what's the impact on this spec? - 5.6: nit: where's option (d)? Be nice to exaplain a bit for the uninformed reader. - 9.1.1 - just wondering: does that mean that if I guess a VLAN ID then I get to join a MC group? Aren't they only 10 bits long? Does that mean that any other AS can try search all the MC groups that exist?
Brian Haberman (was Discuss) No Objection
Thanks for addressing my DISCUSS point.
Joel Jaeggli No Objection
Comment (2013-11-20 for -15)
-15 addressed the opsdir review comments thanks
Barry Leiba No Objection
( Ted Lemon ) No Objection
Comment (2013-11-20 for -15)
In 3, the acronym "PE" is used several times without definition. It is defined in 4761, but you use it so frequently that it seems like it would be worth defining it here despite the reference to 4761. Also in 3: A "Selective tree" is a single multicast distribution tree in the Service Provider network that carries multicast traffic belonging only to a specified set of IP multicast streams, and all these streams belong to the same VPLS instance on a given PE. could IMO be made clearer by adding: A selective tree differs from an inclusive tree in that it may reach a subset of the PEs reached by an inclusive. I propose this addition because when I first read this section it wasn't clear to me what the distinction between selective and inclusive trees was; this was made clear in section 5.1, so the change isn't strictly necessary, but it would save the new reader some speculative effort when reading the glossary. Of course, the text I've proposed for addition is probably incorrect—I propose it to illustrate the point, not as some kind of demand that it be included verbatim. If you think something along these lines would improve this definition, please include it; otherwise feel free to ignore it, since the point is ultimately resolved in 5.1 anyway. There are a number of cases throughout the document where "needs to" is used where a direct verb would (IMO!) be more clear. For instance, in 5.1: is termed Aggregation. The tree needs to include every PE that is could be: is termed Aggregation. The tree includes every PE that is This is a really minor style issue and also a matter of opinion, so please ignore it if you don't see it as an improvement. There are also a number of cases where the document says "needs to know," which is correct and shouldn't be changed. 5.1, paragraph 5: OLD: trees, as previousely state, must be used only for IP multicast data NEW: trees, as previously stated, must be used only for IP multicast data 5.2, paragraph 1, this is hard to parse: In order to establish Inclusive P-Multicast trees for one or more VPLS instances, when aggregation is performed (with either mLDP or P2MP RSVP-TE as the tunneling technology), or when the tunneling technology is P2MP RSVP-TE If this means the same thing, it might be clearer: In order to establish Inclusive P-Multicast trees for one or more VPLS instances when the tunneling technology is P2MP RSVP-TE, or when aggregation is performed, The bit about mLDP is repeated later in the paragraph, so I think this covers all the cases you are trying to cover. The reason I suggest this change is that it's less text and more easily parsed, so if it's wrong, or doesn't seem clearer to you, please ignore this suggestion. Same paragraph: OLD: must be able to discover the other PEs that have membership of these NEW: must be able to discover the other PEs that have membership in these right? or: must be able to discover the other PEs that are members of these In section 6 and subsequently, writing A-D instead of auto-discovery probably makes the document a bit shorter, but also makes it harder to read. You could also make the document a bit easier to read by writing pseudo-wire instead of PW. Particularly in section six, so many acronyms are introduced so quickly that it is a lot to juggle as you read. You're not getting a ton of value out of abbreviating auto-discovery and pseudo-wire. Also, why the dash in A-D but not P-W? The document also abbreviates Route Target as RT, but this is introduced several times, and used as an abbreviation only a few times. There seems to be little value in this abbreviation as well. To further nitpick, VSI, PMSI, ASBR and NLRI are used throughout the document, but not mentioned in the Terminology section, so the reader is forced to hunt in order to find the initial use of these acronyms so as to remember what they stand for (in the case of ASBR, there is no expanded version). Likely not a problem for a domain expert, of course, but for a new reader this will be a problem. It might be worth expanding the P2MP TE LSP acronym once in 8.2.1. You have the reference to RFC 4875, so this isn't strictly necessary, but it took me a while to figure out the connection. Whether you expand the acronym or not, you should really add a reference to RFC4875 on the first occurrence in 8.2.1 for completeness. Speaking of which, there's what looks like a typo in this reference: [RFC4875] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4857, May 2007. The actual RFC reference appears to have the last two digits transposed. The acronym "VE" as in "VE ID" is never expanded.
( Pete Resnick ) No Objection
Comment (2013-11-20 for -15)
I gave this document a cursory scan for applications issues and finding none I will simply No Obj.