Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2014-02-11
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-01-23
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-01-14
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-01-14
16 (System) RFC Editor state changed to EDIT from AUTH
2014-01-02
16 (System) RFC Editor state changed to AUTH from EDIT
2013-12-02
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-12-02
16 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2013-11-28
16 Gunter Van de Velde Closed request for Telechat review by OPSDIR with state 'No Response'
2013-11-27
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-11-27
16 (System) IANA Action state changed to In Progress
2013-11-26
16 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2013-11-26
16 (System) RFC Editor state changed to EDIT
2013-11-26
16 (System) Announcement was received by RFC Editor
2013-11-26
16 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2013-11-26
16 Amy Vezza IESG has approved the document
2013-11-26
16 Amy Vezza Closed "Approve" ballot
2013-11-26
16 Amy Vezza Ballot approval text was generated
2013-11-26
16 Amy Vezza Ballot writeup was changed
2013-11-26
16 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2013-11-22
16 Brian Haberman [Ballot comment]
Thanks for addressing my DISCUSS point.
2013-11-22
16 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2013-11-22
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-11-22
16 Yakov Rekhter IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-11-22
16 Yakov Rekhter New version available: draft-ietf-l2vpn-vpls-mcast-16.txt
2013-11-21
15 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup::AD Followup
2013-11-21
15 Stephen Farrell
[Ballot comment]

- 5.4: This is based on rfc 6074, the security
considerations of which say that automated security
mechanisms are recommended as a …
[Ballot comment]

- 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?
2013-11-21
15 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2013-11-21
15 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-11-21
15 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-11-21
15 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-11-20
15 Pete Resnick [Ballot comment]
I gave this document a cursory scan for applications issues and finding none I will simply No Obj.
2013-11-20
15 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-11-20
15 Joel Jaeggli [Ballot comment]
-15 addressed the opsdir review comments

thanks
2013-11-20
15 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-11-20
15 Ted Lemon
[Ballot comment]
In 3, the acronym "PE" is used several times without definition.  It is defined in 4761, but you use it so frequently that …
[Ballot comment]
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.
2013-11-20
15 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2013-11-20
15 Brian Haberman
[Ballot discuss]
This should be a short discussion for clarity (I intend to clear no later than after the IESG telechat).  This document does not …
[Ballot discuss]
This should be a short discussion for clarity (I intend to clear no later than after the IESG telechat).  This document does not explicitly state if this proposed approach impacts the IP multicast model.  So, does this approach support both ASM and SSM models?  Is it applicable to both IPv4 and IPv6?  It is unclear since only IGMP (IPv4) is mentioned in passing.
2013-11-20
15 Brian Haberman
[Ballot comment]
1. It would be useful to explicitly reference the IGMP (and MLD?) specifications.

2. ID-nits complains about a few issues:

** There are …
[Ballot comment]
1. It would be useful to explicitly reference the IGMP (and MLD?) specifications.

2. ID-nits complains about a few issues:

** There are 4 instances of too long lines in the document, the longest one
    being 3 characters in excess of 72.

** The abstract seems to contain references ([RFC4761], [RFC4762]), which
    it shouldn't.  Please replace those with straight textual mentions of the
    documents in question.
2013-11-20
15 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2013-11-20
15 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-11-20
15 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-11-19
15 Stephen Farrell
[Ballot discuss]

A brief discuss that I'll soon clear since I'm sure that
this probably isn't the right document in which to
tackle this problem, …
[Ballot discuss]

A brief discuss that I'll soon clear since I'm sure that
this probably isn't the right document in which to
tackle this problem, but I'll ask anyway...

The security considerations say that if you know the
labels, you can eavesdrop, and that I guess applies to
all ASes that are neighbours and maybe more. (Or does
it? If not, saying why not here would be good.) Given
recent developments, maybe assuming that all ASes are
"composed of trusted nodes/links" might not be so
credible anymore so where/how might this be addressed?
(Like I said above, I'll clear once we've chatted
briefly about this.)
2013-11-19
15 Stephen Farrell
[Ballot comment]


- 5.4: This is based on rfc 6074, the security
considerations of which say that automated security
mechanisms are recommended as a …
[Ballot comment]


- 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?
2013-11-19
15 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2013-11-18
15 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2013-11-15
15 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder
2013-11-15
15 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder
2013-11-14
15 Jean Mahoney Request for Telechat review by GENART is assigned to Wassim Haddad
2013-11-14
15 Jean Mahoney Request for Telechat review by GENART is assigned to Wassim Haddad
2013-10-30
15 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2013-10-29
15 Stewart Bryant Placed on agenda for telechat - 2013-11-21
2013-10-29
15 Stewart Bryant Changed consensus to Yes from Unknown
2013-10-29
15 Stewart Bryant Ballot has been issued
2013-10-29
15 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2013-10-29
15 Stewart Bryant Created "Approve" ballot
2013-10-29
15 Stewart Bryant Ballot writeup was changed
2013-10-02
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-10-02
15 Yakov Rekhter IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-10-02
15 Yakov Rekhter New version available: draft-ietf-l2vpn-vpls-mcast-15.txt
2013-09-30
14 Stewart Bryant Waiting revised ID resulting from RTG DIR review
2013-09-30
14 Stewart Bryant State changed to Waiting for Writeup::Revised I-D Needed from Waiting for AD Go-Ahead::Revised I-D Needed
2013-09-30
14 Stewart Bryant Waiting for update following external review
2013-09-30
14 Stewart Bryant State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup::External Party
2013-09-26
14 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Catherine Meadows.
2013-09-24
14 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2013-09-24
14 David Black Request for Last Call review by TSVDIR Completed: Ready with Nits. Reviewer: David Black.
2013-09-23
14 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2013-09-23
14 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-l2vpn-vpls-mcast-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-l2vpn-vpls-mcast-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

The document says, "This document defines a new NLRI, called MCAST-VPLS, to be carried in BGP using multiprotocol extensions. It requires assignment of a new SAFI. This is to be assigned by IANA."

QUESTION: This appears to be requesting a new SAFI Value in http://www.iana.org/assignments/safi-namespace. Is this correct?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2013-09-23
14 Stewart Bryant Waiting for RDG DIR reviewer report which is expected end of this week.
2013-09-23
14 Stewart Bryant State changed to Waiting for Writeup::External Party from Waiting for Writeup
2013-09-23
14 (System) State changed to Waiting for Writeup from In Last Call (ends 2013-09-23)
2013-09-10
14 Martin Stiemerling Request for Last Call review by TSVDIR is assigned to David Black
2013-09-10
14 Martin Stiemerling Request for Last Call review by TSVDIR is assigned to David Black
2013-09-05
14 Jean Mahoney Request for Last Call review by GENART is assigned to Wassim Haddad
2013-09-05
14 Jean Mahoney Request for Last Call review by GENART is assigned to Wassim Haddad
2013-09-05
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Catherine Meadows
2013-09-05
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Catherine Meadows
2013-09-03
14 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-09-03
14 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multicast in VPLS) to Proposed …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multicast in VPLS) to Proposed Standard


The IESG has received a request from the Layer 2 Virtual Private Networks
WG (l2vpn) to consider the following document:
- 'Multicast in VPLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  [RFC4761] and [RFC4762] describe a solution for Virtual Private LAN
  Service (VPLS) multicast that relies on the use of point-to-point or
  multipoint-to-point unicast Label Switched Paths (LSPs) for carrying
  multicast traffic. This solution has certain limitations for certain
  VPLS multicast traffic profiles. For example, it may result in highly
  non-optimal bandwidth utilization when large amount of multicast
  traffic is to be transported.

  This document describes a solution for overcoming a subset of the
  limitations of existing VPLS multicast solution. It describes
  procedures for VPLS multicast that utilize multicast trees in the
  service provider (SP) network. The solution described in this
  document allows sharing of one such multicast tree among multiple
  VPLS instances. Furthermore, the solution described in this document
  allows a single multicast tree in the SP network to carry traffic
  belonging only to a specified set of one or more IP multicast streams
  from one or more VPLS instances.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-mcast/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-mcast/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1939/
  http://datatracker.ietf.org/ipr/1117/



2013-09-03
14 Amy Vezza State changed to In Last Call from Last Call Requested
2013-09-02
14 Stewart Bryant Last call was requested
2013-09-02
14 Stewart Bryant Ballot approval text was generated
2013-09-02
14 Stewart Bryant Ballot writeup was generated
2013-09-02
14 Stewart Bryant State changed to Last Call Requested from AD Evaluation::AD Followup
2013-09-02
14 Stewart Bryant Last call announcement was changed
2013-09-02
14 Stewart Bryant Last call announcement was generated
2013-07-02
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-07-02
14 Yakov Rekhter New version available: draft-ietf-l2vpn-vpls-mcast-14.txt
2013-05-31
13 Stewart Bryant
I apologize for the length of time that I have taken with
this draft, however I found that it was a particularly
difficult text to …
I apologize for the length of time that I have taken with
this draft, however I found that it was a particularly
difficult text to read and understand, particularly the
earlier text which has the purpose of setting out the
solution for the reader.

I recognize that the draft describes an existing, deployed
technology, and as such I have no desire to change the
definition of the technology. However I do have
significant concerns over the earlier sections of
the text. The purpose of a Standards Track
RFC is to describe a technology such that a competent
engineer that did not take part in the IETF process can
read the it,  together with its normative references,
and then correctly and safely implement or operate
the technology, in a way that is interoperable with
other equipments and deployments. It is my opinion
this in this regard that the text falls short.

When I first reviewed the draft I found it pretty much
impenetrable, mainly due to its density, repetition and
lack of precise consistent definitions, and on a
second reading reached the same conclusion. I have
commissioned a early Routing Directorate review of the
draft, and although the review is not yet complete
preliminary discussions with the reviewer indicate
concurrence with this view. Thus I fear that if
we plough on with the publication process these
concerns will be echoed in the reviews that follow
AD evaluation.

I read the text a third time and I provide my own
detailed review comments inline. A revised ID is
certainly needed and I have changed the state to
indicate that. I hope that the shepherd will work
with you in the resolving these comments, and I would
suggest that you engage the L2VPN working group in
the verification of the correctness of the changes
and the clarity of any new or revised text.

Regards

Stewart


========

                  Draft-ietf-l2vpn-vpls-mcast-13.txt

========
Talking to the chairs we seems that this draft
has a number of components:

- The framework
- An underlay system with a number of options
- An overlay for L2
- An overlay for IP.

Now my view is that this might have been more manageable
and easier for a new reader if it had been written as
perhaps four (or more) smaller drafts with the above
structure.

However I assume that we are to continue with a single
draft and I suspect that it would be a lot more readable
if the  was more obviously structured in a format similar
to the above so the reader knew more clearly which aspect
of the problem they were dealing with and could better
focus on the elements of the networking problem that
they were concerned with at the time.

Also I think that you need to give serious consideration
to providing a manageability section. From previous experience with
Ops Directorate reviews I think that you are going to be asked
for more text on operations and management.

=======

Abstract

  This document describes a solution for overcoming a subset of the
  limitations of existing VPLS multicast solutions.
SB> I think that it would be would be better for the reader if you
SB> started with a succinct definition of the  problem.
SB>
SB> VPLS is not an IETF "known" term. The RFC Editor has a list
SB> of terms that it assumes everyone knows. All other terms
SB> need to be expanded on first use, and in the case of this
SB> draft could usefully be include in the terminology section.
SB>
SB> If we don't do this it will be a lot of work for the RFCeditor
SB> and then the authors will need to select or verify the proposed
SB> expansions in Auth48, so please scrub the document for unexpanded
SB> terms.

  It describes
  procedures for VPLS multicast that utilize multicast trees in the
  sevice provider (SP) network.  One such multicast tree can be shared
SB> sevice - typo
  between multiple VPLS instances.  Procedures by which a single
  multicast tree in the SP network can be used to carry traffic
  belonging only to a specified set of one or more IP multicast streams
  from one or more VPLSes are also described.

SB> s/VPLSes/VPLS instances/


Internet Draft    draft-ietf-l2vpn-vpls-mcast-13.txt      January 2013


Table of Contents

