Skip to main content

Multicast in Virtual Private LAN Service (VPLS)
draft-ietf-l2vpn-vpls-mcast-16

Yes

(Adrian Farrel)
(Stewart Bryant)

No Objection

(Barry Leiba)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)

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

Adrian Farrel Former IESG member
Yes
Yes (for -15) Unknown

                            
Stewart Bryant Former IESG member
Yes
Yes (for -15) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (2013-11-22) Unknown
Thanks for addressing my DISCUSS point.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-11-20 for -15) Unknown
-15 addressed the opsdir review comments

thanks
Martin Stiemerling Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2013-11-20 for -15) Unknown
I gave this document a cursory scan for applications issues and finding none I will simply No Obj.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-11-21 for -15) Unknown
- 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?
Ted Lemon Former IESG member
No Objection
No Objection (2013-11-20 for -15) Unknown
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.