Subject: Comments on draft-ietf-l2vpn-vpls-mcast-08

From: Eric Rosen <[email-masked]>
Date: Mon, 04 Apr 2011 16:19:56 -0400

Since I haven't been following this mailing list regularly, I missed the WG
LC on draft-ietf-l2vpn-vpls-mcast-08.  I do have a few comments to make
though; fortunately IETF LC has not occurred yet.

1. "Snooped State"

>From section 11.3:

       If as a result of IGMP or PIM snooping on the PE-CE interfaces,
       the PE has snooped state for at least one multicast join that
       matches the multicast source and group advertised in the S-PMSI
       A-D route.

The document contains no definition of "IGMP snooping" or "PIM snooping",
nor any reference to another document defining these terms.  The document
proceeds to freely use the term "snooped state", without any definition.  

Without a definition of (or normative reference to such a definition)
"snooping" and "snooped state", I don't see how this document can claim to
be implementable.

2. How does traffic get from a multicast source to the designated router?

Consider group G.  Suppose site 1 contains the DR (but no sources or
receivers), site 2 contains the source S, site 3 contains a receiver R.  The
PE attached to site 2 might set up a selective tree for (S,G), and the PE
attached to site 3 will join the selective tree, no doubt due to it's having
"snooped state" indicating that there is a receiver at site 3.  The PE
attached to site 1 also needs to join the selective tree, or S will be cut
off from its DR.  However, I don't see where in the draft it provides a
procedure causing the site 1 PE to join the selective tree.  

Presumably there has to be some "snooping" of the DR election.  But this
doesn't seem to be mentioned at all.

3. Applicability Restrictions

The following applicability restriction is stated:

   These procedures are applicable when IGMP is used as the multicast
   routing protocol between the VPLS CEs. They are also applicable when
   PIM is used as the multicast routing protocol between the VPLS CEs
   and PIM join suppression is disabled on all the CEs. However these
   procedures do not apply when PIM is used as the multicast routing
   protocol between the VPLS CEs and it not possible to disable PIM join
   suppression on all the CEs

This suggests, incorrectly, that PIM and IGMP will not be running on the
same LAN. (Not sure whether that is the intention or not.)  I think the
correct statement of the applicability restriction is the following:

   These procedures are not applicable if any VPLS CE, or any other host or
   router that is bridged to the VPLS, uses a multicast control protocol
   that does not periodically retransmit control messages stating the set of
   (S,G) and (*,G) flows in which it is interested.

   Among such CEs are the following:

   - CEs that run PIM, but that have join suppression enabled (i.e., the
     vast majority of systems running PIM).  Note that the issue is not
     whether it is "possible to disable PIM join suppression on all the
     CEs", but whether it has actually been disabled.

   - CEs that run the protocol specified in draft-ietf-pim-port-06.txt.

   - CEs that run the protocol specified in draft-ietf-l3vpn-2547bis-mcast-
     bgp.

There should also be a clear statement to SPs that if a customer deploys
such a CE, the VPLS multicast service will create black holes that are
going to be difficult for the SP to troubleshoot.

If the document is going to recommend that join suppression be disabled (if
possible), there should be some discussion of the costs of disabling join
suppression. 

4. Allowable P-Tunnel Technologies

It is clear that the document allows the use of RSVP-TE P2MP and allows the
use of mLDP.  It is very difficult to understand just what the intention is
with respect to other tunneling technologies.  The document claims that the
architecture is flexible enough to support other technologies, but it also
says that other technologies are not supported. Right now the document does
not appear to make a consistent statement about this, leaving it unclear
whether the document means to prohibit other technologies or not.

Perhaps what it should say is just that other technologies are outside the
scope of this document.

5. Options, models, variants

The terminology in section 10 is very confusing.  The terms "options",
"models", and "variants" are not used in a consistent manner.

- Section 10 mentions "options" a, b, and c, then proceeds almost
  immediately (section 10.2) to an option e, which is never explicitly
  defined.