1          Specification of requirements  .........................  4
2          Contributors  ..........................................  4
3          Terminology  ...........................................  5
4          Introduction  ..........................................  5
5          Existing Limitations of VPLS Multicast  ................  6
6          Overview  ..............................................  6
6.1        Inclusive and Selective Multicast Trees  ...............  6
6.2        BGP-Based VPLS Membership Auto-Discovery  ..............  8
6.3        IP Multicast Group Membership Discovery  ...............  8
6.4        Advertising P-Multicast Tree to VPLS/C-Multicast Binding ..9
6.5        Aggregation  ...........................................  10
6.6        Inter-AS VPLS Multicast  ...............................  10
7          Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding11
7.1        Originating intra-AS VPLS A-D routes  ..................  12
7.2        Receiving intra-AS VPLS A-D routes  ....................  12
8          Demultiplexing P-Multicast Tree Traffic  ...............  14
8.1        One P-Multicast Tree - One VPLS Mapping  ...............  14
8.2        One P-Multicast Tree - Many VPLS Mapping  ..............  14
9          Establishing P-Multicast Trees  ........................  15
9.1        Common Procedures  .....................................  15
9.2        RSVP-TE P2MP LSPs  .....................................  16
9.2.1      P2MP TE LSP - VPLS Mapping  ............................  16
9.3        Receiver Initiated MPLS Trees  .........................  17
9.3.1      P2MP LSP - VPLS Mapping  ...............................  17
9.4        Encapsulation of Aggregate P-Multicast Trees  ..........  17
10          Inter-AS Inclusive P-Multicast Tree A-D/Binding  .......  17
10.1        VSIs on the ASBRs  .....................................  18
10.1.1      Option (a): VSIs on the ASBRs  .........................  18
10.1.2      Option (e): VSIs on the ASBRs  .........................  18
10.2        Option (b) - Segmented Inter-AS Trees  .................  19
10.2.1      Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding  ....  19
10.2.2      Propagating BGP VPLS A-D routes to other ASes: Overview ..20
10.2.2.1    Propagating Intra-AS VPLS A-D routes in EBGP  ..........  21
10.2.2.2    Inter-AS A-D route received via EBGP  ..................  22
10.2.2.3    Leaf A-D Route received via EBGP  ......................  24
10.2.2.4    Inter-AS A-D Route received via IBGP  ..................  24
10.3        Option (c): Non-Segmented Tunnels  .....................  25
11 Optimizing Multicast Distribution via Selective Trees
.  26
11.1        Protocol for Switching to Selective Trees  .............  27
11.2        Advertising (C-S, C-G) Binding to a Selective Tree  ....  28
11.3        Receiving S-PMSI A-D routes by PEs  ....................  30
11.4        Inter-AS Selective Tree  ...............................  32
11.4.1      VSIs on the ASBRs  .....................................  33
11.4.1.1    VPLS Inter-AS Selective Tree A-D Binding  ..............  33
11.4.2      Inter-AS Segmented Selective Trees  ....................  33
11.4.2.1    Handling S-PMSI A-D routes by ASBRs  ...................  34
11.4.2.1.1  Merging Selective Tree into an Inclusive Tree  .........  35
11.4.3      Inter-AS Non-Segmented Selective trees  ................  36
12          BGP Extensions  ........................................  36
12.1        Inclusive Tree/Selective Tree Identifier  ..............  36
12.2        MCAST-VPLS NLRI  .......................................  37
12.2.1      S-PMSI A-D route  ......................................  38
12.2.2      Leaf A-D route  ........................................  39
13          Aggregation Considerations  ............................  39
14          Data Forwarding  .......................................  40
14.1        MPLS Tree Encapsulation  ...............................  40
14.1.1      Mapping multiple VPLS instances to a P2MP LSP  .........  40
14.1.2      Mapping one VPLS instance to a P2MP LSP  ...............  41
15          VPLS Data Packet Treatment  ............................  42
16          Security Considerations  ...............................  43
17          IANA Considerations  ...................................  44
18          Acknowledgments  .......................................  44
19          Normative References  ..................................  44
20          Informative References  ................................  45
21          Author's Address  ......................................  46








3. Terminology


  This document uses terminology described in [RFC4761] And [RFC4762].

  In this document we refer to various auto-discovery routes, as "A-D
  routes".

SB> As far as I can tell you have not precisely alignmed the
SB> terminology with the terminology in the texts that you reference.
SB>
SB> In any case there seem to be terms in here that you assume are
SB> defined over there, but which are not over there. I think that
SB> you need a scub of the terminology to make sure that if it is
SB> over there you reference it as such (and that it is precisely
SB> aligned). If it is not in your references you need a precise
SB> definition in this section.
SB>
SB> Additionally it would be useful to the raeder to at least list
SB> the terms which are used from these RFCs

4. Introduction

SB> For someone who is not familiar with Inclusive, Aggregate
SB> Inclusive, Selective and Aggregate Selective, this section is
SB> very difficult to follow. Starting off with some general
SB> definitions of these terms or a reference to other RFCs (may be
SB> under the terminology section) would certainly help the reader.
SB>
SB> Alternatively you could include a forward reference to
SB> section 6.1, but that is less helpful to the reader than
SB> moving them earlier in the draft.

  [RFC4761] and [RFC4762] describe a solution for VPLS multicast that
  relies on the use of P2P RSVP-TE or MP2P LDP LSPs, referred to as
  Ingress Replication In this document.

SB> Ingress Replication does not seem to be defined either in this
SB> text or the referenced text.

  This solution

SB> "This solution" - Do you mean or the solution defined here?
SB> Do you mean: “for the use of pseudowires transported over P2P
SB> RSVP-TE or MP2P …

  has certain
  limitations for certain VPLS multicast traffic profiles. For example,
  it may result in highly non-optimal bandwidth utilization in the MPLS
  network when large amount of multicast traffic is to be transported.

SB> You say plural limitations but you only specify one.

  This document describes procedures for overcoming the limitations of
  existing VPLS multicast solutions. It describes procedures for VPLS
  multicast that utilize multicast trees in the Service Provider (SP)
  network. The procedures described in this document are applicable to
  both [RFC4761] and [RFC4762].

  It provides mechanisms that allow a single multicast distribution
SB> Please say what "it" is.

  tree in the Service Provider (SP) network to carry all the multicast
  traffic from one or more VPLS sites connected to a given PE,
  irrespective of whether these sites belong to the same or different
  VPLSes. Such a tree is referred to as an "Inclusive tree" and more
SB> Since the term VPLS has multiple definitions (solution, network, service),
SB> perhaps it is better to use VPLS instances here?
  specifically as an "Aggregate Inclusive tree" when the tree is used
  to carry multicast traffic from more than one VPLS.

SB> You need to define the difference between an IT and an AIT?
SB> s/VPLS/VPLS instances/

  This document also provides procedures by which a single multicast
  distribution tree in the SP network can be used to carry traffic
  belonging only to a specified set of IP multicast streams, originated
  in one or more VPLS sites connected to a given PE, irrespective of
  whether these sites belong to the same or different VPLSes. 

SB> It might be useful to introduce the problem before introducing
SB> the solution - minor reordering.
SB> Given the association of VPLS with Ethernet, why do you only
SB> provide this service for IP packets?

  Such a
  tree is referred to as a "Selective tree" and more specifically as an
  "Aggregate Selective tree" when the IP multicast streams belong to
  different VPLSes. This allows multicast traffic, by default, to be
  carried on an Inclusive tree, while traffic from some specific
  multicast streams, e.g., high bandwidth streams, could be carried on
  one of the "Selective trees".


SB> Some figures/reference models in the draft would really help
SB> the reader to understand the problem. They need to be early
SB> in the text, such as here.


5. Existing Limitations of VPLS Multicast


  One of the limitations of existing VPLS multicast solutions described
  in [RFC4761] and [RFC4762] is that they rely on ingress replication.
  Thus, the ingress PE replicates the multicast packet for each egress
  PE and sends it to the egress PE using a unicast tunnel.

SB> This text would have been useful earlier.
SB> Also much of this text seems to repeat earlier text and I would
SB> suggest that you remove it.

  Ingress Replication may be an acceptable model when the bandwidth of
  the multicast traffic is low or/and the number of replications
  performed on average on each outgoing interface for a particular
  customer VPLS multicast packet is small.
SB> Is this a run on sentence?
  If this is not the case it
  is desirable to utilize multicast trees in the SP network to transmit
  VPLS multicast packets [RFC5501].
SB> There’s no explicit mention of “broadcast”. Would it fit under the
SB> multicast or unicast treatment?

  Note that unicast packets that are
  flooded to each of the egress PEs, before the ingress PE learns the
  destination MAC address of those unicast packets, MAY still use
  ingress replication.

SB> Again, I think that a consistent single intro to the problem
SB> would be much more helpful to the reader in getting up to speed
SB> with the applicability of the solution you are about to describe.


6. Overview


  This document describes procedures for using multicast trees in the
  SP network to transport VPLS multicast data packets.

SB> This text seems to repeat text that you wrote earlier.
SB> At this stage I was confused as to whether or not
SB> you were only concerned with MPLS m/c trees. You clarify
SB> this later, but I think that the raeder would find it
SB> useful if you cleared this up earlier?

  RSVP-TE P2MP
  LSPs described in [RFC4875] are an example of such multicast trees.
  The use of multicast trees in the SP network can be beneficial when
  the bandwidth of the multicast traffic is high or when it is
  desirable to optimize the number of copies of a multicast packet
  transmitted on a given link.

SB> Again this seems to be repeated text.

  This comes at a cost of state in the SP
  network to build multicast trees and overhead to maintain this state.
  This document describes procedures for using multicast trees for VPLS
  multicast when the provider tunnels are P2MP LSPs signaled by either
  P2MP RSVP-PE or mLDP [RFC6388].

SB> Again I think this is repeated text.
SB> You seem to be saying m/c trees are a state problem
SB> so we are going to use them, when think you mean to say
SB> m/c trees are a state problem but we are going to show how
SB> to use them efficiently. Please consider integrating
SB> this text with 6.1.

  This document uses the prefix 'C' to refer to the customer control or
  data packets and 'P' to refer to the provider control or data
  packets.

SB> This notation needs to be much easier to find - perhaps in
SB> it should be in the terminology section?

  An IP (multicast source, multicast group) tuple is
  abbreviated to (S, G).

SB> Again this is almost certainly better placed in terminology.


6.1. Inclusive and Selective Multicast Trees

SB> You strongly hint at this before. It would be better to unify
SB> the definitions of the m/c tree types so as to make a
SB> more efficient description that the reader can get their
SB> heads around the first time they meet this.

  Multicast trees used for VPLS can be of two types:

SB> It would be useful if things like Inc P-m/c tree were in terminology.

    + Inclusive trees. This option supports the use of a single
      multicast distribution tree, referred to as an Inclusive P-
      Multicast tree, in the SP network to carry all the multicast
      traffic from a specified set of VPLS sites connected to a given
      PE. There is no assumption made with respect to whether this
      traffic is IP encapsulated or not. A particular P-Multicast tree
      can be set up to carry the traffic originated by sites belonging
      to a single VPLS, or to carry the traffic originated by sites
      belonging to different VPLSes. The ability to carry the traffic
      of more than one VPLS on the same tree is termed Aggregation. The
      tree needs to include every PE that is a member of any of the
      VPLSes that are using the tree. This implies that a PE may
      receive multicast traffic for a multicast stream even if it
      doesn't have any receivers that are interested in receiving
      traffic for that stream.

SB> This would have been better earlier in place of the partial
SB> definitions above.

      An Inclusive P-Multicast tree as defined in this document is a
      P2MP tree.  A P2MP tree is used to carry traffic only from VPLS
      sites that are connected to the PE that is the root of the tree.

SB> This seems to be repeated text, and does the following text.

    + Selective trees. A Selective P-Multicast tree is used by a PE to
      send IP multicast traffic for one or more specific IP multicast
      streams, received by a PE over PE-CE interfaces 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
SB> Please clarify which PEs?
      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
      Aggregation. The reason for having Selective P-Multicast trees is
      to provide a PE the ability to create separate SP multicast trees
      for specific multicast streams, e.g. high bandwidth multicast
      streams. This allows traffic for these multicast streams to reach
      only those PE routers that have receivers in these streams. This
SB> s/in/for/
      avoids flooding other PE routers in the VPLS.

SB> Again this seems to be repeating earlier text

SB> I think you are saying that an ST is an IT with IP m/c filtering
SB? is that correct?

  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 must be used only for IP multicast data traffic. The
  use of Selective P-Multicast trees for non-IP multicast traffic is
  outside the scope of this document.

SB> The normal ordering is A or B or A+B, but it's up to you.

  A variety of transport technologies may be used in the SP network.

SB> I am not sure these are transport technologies. They do not
SB> fit the ITU use of the term nor the layer four use. I think
SB> you really mean network layer technologies.

  For inclusive P-Multicast trees, these transport technologies include
  point-to-multipoint LSPs created by RSVP-TE or mLDP. For selective P-
  Multicast trees, unicast PE-PE tunnels (using MPLS or IP/GRE

SB> Why unicast? You said you were using p2mp in the SP layer!

  encapsulation) and P2MP LSPs are supported, and the supported P2MP
  LSP signaling protocols are RSVP-TE, and mLDP. Other transport
  technologies are outside the scope of this document.

SB> You only support MPLS - is that correct? If so where does
SB> IP/GRE come into it?

  This document also describes the data plane encapsulations for
  supporting the various SP multicast transport options.

SB> Again I am confused over the term "transport".

6.2. BGP-Based VPLS Membership Auto-Discovery


  In order to establish Inclusive P-Multicast trees for one or more
  VPLSes, when aggregation is performed (with either mLDP or P2MP RSVP-
  TE as the tunneling technology), or when the tunneling technology is
  P2MP RSVP-TE, the PE acting as a root of a P2MP LSP must be able to
  discover the other PEs that have membership in one or more of these
  VPLSes (these other PEs act as leaves of that P2MP LSP). This
  document uses the BGP-based procedures described in [RFC4761] and
  [RFC6074] for discovering the VPLS membership of all PEs. When no
  aggregation is performed and the tunneling technology is mLDP, then
  the root of the P2MP LSP need not discover the other PEs that are the
  leaves of that LSP.

SB> I do not understand the logic that gets you to the above
SB> statement or why the different behaviors?

SB> Re the text up to PSMP LSP)
SB> Please consider revising, too long to follow.
SB>
SB> This is confusing: when mLDP is used, the root doesn’t need to
SB> discover the leaf nodes for inclusive multicast. However,
SB> this sentence implies otherwise.



  The leaves of the Inclusive P-Multicast tree must also be able to
  auto-discover the identifier of the tree (note that this applies when
  the tree is established by either mLDP or P2MP RSVP-TE).  This is
  described in section 6.4.

