datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

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

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

Summary: Has enough positions to pass.

Brian Haberman

Comment (2013-11-22)

Thanks for addressing my DISCUSS point.

Joel Jaeggli

Comment (2013-11-20)

-15 addressed the opsdir review comments

thanks

Pete Resnick

Comment (2013-11-20)

I gave this document a cursory scan for applications issues and finding none I
will simply No Obj.

Stephen Farrell

Comment (2013-11-21)

- 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

Comment (2013-11-20)

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.