- Options a, b, and c are called "three models", and there is a requirement
  to support all three "models".  Then the text goes on to say that options a
  and b use a single "model" ("where inter-AS VPLS service can be offered
  without requiring a single P-multicast tree to span multiple ASes".)  Then
  there are two "variants" of this "model".

- I think the intention is that there are two "variants": "VSIs on the
  ASBRs", and "Segmented Inter-AS Trees", and that these two variants
  combine with the four "options" (a, b, c, and e) to make a total of 5
  models:

  * Model 1: Option (a) plus the variant "VSIs on the ASBRS"

  * Model 2: Option (e) plus the variant "VSIs on the ASBRS"

  * Model 3: Option (b) plus the variant "Segmented Inter-AS Trees"

  * Model 4: Option (c) plus the variant "Segmented Inter-AS Trees"

  * Model 5: Option (c) plus non-segmented Inter-AS trees but without VSIs
    on the ASBRs (not sure I got this one right, this seems like a hitherto
    unmentioned "variant").

  The terminology in section 10 really needs to be cleaned up for clarity
  and consistency.

6. Section 11.2.1

   This section is referred to multiple times, as the place where the
   explicit tracking procedures are specified.  However, there is no section
   11.2.1. I suspect the proper reference is 11.3.

6. Miscellaneous comments

>From the introduction (section 4), page 5:

   [RFC4761] and [RFC4762] describe a solution for VPLS multicast that
   relies on ingress replication.

"Ingress replication" should be defined; I don't think this term appears in
either RFC4761 or RFC4762.

Also from the introduction, page 5:

   It provides mechanisms that allow a single multicast distribution
   tree in the Service Provider (SP) network to carry all the multicast
   traffic from one or VPLS sites connected to a given PE, irrespective

"from one or VPLS" --> "from one or more VPLS"

>From the overview (section 6), page 6:

   This document describes procedures for using multicast trees for VPLS
   multicast when the provider tunneling technology is either P2MP RSVP-
   PE or mLDP [MLDP]. The protocol architecture described herein is
   considered to be flexible to support other P-tunneling technologies
   as well.

The phrase "either P2MP RSVP-PE or mLDP" is mangled.  I think what is
intended is "P2MP LSPs created either by RSVP-TE or mLDP".

Page 7

   The ability to carry the traffic of more than one VPLS on the
   same tree is termed of the VPLSes that are using the tree. This

"is termed of the VPLSes", looks like a cut-and-paste error of some sort.
   
   An Inclusive P-Multicast tree as defined in this document is a P2MP
   tree.  A P2MP tree is used to carry traffic only for VPLS sites that
   are connected to the PE that is the root of the tree.

I suggest "carry traffic only for" be replaced by "carry traffic only from",
as "for" could be taken to mean either "to" or "from" or "both" in this context.

Note that this paragraph seems to imply that MP2MP LSPs or PIM-BIDIR trees
would not be Inclusive P-multicast trees "as defined in this document".
Perhaps what it should say is "This document only defines procedures for
instantiating an inclusive P-multicast tree as a P2MP LSP; other possible
methods of instantiation are outside the scope of this document".  This
would be more consistent with the prior statement that the protocol
architecture of the document is flexible enough to support other tunneling
technologies.

Also on page 7:

       2. Selective trees. A Selective P-Multicast tree is used by a PE
   to send IP multicast traffic for one or IP more specific multicast
   streams, originated within sites connected to the PE, that belong to
   the same or different VPLSes, to a subset of the PEs that belong to
   those VPLSes. Each of the PEs in the subset should be on the path to
   a receiver of one or more multicast streams that are mapped onto the
   tree. The ability to use the same tree for multicast streams that
   belong to different VPLSes is termed a PE the ability to create

"Is termed a PE the ability to create"?  Maybe this should be "gives a PE
the ability to create".

I don't think it is correct to say that the traffic must have originated
within a site connected to the PE; the traffic could have originated
somewhere far away on the Internet, in a television studio, etc.  Instead of
"originated within sites connected to the PE", maybe what is meant is
"received by the PE over a PE-CE interface".  This error occurs in multiple
places. 

Page 7 again:

   A SP can use both Inclusive P-Multicast trees and Selective P-
   Multicast trees or either of them for a given VPLS on a PE, based on
   local configuration.  Inclusive P-Multicast trees can be used for
   both IP and non-IP data multicast traffic, while Selective P-
   Multicast trees can be used only for IP multicast data traffic.

It might be better to say "using selective P-trees for anything other than
IP multicast data traffic is outside the scope of this spec."  If this is
really meant to prohibit such use entirely, normative language ("MUST NOT")
should be used.

Once more, page 7:

   A variety of transport technologies may be used in the SP network.
   For inclusive P-Multicast trees, these transport technologies include
   point-to-multipoint LSPs created by RSVP-TE or mLDP. For selective P-
   Multicast trees, only unicast PE-PE tunnels (using MPLS or IP/GRE
   encapsulation) and P2MP LSPs are supported, and the supported P2MP
   LSP signaling protocols are RSVP-TE, and mLDP.

It's not very clear what this paragraph is saying.  If a technology is "not
supported", does that mean it is outside the scope of this document, or that
it is prohibited for some unspecified reason.  (If the latter, the reason
should be specified.)

It's hard to understand why unicast tunnels are supported only for selective
tunnels, why GRE encaps is supported only for unicast tunnels, etc.

Page 8:

   However these
   procedures do not apply when PIM is used as the multicast routing
   protocol between the VPLS CEs and it not possible to disable PIM join
   suppression on all the CEs.  Procedures for this case are for further
   study.

Change "it not possible to disable PIM Join suppression on all the CEs" to
"PIM Join Suppression is not disabled on all the CEs".  But see also my
prior comment on other multicast protocols for which every CE does not
periodically retransmit every Join.

Page 10:

   Aggregation requires a mechanism for the egresses of the P-Multicast
   tree to demultiplex the multicast traffic received over the P-
   Multicast tree. This document describes how upstream-assigned labels
   can be assigned and distributed by the root of aggregate P-Multicast
   tree and then used by the egresses to perform this demultiplexing.

I think it would be clearer to replace the last sentence by "To enable the
egress nodes to perform this demultiplexing, upstream-assigned labels
[RFC5331] MUST be assigned and distributed by the root of the aggregate
P-multicast tree".  This would make it clear that upstream-assigned labels
are a mandatory feature if (and only if) aggregation is used.

Page 11:

   It is to be noted that BGP A-D is an inherent feature of BGP-VPLS.
   However it is not an inherent feature of LDP-VPLS. Infact there are
   deployments and/or implementations of LDP-VPLS that require
   configuration to enable a PE in a particular VPLS to determine other
   PEs in the VPLS and exchange PW labels using FEC 128 [RFC4447]. The
   use of BGP A-D for LDP-VPLS [L2VPN-SIG], to enable automatic setup of
   PWs, requires FEC 129 [RFC4447]. However FEC 129 is not required in
   order to use BGP A-D for the setup of P-Multicast trees for LDP-VPLS
   as described in this document. An LDP-VPLS implementation that
   supports P-Multicast trees described in this document, MUST support
   the BGP A-D procedures to setup P-Multicast trees and it MAY support
   FEC 129 to automate the signaling of PWs.

It's very unclear to me just what is and is not being required by this
paragraph.  If it's just that an LDP-VPLS implementation may support the
procedures in this draft even if it doesn't support FEC 129, that seems fair
enough.  If it's that an LDP-VPLS implementation that uses P-multicast trees
to optimize IP multicast MUST support the BGP A-D procedures described
herein, that seems gratuitous.  The phrase "supports P-multicast trees
described in this document" is also unclear.

Page 12:

   A PE that uses an Inclusive P-Multicast tree to instantiate the
   provider tunnel MAY aggregate two or more VPLSes present on the PE
   onto the same tree. If the PE decides to perform aggregation after it
   has already advertised the intra-AS VPLS auto-discovery routes for
   these VPLSes, then aggregation requires the PE to re-advertise these
   routes.

Should there be some statement about when it's okay to start sending the
data on the newly aggregated tunnel?  Is it necessary or desirable to wait a
certain amount of time?

Page 12:

   The re-advertised routes MUST be the same as the original
   ones, except for the PMSI Tunnel attribute. If the PE has not
   previously advertised intra-AS auto-discovery routes for these
   VPLSes, then the aggregation requires the PE to advertise (new)
   intra-AS auto-discovery routes for these VPLSes.  The P-Tunnel
   attribute in the newly advertised/re-advertised routes MUST carry the
   identity of the P-Multicast tree that aggregates the VPLSes, as well
   as an MPLS upstream-assigned label [RFC5331]. Each re-advertised
   route MUST have a distinct label.

For consistency, "P-Tunnel attribute" --> "PMSI Tunnel attribute"

The requirement for a distinct label applies to the newly advertised routes
as well as the re-advertised routes, no?

Page 13:

     + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE
       P2MP LSP, the receiving PE has to establish the appropriate state
       to properly handle the traffic received over that LSP. The PE
       that originated the route MUST establish an RSVP-TE P2MP LSP with
       the local PE as a leaf. This LSP MAY have been established before
       the local PE receives the route.

Isn't a normative reference to draft-ietf-mpls-rsvp-te-no-php-oob-mapping-
05.txt needed here, for the case where the TE tunnel is established before
its use has been communicated?

Page 14:

   When a P-Multicast tree is mapped to only one VPLS, determining the
   tree on which the packet is received is sufficient to determine the
   VPLS instance on which the packet is received. The tree is determined
   based on the tree encapsulation. If MPLS encapsulation is used, eg:
   RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the
   tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP (RSVP-
   TE P2MP LSP or LDP P2MP LSP).

Doesn't this require a normative reference to draft-ietf-mpls-rsvp-te-no-
php-oob-mapping-05.txt?

Page 14, section 8.2:

   This document requires the use of upstream label assignment by the
   ingress PE [RFC5331].

It might be better to use 2119 language here, "If traffic from multiple
VPLSes is carried on a single tree, upstream-assigned labels [RFC5331] MUST
be used.

Also page 14:

   If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the
   outer MPLS label and the incoming interface provides the label space
   of the label beneath it. This assumes that penultimate-hop-popping is
   disabled. The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT
   NULL for that tree.

If the P2MP LSP is signaled before the BGP route is received, how does the
egress PE know to avoid advertising NULL for that LSP?

Page 15:

   9. Establishing P-Multicast Trees

   This document does not place any fundamental restrictions on the
   multicast technology used to setup P-Multicast trees. However
   specific procedures are specified only for RSVP-TE P2MP LSPs and LDP
   P2MP LSPs. An implementation that supports this document MUST support
   RSVP-TE P2MP LSPs and LDP P2MP LSPs.

   The P-Multicast trees supported in this document are P2MP trees.

It would be less confusing to say that "specific procedures are specified
only for P2MP LSPs", otherwise it is hard to know what to make of these two
paragraphs together.

   A
   P2MP tree is used to carry traffic originated in sites connected to
   the PE which is the root of the tree, irrespective of whether these
   sites belong to the same or different VPLSes.

This suggests, incorrectly, that aggregation is always done. Maybe change
"is used" to "MAY be used".  

9.1. Common Procedures

   The following procedures apply to both RSVP-TE P2MP and LDP P2MP
   LSPs.

   Demultiplexing the C-multicast data packets at the egress PE requires
   that the PE must be able to determine the P2MP LSP that the packets are
   received on. This enables the egress PE to determine the VPLS that the
   packet belongs to. To achieve this the LSP MUST be signaled with
   penultimate-hop-popping (PHP) off as described in section 8.  In other
   words an egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for
   a P2MP LSP that is carrying traffic for one or more VPLSes.

As I commented earlier, I don't think this draft explains how the egress
knows to do this in the case of RSVP-TE P2MP LSPs.
   
Page 17:

9.4. Encapsulation of Aggregate P-Multicast Trees

   An Aggregate Inclusive P-Multicast tree or an Aggregate Selective P-
   Multicast tree MUST use a MPLS encapsulation. The protocol type in
   the data link header is as described in [RFC5332].

Presumably the encapsulation used to send data on a certain tunnel is
determined by the tunnel type.  I'm not sure why this short section is
needed, there is no section on encapsulation of non-aggregate trees.

Page 27:

   These procedures are applicable when IGMP is used as the multicast
   routing protocol between the VPLS CEs. They are also applicable when
   PIM is used as the multicast routing protocol between the VPLS CEs
   and PIM join suppression is disabled on all the CEs. However these
   procedures do not apply when PIM is used as the multicast routing
   protocol between the VPLS CEs and it not possible to disable PIM join
   suppression on all the CEs.  Procedures that allow the setup of
   Selective trees for this case are for further study.

This paragraph is just repeated from earlier in the document.  See my
earlier comments. (Regardless of the disposition of those comments, this
paragraph should probably not be repeated here.)

Page 28:
 
   If the Selective tree is instantiated by a RSVP-TE P2MP LSP the PE at
   the root of the tree MUST establish the P2MP RSVP-TE LSP to the
   leaves. This LSP MAY have been established before the leaves receive
   the Selective tree binding, or MAY be established after the leaves
   receives the binding. A leaf MUST not switch to the Selective tree
   until it receives the binding and the RSVP-TE P2MP LSP is setup to
   the leaf.

This paragraph has already occurred before.

Page 31:

     + If as a result of IGMP or PIM snooping on the PE-CE interfaces,
       the PE has snooped state for at least one multicast join that
       matches the multicast source and group advertised in the S-PMSI
       A-D route. Further if the oif (outgoing interfaces) for this
       state contains one or more interfaces to the locally attached
       CEs.

As previously pointed out, "IGMP or PIM snooping" has to be defined and
specified (perhaps via a normative reference).  Otherwise there is no way to
know what is meant below by "snooped state" how such states are created
and destroyed, and exactly what states the PEs need to keep track of.
     
Pages 31-32

   The snooped state is said to "match" the S-PMSI A-D route if any of
   the following is true:

     +  The S-PMSI A-D route carries (C-S, C-G) and the snooped state is
       for (C-S, C-G). OR

     +  The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped
       state is for (C-*, C-G) OR (b) the snooped state is for at least
       one multicast join with the multicast group address equal to C-G
       and there doesn't exist another S-PMSI A-D route that carries (C-
       S, C-G) where C-S is the source address of the snooped state.

     +  The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped
       state is for at least one multicast join with the multicast
       source address equal to C-S, and (b) there doesn't exist another
       S-PMSI A-D route that carries (C-S, C-G) where C-G is the group
       address of the snooped state.

     +  The S-PMSI A-D route carries (C-*, C-*)