SB> It is the procedures that is described in 6.4. I assume that you
SB> are saying that you always need to discover the tree identity.
SB> The way that you express it leaves a mild doubt.

6.3. IP Multicast Group Membership Discovery


  The setup of a Selective P-Multicast tree for one or more IP
  multicast (C-S, C-G)s, requires the ingress PE to learn the PEs that
  have receivers in one or more of these (C-S, C-G)s, in the following
  cases:

    + When aggregation is used OR

SB> Why in the case of mLDP - this is not clear?

    + When the tunneling technology is P2MP RSVP-TE

    +  If ingress replication is used and the ingress PE wants to send
      traffic for (C-S, C-G)s to only those PEs that are on the path to
      receivers for the (C-S,C-G)s.

SB> It would be helpful if you explained the overarching reason
SB> and then perhaps a list rather than leaving the reader to puzzle.

  For discovering the IP multicast group membership, this document
  describes procedures that allow an ingress PE to enable explicit
  tracking.

SB> Tracking of what?

  Thus an ingress PE can request the IP multicast membership
  from egress PEs for one or more C-multicast streams. These procedures
  are described in section "Optimizing Multicast Distribution via
  Selective Trees".

SB> You should consider rewording the above two sentences for clarity.

  These procedures are applicable when IGMP is used as the multicast
  signaling protocol between the VPLS CEs. They are also applicable
  when PIM as specified in [RFC4601] 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 PIM join
  suppression is not disabled on all the CEs. Procedures for this case
  are for further study.

SB> Why is this? The rationale for all of these conditions is not
SB> captured. A reader who was not involved in writing this draft has
SB> no idea as to why these restrictions are in place.

  The leaves of the Selective P-Multicast trees must also be able to
  discover the identifier of the tree. This is described in section
  6.4.

SB> Identifier of which tree?


6.4. Advertising P-Multicast Tree to VPLS/C-Multicast Binding


  This document describes procedures based on BGP VPLS Auto-Discovery
  (A-D)

SB> This needs a reference and is also a good candidate for the terminology
SB> section.

  that are used by the root of an Aggregate P-Multicast tree to
  advertise the Inclusive or Selective P-Multicast tree binding and the
  de-multiplexing information to the leaves of the tree. This document
  uses the PMSI Tunnel attribute [RFC6514] for this purpose.
SB> PMSI needs expanding


  Once a PE decides to bind a set of VPLSes or customer multicast

SB> You need to be clear whether this is an ingress, egress or
SB> either type of PE, and how the decision to bind is taken.

  groups to an Inclusive P-Multicast tree or a Selective P-Multicast
  tree, it needs to announce this binding to other PEs in the network.
  This procedure is referred to as Inclusive P-Multicast tree or
  Selective P-Multicast tree binding distribution and is performed
  using BGP.

  When an Aggregated Inclusive P-Multicast tree is used by an ingress
  PE, this discovery implies that an ingress PE MUST announce the
SB> What discovery?
  binding of all VPLSes bound to the Inclusive P-Multicast tree to the
  other PEs.
SB> Why to all?

  The inner label assigned by the ingress PE for each VPLS
  MUST be included, if more than one VPLS is bound to the same P-
  Multicast tree. The Inclusive P-Multicast tree Identifier MUST be
  included.

  For a Selective P-Multicast tree this discovery implies announcing
  all the specific  entries bound to this P-Multicast tree
  along with the Selective P-Multicast tree Identifier. The inner label
  assigned for each  MUST be included if s from
  different VPLSes are bound to the same P-Multicast tree. The labels
  MUST be distinct on a per VPLS basis and MAY be distinct on a per  basis.  The Selective P-Multicast tree Identifier MUST be
  included.

6.5. Aggregation


  As described above the ability to carry the traffic of more than one
  VPLS on the same P-Multicast tree is termed 'Aggregation'. Both
  Inclusive and Selective P-Multicast trees support aggregation.

  Aggregation enables the SP to place a bound on the amount of
  multicast tree forwarding and control plane state which the P routers
  must have. 

SB> Re all of the above, this seems similar to text earlier in the draft.

  Let us call the number of VPLSes aggregated onto a single
  P-Multicast tree as the "Aggregation Factor". When Inclusive source
  P-Multicast trees are used the number of trees that a PE is the root
  of is proportional to:

    + (Number of VPLSes on the PE / Aggregation Factor).


  In this case the state maintained by a P router, is proportional to:

    + ((Average number of VPLSes on a PE / Aggregation Factor) * number
      of PEs) / (Average number of P-Multicast trees that transit a
      given P router)


  Thus, the state does not grow linearly with the number of VPLSes.

SB> Isn't the above sort of obvious? It might be useful to comment
SB> on the expected range of AFs.

  Aggregation requires a mechanism for the egresses of the P-Multicast
  tree to demultiplex the multicast traffic received over the P-
  Multicast tree.  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."