As this algorithm is specified, every "snooped state" matches an S-PMSI A-D
route specifying (C-*,C-*), even if (C-*,C-*) is not the "longest match".  I
think what is meant is that the snooped state matches the S-PMSI A-D route
that meets the first condition, if there is one; otherwise it matches the
S-PMSI A-D route that meets the second condition, if there is one; otherwise
it matches the S-PMSI A-D route that meets the third condition, if there is
one; otherwise it matches the S-PMSI A-D route that meets the fourth
condition, if there is one; otherwise there is no match. However, this is
not what it says.

Something should be specified to cover the case where the S-PMSI A-D route
does not match any "snooped state", and the case where a newly created
"snooped state" matches an S-PMSI A-D route that is already present.
     
Page 36:

12.1. Inclusive Tree/Selective Tree Identifier

   Inclusive P-Multicast tree and Selective P-Multicast tree
   advertisements carry the P-Multicast tree identifier.

   This document reuses the BGP attribute, called PMSI Tunnel Attribute
   that is defined in [MVPN].

   Only the following Tunnel Types MUST be used when PMSI Tunnel
   attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes:

     + 0 - No tunnel information present
     + 1 - RSVP-TE P2MP LSP
     + 2 - LDP P2MP LSP
     + 6 - Ingress Replication