SB> Spurious """


6.6. Inter-AS VPLS Multicast


  This document supports four models of inter-AS VPLS service, option
  (a), (b), (c), and (e).

SB> You do not explain to the reader
SB>
SB> 1) Where on earth options a..b,e come from.
SB> 2) What they are in a more meaningful name.

  Options (a), (b), and (c) are very similar
  conceptually to options (a), (b) and (c) specified in [RFC4364]

SB> I just grepped [RFC4364] and the only time "option" occurs
SB> is in conjunction with MD5 at least in the normative text.
SB> You either need a concise definition here and a pointer
SB< to a precise definition, or a precise definition.
SB>
SB> This is an important point because you can't follow
SB> a lot of what follows without these definitions.


  For
  IP VPNs. These options described here are also similar to the three
  options described in [RFC4761], Which in turn extends the concepts of
  [RFC4364] to inter-AS VPLS.

SB> Again the definitions in tbe referenced text seems to be
SB> missing.



  For option (a) and option (b) support, this document specifies a
  model where Inter-AS VPLS service can be offered without requiring a
  single P-Multicast tree to span multiple ASes. There are two variants
  of this model and they are described in section 10.

SB> Again the above is impossible to understand  because the reader has no
SB> idea what option(a/b) is at this point.

  For option (c) support this document specifies a model where Inter-AS
  VPLS service is offered by requiring a single P-Multicast tree to

  span multiple ASes. This is because in the case of option (c) the
  ASBRs do not exchange BGP-VPLS NLRIs or A-D routes.

  In addition, this document also specifies option (e), which one may
  think of as a variant of option (a).

SB> So option(e) is not defined in any of the referenced text and the
SB> reader so far has no idea at all what it is.

SB> It's not clear where you use the option notation until you list it
SB> all again much later.

7. Intra-AS Inclusive P-Multicast Tree Auto-discovery/Binding


  This section specifies procedures for the intra-AS auto-discovery of
  VPLS membership and the distribution of information used to
  instantiate P-Multicast Tunnels.

  VPLS auto-discovery/binding consists of two components: intra-AS and
  inter-AS. The former provides VPLS auto-discovery/binding within a
  single AS. The latter provides VPLS auto-discovery/binding across
  multiple ASes. Inter-AS auto-discovery/binding is described in
  section 10.

  VPLS auto-discovery using BGP as described in [RFC4761, RFC6074]
  enables a PE to learn the VPLS membership of other PEs. A PE that
  belongs to a particular VPLS announces a BGP Network Layer
  Reachability Information (NLRI) that identifies the Virtual Switch
  Instance (VSI). This NLRI is constructed from the  tuple. The
  NLRI defined in [RFC4761] comprises the  tuple and label
  blocks for PW signaling. The VE-ID in this case is a two octet
  number. The NLRI defined in [RFC6074] comprises only the
  where the VE-ID is a four octet number.

  The procedures for constructing Inclusive intra-AS and inter-AS trees
  as specified in this document require the BGP A-D NLRI to carry only
  the . Hence these procedures can be used for both BGP-VPLS
  and LDP-VPLS with BGP A-D.

  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. In fact 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 [RFC6074], to enable automatic setup of
  PWs, requires FEC 129 [RFC4447]. However FEC 129 is not required in
  order to use procedures in this document for LDP-VPLS.  An LDP-VPLS
  implementation that supports this document MUST support the BGP A-D
  procedures to setup P-Multicast trees, as described here, and it MAY
  support FEC 129 to automate the signaling of PWs.

SB> Please look to see if the above can be expressed more clearly.


7.1. Originating intra-AS VPLS A-D routes


  To participate in the VPLS auto-discovery/binding a PE router that
  has a given VSI of a given VPLS originates an BGP VPLS intra-AS A-D
SB> s/an/a/
  route and advertises this route in Multi-Protocol (MP) IBGP. The
  route is constructed as described in [RFC4761] and [RFC6074].

SB> This seems to be a repetition of earlier text

  The route carries a single L2VPN NLRI with the RD set to the RD of
  the VSI, and the VE-ID set to the VE-ID of the VSI.  The route also
  carries one or more Rout Targets (RTs) as specified in [RFC4761] and
  [RFC6074].

SB>s/Rout/Route/

  If an Inclusive P-Multicast tree is used to instantiate the provider
  tunnel for VPLS multicast on the PE, the advertising PE MUST
  advertise the type and the identity of the P-Multicast tree in the
  PMSI Tunnel attribute [RFC6514]. This attribute is described in
  section 12.1.

  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 A-D routes for these VPLSes,
  then aggregation requires the PE to re-advertise these routes. The
  re-advertised routes MUST be the same as the original ones, except
  for the PMSI Tunnel attribute.
SB> Why the MUST?

  If the PE has not previously
  advertised intra-AS A-D routes for these VPLSes, then the aggregation
  requires the PE to advertise (new) intra-AS A-D routes for these
  VPLSes. 
SB> This seems obvious, I am wondering whether the order of cases
SB> called up is counter intuitive which then causes this to grate a bit.


  The PMSI 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.

SB> Distinct over what space?
SB> Re "re-advertised"
SB> Even a new route must have a distinct label

  Discovery of PE capabilities in terms of what tunnels types they
  support is outside the scope of this document. Within a given AS PEs
  participating in a VPLS are expected to advertise tunnel bindings
  whose tunnel types are supported by all other PEs that are
  participating in this VPLS and are part of the same AS.


7.2. Receiving intra-AS VPLS A-D routes


  When a PE receives a BGP Update message that carries an intra-AS A-D
  route such that (a) the route was originated by some other PE within
  the same AS as the local PE, (b) at least one of the Route Targets of
  the route matches one of the import Route Targets configured for a
  particular VSI on the local PE, (c) the BGP route selection
  determines that this is the best route with respect to the NLRI
  carried by the route, and (d) the route carries the PMSI Tunnel
  attribute, the PE performs the following.

  If the route carries the PMSI Tunnel attribute then:
SB> We only got here because Condition (d) above confirmed
SB> that the route did indeed carry this attribute. So, this check
SB> is not needed.

    + If the Tunnel Type in the PMSI Tunnel attribute is set to LDP
      P2MP LSP, the PE SHOULD join the P-Multicast tree whose identity
      is carried in the PMSI Tunnel attribute.

    + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE
      P2MP LSP,

SB> Didn't you say earlier: "Discovery of PE capabilities in terms of what
SB> tunnels types they support is outside the scope of this document."

      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.

SB> Re whole para
SB> It might make sense to defer this bullet till after the very last
SB> paragraph of this section, i.e. the one that starts with “If the local
SB> PE uses RSVP-TE P2MP LSP for sending (multicast)  traffic.” That,
SB> I think, provides a more logical flow.

    + If the PMSI Tunnel attribute does not carry a label, then all
      packets that are received on the P-Multicast tree, as identified
      by the PMSI Tunnel attribute, are forwarded using the VSIs that
      have at least one of its import Route Targets that matches one of
      the Route Targets of the received A-D route.

    + If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP
      LSP or RSVP-TE P2MP LSP, and the attribute also carries an MPLS
      label, then the egress PE MUST treat this as an upstream-assigned
      label, and all packets that are received on the P-Multicast tree,
      as identified by the PMSI Tunnel attribute, with that upstream
      label are forwarded using the VSIs that have at least one of its
      import Route Target that matches one of the Route Targets of the
      received intra-AS A-D route.


  If the local PE uses RSVP-TE P2MP LSP for sending (multicast)
  traffic, originated by VPLS sites connected to the PE, to the sites
  attached to other PEs then the local PE MUST use the Originating
  Router's IP address information carried in the intra-AS A-D route to
  add the PE, that originated the route, as a leaf node to the LSP.
  This MUST be done irrespective of whether the received Intra-AS A-D
  route carries the PMSI Tunnel attribute or not.

8. Demultiplexing P-Multicast Tree Traffic


  Demultiplexing received VPLS traffic requires the receiving PE to
  determine the VPLS instance the packet belongs to. The egress PE can
  then perform a VPLS lookup to further forward the packet. It also
  requires the egress PE to determine the identity of the ingress PE
  for MAC learning, as described in section 15.


8.1. One P-Multicast Tree - One VPLS Mapping


  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,
  e.g.,: 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).


8.2. One P-Multicast Tree - Many VPLS Mapping


  As traffic belonging to multiple VPLSes can be carried over the same
  tree, there is a need to identify the VPLS the packet belongs to.
  This is done by using an inner label that determines the VPLS for
  which the packet is intended. The ingress PE uses this label as the
  inner label while encapsulating a customer multicast data packet.
  Each of the egress PEs must be able to associate this inner label
  with the same VPLS and use it to demultimplex the traffic received
SB> s/demultimplex/demultiplex/
  over the Aggregate Inclusive tree or the Aggregate Selective tree.

SB> Again this seems to repeat earlier text

  If traffic from multiple VPLSes is carried on a single tree,
  upstream-assigned labels [RFC5331] MUST be used. Hence the inner
  label is assigned by the ingress PE.  When the egress PE receives a
  packet over an Aggregate tree, the outer encapsulation (in the case
  of MPLS P2MP LSPs, the outer MPLS label) specifies the label space to
  perform the inner label lookup. The same label space MUST be used by
  the egress PE for all P-Multicast trees that have the same root
  [RFC5331].

  If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the
  outer MPLS label and optionally 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 once it is known to the egress PE
  that the tree is bound to one or more VPLSes. Once the label
  representing the tree is popped off the MPLS label stack, the next
  label is the demultiplexing information that allows the proper VPLS
  instance to be determined.

  The ingress PE informs the egress PEs about the inner label as part
  of the tree binding procedures described in section 12.


9. Establishing P-Multicast Trees


  This document supports only P2MP P-Multicast trees wherein it is
  possible for egress PEs to identify the ingress PE to perform MAC
  learning.  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.

  A P2MP tree is used to carry traffic originated in sites connected to
  the PE which is the root of the tree. These sites MAY belong to
  different VPLSes or the same VPLS.

SB> Again this seems to repeat earlier text

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
  instances that the packet belongs to. To achieve this the LSP MUST be
  signaled with penultimate-hop-popping (PHP) off and a non-reserved
  MPLS label 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.

SB> The above seems to be a universal statement, in which case perhaps
SB> it could be stated once as a reference to the whole document

  This is because the
  egress PE needs to rely on the MPLS label, that it advertises to its
  upstream neighbor, to determine the P2MP LSP that a C-multicast data
  packet is received on.

  The egress PE also needs to identify the ingress PE to perform MAC
  learning.  When P2MP LSPs are used as P2MP trees, determining the
  P2MP LSP that the packets are received on, is sufficient to determine
  the ingress PE.  This is because the ingress PE is the root of the
  P2MP LSP.

  The egress PE relies on receiving the PMSI Tunnel attribute in BGP to
  determine the VPLS instance to P2MP LSP mapping.



SB> It seems to me that there are a few key invariants that could be
SB> called out such as no PHP and then the rest of the text would
SB> be simpler.
SB>
SB> Is the problem that you have two (or more) classes of solutions that you
SB> are trying to force into a single text?


9.2. RSVP-TE P2MP LSPs


  This section describes procedures that are specific to the usage of
  RSVP-TE P2MP LSPs for instantiating a P-Multicast tree. Procedures in
  [RFC4875] are used to signal the P2MP LSP. The LSP is signaled as the
  root of the P2MP LSP discovers the leaves. The egress PEs are
  discovered using the procedures described in section 7. Aggregation
  as described in this document is supported.


9.2.1. P2MP TE LSP - VPLS Mapping


  P2MP TE LSP to VPLS mapping is learned at the egress PEs using BGP
  based advertisements of the P2MP TE LSP - VPLS mapping. They require
  that the root of the tree include the P2MP TE LSP identifier as the
  tunnel identifier in the BGP advertisements. This identifier contains
  the following information elements:
        - The type of the tunnel is set to RSVP-TE P2MP LSP
        - RSVP-TE P2MP LSP's SESSION Object

  This Tunnel Identifier is described in section 12.1.

  Once the egress PE receives the P2MP TE LSP to VPLS mapping:

    + If the egress PE already has RSVP-TE state for the P2MP TE LSP,
      it MUST begin to assign an MPLS label from the non-reserved label
SB> Reserved labels are now called special purpose labels.

      range, for the P2MP TE LSP and signal this to the previous hop of
      the P2MP TE LSP.  Further it MUST create forwarding state to
      forward packets received on the P2MP LSP.

    + If the egress PE does not have RSVP-TE state for the P2MP TE LSP,
      it MUST retain this mapping. Subsequently when the egress PE
      receives the RSVP-TE P2MP signaling message, it creates the RSVP-
      TE P2MP LSP state.  It MUST then assign an MPLS label from the
      non-reserved label range, for the P2MP TE LSP, and signal this to
      the previous hop of the P2MP TE LSP.

      Note that if the signaling to set up an RSVP-TE P2MP LSP is
      completed before a given egress PE learns, via a PMSI Tunnel
      attribute, of the VPLS or set of VPLSes to which the LSP is
      bound, the PE MUST discard any traffic received on that LSP until
      the binding is received. In order for the egress PE to be able to
      discard such traffic it needs to know that the LSP is associated
      with one or more VPLSes and that the VPLS A-D route that binds
      the LSP to a VPLS has not yet been received. This is provided by
      extending [RFC4875] with [RFC6511].


9.3. Receiver Initiated MPLS Trees


  Receiver initiated P2MP MPLS trees signaled using LDP [RFC6388] can
  also be used. Procedures in [RFC6388] MUST be used to signal the P2MP
  LSP. The LSP is signaled once the leaves receive the LDP FEC for the
  tree from the root as described in section 7. An ingress PE is
  required to discover the egress PEs when aggregation is used and this
  is achieved using the procedures in section 7.

SB> Sentence starting "An ingress PE..."
SB> Why? This is the second time that this is being asserted, in the document,
SB> without providing a reason or rationale to the reader.

9.3.1. P2MP LSP - VPLS Mapping


  P2MP LSP to VPLS mapping is learned at the egress PEs using BGP based
  advertisements of the P2MP LSP - VPLS mapping. They require that the
  root of the tree include the P2MP LSP identifier as the tunnel
  identifier in the BGP advertisements. This identifier contains the
  following information elements:
        - The type of the tunnel is set to LDP P2MP LSP
        - LDP P2MP FEC which includes an identifier generated by the
  root.

  Each egress PE SHOULD "join" the P2MP MPLS tree by sending LDP label
  mapping messages for the LDP P2MP FEC, that was learned in the BGP
  advertisement, using procedures described in [RFC6388].


9.4. Encapsulation of Aggregate P-Multicast Trees


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


10. Inter-AS Inclusive P-Multicast Tree A-D/Binding

SB> Same comments as when I last saw options a..c, e - please
SB> provide a precise definition and maybe even a comparison
SB> table.

  This document supports four options of inter-AS VPLS service, option
  (a), (b), (c) and (e). Of these option (a), (b) and (c) are very
  similar conceptually to option (a), (b) and (c) specified in
  [RFC4364] for IP VPNs. These three options are also similar to the
  three options described in [RFC4761], which in turn extend the
  concepts of [RFC4364] to inter-AS VPLS. An implementation MUST
SB> Why a MUST? Too strong of a requirement. Why not give vendors
SB> greater flexibility
  support all three of these options. When there are multiple ways for
  implementing one of these options this section specifies which one is
  mandatory.  Option (e) is described further down in section 10.1.2.

  For option (a), (b) and (e) support this section specifies a model
  where inter-AS VPLS service can be offered without requiring a single
  P-Multicast tree to span multiple ASes. This allows individual ASes
  to potentially use different P-tunneling technologies. There are two
  variants of this model. One that requires MAC lookup on the ASBRs and
  applies to option (a) and (e). The other is one that does not require
  MAC lookup on the ASBRs and instead builds segmented inter-AS
  Inclusive or Selective trees.  This applies only to option (b).

  For option (c) support this document specifies a model where Inter-AS
  VPLS service is offered by requiring a single Inclusive P-Multicast
  tree to span multiple ASes. This is referred to as a non-segmented P-
  Multicast tree. This is because in the case of option (c) the ASBRs
  do not exchange BGP-VPLS NLRIs or VPLS A-D routes. Selective inter-AS
  trees for option (c) support may be segmented or non-segmented.

SB> It be so useful in understanding the above to have names other
SB> than option(x).

SB> Additionally the following would be so much easier to follow if
SB> there were some reference models/figs somewhere.

10.1. VSIs on the ASBRs


  When VSIs are configured on ASBRs, the ASBRs MUST perform a MAC
  lookup, in addition to any MPLS lookups, to determine the forwarding
  decision on a VPLS packet. The P-Multicast trees are confined to an
  AS. An ASBR on receiving a VPLS packet from another ASBR is required
  to perform a MAC lookup to determine how to forward the packet. Thus
  an ASBR is required to keep a VSI for the VPLS and MUST be configured
  with its own VE ID for the VPLS. The BGP VPLS A-D routes generated by
  PEs in an AS MUST NOT be propagated outside the AS.


10.1.1. Option (a): VSIs on the ASBRs


  When VSIs are configured on ASBRs and option (a) is used then an ASBR
  in one AS treats an adjoining ASBR in another AS as a CE and
  determines the VSI for packets received from that ASBR based on the
  incoming Ethernet interface or VLAN ID. In option (a) the ASBRs do
  not exchange VPLS A-D routes.

  An implementation MUST support option (a).

SB> Please condider find a way to structure this discussion in
SB> a less confusing way.


10.1.2. Option (e): VSIs on the ASBRs


  The VSIs on the ASBRs scheme can be used such that the interconnect
  between the ASBRs is a PW and MPLS encapsulation is used between the
  ASBRs.  An ASBR in one AS treats an adjoining ASBR in another AS as a
  CE and determines the VSI for packets received from another ASBR

SB> Should this be U-PE? VPLS doesn’t define a model where PWs are used
SB> between a PE and a CE. It seems to me that this model makes each ASBR
SB> treat its counterpart as a U-PE with a spoke PW.

  based on the incoming MPLS encapsulation. This is referred to as
  option (e).  The only VPLS A-D routes that are propagated outside the
  AS are the ones originated by ASBRs.  This MPLS PW connects the VSIs
  on the ASBRs and MUST be signaled using the procedures defined in
  [RFC4761] or [RFC4762].

  The P-Multicast trees for a VPLS are confined to each AS and the VPLS
  auto-discovery/binding MUST follow the intra-AS procedures described
  in section 8. An implementation MAY support option (e).


10.2. Option (b) - Segmented Inter-AS Trees


  In this model, an inter-AS P-Multicast tree, rooted at a particular
  PE for a particular VPLS instance, consists of a number of
  "segments", one per AS, which are stitched together at ASBRs. These
  are known as "segmented inter-AS trees". Each segment of a segmented
  inter-AS tree may use a different multicast transport technology. In
  this model, an ASBR is not required to keep a VSI for the VPLS and is
  not required to perform a MAC lookup in order to forward the VPLS
  packet.  This implies that an ASBR is not required to be configured
  with a VE ID for the VPLS. This model is applicable to option (b).

SB> Aren't you describing option (b)?

  An
  implementation MUST support option (b) using this model.

  The construction of segmented Inter-AS trees requires the BGP-VPLS A-
  D NLRI described in [RFC4761, RFC6074]. A BGP VPLS A-D route for a
    tuple advertised outside the AS, to which the originating
  PE belongs, will be referred to as an inter-AS VPLS A-D route (Though
  this route is originated by a PE as an intra-AS route and is referred
  to as an inter-AS route outside the AS).

  In addition to this, segmented inter-AS trees require support for the
  PMSI Tunnel attribute described in section 12.1. They also require
  additional procedures in BGP to signal leaf A-D routes between ASBRs
  as explained in subsequent sections.


10.2.1. Segmented Inter-AS Trees VPLS Inter-AS A-D/Binding


  This section specifies the procedures for inter-AS VPLS A-D/binding
  for segmented inter-AS trees.

  An ASBR must be configured to support a particular VPLS as follows:

    + An ASBR MUST be configured with a set of (import) Route Targets
      (RTs) that specify the set of VPLSes supported by the ASBR. These
      Route Targets control acceptance of BGP VPLS auto-discovery
      routes by the ASBR. Note that instead of being configured, the
      ASBR MAY obtain this set of (import) Route Targets (RTs) by using
      Route Target Constrain [RFC4684].

    + The ASBR MUST be configured with the tunnel types for the intra-
      AS segments of the VPLSes supported by the ASBR, as well as
      (depending on the tunnel type) the information needed to create
      the PMSI Tunnel attribute for these tunnel types. Note that
      instead of being configured, the ASBR MAY derive the tunnel types
      from the intra-AS A-D routes received by the ASBR from the PEs in
      its own AS.

SB> What about the inter-AS segments, how do the ASBRs determine the tunnel
SB> types for those? In a later section, it is mentioned that the inter-AS
SB> tunnel types are set to ingress replication. But the reader is left
SB> wondering here…



  If an ASBR is configured to support a particular VPLS, the ASBR MUST
  participate in the intra-AS VPLS auto-discovery/binding procedures
  for that VPLS within the ASBR's own AS, as defined in this document.

  Moreover, in addition to the above the ASBR performs procedures
  specified in the next section.

SB> Always best to specify the section number - it may change


10.2.2. Propagating BGP VPLS A-D routes to other ASes: Overview

SB> The first two paragraphs of this section are cryptic. A diagram
SB> and thoroughly detailed example can help clear it up. There are
SB> terms being used that do not align with the rest of the document.
R> For e.g., see the next comment.

  An A-D route for a given VPLS, originated by an ASBR within a given
SB> re ASBR Shouldn’t this be “PE” instead?
  AS, is propagated via BGP to other ASes. The precise rules for
  distributing and processing the inter-AS A-D routes are given in
  subsequent sections.

  Suppose that an ASBR A receives and installs an A-D route for VPLS
  "X" and VE ID "V" that originated at a particular PE, PE1. The BGP
  next hop of that received route becomes A's "upstream neighbor" on a
  multicast distribution tree for (X, V) that is rooted at PE1. When
  the A-D routes have been distributed to all the necessary ASes, they
  define a "reverse path" from any AS that supports VPLS X and VE ID V
  back to PE1. For instance, if AS2 supports VPLS X, then there will be
  a reverse path for VPLS X and VE ID V from AS2 to AS1. This path is a
  sequence of ASBRs, the first of which is in AS2, and the last of
  which is in AS1. Each ASBR in the sequence is the BGP next hop of the
  previous ASBR in the sequence.

SB> Re the sentence starting "the BGP next hop..."
SB> What does this mean? How is the tree for a VPLS AND a VE ID?
SB>
SB> What does “upstream neighbor” mean here? Are PE1 and A in the same
SB> AS? Ifo so, then A will become the next hop when the route is
SB> re-advertised by A.

  This reverse path information can be used to construct a
  unidirectional multicast distribution tree for VPLS X and VE ID V,
  containing all the ASes that support X, and having PE1 at the root.
  We call such a tree an "inter-AS tree". Multicast data originating in
  VPLS sites for VPLS X connected to PE1 will travel downstream along
  the tree which is rooted at PE1.

  The path along an inter-AS tree is a sequence of ASBRs. It is still
  necessary to specify how the multicast data gets from a given ASBR to
  the set of ASBRs which are immediately downstream of the given ASBR
  along the tree. This is done by creating "segments": ASBRs in
  adjacent ASes will be connected by inter-AS segments, ASBRs in the
  same AS will be connected by "intra-AS segments".

  For a given inter-AS tree and a given AS there MUST be only one ASBR
  within that AS that accepts traffic flowing on that tree. Further for
  a given inter-AS tree and a given AS there MUST be only one ASBR in
  that AS that sends the traffic flowing on that tree to a particular
  adjacent AS.  The precise rules for accomplishing this are given in
  subsequent sections.

  An ASBR initiates creation of an intra-AS segment when the ASBR
  receives an inter-AS A-D route from an EBGP neighbor.  Creation of
  the segment is completed as a result of distributing, via IBGP, this
  route within the ASBR's own AS.

  For a given inter-AS tunnel each of its intra-AS segments could be
  constructed by its own independent mechanism. Moreover, by using
  upstream-assigned labels within a given AS multiple intra-AS segments
  of different inter-AS tunnels of either the same or different VPLSes
  may share the same P-Multicast tree.

  If the P-Multicast tree instantiating a particular segment of an
  inter-AS tunnel is created by a multicast control protocol that uses
  receiver-initiated joins (e.g, mLDP), and this P-Multicast tree does
  not aggregate multiple segments, then all the information needed to
  create that segment will be present in the inter-AS A-D routes
  received by the ASBR from the neighboring ASBR. But if the P-
  Multicast tree instantiating the segment is created by a protocol
  that does not use receiver-initiated joins (e.g., RSVP-TE, ingress
  unicast replication), or if this P-Multicast tree aggregates multiple
  segments (irrespective of the multicast control protocol used to
  create the tree), then the ASBR needs to learn the leaves of the
  segment. These leaves are learned from A-D routes received from other
  PEs in the AS, for the same VPLS as the one that the segment belongs
  to.

  The following sections specify procedures for propagation of inter-AS
  A-D routes across ASes in order to construct inter-AS segmented
  trees.


10.2.2.1. Propagating Intra-AS VPLS A-D routes in EBGP


  For a given VPLS configured on an ASBR when the ASBR receives intra-
  AS A-D routes originated by PEs in its own AS, the ASBR MUST
  propagate each of these route in EBGP. This procedure MUST be
  performed for each of the VPLSes configured on the ASBR. Each of
  these routes is constructed as follows:

    + The route carries a single BGP VPLS A-D NLRI with the RD and VE
      ID being the same as the NLRI in the received intra-AS A-D route.

    + The Next Hop field of the MP_REACH_NLRI attribute is set to a
      routable IP address of the ASBR.

    + The route carries the PMSI Tunnel attribute with the Tunnel Type
      set to Ingress Replication; the attribute carries no MPLS labels.

    + The route MUST carry the export Route Target used by the VPLS.


10.2.2.2. Inter-AS A-D route received via EBGP


  When an ASBR receives from one of its EBGP neighbors a BGP Update
  message that carries an inter-AS A-D route, if (a) at least one of
  the Route Targets carried in the message matches one of the import
  Route Targets configured on the ASBR, and (b) the ASBR determines
  that the received route is the best route to the destination carried
  in the NLRI of the route, the ASBR re-advertises this inter-AS A-D
  route to other PEs and ASBRs within its own AS.  The best route
  selection procedures MUST ensure that for the same destination, all
  ASBRs in an AS pick the same route as the best route.  The best route
  selection procedures are specified in [RFC4761] and clarified in
  [MULTI-HOMING]. The best route procedures ensure that if multiple
  ASBRs, in an AS, receive the same inter-AS A-D route from their EBGP
  neighbors, only one of these ASBRs propagates this route in IBGP.
  This ASBR becomes the root of the intra-AS segment of the inter-AS
  tree and ensures that this is the only ASBR that accepts traffic into
  this AS from the inter-AS tree.

  When re-advertising an inter-AS A-D route the ASBR MUST set the Next
  Hop field of the MP_REACH_NLRI attribute to a routable IP address of
  the ASBR.

  Depending on the type of a P-Multicast tunnel used to instantiate the
  intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute of
  the re-advertised inter-AS A-D route is constructed as follows:

    + If the ASBR uses ingress replication to instantiate the intra-AS
      segment of the inter-AS tunnel, the re-advertised route MUST NOT
      carry the PMSI Tunnel attribute.

SB> It is not clear why not include the PMSI tunnel attribute with Tunnel
SB> Type set to “ingress replication? As a reader, I’m left wondering
SB> about the reason…

    + If the ASBR uses a P-Multicast tree to instantiate the intra-AS
      segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST
      contain the identity of the tree that is used to instantiate the
      segment (note that the ASBR could create the identity of the tree
      prior to the actual instantiation of the segment). If in order to
      instantiate the segment the ASBR needs to know the leaves of the
      tree, then the ASBR obtains this information from the A-D routes
      received from other PEs/ASBRs in ASBR's own AS.

    + An ASBR that uses a P-Multicast tree to instantiate the intra-AS
      segment of the inter-AS tunnel MAY aggregate two or more VPLSes
      present on the ASBR onto the same tree. If the ASBR already
      advertises inter-AS A-D routes for these VPLSes, then aggregation
      requires the ASBR to re-advertise these routes. The re-advertised
      routes MUST be the same as the original ones, except for the PMSI
      Tunnel attribute. If the ASBR has not previously advertised
      inter-AS A-D routes for these VPLSes, then the aggregation
      requires the ASBR to advertise (new) inter-AS A-D routes for
      these VPLSes. The PMSI 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.

SB> Each re-advertised or new


  In addition the ASBR MUST send to the EBGP neighbor, from whom it
  receives the inter-AS A-D route, a BGP Update message that carries a
  leaf A-D route. The exact encoding of this route is described in
  section 12. This route contains the following information elements:

    + The route carries a single NLRI with the Route Key field set to
      the  tuple of the BGP VPLS A-D NLRI of the inter-AS A-
      D route received from the EBGP neighbor. The NLRI also carries
      the IP address of the ASBR (this MUST be a routable IP address).

    + The leaf A-D route MUST include the PMSI Tunnel attribute with
      the Tunnel Type set to Ingress Replication, and the Tunnel
      Identifier set to a routable address of the advertising router.
      The PMSI Tunnel attribute MUST carry a downstream assigned MPLS
      label that is used to demultiplex the VPLS traffic received over
      a unicast tunnel by the advertising router.
SB> Re unicast tunnel
SB>  This should be the inter-AS segment of the multicast tunnel.

    + The Next Hop field of the MP_REACH_NLRI attribute of the route
      SHOULD be set to the same IP address as the one carried in the
      Originating Router's IP Address field of the route.

    + To constrain the distribution scope of this route the route MUST
      carry the NO_ADVERTISE BGP community ([RFC1997]).

    + The ASBR constructs an IP-based Route Target extended community
      by placing the IP address carried in the next hop of the received
      Inter-AS VPLS A-D route in the Global Administrator field of the
      community, with the Local Administrator field of this community
      set to 0, and sets the Extended Communities attribute of the leaf
      A-D route to that community. Note that this Route Target is the
      same as the ASBR Import RT of the EBGP neighbor from which the
      ASBR received the inter-AS VPLS A-D route.


10.2.2.3. Leaf A-D Route received via EBGP


  When an ASBR receives via EBGP a leaf A-D route, the ASBR accepts the
  route only if (a) at least one of the Route Targets carried in the
  message matches one of the import Route Targets configured on the
  ASBR, and (b) the ASBR determines that the received route is the best
  route to the destination carried in the NLRI of the route.

  If the ASBR accepts the leaf A-D route, the ASBR looks for an
  existing A-D route whose BGP-VPLS A-D NLRI has the same value as the
    field of the leaf A-D route just accepted. If such an A-D
  route is found, then the MPLS label carried in the PMSI Tunnel
  attribute of the leaf A-D route is used to stitch a one hop ASBR-ASBR
  LSP to the tail of the intra-AS tunnel segment associated with the
  found auto- discovery route.


10.2.2.4. Inter-AS A-D Route received via IBGP


  In the context of this section we use the term "PE/ASBR router" to
  denote either a PE or an ASBR router.

  Note that a given inter-AS A-D route is advertised within a given AS
  by only one ASBR as described above.

SB> Please elaborated the contest better. I had to read this
SB> section, then go back to section 10.2.2.2 and then come back and
SB> reread this to understand the context. It would be great to
SB> clarify here that the ASBR advertises the inter-AS AD route within
SB> its local AS as a result of receiving an inter-AS AD route via
SB> EBGP as was discussed in section 10.2.2.2.



  When a PE/ASBR router receives from one of its IBGP neighbors a BGP
  Update message that carries an inter-AS A-D route, if (a) at least
  one of the Route Targets carried in the message matches one of the
  import Route Targets configured on the PE/ASBR, and (b) the PE/ASBR
  determines that the received route is the best route to the
  destination carried in the NLRI of the route, the PE/ASBR performs
  the following operations. The best route determination is based as
  described in [RFC4761] and clarified in [MULTI-HOMING].

  If the router is an ASBR then the ASBR propagates the route to its
  EBGP neighbors. When propagating the route to the EBGP neighbors the
  ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a
  routable IP address of the ASBR.

  If the received inter-AS A-D route carries the PMSI Tunnel attribute
  with the Tunnel Type set to LDP P2MP LSP, the PE/ASBR SHOULD join the
  P-Multicast tree whose identity is carried in the PMSI Tunnel
  attribute.

  If the received inter-AS A-D route carries the PMSI Tunnel attribute
  with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR
  that originated the route MUST establish an RSVP-TE P2MP LSP with the
  local PE/ASBR as a leaf. This LSP MAY have been established before
  the local PE/ASBR receives the route, or MAY be established after the
  local PE receives the route.

  If the received inter-AS A-D route carries the PMSI Tunnel attribute
  with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP LSP, but
  the attribute does not carry a label, then the P-Multicast tree, as
  identified by the PMSI Tunnel attribute, is an intra-AS LSP segment
  that is part of the inter-AS Tunnel for the  advertised
  by the inter-AS A-D route and rooted at the PE that originated the A-
  D route. If the PMSI Tunnel attribute carries a (upstream-assigned)
  label, then a combination of this tree and the label identifies the
  intra-AS segment. If the receiving router is an ASBR, this intra-AS
  segment may further be stitched to ASBR-ASBR inter-AS segment of the
  inter-AS tunnel. If the PE/ASBR has local receivers in the VPLS,
  packets received over the intra-AS segment must be forwarded to the
  local receivers using the local VSI.


10.3. Option (c): Non-Segmented Tunnels


  In this model, there is a multi-hop EBGP peering between the PEs (or
  a Route Reflector) in one AS and the PEs (or Route Reflector) in
  another AS. The PEs exchange BGP-VPLS NLRI or BGP-VPLS A-D NLRI,
  along with PMSI Tunnel attribute, as in the intra-AS case described
  in section 8. An implementation MUST support this model.

  The PEs in different ASes use a non-segmented inter-AS P2MP tunnel
  for VPLS multicast. A non-segmented inter-AS tunnel is a single
  tunnel which spans AS boundaries. The tunnel technology cannot change
  from one point in the tunnel to the next, so all ASes through which
  the tunnel passes must support that technology. In essence, AS
  boundaries are of no significance to a non-segmented inter-AS P2MP
  tunnel.

  This model requires no VPLS A-D routes in the control plane or VPLS
  MAC address learning in the data plane on the ASBRs. The ASBRs only
  need to participate in the non-segmented P2MP tunnel setup in the
  control plane, and do MPLS label forwarding in the data plane.

  The setup of non-segmented inter-AS P2MP tunnels MAY require the P-
  routers in one AS to have IP reachability to the loopback addresses
  of the PE routers in another AS, depending on the tunneling
  technology chosen. If this is the case, reachability to the loopback
  addresses of PE routers in one AS MUST be present in the IGP in
  another AS.

SB> re technology chosen:
SB> A listing of which tunneling technologies impose this restriction
SB> would be helpful here.


  The data forwarding in this model is the same as in the intra-AS case
  described in section 8.


11. Optimizing Multicast Distribution via Selective Trees


  Whenever a particular multicast stream is being sent on an Inclusive
  P-Multicast tree, it is likely that the data of that stream is being
  sent to PEs that do not require it as the sites connected to these
  PEs may have no receivers for the stream. If a particular stream has
  a significant amount of traffic, it may be beneficial to move it to a
  Selective P-Multicast tree which has at its leaves only those PEs,
  connected to sites that have receivers for the multicast stream (or
  at least includes fewer PEs that are attached to sites with no
  receivers compared to an Inclusive tree).

  A PE connected to the multicast source of a particular multicast
  stream may be performing explicit tracking - i.e., it may know the
  PEs that have receivers in the multicast stream. Section 11.3
  describes procedures that enable explicit tracking. If this is the
  case Selective P-Multicast trees can also be triggered on other
  criteria. For instance there could be a "pseudo wasted bandwidth"
  criteria: switching to a Selective tree would be done if the
  bandwidth multiplied by the number of "uninterested" PEs (PEs that
  are receiving the stream but have no receivers) is above a specified
  threshold.  The motivation is that (a) the total bandwidth wasted by
  many sparsely subscribed low-bandwidth groups may be large, and (b)
  there's no point to moving a high-bandwidth group to a Selective tree
  if all the PEs have receivers for it.

  Switching a (C-S, C-G) stream to a Selective P-Multicast tree may
  require the root of the tree to determine the egress PEs that need to
  receive the (C-S, C-G) traffic. This is true in the following cases:

    + If the tunnel is a P2MP tree, such as a RSVP-TE P2MP Tunnel, the
      PE needs to know the leaves of the tree before it can instantiate
      the Selective tree.

    + If a PE decides to send traffic for multicast streams, belonging
      to different VPLSes, using one P-Multicast Selective tree, such a
      tree is termed an Aggregate tree with a selective mapping. The
      setting up of such an Aggregate tree requires the ingress PE to
      know all the other PEs that have receivers for multicast groups
      that are mapped onto the tree.

SB> If mLDP is used to set up the tree, why does the root need to know
SB> the leaves?

    + If ingress replication is used and the ingress PE wants to send
      traffic for (C-S, C-G)s to only those PEs that are on the path to
      receivers to the (C-S,C-G)s.


  For discovering the IP multicast group membership, for the above
  cases, this document describes procedures that allow an ingress PE to
  enable explicit tracking. Thus an ingress PE can request the IP
  multicast membership from egress PEs for one or more C-multicast
  streams. These procedures are described in section 11.3.

  The root of the Selective P-Multicast tree MAY decide to do explicit
  tracking of the IP multicast stream only after it has determined to
  move the stream to a Selective tree, or it MAY have been doing
  explicit tracking all along.  This document also describes explicit
  tracking for a wildcard source and/or group in section 11.3, which
  facilitates a Selective P-Multicast tree only mode in which IP
  multicast streams are always carried on a Selective P-Multicast tree.
  In the description on Selective P-Multicast trees the notation C-S,
  is intended to represent either a specific source address or a
  wildcard. Similarly C-G is intended to represent either a specific
  group address or a wildcard.

  The PE at the root of the tree MUST signal the leaves of the tree
  that the (C-S, C-G) stream is now bound to the Selective Tree. Note
  that the PE could create the identity of the P-Multicast tree prior
  to the actual instantiation of the tunnel.

  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
  receive 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.


11.1. Protocol for Switching to Selective Trees


  Selective trees provide a PE the ability to create separate P-
  Multicast trees for certain  streams. The source PE, that
  originates the Selective tree, and the egress PEs, MUST use the
  Selective tree for the  streams that are mapped to it. This
  may require the source and egress PEs to switch to the Selective tree
  from an Inclusive tree if they were already using an Inclusive tree
  for the  streams mapped to the Selective tree.

  Once a source PE decides to setup a Selective tree, it MUST announce
  the mapping of the  streams (which may be in different
  VPLSes) that are mapped to the tree to the other PEs using BGP. After
  the egress PEs receive the announcement they setup their forwarding
  path to receive traffic on the Selective tree if they have one or
  more receivers interested in the  streams mapped to the
  tree. Setting up the forwarding path requires setting up the
  demultiplexing forwarding entries based on the top MPLS label (if
  there is no inner label) or the inner label (if present) as described
  in section 9. The egress PEs MAY perform this switch to the Selective
  tree once the advertisement from the ingress PE is received or wait
  for a preconfigured timer to do so, after receiving the
  advertisement, when the P2MP LSP protocol is mLDP.  When the P2MP LSP
  protocol is P2MP RSVP-TE an egress PE MUST perform this switch to the
  Selective tree only after the advertisement from the ingress PE is
  received and the RSVP-TE P2MP LSP has been setup to the egress PE.
  This switch MAY be done after waiting for a preconfigured timer after
  these two steps have been accomplished.

  A source PE MUST use the following approach to decide when to start
  transmitting data on the Selective tree, if it was already using an

SB> I think you mean "if it is currently using"

  Inclusive tree. A certain pre-configured delay after advertising the
    streams mapped to an Selective tree, the source PE begins
  to send traffic on the Selective tree.

SB> The ops area is going to ask you a whole load of questions about
SB> seting, maintaining etc that delay and what happens if you get it
SB> wrong.

  At this point it stops to send
  traffic for the  streams, that are mapped on the Selective
  tree, on the Inclusive tree. This traffic is instead transmitted on
  the Selective tree.


11.2. Advertising (C-S, C-G) Binding to a Selective Tree


  The ingress PE informs all the PEs that are on the path to receivers
  of the (C-S, C-G) of the binding of the Selective tree to the (C-S,
  C-G), using BGP. The BGP announcement is done by sending update for
  the MCAST-VPLS address family using what is referred to as the S-PMSI
  A-D route.
SB> Please provide a reference?

  The format of the NLRI is described in section 12.1. The
  NLRI MUST be constructed as follows:

    +  The RD MUST be set to the RD configured locally for the VPLS.

SB> Have you defined RD yet - I don't think so - please check?

      This is required to uniquely identify the  as the
      addresses could overlap between different VPLSes.  This MUST be
      the same RD value used in the VPLS auto-discovery process.

    +  The Multicast Source field MUST contain the source address
      associated with the C-multicast stream, and the Multicast Source
      Length field is set appropriately to reflect this. If the source
      address is a wildcard the source address is set to 0.

    +  The Multicast Group field MUST contain the group address
      associated with the C-multicast stream, and the Multicast Group
      Length field is set appropriately to reflect this. If the group
      address is a wildcard the group address is set to 0.

    + The Originating Router's IP Address field MUST be set to the IP
      address that the (local) PE places in the BGP next-hop of the
      BGP-VPLS A-D routes. Note that the  tuple uniquely identifies a given VPLS instance on a PE.


  The PE constructs the rest of the Selective A-D route as follows.

  Depending on the type of a P-Multicast tree used for the P-tunnel,
  the PMSI tunnel attribute of the S-PMSI A-D route is constructed as
  follows:

    +  The PMSI tunnel attribute MUST contain the identity of the P-
      Multicast tree (note that the PE could create the identity of the
      tree prior to the actual instantiation of the tree).

    +  If in order to establish the P-Multicast tree the PE needs to
      know the leaves of the tree within its own AS, then the PE
      obtains this information from the leaf A-D routes received from
      other PEs/ASBRs within its own AS (as other PEs/ASBRs originate
      leaf A-D routes in response to receiving the S-PMSI A-D route) by
      setting the Leaf Information Required flag in the PMSI Tunnel
      attribute to 1. This enables explicit tracking for the multicast
      stream(s) advertised by the S-PMSI A-D route.

    +  If a PE originates S-PMSI A-D routes with the Leaf Information
      Required flag in the PMSI Tunnel attribute set to 1, then the PE
      MUST be (auto)configured with an import Route Target, which
      controls acceptance of leaf A-D routes by the PE. (Procedures for
      originating leaf A-D routes by the PEs that receive the S-PMSI A-
      D route are described in section "Receiving S-PMSI A-D routes by
      PEs.")

      This Route Target is IP address specific. The Global
      Administrator field of this Route Target MUST be set to the IP
      address carried in the Next Hop of all the S-PMSI A-D routes
      advertised by this PE (if the PE uses different Next Hops, then
      the PE MUST be (auto)configured with multiple import RTs, one per
      each such Next Hop). The Local Administrator field of this Route
      Target MUST be set to 0.

      If the PE supports Route Target Constrain [RFC4684], the PE
      SHOULD advertise this import Route Target within its own AS using
      Route Target Constrains. To constrain distribution of the Route
      Target Constrain routes to the AS of the advertising PE these
      routes SHOULD carry the NO_EXPORT Community ([RFC1997]).

    +  A PE MAY aggregate two or more S-PMSIs originated by the PE onto
      the same P-Multicast tree. If the PE already advertises S-PMSI A-
      D routes for these S-PMSIs, then aggregation requires the PE to
      re-advertise these routes. 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 S-PMSI A-D routes for
      these S-PMSIs, then the aggregation requires the PE to advertise
      (new) S-PMSI A-D routes for these S-PMSIs.  The PMSI Tunnel
      attribute in the newly advertised/re-advertised routes MUST carry
      the identity of the P-Multicast tree that aggregates the S-PMSIs.
      If at least some of the S-PMSIs aggregated onto the same P-
      Multicast tree belong to different VPLSes, then all these routes
      MUST carry an MPLS upstream assigned label [RFC5331].  If all
      these aggregated S-PMSIs belong to the same VPLS, then the routes
      MAY carry an MPLS upstream assigned label [RFC5331].  The labels
      MUST be distinct on a per VPLS basis, and MAY be distinct on a
      per route basis.


  The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
  be set to the same IP address as the one carried in the Originating
  Router's IP Address field.

  By default the set of Route Targets carried by the route MUST be the
  same as the Route Targets carried in the BGP-VPLS A-D route
  originated from the VSI. The default could be modified via
  configuration.



11.3. Receiving S-PMSI A-D routes by PEs


  Consider a PE that receives an S-PMSI A-D route. If one or more of
  the VSIs on the PE have their import Route Targets that contain one
  or more of the Route Targets carried by the received S-PMSI A-D
  route, then for each such VSI the PE performs the following.

  Procedures for receiving an S-PMSI A-D route by a PE (both within and
  outside of the AS of the PE that originates the route) are the same
  as specified in Section "Inter-AS A-D route received via IBGP" except
  that (a) instead of Inter-AS A-D routes the procedures apply to S-
  PMSI A-D routes, and (b) the rules for determining whether the
  received S-PMSI A-D route is the best route to the destination
  carried in the NLRI of the route, are the same as BGP path selection
  rules and may be modified by policy, and (c) a PE performs procedures
  specified in that section only if in addition to the criteria
  specified in that section the following is true:

    +  If as a result of multicast state 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 oifs (outgoing interfaces)
      for this state contains one or more interfaces to the locally
      attached CEs. When the multicast signaling protocol among the CEs
      is IGMP, then snooping and associated procedures are defined in
      [RFC4541]. The snooped state is determined using these
      procedures. When the multicast signaling protocol among the CEs
      is PIM, the procedures in [RFC4541] are not sufficient to
      determine the snooped state. The additional details required to
      determine the snooped state when CE-CE protocol is PIM are for
      further study. When such procedures are defined it is expected
      that the procedures in this section will apply to the snooped
      state created as a result of PIM as PE-CE protocol.


  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 for (C-*, 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-*) and there is no other S-
      PMSI A-D route that matches the snooped state as per the above
      conditions.


  Note if the above conditions are true, and if the received S-PMSI A-D
  route has a PMSI Tunnel attribute with the Leaf Information Required
  flag set to 1, then the PE originates a leaf A-D route, constructed
  as follows:

    +  The route carries a single MCAST-VPN NLRI with the Route Key
      field set to the MCAST-VPN NLRI of the received S-PMSI A-D route.

SB>  The route name in the BGP section later on is MCAST-VPLS

    +  The Originating Router's IP address set to the IP address of the
      PE (this MUST be a routable IP address).

    +  The PE constructs an IP-based Route Target Extended Community by
      placing the IP address carried in the Next Hop of the received S-
      PMSI A-D route in the Global Administrator field of the
      Community, with the Local Administrator field of this Community
      set to 0 and setting the Extended Communities attribute of the
      leaf A-D route to that Community.

    +  The Next Hop field of the MP_REACH_NLRI attribute of the route
      MUST be set to the same IP address as the one carried in the
      Originating Router's IP Address field of the route.

    +  To constrain the distribution scope of this route, the route
      MUST carry the NO_EXPORT Community [RFC1997], except for the
      inter-AS scenario with option (c).

  Once the leaf A-D route is constructed, the PE advertises this route
  into IBGP.

  In addition to the procedures specified in Section "Inter-AS A-D
  route received via IBGP" the PE MUST set up its forwarding path to
  receive traffic, for each multicast stream in the matching snooped
  state, from the tunnel advertised by the S-PMSI A-D route (the PE
  MUST switch to the Selective tree).

  When a new snooped state is created by a PE then the PE MUST first
  determine if there is a S-PMSI route that matches the snooped state
  as per the conditions described above. If such a S-PMSI route is
  found then the PE MUST follow the procedures described in this
  section, for that particular S-PMSI route.

SB> What happens when the snoop multicast state ages out or is
SB> removed, shouldn’t the leaf AD route be withdrawn? There’s
SB> no discussion of that case.


11.4. Inter-AS Selective Tree


  Inter-AS Selective trees support all three options of inter-AS VPLS
  service, option (a), (b) and (c), that are supported by Inter-AS
  Inclusive trees.  They are constructed in a manner that is very
  similar to Inter-AS Inclusive trees.

  For option (a) and option (b) support inter-AS Selective trees are
  constructed without requiring a single P-Multicast tree to span
  multiple ASes. This allows individual ASes to potentially use
  different P-tunneling technologies. There are two variants of this.

  One that requires MAC and IP multicast lookup on the ASBRs and
  another that does not require MAC/IP multicast lookup on the ASBRs
  and instead builds segmented inter-AS Selective trees.

  Segmented Inter-AS Selective trees can also be used with option (c),
  unlike Segmented Inter-AS Inclusive trees. This is because the S-PMSI
  A-D routes can be exchanged via ASBRs (even though BGP VPLS A-D
  routes are not exchanged via ASBRs).

  In the case of Option (c) an Inter-AS Selective tree may also be a
  non-segmented P-Multicast tree that spans multiple ASes.


11.4.1. VSIs on the ASBRs


  The requirements on ASBRs, when VSIs are present on the ABSRs,
  include the requirements presented in section 10. The source ASBR
  (that receives traffic from another AS) may independently decide
  whether it wishes to use Selective trees or not. If it uses Selective
  trees the source ASBR MUST perform a MAC lookup to determine the
  Selective tree to forward the VPLS packet on.


11.4.1.1. VPLS Inter-AS Selective Tree A-D Binding


  The mechanisms for propagating S-PMSI A-D routes are the same as the
  intra-AS case described in section 12.2. The BGP Selective tree A-D
  routes generated by PEs in an AS MUST NOT be propagated outside the
  AS.


11.4.2. Inter-AS Segmented Selective Trees


  Inter-AS Segmented Selective trees MUST be used when option (b) is
  used to provide the inter-AS VPLS service. They MAY be used when
  option (c) is used to provide the inter-AS VPLS service.

  A Segmented inter-AS Selective Tunnel is constructed similar to an
  inter-AS Segmented Inclusive Tunnel. Namely, such a tunnel is
  constructed as a concatenation of tunnel segments. There are two
  types of tunnel segments: an intra-AS tunnel segment (a segment that
  spans ASBRs within the same AS), and inter-AS tunnel segment (a
  segment that spans adjacent ASBRs in adjacent ASes). ASes that are
  spanned by a tunnel are not required to use the same tunneling
  mechanism to construct the tunnel - each AS may pick up a tunneling
  mechanism to construct the intra-AS tunnel segment of the tunnel, in
  its AS.

  The PE that decides to set up a Selective tree, advertises the
  Selective tree to multicast stream binding using an S-PMSI A-D route
  as per procedures in section 11.2, to the routers in its own AS.

  An S-PMSI A-D route advertised outside the AS, to which the
  originating PE belongs, will be referred to as an inter-AS Selective
  Tree A-D route (although this route is originated by a PE as an
  intra-AS route it is referred to as an inter-AS route outside the
  AS).



11.4.2.1. Handling S-PMSI A-D routes by ASBRs


  Procedures for handling an S-PMSI A-D route by ASBRs (both within and
  outside of the AS of the PE that originates the route) are the same
  as specified in Section "Propagating VPLS BGP A-D routes to other
  ASes", except that instead of Inter-AS BGP-VPLS A-D routes and the
  BGP-VPLS A-D NLRI these procedures apply to S-PMSI A-D routes and the
  S-PMSI A-D NLRI.

  In addition to these procedures an ASBR advertises a leaf A-D route
  in response to an S-PMSI A-D route only if:

    +  The S-PMSI A-D route was received via EBGP from another ASBR and
      the ASBR merges the S-PMSI A-D route into an Inter-AS BGP VPLS A-
      D route as described in the next section. OR

    +  The ASBR receives a leaf A-D route from a downstream PE or ASBR
      in response to the S-PMSI A-D route, received from an upstream PE
      or ASBR, that the ASBR propagated inter-AS to downstream ASBRs
      and PEs.

    +  The ASBR has snooped state from local CEs that matches the NLRI
      carried in the S-PMSI A-D route as per the following rules:

      i) The NLRI encodes (C-S, C-G) which is the same as the snooped
      (C-S, C-G)

      ii) The NLRI encodes (*, C-G) and there is snooped state for at
      least one (C-S, C-G) and there is no other matching S-PMSI A-D
      route for (C-S, C-G) OR there is snooped state for (*, C-G)

      iii) The NLRI encodes (*, *) and there is snooped state for at
      least one (C-S, C-G) or (*, C-G) and there is no other matching
      S-PMSI A-D route for that (C-S, C-G) or (*, C-G) respecively.


  The C-multicast data traffic is sent on the Selective tree by the
  originating PE. When it reaches an ASBR that is on the Inter-AS
  segmented tree, it is delivered to local receivers, if any. It is
  then forwarded on any inter-AS or intra-AS segments that exist on the
  Inter-AS Selective Segmented tree. If the Inter-AS Segmented
  Selective Tree is merged onto an Inclusive tree, as described in the
  next section, the data traffic is forwarded onto the Inclusive tree.



11.4.2.1.1. Merging Selective Tree into an Inclusive Tree


  Consider the situation where:

    +  An ASBR is receiving (or expecting to receive) inter-AS (C-S, C-
      G) data from upstream via a Selective tree.

    +  The ASBR is sending (or expecting to send) the inter-AS (C-S, C-
      G) data downstream via an Inclusive tree.


  This situation may arise if the upstream providers have a policy of
  using Selective trees but the downstream providers have a policy of
  using Inclusive trees. To support this situation, an ASBR  MAY, under
  certain conditions, merge one or more upstream Selective trees into a
  downstream Inclusive tree. Note that this can be the case only for
  option (b) and not for option (c) as for option (c) the ASBRs do not
  have Inclusive tree state.

  A Selective tree (corresponding to a particular S-PMSI A-D route) MAY
  be merged by a particular ASBR into an Inclusive tree (corresponding
  to a particular Inter-AS BGP VPLS A-D route) if and only if the
  following conditions all hold:

    +  The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route
      originate in the same AS. The Inter-AS BGP VPLS A-D route carries
      the originating AS in the AS_PATH attribute of the route. The S-
      PMSI A-D route carries the originating AS in the AS_PATH
      attribute of the route.

    +  The S-PMSI A-D route and the Inter-AS BGP VPLS A-D route have
      exactly the same set of RTs.


  An ASBR performs merging by stitching the tail end of the P-tunnel,
  as specified in the PMSI Tunnel attribute of the S-PMSI A-D route
  received by the ASBR, to the head of the P-tunnel, as specified in
  the PMSI Tunnel attribute of the Inter-AS BGP VPLS A-D route re-
  advertised by the ASBR.

  An ASBR that merges an S-PMSI A-D route into an Inter-AS BGP VPLS A-D
  route MUST NOT re-advertise the S-PMSI A-D route.


11.4.3. Inter-AS Non-Segmented Selective trees


  Inter-AS Non-segmented Selective trees MAY be used in the case of
  option (c).

  In this method, there is a multi-hop EBGP peering between the PEs (or
  a Route Reflector) in one AS and the PEs (or Route Reflector) in
  another AS. The PEs exchange BGP Selective tree A-D routes, along
  with PMSI Tunnel attribute, as in the intra-AS case described in
  section 10.3.

  The PEs in different ASes use a non-segmented Selective inter-AS P2MP
  tunnel for VPLS multicast.

  This method requires no VPLS information (in either the control or
  the data plane) on the ASBRs. The ASBRs only need to participate in
  the non-segmented P2MP tunnel setup in the control plane, and do MPLS
  label forwarding in the data plane.

  The data forwarding in this model is the same as in the intra-AS case
  described in section 9.


12. BGP Extensions


  This section describes the encoding of the BGP extensions required by
  this document.

SB> Has this section been reviewed by the IDR WG?


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 [RFC6514].

  This document supports only the following Tunnel Types 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



12.2. MCAST-VPLS NLRI


  This document defines a new BGP NLRI, called the MCAST-VPLS NLRI.

  Following is the format of the MCAST-VPLS NLRI:

                +-----------------------------------+
                |    Route Type (1 octet)          |
                +-----------------------------------+
                |    Length (1 octet)              |
                +-----------------------------------+
                | Route Type specific (variable)    |
                +-----------------------------------+


  The Route Type field defines encoding of the rest of MCAST-VPLS NLRI
  (Route Type specific MCAST-VPLS NLRI).

  The Length field indicates the length in octets of the Route Type
  specific field of MCAST-VPLS NLRI.

  This document defines the following Route Types for A-D routes:
    + 3 - Selective Tree A-D route;
    + 4 - Leaf A-D route.

  The MCAST-VPLS NLRI is carried in BGP using BGP Multiprotocol
  Extensions [RFC4760] with an AFI of 25 (L2VPN AFI), and an SAFI of
  MCAST-VPLS [To be assigned by IANA].

SB> If this has been implemented (as stated) - how has this been done
SB> without an IANA assignment?


  The NLRI field in the
  MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the MCAST-VPLS NLRI
  (encoded as specified above).

  In order for two BGP speakers to exchange labeled MCAST-VPLS NLRI,
  they must use BGP Capabilities Advertisement to ensure that they both
  are capable of properly processing such NLRI. This is done as
  specified in [RFC4760], by using capability code 1 (multiprotocol
  BGP) with an AFI of 25 and an SAFI of MCAST-VPLS.

  The following describes the format of the Route Type specific MCAST-
  VPLS NLRI for various Route Types defined in this document.

12.2.1. S-PMSI A-D route


  An S-PMSI A-D route type specific MCAST-VPLS NLRI consists of the
  following:

                +-----------------------------------+
                |      RD  (8 octets)              |
                +-----------------------------------+
                | Multicast Source Length (1 octet) |
                +-----------------------------------+
                |  Multicast Source (Variable)      |
                +-----------------------------------+
                |  Multicast Group Length (1 octet) |
                +-----------------------------------+
                |  Multicast Group  (Variable)    |
                +-----------------------------------+
                |  Originating Router's IP Addr    |
                +-----------------------------------+

  The RD is encoded as described in [RFC4364].

  The Multicast Source field contains the C-S address i.e the address
  of the multicast source. 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 value of the
  Multicast Source Length field may be set to 0 to indicate a wildcard.

  The Multicast Group field contains the C-G address i.e. the address
  of the multicast group. 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 Multicast Group
  Length field may be set to 0 to indicate a wildcard.

  Whether the Originating Router's IP Address field carries an IPv4 or
  IPv6 address is determined from the value of the Length field of the
  MCAST-VPLS NLRI. If the Multicast Source field contains an IPv4
  address and the Multicast Group field contains an IPv4 address,  then
  the value of the Length field is 22 bytes if the Originating Router's
  IP address carries an IPv4 address and 34 bytes if it is an IPv6
  address.  If the Multicast Source and Multicast Group fields contain
  IPv6 addresses, then the value of the Length field is 46 bytes if the
  Originating Router's IP address carries an IPv4 address and 58 bytes
  if it is an IPv6 address.  The following table summarizes the above.


      Multicast  Multicast                Originating Router's  Length
      Source      Group                      IP Address

        IPv4      IPv4                        IPv4                  22
        IPv4      IPv4                        IPv6                  34
        IPv6      IPv6                        IPv4                  46
        IPv6      IPv6                        IPv6                  58

  Usage of Selective Tree A-D routes is described in Section
  11.


12.2.2. Leaf A-D route


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

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

  Whether the Originating Router's IP Address field carries an IPv4 or
  IPv6 address is determined from the Length field of the MCAST-VPLS
  NLRI and the length of the Route Key field. From these two length
  fields one can compute the length of the Originating Router's IP
  Address. If this computed length is 4 then the address is an IPv4
  address and if its 16 then the address is an IPv6 address.

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


13. Aggregation Considerations


  In general the heuristic used to decide which VPLS instances or (C-S,
  C-G) entries to aggregate is implementation dependent. It is also
  conceivable that offline tools can be used for this purpose. This
  section discusses some tradeoffs with respect to aggregation.

  The "congruency" of aggregation is defined by the amount of overlap
  in the leaves of the client trees that are aggregated on an SP tree.
  For Aggregate Inclusive trees the congruency depends on the overlap
  in the membership of the VPLSes that are aggregated on the Aggregate
  Inclusive tree. If there is complete overlap aggregation is perfectly
  congruent. As the overlap between the VPLSes that are aggregated
  reduces, the congruency reduces.

  If aggregation is done such that it is not perfectly congruent a PE
  may receive traffic for VPLSes to which it doesn't belong. As the
  amount of multicast traffic in these unwanted VPLSes increases
  aggregation becomes less optimal with respect to delivered traffic.
  Hence there is a tradeoff between reducing multicast state in the
  core and delivering unwanted traffic.

  An implementation should provide knobs to control the congruency of
  aggregation.

SB> Do you mean congurency here? Surely you are talking about the
SB> the extent of wasted b/w. Delivered traffic MUST be congruent
SB> with the tree.
SB> In any case I am not sure you actually control the congruency
SB> you control criteria for creating or merging trees.
SB>
SB> Expect a bunch of questions from the ops area reviewer
SB> on this.

  This will allow an SP to deploy aggregation depending on
  the VPLS membership and traffic profiles in its network.  If
  different PEs or shared roots are setting up Aggregate Inclusive
  trees this will also allow an SP to engineer the maximum amount of
  unwanted VPLSes that a particular PE may receive traffic for.

SB> I would have thought bw was more of an issue than number of
SB> VPLSes

  The state/bandwidth optimality trade-off can be further improved by
  having a versatile many-to-many association between client trees and
  provider trees. Thus a VPLS can be mapped to multiple Aggregate
  trees. The mechanisms for achieving this are for further study. Also
  it may be possible to use both ingress replication and an Aggregate
  tree for a particular VPLS. Mechanisms for achieving this are also
  for further study.


14. Data Forwarding


14.1. MPLS Tree Encapsulation


14.1.1. Mapping multiple VPLS instances to a P2MP LSP


  The following diagram shows the progression of the VPLS multicast
  packet as it enters and leaves the SP network when MPLS trees are
  being used for multiple VPLS instances. RSVP-TE P2MP LSPs are
  examples of such trees.


      Packets received        Packets in transit      Packets forwarded
      at ingress PE          in the service          by egress PEs
                              provider network



                              +---------------+
                              |MPLS Tree Label|
                              +---------------+
                              | VPLS Label    |
      ++=============++      ++=============++      ++=============++
      ||C-Ether Hdr  ||      || C-Ether Hdr ||      || C-Ether Hdr ||
      ++=============++ >>>>> ++=============++ >>>>> ++=============++
      || C-IP Header ||      || C-IP Header ||      || C-IP Header ||
      ++=============++ >>>>> ++=============++ >>>>> ++=============++
      || C-Payload  ||      || C-Payload  ||      || C-Payload  ||
      ++=============++      ++=============++      ++=============++


  The receiver PE

SB> You mean the egress PE surely? Both PEs receive. In any case
SB> receiver PE is not defined in the above

  does a lookup on the outer MPLS tree label and
  determines the MPLS forwarding table in which to lookup the inner
  MPLS label.

SB> Much better to use the names of the labels rather than inner
SB> outer.

  This table is specific to the tree label space. The inner
  label is unique within the context of the root of the tree (as it is
  assigned by the root of the tree, without any coordination with any
  other nodes). Thus it is not unique across multiple roots.  So, to
  unambiguously identify a particular VPLS one has to know the label,
  and the context within which that label is unique. The context is
  provided by the outer MPLS label [RFC5331].

  The outer MPLS label is stripped. The lookup of the resulting MPLS
  label determines the VSI in which the receiver PE needs to do the C-
  multicast data packet lookup. It then strips the inner MPLS label and
  sends the packet to the VSI for multicast data forwarding.

SB> The above is correct, but I am sure it can be written with
SB> much greater precision.

SB> Where do you describe the imposition logic?
SB> Same question for following sub-sections.

SB> The term is surely pops not strips?


14.1.2. Mapping one VPLS instance to a P2MP LSP


  The following diagram shows the progression of the VPLS multicast
  packet as it enters and leaves the SP network when a given MPLS tree
  is being used for a single VPLS instance. RSVP-TE P2MP LSPs are
  examples of such trees.


      Packets received        Packets in transit      Packets forwarded
      at ingress PE          in the service          by egress PEs
                              provider network



                              +---------------+
                              |MPLS Tree Label|
      ++=============++      ++=============++      ++=============++
      ||C-Ether Hdr  ||      || C-Ether Hdr ||      || C-Ether Hdr ||
      ++=============++ >>>>> ++=============++ >>>>> ++=============++
      || C-IP Header ||      || C-IP Header ||      || C-IP Header ||
      ++=============++ >>>>> ++=============++ >>>>> ++=============++
      || C-Payload  ||      || C-Payload  ||      || C-Payload  ||
      ++=============++      ++=============++      ++=============++


  The receiver PE does a lookup on the outer MPLS tree label and
SB> Surely the egress PE

  determines the VSI in which the receiver PE needs to do the C-
  multicast data packet lookup. It then strips the inner MPLS label and
SB> The term is surely pops, not strips?
  sends the packet to the VSI for multicast data forwarding.



15. VPLS Data Packet Treatment


  If the destination MAC address of a VPLS packet received by a PE from
  a VPLS site is a multicast address, 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 MUST be used. Else if a (C-*, C-*)
  Selective tree exists for the VPLS it SHOULD be used. Else if an
  Inclusive tree exists for the VPLS, it SHOULD be used.

  If the destination MAC address of a VPLS packet is a broadcast
  address, it is flooded. If a (C-*, C-*) Selective tree exists for the
  VPLS the PE SHOULD flood over it. Else if Inclusive tree exists for
  the VPLS the PE SHOULD flood over it.  Else the PE MUST flood over
  multiple PWs, based on [RFC4761] or [RFC4762].

  If the destination MAC address of a packet is a unicast address and
  it has not been learned, the packet MUST be sent to all PEs in the
  VPLS.  Inclusive P-Multicast trees or a Selective P-Multicast tree
  bound to (C-*, C-*) SHOULD be used for sending unknown unicast MAC
  packets to all PEs. When this is the case the receiving PEs MUST
  support the ability to perform MAC address learning for packets
  received on a multicast tree. In order to perform such learning, the
  receiver PE MUST be able to determine the sender PE when a VPLS
  packet is received on a P-Multicast tree.  This further implies that
  the MPLS P-Multicast tree technology MUST allow the egress PE to
  determine the sender PE from the received MPLS packet.

  When a receiver PE receives a VPLS packet with a source MAC address,
  that has not yet been learned, on a P-Multicast tree, the receiver PE
  determines the PW to the sender PE. The receiver PE then creates
  forwarding state in the VPLS instance with a destination MAC address
  being the same as the source MAC address being learned, and the PW
  being the PW to the sender PE.

  It should be noted that when a sender PE that is sending packets
  destined to an unknown unicast MAC address over a P-Multicast tree
  learns the PW to use for forwarding packets destined to this unicast
  MAC address, it might immediately switch to transport such packets
  over this particular PW. Since the packets were initially being
  forwarded using a P-Multicast tree, this could lead to packet
  reordering. This constraint should be taken into consideration if
  unknown unicast frames are forwarded using a  P-Multicast tree,
  instead of multiple PWs based on [RFC4761] or [RFC4762].

  An implementation MUST support the ability to transport unknown
  unicast traffic over Inclusive P-Multicast trees. Further an
  implementation MUST support the ability to perform MAC address
  learning for packets received on a P-Multicast tree.

SB>  Why not a SHOULD? Especially given the packet reordering potential.

16. Security Considerations


  Security considerations discussed in [RFC4761] and [RFC4762] apply to
  this document. This section describes additional considerations.

  As mentioned in [RFC4761], there are two aspects to achieving data
  privacy in a VPLS: securing the control plane and protecting the
  forwarding path. Compromise of the control plane could result in a PE
  sending multicast data belonging to some VPLS to another VPLS, or
  black-holing VPLS multicast data, or even sending it to an
SB> Black holing is a security issue, but not a privacy issue.
  eavesdropper; none of which are acceptable from a data privacy point
  of view. The mechanisms in this document use BGP for the control
  plane. Hence techniques such as in [RFC5925] help authenticate BGP
  messages, making it harder to spoof updates (which can be used to
  divert VPLS traffic to the wrong VPLS) or withdrawals (denial-of-
  service attacks).
SB> DOS is not a privacy issue.

  In the multi-AS methods (b) and (c) described in
  Section 11, this also means protecting the inter-AS BGP sessions,
  between the ASBRs, the PEs, or the Route Reflectors.

  Note that [RFC5925] will not help in keeping MPLS labels, associated
  with P2MP LSPs or the upstream MPLS labels used for aggregation,
  private -- knowing the labels, one can eavesdrop on VPLS traffic.

SB> Surely only on an otherwise trusted node?

  However, this requires access to the data path within a Service
  Provider network.

SB> Don't you also require trusted signalling access?

  One of the requirements for protecting the data plane is that the
  MPLS labels are accepted only from valid interfaces. This applies
  both to MPLS labels associated with P2MP LSPs and also applies to the
  upstream assigned MPLS labels. For a PE, valid interfaces comprise
  links from P routers.
SB> Surely also from peer PEs in a multi-domain case?

  For an ASBR, valid interfaces comprise links
  from P routers and links from other ASBRs in ASes that have instances
  of a given VPLS.
SB> ... and the PEs attached?

It is especially important in the case of multi-AS
  VPLSes that one accept VPLS packets only from valid interfaces.


17. IANA Considerations


  This document defines a new NLRI, called MCAST-VPLS, to be carried in
  BGP using multiprotocol extensions. It requires assignment of a new
  SAFI. This is to be assigned by IANA.

SB> See earlier puzzlement - I thought this was already implimented.
SB> Is there an un-noted early allocation?

  This document defines a BGP optional transitive attribute, called
  PMSI attribute. This is the same attribute as the one defined in
  [RFC6514] and the code point for this attribute has already been
  assigned by IANA as 22 [BGP-IANA]. Hence no further action is
  required from IANA regarding this attribute.


2013-05-31
13 Stewart Bryant State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::External Party
2013-05-24
13 Stewart Bryant I have requested two independent reviews of this draft and I expect to have the results back this week.
2013-05-24
13 Stewart Bryant State changed to AD Evaluation::External Party from Publication Requested
2013-03-12
13 Cindy Morgan
Draft Title:  Multicast in VPLS
Draft Name: draft-ietf-l2vpn-vpls-mcast-13.txt

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? …
Draft Title:  Multicast in VPLS
Draft Name: draft-ietf-l2vpn-vpls-mcast-13.txt

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards.

This is the proper type of RFC as this is an enhancement to a core L2VPN protocol rather than a core protocol in itself.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

    Technical Summary:

    The draft describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network.

    Working Group Summary:

    This document is an L2VPN Working Group document, and has been well reviewed in the working group through multiple iterations of the draft and WG last calls. The authors have addressed the comments received on the mailing list and the WG chairs. The draft   
    was last-called after those comments were addressed and passed the WG last call.

    Document Quality:

    The document has good quality. It is clear on the technical content and written with good English and layout.

    Personnel:

    Document Shepherd: Nabil Bitar (nabil.n.bitar@verizon.com)
    Area Director: Stewart Bryant (stbryant@cisco.com)

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd did a full review of version 11 of the draft that addressed the earlier comments. There were some idnits errors that led to issuing draft version 12. Version 12 addressed most of the idnits errors except for the line lengths of some entries in the table of content. 

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. This document had been well reviewed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Juniper networks made a statement about IPR claimed in the draft on March 17, 2009 related to version 04 of the draft. This disclosure was made much earlier than my tenure as a WG chair and I am not aware of any discussion of that IPR disclosure. In addition, Juniper networks filed another disclosure on December 12, 2012 after the IPR call directed to the authors was issued. As a result, a WG last call was issued again related to that IPR. A A 2-week period was given for that call. The call closed on 1/29/2013. There was no concern or objection to proceeding with the draft received on the mailing list.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

This draft had been work in progress for a while. It was expert reviewed by Wim Hendrix following a previous WG last call that resulted in the 08 draft. Version 09 addressed further comments received from Eric Rosen and the chairs.  It further addressed comments from the WG chairs and Eric in version 11. In the WG calls to version 08 and version 11, there was no other feedback received.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Upon running the idnits tool, there was one error found "** The document seems to lack an Introduction section.". However, the document does have an introduction section. The idnits check passed otherwise. earlier nits that were in version 12 have been fixed in this version, version 13.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review required.

(13) Have all references within this document been identified as either normative or informative?

Yes.  The Document Shepherd checked all this as part of the document review.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No - all normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No - all normative references are upward.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No - no impact on status of existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section calls out the need for allocating a SAFI value for the MCAST-VPLS NLRI

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No sections written in a formal language.

2013-03-12
13 Cindy Morgan Note added 'Nabil Bitar (nabil.n.bitar@verizon.com) is the document shepherd.'
2013-03-12
13 Cindy Morgan Intended Status changed to Proposed Standard
2013-03-12
13 Cindy Morgan IESG process started in state Publication Requested
2013-01-30
13 Yakov Rekhter New version available: draft-ietf-l2vpn-vpls-mcast-13.txt
2012-12-08
(System) Posted related IPR disclosure: Juniper's Statement of IPR Related to draft-ietf-l2vpn-vpls-mcast-12
2012-11-27
12 Stephanie McCammon New version available: draft-ietf-l2vpn-vpls-mcast-12.txt
2012-07-11
11 Stephanie McCammon New version available: draft-ietf-l2vpn-vpls-mcast-11.txt
2012-02-02
10 (System) New version available: draft-ietf-l2vpn-vpls-mcast-10.txt
2012-01-06
10 (System) Document has expired
2011-07-05
09 (System) New version available: draft-ietf-l2vpn-vpls-mcast-09.txt
2010-10-25
08 (System) New version available: draft-ietf-l2vpn-vpls-mcast-08.txt
2010-09-01
07 (System) New version available: draft-ietf-l2vpn-vpls-mcast-07.txt
2010-03-08
06 (System) New version available: draft-ietf-l2vpn-vpls-mcast-06.txt
2009-07-13
05 (System) New version available: draft-ietf-l2vpn-vpls-mcast-05.txt
2009-03-17
(System) Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-l2vpn-vpls-mcast-04
2008-06-02
04 (System) New version available: draft-ietf-l2vpn-vpls-mcast-04.txt
2007-11-18
03 (System) New version available: draft-ietf-l2vpn-vpls-mcast-03.txt
2007-09-21
02 (System) New version available: draft-ietf-l2vpn-vpls-mcast-02.txt
2007-03-09
01 (System) New version available: draft-ietf-l2vpn-vpls-mcast-01.txt
2005-12-01
00 (System) New version available: draft-ietf-l2vpn-vpls-mcast-00.txt