If the protocol architecture is flexible enough to handle other tunnel
types, as is stated several times earlier, this should say that the use of
other tunnel types is outside the scope of the document, rather than saying
that other tunnel types MUST NOT be used.  (Actually, the phrase "only the
following tunnel types MUST be used ..." is not really comprehensible, I'm
just guessing that it means that other tunnel types MUST NOT be used.)

Page 38:

   The Multicast Source field contains the C-S address i.e the address
   of the multicast source. This may be 0 to indicate a wildcard. If the
   Multicast Source field contains an IPv4 address, then the value of
   the Multicast Source Length field is 32. If the Multicast Source
   field contains an IPv6 address, then the value of the Multicast
   Source Length field is 128.

   The Multicast Group field contains the C-G address i.e. the address
   of the multicast group. This may be 0 to indicate a wildcard.  If the
   Multicast Group field contains an IPv4 address, then the value of the
   Multicast Group Length field is 32. If the Multicast Group field
   contains an IPv6 address, then the value of the Multicast Group
   Length field is 128.

The wildcard encoding does not appear to be consistent with that used in
MVPN.  It is also not clear what the length of a wildcard field is supposed
to be, or whether a wildcard is a wildcard only for a particular address
family.

Please state how to determine the address family of the "originating
router's IP address".

   Usage of Selective Tree auto-discovery routes is described in Section
   12.

Well, this is section 12! 

Page 38:

   A leaf auto-discovery route type specific MCAST-VPLS NLRI consists of
   the following:

                +-----------------------------------+
                |      Route Key (variable)         |
                +-----------------------------------+
                |   Originating Router's IP Addr    |
                +-----------------------------------+

   Usage of Leaf auto-discovery routes is described in sections "Inter-
   AS Inclusive P-Multicast tree A-D/Binding" and "Optimizing Multicast
   Distribution via Selective trees".

Please state how to determine the address family of the "originating
router's IP address".

Page 39:

     13. Aggregation Methodology

A better title would be "Aggregation Considerations", as this section
contains some discussion and observations, but does not specify a
methodology. 

Page 41:

   If the destination MAC address of a VPLS packet received by a PE from
   a VPLS site is a multicast adddress, a P-Multicast tree SHOULD be
   used to transport the packet, if possible. If the packet is an IP
   multicast packet and a Selective tree exists for that multicast
   stream, the Selective tree SHOULD be used. Else if an Inclusive tree
   exists for the VPLS, it SHOULD be used.

So a transmitter is not required to use the selective tree for a given flow,
even if it exists?  Is that really the intention?

It is not completely clear what the intention is for a packet that has an
ethernet multicast DA but is not an IP multicast packet.  Would it ever be
sent on a selective tree (perhaps one bound to (C-*,C-*))?