doc: Add RFC documents

1 files changed, 3307 insertions, 0 deletions

diff --git a/doc/rfc/rfc6514.txt b/doc/rfc/rfc6514.txt
new file mode 100644
index 0000000..484cbcd
--- /dev/null
+++ b/doc/rfc/rfc6514.txt
@@ -0,0 +1,3307 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       R. Aggarwal
+Request for Comments: 6514                              Juniper Networks
+Category: Standards Track                                       E. Rosen
+ISSN: 2070-1721                                      Cisco Systems, Inc.
+                                                                T. Morin
+                                                 France Telecom - Orange
+                                                              Y. Rekhter
+                                                        Juniper Networks
+                                                           February 2012
+
+     BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs
+
+Abstract
+
+   This document describes the BGP encodings and procedures for
+   exchanging the information elements required by Multicast in MPLS/BGP
+   IP VPNs, as specified in RFC 6513.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6514.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 1]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Specification of Requirements ...................................4
+   3. Terminology .....................................................4
+   4. MCAST-VPN NLRI ..................................................5
+     4.1. Intra-AS I-PMSI A-D Route ...................................6
+     4.2. Inter-AS I-PMSI A-D Route ...................................7
+     4.3. S-PMSI A-D Route ............................................7
+     4.4. Leaf A-D Route ..............................................8
+     4.5. Source Active A-D Route .....................................9
+     4.6. C-Multicast Route ..........................................10
+   5. PMSI Tunnel Attribute ..........................................10
+   6. Source AS Extended Community ...................................13
+   7. VRF Route Import Extended Community ............................14
+   8. PE Distinguisher Labels Attribute ..............................15
+   9. MVPN Auto-Discovery/Binding ....................................16
+     9.1. MVPN Auto-Discovery/Binding - Intra-AS Operations ..........16
+       9.1.1. Originating Intra-AS I-PMSI A-D Routes .................16
+       9.1.2. Receiving Intra-AS I-PMSI A-D Routes ...................19
+     9.2. MVPN Auto-Discovery/Binding - Inter-AS Operations ..........20
+       9.2.1. Originating Inter-AS I-PMSI A-D Routes .................22
+       9.2.2. When Not to Originate Inter-AS I-PMSI A-D Routes .......23
+       9.2.3. Propagating Inter-AS I-PMSI A-D Routes .................23
+         9.2.3.1. Propagating Inter-AS I-PMSI A-D Routes - Overview ..23
+         9.2.3.2. Inter-AS I-PMSI A-D Route Received via EBGP ........24
+           9.2.3.2.1. Originating Leaf A-D Route into EBGP ...........25
+         9.2.3.3. Leaf A-D Route Received via EBGP ...................26
+         9.2.3.4. Inter-AS I-PMSI A-D Route Received via IBGP ........27
+           9.2.3.4.1. Originating Leaf A-D Route into IBGP ...........28
+         9.2.3.5. Leaf A-D Route Received via IBGP ...................29
+         9.2.3.6. Optimizing Bandwidth by IP Filtering on ASBRs ......30
+   10. Non-Congruent Unicast and Multicast Connectivity ..............30
+   11. Exchange of C-Multicast Routing Information among PEs .........32
+     11.1. Originating C-Multicast Routes by a PE ....................32
+       11.1.1. Originating Routes: PIM as the C-Multicast Protocol ...32
+         11.1.1.1. Originating Source Tree Join C-Multicast Route ....33
+         11.1.1.2. Originating Shared Tree Join C-Multicast Route ....33
+       11.1.2. Originating Routes: mLDP as the C-Multicast Protocol ..34
+       11.1.3. Constructing the Rest of the C-Multicast Route ........34
+       11.1.4. Unicast Route Changes .................................35
+     11.2. Propagating C-Multicast Routes by an ASBR .................36
+     11.3. Receiving C-Multicast Routes by a PE ......................37
+       11.3.1. Receiving Routes: PIM as the C-Multicast Protocol .....37
+         11.3.1.1. Receiving Source Tree Join C-Multicast Route ......38
+         11.3.1.2. Receiving Shared Tree Join C-Multicast Route ......38
+       11.3.2. Receiving Routes: mLDP as the C-Multicast Protocol ....39
+     11.4. C-Multicast Routes Aggregation ............................39
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 2]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   12. Using S-PMSI A-D Routes to Bind C-Trees to P-Tunnels ..........40
+     12.1. Originating S-PMSI A-D Routes .............................40
+     12.2. Handling S-PMSI A-D Routes by ASBRs .......................43
+       12.2.1. Merging S-PMSI into an I-PMSI .........................43
+     12.3. Receiving S-PMSI A-D Routes by PEs ........................44
+   13. Switching from Shared a C-Tree to a Source C-Tree .............45
+     13.1. Source within a Site - Source Active Advertisement ........46
+     13.2. Receiving Source Active A-D Route .........................47
+       13.2.1. Pruning Sources off the Shared Tree ...................48
+   14. Supporting PIM-SM without Inter-Site Shared C-Trees ...........49
+     14.1. Discovering Active Multicast Sources ......................50
+     14.2. Receiver(s) within a Site .................................51
+     14.3. Receiving C-Multicast Routes by a PE ......................52
+   15. Carrier's Carrier .............................................52
+   16. Scalability Considerations ....................................52
+     16.1. Dampening C-Multicast Routes ..............................54
+       16.1.1. Dampening Withdrawals of C-Multicast Routes ...........54
+       16.1.2. Dampening Source/Shared Tree Join C-Multicast Routes ..55
+     16.2. Dampening Withdrawals of Leaf A-D Routes ..................55
+   17. Security Considerations .......................................55
+   18. IANA Considerations ...........................................56
+   19. Acknowledgements ..............................................57
+   20. References ....................................................57
+     20.1. Normative References ......................................57
+     20.2. Informative References ....................................58
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 3]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+1.  Introduction
+
+   This document describes the BGP encodings and procedures for
+   exchanging the information elements required by Multicast in MPLS/BGP
+   IP VPNs, as specified in [MVPN].  This document assumes a thorough
+   familiarity with the procedures, concepts, and terms described in
+   [MVPN].
+
+   This document defines a new Network Layer Reachability Information
+   (NLRI), MCAST-VPN NLRI.  The MCAST-VPN NLRI is used for MVPN auto-
+   discovery, advertising MVPN to Inclusive P-Multicast Service
+   Interface (I-PMSI) tunnel binding, advertising (C-S,C-G) to Selective
+   PMSI (S-PMSI) tunnel binding, VPN customer multicast routing
+   information exchange among Provider Edge routers (PEs), choosing a
+   single forwarder PE, and for procedures in support of co-locating a
+   Customer Rendezvous Point (C-RP) on a PE.
+
+   This document specifies two new BGP attributes: the P-Multicast
+   Service Interface Tunnel (PMSI Tunnel) attribute and the PE
+   Distinguisher Label attribute.
+
+   This document also defines two new BGP Extended Communities: the
+   Source Autonomous System (AS) Extended Community and the VPN Routing
+   and Forwarding (VRF) Route Import Extended Community.
+
+2.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Terminology
+
+   In the context of this document, we will refer to the MVPN auto-
+   discovery/binding information carried in BGP as "auto-discovery
+   routes" ("A-D routes").  For a given MVPN, there are the following
+   types of A-D routes:
+
+      + Intra-AS I-PMSI A-D route;
+
+      + Inter-AS I-PMSI A-D route;
+
+      + S-PMSI A-D route;
+
+      + Leaf A-D route;
+
+      + Source Active A-D route.
+
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 4]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   In the context of this document, we will refer to the MVPN customers'
+   multicast routing information carried in BGP as "C-multicast routes".
+   For a given MVPN, there are the following types of C-multicast
+   routes:
+
+      + Shared Tree Join route;
+
+      + Source Tree Join route;
+
+   For each MVPN present on a PE, the PE maintains a Tree Information
+   Base (MVPN-TIB).  This is the same as TIB defined in [RFC4601],
+   except that instead of a single TIB, a PE maintains multiple MVPN-
+   TIBs: one per each MVPN.
+
+   Throughout this document, we will use the term "VPN-IP route" to mean
+   a route that is either in the VPN-IPv4 address family [RFC4364] or in
+   the VPN-IPv6 address family [RFC4659].
+
+4.  MCAST-VPN NLRI
+
+   This document defines a new BGP NLRI, called the MCAST-VPN NLRI.
+
+   The following is the format of the MCAST-VPN NLRI:
+
+      +-----------------------------------+
+      |    Route Type (1 octet)           |
+      +-----------------------------------+
+      |     Length (1 octet)              |
+      +-----------------------------------+
+      | Route Type specific (variable)    |
+      +-----------------------------------+
+
+   The Route Type field defines the encoding of the rest of MCAST-VPN
+   NLRI (Route Type specific MCAST-VPN NLRI).
+
+   The Length field indicates the length in octets of the Route Type
+   specific field of the MCAST-VPN NLRI.
+
+   This document defines the following Route Types for A-D routes:
+
+      + 1 - Intra-AS I-PMSI A-D route;
+      + 2 - Inter-AS I-PMSI A-D route;
+      + 3 - S-PMSI A-D route;
+      + 4 - Leaf A-D route;
+      + 5 - Source Active A-D route.
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 5]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   This document defines the following Route Types for C-multicast
+   routes:
+
+      + 6 - Shared Tree Join route;
+      + 7 - Source Tree Join route;
+
+   The MCAST-VPN NLRI is carried in BGP [RFC4271] using BGP
+   Multiprotocol Extensions [RFC4760] with an Address Family Identifier
+   (AFI) of 1 or 2 and a Subsequent AFI (SAFI) of MCAST-VPN.  The NLRI
+   field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the
+   MCAST-VPN NLRI (encoded as specified above).  The value of the AFI
+   field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute that carries the
+   MCAST-VPN NLRI determines whether the multicast source and multicast
+   group addresses carried in the S-PMSI A-D routes, Source Active A-D
+   routes, and C-multicast routes are IPv4 or IPv6 addresses (AFI 1
+   indicates IPv4 addresses, AFI 2 indicates IPv6 addresses).
+
+   In order for two BGP speakers to exchange labeled MCAST-VPN NLRIs,
+   they must use a BGP Capabilities Advertisement to ensure that they
+   both are capable of properly processing such an NLRI.  This is done
+   as specified in [RFC4760], by using capability code 1 (multiprotocol
+   BGP) with an AFI of 1 or 2 and an SAFI of MCAST-VPN.
+
+   The following describes the format of the Route Type specific MCAST-
+   VPN NLRI for various Route Types defined in this document.
+
+4.1.  Intra-AS I-PMSI A-D Route
+
+   An Intra-AS I-PMSI A-D Route Type specific MCAST-VPN NLRI consists of
+   the following:
+
+      +-----------------------------------+
+      |      RD   (8 octets)              |
+      +-----------------------------------+
+      |   Originating Router's IP Addr    |
+      +-----------------------------------+
+
+   The Route Distinguisher (RD) is encoded as described in [RFC4364].
+
+   Usage of Intra-AS I-PMSI A-D routes is described in Section 9.2.
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 6]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+4.2.  Inter-AS I-PMSI A-D Route
+
+   An Inter-AS I-PMSI A-D Route Type specific MCAST-VPN NLRI consists of
+   the following:
+
+      +-----------------------------------+
+      |      RD   (8 octets)              |
+      +-----------------------------------+
+      |      Source AS (4 octets)         |
+      +-----------------------------------+
+
+   The RD is encoded as described in [RFC4364].
+
+   The Source AS contains an Autonomous System Number (ASN).
+
+   Two-octet ASNs are encoded in the two low-order octets of the Source
+   AS field, with the two high-order octets set to zero.
+
+   Usage of Inter-AS I-PMSI A-D routes is described in Section 9.1.
+
+4.3.  S-PMSI A-D Route
+
+   An S-PMSI A-D Route Type specific MCAST-VPN 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.  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.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 7]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   The Multicast Group field contains the C-G address or C-LDP (Label
+   Distribution Protocol) MP Opaque Value Element (use of C-LDP MP
+   Opaque Value Element is described in the Section 11.3.2.  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.
+
+   Usage of other values of the Multicast Source Length and Multicast
+   Group Length fields is outside the scope of this document.
+
+   Usage of S-PMSI A-D routes is described in Section 12.
+
+4.4.  Leaf A-D Route
+
+   A Leaf A-D Route Type specific MCAST-VPN NLRI consists of the
+   following:
+
+      +-----------------------------------+
+      |      Route Key (variable)         |
+      +-----------------------------------+
+      |   Originating Router's IP Addr    |
+      +-----------------------------------+
+
+   Leaf A-D routes may be originated as a result of processing a
+   received Inter-AS I-PMSI A-D route or S-PMSI A-D route.  A Leaf A-D
+   route is originated in these situations only if the received route
+   has a PMSI Tunnel attribute whose "Leaf Information Required" bit is
+   set to 1.
+
+   If a Leaf A-D route is originated as a result of processing one of
+   the received routes specified in the previous paragraph, the Route
+   Key of the Leaf A-D route is set to the NLRI of the received route.
+
+   Details of the use of the Leaf A-D route may be found in Sections
+   9.2.3.2.1, 9.2.3.3, 9.2.3.4.1, 9.2.3.5, and 12.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 8]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+4.5.  Source Active A-D Route
+
+   A Source Active A-D Route Type specific MCAST-VPN NLRI consists of
+   the following:
+
+      +-----------------------------------+
+      |      RD   (8 octets)              |
+      +-----------------------------------+
+      | Multicast Source Length (1 octet) |
+      +-----------------------------------+
+      |   Multicast Source (variable)     |
+      +-----------------------------------+
+      |  Multicast Group Length (1 octet) |
+      +-----------------------------------+
+      |  Multicast Group (variable)       |
+      +-----------------------------------+
+
+   The RD is encoded as described in [RFC4364].
+
+   The Multicast Source field contains the C-S address.  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.
+
+   Use of the Source Active A-D routes with the Multicast Source Length
+   field of 0 is outside the scope of this document.
+
+   The Multicast Group field contains the C-G address.  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.
+
+   Source Active A-D routes with a Multicast group belonging to the
+   Source Specific Multicast (SSM) range (as defined in [RFC4607], and
+   potentially extended locally on a router) MUST NOT be advertised by a
+   router and MUST be discarded if received.
+
+   Usage of Source Active A-D routes is described in Sections 13 and 14.
+
+
+
+
+
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                    [Page 9]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+4.6.  C-Multicast Route
+
+   A Shared Tree Join route and a Source Tree Join Route Type specific
+   MCAST-VPN NLRI consists of the following:
+
+      +-----------------------------------+
+      |      RD   (8 octets)              |
+      +-----------------------------------+
+      |    Source AS (4 octets)           |
+      +-----------------------------------+
+      | Multicast Source Length (1 octet) |
+      +-----------------------------------+
+      |   Multicast Source (variable)     |
+      +-----------------------------------+
+      |  Multicast Group Length (1 octet) |
+      +-----------------------------------+
+      |  Multicast Group   (variable)     |
+      +-----------------------------------+
+
+   The RD is encoded as described in [RFC4364].
+
+   The Source AS contains an ASN.  Two-octet ASNs are encoded in the
+   low-order two octets of the Source AS field.
+
+   For a Shared Tree Join route, the Multicast Source field contains the
+   C-RP address; for a Source Tree Join route, the Multicast Source
+   field contains the C-S address.  If the Multicast Source field
+   contains an IPv4 address, then the value of the Multicast Source
+   Length field is 32.  If the Multicast Source field contains an IPv6
+   address, then the value of the Multicast Source Length field is 128.
+
+   The Multicast Group field contains the C-G address or C-MP Opaque
+   Value Element.  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.
+
+   Usage of C-multicast routes is described in Section 11.
+
+5.  PMSI Tunnel Attribute
+
+   This document defines and uses a new BGP attribute called the
+   "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute".  This
+   is an optional transitive BGP attribute.  The format of this
+   attribute is defined as follows:
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 10]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+      +---------------------------------+
+      |  Flags (1 octet)                |
+      +---------------------------------+
+      |  Tunnel Type (1 octets)         |
+      +---------------------------------+
+      |  MPLS Label (3 octets)          |
+      +---------------------------------+
+      |  Tunnel Identifier (variable)   |
+      +---------------------------------+
+
+   The Flags field has the following format:
+
+       0 1 2 3 4 5 6 7
+      +-+-+-+-+-+-+-+-+
+      |  reserved   |L|
+      +-+-+-+-+-+-+-+-+
+
+   This document defines the following flags:
+
+     + Leaf Information Required (L)
+
+   The Tunnel Type identifies the type of the tunneling technology used
+   to establish the PMSI tunnel.  The type determines the syntax and
+   semantics of the Tunnel Identifier field.  This document defines the
+   following Tunnel Types:
+
+      + 0 - No tunnel information present
+      + 1 - RSVP-TE P2MP LSP
+      + 2 - mLDP P2MP LSP
+      + 3 - PIM-SSM Tree
+      + 4 - PIM-SM Tree
+      + 5 - BIDIR-PIM Tree
+      + 6 - Ingress Replication
+      + 7 - mLDP MP2MP LSP
+
+   If the MPLS Label field is non-zero, then it contains an MPLS label
+   encoded as 3 octets, where the high-order 20 bits contain the label
+   value.  Absence of an MPLS Label is indicated by setting the MPLS
+   Label field to zero.
+
+   When the Tunnel Type is set to "No tunnel information present", the
+   PMSI Tunnel attribute carries no tunnel information (no Tunnel
+   Identifier).  This type is to be used only in the following case: to
+   enable explicit tracking for a particular customer multicast flow (by
+   setting the Leaf Information Required flag to 1), but without binding
+   this flow to a particular provider tunnel (by omitting any tunnel
+   information).
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 11]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   When the Tunnel Type is set to RSVP - Traffic Engineering (RSVP-TE)
+   Point-to-Multipoint (P2MP) Label Switched Path (LSP), the Tunnel
+   Identifier is <Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID> as
+   carried in the RSVP-TE P2MP LSP SESSION Object [RFC4875].
+
+   When the Tunnel Type is set to multipoint Label Distribution Protocol
+   (mLDP) P2MP LSP, the Tunnel Identifier is a P2MP Forwarding
+   Equivalence Class (FEC) Element [mLDP].
+
+   When the Tunnel Type is set to Protocol Independent Multicast -
+   Sparse Mode (PIM-SM) tree, the Tunnel Identifier is <Sender Address,
+   P-Multicast Group>.  The node that originated the attribute MUST use
+   the address carried in the Sender Address as the source IP address
+   for the IP/GRE (Generic Routing Encapsulation) encapsulation of the
+   MVPN data.
+
+   When the Tunnel Type is set to PIM-SSM tree, the Tunnel Identifier is
+   <P-Root Node Address, P-Multicast Group>.  The node that originates
+   the attribute MUST use the address carried in the P-Root Node Address
+   as the source IP address for the IP/GRE encapsulation of the MVPN
+   data.  The P-Multicast Group in the Tunnel Identifier of the Tunnel
+   attribute MUST NOT be expected to be the same group for all Intra-AS
+   A-D routes for the same MVPN.  According to [RFC4607], the group
+   address can be locally allocated by the originating PE without any
+   consideration for the group address used by other PE on the same
+   MVPN.
+
+   When the Tunnel Type is set to BIDIR-PIM tree, the Tunnel Identifier
+   is <Sender Address, P-Multicast Group>.  The node that originated the
+   attribute MUST use the address carried in the Sender Address as the
+   source IP address for the IP/GRE encapsulation of the MVPN data.
+
+   When the Tunnel Type is set to PIM-SM or BIDIR-PIM tree, then the
+   P-Multicast Group in the Tunnel Identifier of the Tunnel attribute
+   SHOULD contain the same multicast group address for all Intra-AS
+   I-PMSI A-D routes for the same MVPN originated by PEs within a given
+   AS.  How this multicast group address is chosen is outside the scope
+   of this specification.
+
+   When the Tunnel Type is set to Ingress Replication, the Tunnel
+   Identifier carries the unicast tunnel endpoint IP address of the
+   local PE that is to be this PE's receiving endpoint address for the
+   tunnel.
+
+   When the Tunnel Type is set to mLDP Multipoint-to-Multipoint (MP2MP)
+   LSP, the Tunnel Identifier is an MP2MP FEC Element [mLDP].
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 12]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   The use of mLDP MP2MP LSPs as Provider tunnels (P-tunnels) requires
+   procedures that are outside the scope of this document.
+
+   A router that supports the PMSI Tunnel attribute considers this
+   attribute to be malformed if either (a) it contains an undefined
+   tunnel type in the Tunnel Type field of the attribute, or (b) the
+   router cannot parse the Tunnel Identifier field of the attribute as a
+   tunnel identifier of the tunnel types specified in the Tunnel Type
+   field of the attribute.
+
+   When a router that receives a BGP Update that contains the PMSI
+   Tunnel attribute with its Partial bit set determines that the
+   attribute is malformed, the router SHOULD treat this Update as though
+   all the routes contained in this Update had been withdrawn.
+
+   An implementation MUST provide debugging facilities to permit issues
+   caused by a malformed PMSI Tunnel attribute to be diagnosed.  At a
+   minimum, such facilities MUST include logging an error when such an
+   attribute is detected.
+
+   The PMSI Tunnel attribute is used in conjunction with Intra-AS I-PMSI
+   A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf
+   A-D routes.
+
+6.  Source AS Extended Community
+
+   This document defines a new BGP Extended Community called "Source
+   AS".
+
+   The Source AS is an AS-specific Extended Community, of an extended
+   type, and is transitive across AS boundaries [RFC4360].
+
+   The Global Administrator field of this Community MUST be set to the
+   ASN of the PE.  The Local Administrator field of this Community MUST
+   be set to 0.
+
+   Consider a given MVPN that uses BGP for exchanging C-multicast
+   routes, and/or uses segmented inter-AS tunnels.  A PE that has sites
+   of that MVPN connected to it, and originates a (unicast) route to
+   VPN-IP addresses associated with the destinations within these sites,
+   MUST include in the BGP Update message that carries this route the
+   Source AS Extended Community.
+
+   The usage of a received Source AS Extended Community is described in
+   Section 11.1.3.
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 13]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+7.  VRF Route Import Extended Community
+
+   This document defines a new BGP Extended Community called "VRF Route
+   Import".
+
+   The VRF Route Import is an IP-address-specific Extended Community, of
+   an extended type, and is transitive across AS boundaries [RFC4360].
+
+   To support MVPN in addition to the import/export Route Target(s)
+   Extended Communities used by the unicast routing, each VRF on a PE
+   MUST have an import Route Target Extended Community, except if it is
+   known a priori that none of the (local) MVPN sites associated with
+   the VRF contain multicast source(s) and/or C-RP; in which case, the
+   VRF need not have this import Route Target.
+
+   We refer to this Route Target as the "C-multicast Import RT", as this
+   Route Target controls imports of C-multicast routes into a particular
+   VRF.
+
+   A PE constructs C-multicast Import RT as follows:
+
+    + The Global Administrator field of the C-multicast Import RT MUST
+      be set to an IP address of the PE.  This address SHOULD be common
+      for all the VRFs on the PE (e.g., this address may be the PE's
+      loopback address).
+
+    + The Local Administrator field of the C-multicast Import RT
+      associated with a given VRF contains a 2-octet number that
+      uniquely identifies that VRF within the PE that contains the VRF
+      (procedures for assigning such numbers are purely local to the PE
+      and are outside the scope of this document).
+
+   The way C-multicast Import RT is constructed allows it to uniquely
+   identify a VRF.
+
+   A PE that has site(s) of a given MVPN connected to it needs to
+   communicate the value of the C-multicast Import RT associated with
+   the VRF of that MVPN on the PE to all other PEs that have sites of
+   that MVPN.  To accomplish this, a PE that originates a (unicast)
+   route to VPN-IP addresses MUST include in the BGP Updates message
+   that carries this route the VRF Route Import Extended Community that
+   has the value of the C-multicast Import RT of the VRF associated with
+   the route, except if it is known a priori (e.g., via provisioning)
+   that none of these addresses could act as multicast sources and/or
+   RP; in which case, the (unicast) route MUST NOT carry the VRF Route
+   Import Extended Community.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 14]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   If a PE uses Route Target Constraint [RT-CONSTRAIN], the PE SHOULD
+   advertise all such C-multicast Import RTs using Route Target
+   Constraints (note that doing this requires just a single Route Target
+   Constraint advertisement by the PE).  This allows each C-multicast
+   route to reach only the relevant PE.  To constrain distribution of
+   the Route Target Constraint routes to the AS of the advertising PE,
+   these routes SHOULD carry the NO_EXPORT Community [RFC1997].
+
+   Usage of VRF Route Import Extended Community is described in
+   Section 11.1.3.
+
+8.  PE Distinguisher Labels Attribute
+
+   This document defines a new BGP attribute, called the "PE
+   Distinguisher Labels" attribute.  This is an optional transitive BGP
+   attribute.  The format of this attribute is defined as follows:
+
+      +---------------------------------+
+      |           PE Address            |
+      +---------------------------------+
+      |     Label (3 octets)            |
+      +---------------------------------+
+      .......
+      +---------------------------------+
+      |           PE Address            |
+      +---------------------------------+
+      |     Label (3 octets)            |
+      +---------------------------------+
+
+   The Label field contains an MPLS label encoded as 3 octets, where the
+   high-order 20 bits contain the label value.
+
+   A router that supports the PE Distinguisher Labels attribute
+   considers this attribute to be malformed if the PE Address field does
+   not contain a unicast address.  The attribute is also considered to
+   be malformed if: (a) the PE Address field is expected to be an IPv4
+   address, and the length of the attribute is not a multiple of 7 or
+   (b) the PE Address field is expected to be an IPv6 address, and the
+   length of the attribute is not a multiple of 19.  The length of the
+   Route Type field of MCAST-VPN NLRI of the route that carries the PE
+   Distinguisher Labels attribute provides the information on whether
+   the PE Address field contains an IPv4 or IPv6 address.  Each of the
+   PE addresses in the PE Distinguisher Labels attribute MUST be of the
+   same address family as the "Originating Router's IP Address" of the
+   route that is carrying the attribute.
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 15]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   When a router that receives a BGP Update that contains the PE
+   Distinguisher Labels attribute with its Partial bit set determines
+   that the attribute is malformed, the router SHOULD treat this Update
+   as though all the routes contained in this Update had been withdrawn.
+
+   An implementation MUST provide debugging facilities to permit issues
+   caused by malformed PE Distinguisher Label attribute to be diagnosed.
+   At a minimum, such facilities MUST include logging an error when such
+   an attribute is detected.
+
+   Usage of this attribute is described in [MVPN].
+
+9.  MVPN Auto-Discovery/Binding
+
+   This section specifies procedures for the auto-discovery of MVPN
+   memberships and the distribution of information used to instantiate
+   I-PMSIs.
+
+   There are two MVPN auto-discovery/binding mechanisms, dubbed "intra-
+   AS" and "inter-AS" respectively.
+
+   The intra-AS mechanisms provide auto-discovery/binding within a
+   single AS.
+
+   The intra-AS mechanisms also provide auto-discovery/binding across
+   multiple ASes when non-segmented inter-AS tunnels are being used.
+
+   The inter-AS mechanisms provide auto-discovery/binding across
+   multiple ASes when segmented inter-AS tunnels are being used.
+
+   Note that if a multi-AS system uses option (a) of section 10 of
+   [RFC4364], the notion of inter-AS tunnels does not apply, and so it
+   needs only the intra-AS mechanisms.
+
+9.1.  MVPN Auto-Discovery/Binding - Intra-AS Operations
+
+   This section describes exchanges of Intra-AS I-PMSI A-D routes
+   originated/received by PEs within the same AS, or if non-segmented
+   inter-AS tunnels are used, then by all PEs.
+
+9.1.1.  Originating Intra-AS I-PMSI A-D Routes
+
+   To participate in the MVPN auto-discovery/binding, a PE router that
+   has a given VRF of a given MVPN MUST, except for the cases specified
+   in this section, originate an Intra-AS I-PMSI A-D route and
+   advertises this route in IBGP.  The route is constructed as follows.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 16]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   The route carries a single MCAST-VPN NLRI with the RD set to the RD
+   of the VRF, and the Originating Router's IP Address field set to the
+   IP address that the PE places in the Global Administrator field of
+   the VRF Route Import Extended Community of the VPN-IP routes
+   advertised by the PE.  Note that the <RD, Originating Router's IP
+   Address> tuple uniquely identifies a given multicast VRF.
+
+   The route carries the PMSI Tunnel attribute if and only if an I-PMSI
+   is used for the MVPN (the conditions under which an I-PMSI is used
+   can be found in [MVPN]).  Depending on the technology used for the
+   P-tunnel for the MVPN on the PE, the PMSI Tunnel attribute of the
+   Intra-AS I-PMSI A-D route is constructed as follows.
+
+    + If the PE that originates the advertisement uses a P-multicast
+      tree for the P-tunnel for the MVPN, the PMSI Tunnel attribute MUST
+      contain the identity of the tree (note that the PE could create
+      the identity of the tree prior to the actual instantiation of the
+      tree).
+
+    + A PE that uses a P-multicast tree for the P-tunnel MAY aggregate
+      two or more MVPNs present on the PE onto the same tree.  In this
+      case, in addition to carrying the identity of the tree, the PMSI
+      Tunnel attribute of the Intra-AS I-PMSI A-D route MUST carry an
+      MPLS upstream-assigned label that the PE has bound uniquely to the
+      MVPN associated with this route (as determined by its RTs).
+
+
+      If the PE has already advertised Intra-AS I-PMSI A-D routes for
+      two or more MVPNs that it now desires to aggregate, then the PE
+      MUST re-advertise those routes.  The re-advertised routes MUST be
+      the same as the original ones, except for the PMSI Tunnel
+      attribute and the label carried in that attribute.
+
+    + If the PE that originates the advertisement uses ingress
+      replication for the P-tunnel for the MVPN, the route MUST include
+      the PMSI Tunnel attribute with the Tunnel Type set to Ingress
+      Replication and Tunnel Identifier set to a routable address of the
+      PE.  The PMSI Tunnel attribute MUST carry a downstream-assigned
+      MPLS label.  This label is used to demultiplex the MVPN traffic
+      received over a unicast tunnel by the PE.
+
+    + The Leaf Information Required flag of the PMSI Tunnel attribute
+      MUST be set to zero and MUST be ignored on receipt.
+
+   Discovery of PE capabilities in terms of what tunnel types they
+   support is outside the scope of this document.  Within a given AS,
+   PEs participating in an MVPN are expected to advertise tunnel
+   bindings whose tunnel types are supported by all other PEs that are
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 17]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   participating in this MVPN and are part of the same AS.  In addition,
+   in the inter-AS scenario with non-segmented inter-AS tunnels, the
+   tunnel types have to be supported by all PEs that are participating
+   in this MVPN, irrespective of whether or not these PEs are in the
+   same AS.
+
+   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.
+
+   By default, the distribution of the Intra-AS I-PMSI A-D routes is
+   controlled by the same Route Targets as the ones used for the
+   distribution of VPN-IP unicast routes.  That is, by default, the
+   Intra-AS I-PMSI A-D route MUST carry the export Route Target used by
+   the unicast routing.  If any other PE has one of these Route Targets
+   configured as an import Route Target for a VRF present on the PE, it
+   treats the advertising PE as a member in the MVPN to which the VRF
+   belongs.  The default could be modified via configuration by having a
+   set of Route Targets used for the Intra-AS I-PMSI A-D routes being
+   distinct from the ones used for the VPN-IP unicast routes (see also
+   Section 10).
+
+   To constrain distribution of the intra-AS membership/binding
+   information to the AS of the advertising PE, the BGP Update message
+   originated by the advertising PE SHOULD carry the NO_EXPORT Community
+   [RFC1997].
+
+   Note that if non-segmented inter-AS P-tunnels are being used, then
+   the Intra-AS I-PMSI routes need to be distributed to other ASes and
+   MUST NOT carry the NO_EXPORT Community.
+
+   When BGP is used to exchange C-multicast routes, if (a) it is known a
+   priori that, as a matter of policy, none of the MVPN sites connected
+   to a given PE are allowed to send multicast traffic to other sites of
+   that MVPN (in other words, all these sites are only in the Receiver
+   Sites set), (b) the PE does not use ingress replication for the
+   incoming traffic of that MVPN, and (c) none of the other PEs that
+   have VRFs of that MVPN use RSVP-TE P2MP LSP for that MVPN, then the
+   local PE SHOULD NOT originate an Intra-AS I-PMSI A-D route.
+
+   When BGP is used to exchange C-multicast routes, if it is known a
+   priori that, as a matter of policy, none of the MVPN sites connected
+   to a given PE can receive multicast traffic from other sites of that
+   MVPN (in other words, all these sites are only in the Sender Sites
+   set), and the PE uses ingress replication for that MVPN, then the PE
+   SHOULD NOT originate an Intra-AS I-PMSI A-D route for that MVPN.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 18]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+9.1.2.  Receiving Intra-AS I-PMSI A-D Routes
+
+   When a PE receives a BGP Update message that carries an Intra-AS
+   I-PMSI A-D route such that (a) at least one of the Route Targets of
+   the route matches one of the import Route Targets configured for a
+   particular VRF on the local PE, (b) either the route was originated
+   by some other PE within the same AS as the local PE, or the MVPN
+   associated with the VRF uses non-segmented inter-AS tunnels, and (c)
+   the BGP route selection determines that this is the best route with
+   respect to the NLRI carried by the route, the PE performs the
+   following.
+
+   If the route does not carry the PMSI Tunnel attribute and ingress
+   replication is not used, either a) the PE that originated the route
+   will be using only S-PMSIs to send traffic to remote PEs, or b) as a
+   matter of policy, the PE that originated the route cannot send
+   multicast traffic from the MVPN sites connected to it to other sites
+   of that MVPN (in other words, the sites connected to the PE are only
+   in the Receiver Sites set).
+
+   When BGP is used to exchange C-multicast routes, to distinguish
+   between cases (a) and (b), we use the presence/absence of the VRF
+   Route Import Extended Community in the unicast VPN routes, as
+   follows.  As specified in Section 7, if it is know a priori that none
+   of the addresses carried in the NLRI of a given (unicast) VPN route
+   could act as multicast sources and/or C-RP, then such a route does
+   not carry the VRF Route Import Extended Community.  Hence, based on
+   the Upstream Multicast Hop (UMH) selection algorithm specified in
+   [MVPN], such a route will be ineligible for the UMH selection.  This
+   implies that if a given VPN route is selected by the UMH selection
+   procedures, and the PE that originates this VPN route also originates
+   an Intra-AS I-PMSI A-D route, but this route does not carry the PMSI
+   Tunnel attribute, then this PE will be using only S-PMSIs for sending
+   (multicast) data.
+
+   If the route carries the PMSI Tunnel attribute, then:
+
+    + If the Tunnel Type in the PMSI Tunnel attribute is set to Ingress
+      Replication, then the MPLS label and the address carried in the
+      Tunnel Identifier field of the PMSI Tunnel attribute should be
+      used when the local PE sends multicast traffic to the PE that
+      originated the route.
+
+    + If the Tunnel Type in the PMSI Tunnel attribute is set to mLDP
+      P2MP LSP, mLDP MP2MP LSP, PIM-SSM tree, PIM-SM tree, or BIDIR-PIM
+      tree, the PE SHOULD join as soon as possible the P-multicast tree
+      whose identity is carried in the Tunnel Identifier.
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 19]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+    + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE
+      P2MP LSP, then 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, or it may
+      be established after the local PE receives the route.
+
+    + The receiving PE has to establish the appropriate state to
+      properly handle the traffic received on the P-multicast tree.
+
+    + 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 VRF that has
+      at least one of its import Route Targets that matches one of the
+      Route Targets of the received Intra-AS I-PMSI A-D route.
+
+    + If the PMSI Tunnel attribute has the Tunnel Type set to mLDP P2MP
+      LSP, PIM-SSM tree, PIM-SM tree, BIDIR-PIM tree, or RSVP-TE P2MP
+      LSP, and the attribute also carries an MPLS label, then this is 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-assigned label are forwarded using the VRF that has
+      at least one of its import Route Targets that matches one of the
+      Route Targets of the received Intra-AS I-PMSI A-D route.
+
+   Irrespective of whether the route carries the PMSI Tunnel attribute,
+   if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic
+   from the VRF to the sites attached to other PEs, then the local PE
+   uses the Originating Router's IP address information carried in the
+   route to add the PE that originated the route as a leaf node to the
+   LSP.
+
+9.2.  MVPN Auto-Discovery/Binding - Inter-AS Operations
+
+   This section applies only to the case where segmented inter-AS
+   tunnels are used.
+
+   An Autonomous System Border Router (ASBR) may be configured to
+   support a particular MVPN as follows:
+
+    + An ASBR MUST be configured with a set of (import) Route Targets
+      (RTs) that specifies the set of MVPNs supported by the ASBR.
+      These Route Targets control acceptance of Intra-AS/Inter-AS I-PMSI
+      A-D routes by the ASBR.  As long as unicast and multicast
+      connectivity are congruent, this could be the same set of Route
+      Targets as the one used for supporting unicast (and therefore
+      would not require any additional configuration above and beyond of
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 20]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+      what is required for unicast).  Note that instead of being
+      configured, the ASBR MAY obtain this set of (import) Route Targets
+      (RTs) by using Route Target Constraint [RT-CONSTRAIN].
+
+    + The ASBR MUST be (auto-)configured with an import Route Target
+      called "ASBR Import RT".  ASBR Import RT controls acceptance of
+      Leaf A-D routes and C-multicast routes by the ASBR, and is used to
+      constrain distribution of both Leaf A-D routes and C-multicast
+      routes (see Section 11).
+
+      ASBR Import RT is an IP-address-specific Route Target.  The Global
+      Administrator field of the ASBR Import RT MUST be set to the IP
+      address carried in the Next Hop of all the Inter-AS I-PMSI A-D
+      routes and S-PMSI A-D routes advertised by this ASBR (if the ASBR
+      uses different Next Hops, then the ASBR MUST be (auto-)configured
+      with multiple ASBR Import RTs, one per each such Next Hop).  The
+      Local Administrator field of the ASBR Import RT MUST be set to 0.
+
+      If the ASBR supports Route Target Constraint [RT-CONSTRAIN], the
+      ASBR SHOULD advertise its ASBR Import RT within its own AS using
+      Route Target Constraints.  To constrain distribution of the Route
+      Target Constraint routes to the AS of the advertising ASBR, these
+      routes SHOULD carry the NO_EXPORT Community [RFC1997].
+
+    + The ASBR MUST be configured with the tunnel types for the intra-AS
+      segments of the MVPNs supported by the ASBR, as well as (depending
+      on the tunnel type) the information needed to create the PMSI
+      attribute for these tunnel types.  Note that instead of being
+      configured, the ASBR MAY derive the tunnel types from the Intra-AS
+      I-PMSI A-D routes received by the ASBR.
+
+    + If the ASBR originates an Inter-AS I-PMSI A-D route for a
+      particular MVPN present on some of the PEs within its own AS, the
+      ASBR MUST be (auto-)configured with an RD for that MVPN.  It is
+      RECOMMENDED that one of the following two options be used:
+
+  (1) To allow more aggregation of Inter-AS I-PMSI A-D routes, it is
+      recommended that all the ASBRs within an AS that are configured to
+      originate an Inter-AS I-PMSI A-D route for a particular MVPN be
+      configured with the same RD (although for a given MVPN each AS may
+      assign this RD on its own, without coordination with other ASes).
+
+  (2) To allow more control over spreading MVPN traffic among multiple
+      ASBRs within a given AS, it is recommended that each ASBR have a
+      distinct RD per each MVPN; in which case, such an RD SHOULD be
+      auto-configured.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 21]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   If an ASBR is configured to support a particular MVPN, the ASBR MUST
+   participate in the intra-AS MVPN auto-discovery/binding procedures
+   for that MVPN within the ASBR's own AS, as specified in Section 9.1.
+
+   Moreover, in addition to the above, the ASBR performs procedures
+   described in Sections 9.2.1, 9.2.2, and 9.2.3.
+
+9.2.1.  Originating Inter-AS I-PMSI A-D Routes
+
+   For a given MVPN configured on an ASBR when the ASBR determines
+   (using the intra-AS auto-discovery procedures) that at least one of
+   the PEs of its own AS has (directly) connected site(s) of the MVPN,
+   the ASBR originates an Inter-AS I-PMSI A-D route and advertises it in
+   External BGP (EBGP).  The route is constructed as follows:
+
+    + The route carries a single MCAST-VPN NLRI with the RD set to the
+      RD configured for that MVPN on the ASBR, and the Source AS set to
+      the ASN of the ASBR.
+
+    + The route carries the PMSI Tunnel attribute if and only if an
+      I-PMSI is used for the MVPN.  The Tunnel Type in the attribute is
+      set to Ingress Replication; the Leaf Information Required flag is
+      set to 1; the attribute carries no MPLS labels.
+
+    + The Next Hop field of the MP_REACH_NLRI attribute is set to a
+      routable IP address of the ASBR.
+
+    + The default policy for aggregation of Intra-AS I-PMSI A-D routes
+      into an Inter-AS I-PMSI A-D route is that a given Inter-AS I-PMSI
+      A-D route aggregates only the Intra-AS I-PMSI A-D routes that
+      carry exactly the same set of RTs (note that this set may have
+      just one RT).  In this case, an Inter-AS I-PMSI A-D route
+      originated by an ASBR carries exactly the same RT(s) as the RT(s)
+      carried by the Intra-AS I-PMSI A-D routes that the ASBR aggregates
+      into that Inter-AS I-PMSI A-D route.  An implementation MUST
+      support the default policy for aggregation of Intra-AS I-PMSI A-D
+      routes into an Inter-AS I-PMSI A-D route.
+
+    + The default policy for aggregation could be modified via
+      configuration on the ASBR.  An implementation MAY support such
+      functionality.  Modified policy MUST include rules for
+      constructing RTs carried by the Inter-AS I-PMSI A-D routes
+      originated by the ASBR.
+
+   An Inter-AS I-PMSI A-D route for a given <AS, MVPN> indicates the
+   presence of the MVPN sites connected to one or more PEs of the AS.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 22]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra-
+   AS I-PMSI A-D routes originated within the ASBR's own AS.  Thus,
+   while the Intra-AS I-PMSI A-D routes originated within an AS are at
+   the granularity of <PE, MVPN> within that AS, outside of that AS the
+   (aggregated) Inter-AS I-PMSI A-D routes could be at the granularity
+   of <AS, MVPN>.
+
+9.2.2.  When Not to Originate Inter-AS I-PMSI A-D Routes
+
+   If, for a given MVPN and a given AS, all of the sites connected to
+   the PEs within the AS are known a priori to have no multicast
+   sources, then ASBRs of that AS MAY refrain from originating an Inter-
+   AS I-PMSI A-D route for that MVPN at all.
+
+9.2.3.  Propagating Inter-AS I-PMSI A-D Routes
+
+   An Inter-AS I-PMSI A-D route for a given MVPN originated by an ASBR
+   within a given AS is propagated via BGP to other ASes.
+
+9.2.3.1.  Propagating Inter-AS I-PMSI A-D Routes - Overview
+
+   Suppose that ASBR A installs an Inter-AS I-PMSI A-D route for MVPN V
+   that originated at a particular AS, AS1.  The BGP Next Hop of that
+   route becomes A's "upstream multicast hop" on a multicast
+   distribution tree for V that is rooted at AS1.  When the Inter-AS
+   I-PMSI A-D routes have been distributed to all the necessary ASes,
+   they define a "reverse path" from any AS that supports MVPN V back to
+   AS1.  For instance, if AS2 supports MVPN V, then there will be a
+   reverse path for MVPN 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 on the given Inter-AS I-PMSI A-D route.
+
+   This reverse path information can be used to construct a
+   unidirectional multicast distribution tree for MVPN V, containing all
+   the ASes that support V, and having AS1 at the root.  We call such a
+   tree an "inter-AS tree".  Multicast data originating in MVPN sites
+   connected to PEs within a given AS will travel downstream along the
+   tree, which is rooted at that AS.
+
+   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 that 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".
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 23]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   An ASBR initiates creation of an intra-AS segment when the ASBR
+   receives an Inter-AS I-PMSI 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 MVPNs
+   may share the same P-multicast tree.
+
+   If the P-multicast tree that serves as a particular intra-AS segment
+   of an inter-AS tunnel is created by a multicast control protocol that
+   uses receiver-initiated joins (e.g., mLDP, any PIM variant), and this
+   P-multicast tree does not aggregate multiple segments, then all the
+   information needed to create that segment is present in the PMSI
+   Tunnel attribute of the Inter-AS I-PMSI A-D routes.  However, if the
+   P-multicast tree that serves as 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 it is also necessary to use Leaf A-D routes.
+   The precise conditions under which Leaf A-D routes need to be used
+   are described in subsequent sections.
+
+   Since (aggregated) Inter-AS I-PMSI A-D routes could have granularity
+   of <AS, MVPN>, an MVPN that is present in N ASes could have a total
+   of N inter-AS tunnels.  Thus, for a given MVPN, the number of inter-
+   AS tunnels constituting the I-PMSIs is independent of the number of
+   PEs that have this MVPN.
+
+   The precise rules for distributing and processing the Inter-AS I-PMSI
+   A-D routes across ASes are given in the following sections.
+
+9.2.3.2.  Inter-AS I-PMSI 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 I-PMSI 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 for its NLRI,
+   the ASBR re-advertises this route to other PEs and ASBRs within its
+   own AS (handling of this route by other PEs and ASBRs is described in
+   Section 9.2.3.4).
+
+   When re-advertising an Inter-AS I-PMSI 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.
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 24]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
+   attribute, then, depending on the technology used to instantiate the
+   intra-AS segment of the inter-AS tunnel, the ASBR constructs the PMSI
+   Tunnel attribute of the re-advertised Inter-AS I-PMSI A-D route as
+   follows.
+
+    + If the ASBR uses ingress replication for the intra-AS segment of
+      the inter-AS tunnel, the re-advertised route MUST carry the PMSI
+      Tunnel attribute with the Tunnel Type set to Ingress Replication,
+      but no MPLS labels.
+
+    + If the ASBR uses a P-multicast tree for the intra-AS segment of
+      the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the
+      identity of the tree (note that the ASBR could create the identity
+      of the tree prior to the actual instantiation of the tree).  If,
+      in order to instantiate the tree, the ASBR needs to know the
+      leaves of the tree, then the ASBR obtains this information from
+      the Leaf A-D routes received from other PEs/ASBRs in the ASBR's
+      own AS (as described in Section 9.2.3.5) by setting the Leaf
+      Information Required flag in the PMSI Tunnel attribute to 1.
+
+    + An ASBR that uses a P-multicast tree as the intra-AS segment of
+      the inter-AS tunnel MAY aggregate two or more MVPNs present on the
+      ASBR onto the same tree.  In this case, in addition to the
+      identity of the tree, the PMSI Tunnel attribute of the Inter-AS I-
+      PMSI A-D route MUST carry an MPLS upstream-assigned label that the
+      PE has bound uniquely to the MVPN associated with this route (as
+      determined by its RTs).
+
+      If the ASBR has already advertised Inter-AS I-PMSI A-D routes for
+      two or more MVPNs that it now desires to aggregate, then the ASBR
+      MUST re-advertise those routes.  The re-advertised routes MUST be
+      the same as the original ones, except for the PMSI Tunnel
+      attribute and the MVPN label.
+
+9.2.3.2.1.  Originating Leaf A-D Route into EBGP
+
+   In addition, the ASBR MUST send to the EBGP neighbor from whom it
+   received the Inter-AS I-PMSI A-D route, a BGP Update message that
+   carries 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 Inter-AS I-PMSI A-D route
+      received from that neighbor and the Originating Router's IP
+      address set to the IP address of the ASBR (this MUST be a routable
+      IP address).
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 25]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+    + 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 by the advertising router to demultiplex the MVPN traffic
+      received over a unicast tunnel from the EBGP neighbor.
+
+    + 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 I-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.  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 I-PMSI A-D route.
+
+    + 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_ADVERTISE BGP Community [RFC1997].
+
+   Handling of this Leaf A-D route by the EBGP neighbor is described in
+   Section 9.2.3.3.
+
+   The ASBR MUST set up its forwarding state such that packets that
+   arrive on the one-hop ASBR-ASBR LSP, as specified in the PMSI Tunnel
+   attribute of the Leaf A-D route, are transmitted on the intra-AS
+   segment, as specified in the PMSI Tunnel attribute of the Inter-AS
+   I-PMSI A-D route that the ASBR re-advertises in its own AS.  However,
+   the packets MAY be filtered before forwarding, as specified in
+   Section 9.2.3.6.
+
+9.2.3.3.  Leaf A-D Route Received via EBGP
+
+   When an ASBR receives, via EBGP, a Leaf A-D route originated by its
+   neighbor ASBR, if the Route Target carried in the Extended
+   Communities attribute of the route matches one of the ASBR Import RT
+   (auto-)configured on the ASBR, the ASBR performs the following.
+
+    + The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI
+      has the same value as the Route Key field of the Leaf A-D route.
+
+    + If the found Inter-AS I-PMSI A-D route was originated by ASBR
+      itself, then the ASBR sets up its forwarding state such that
+      packets received on the intra-AS tunnels originating in the ASBR's
+      own AS are transmitted on the one-hop ASBR-ASBR LSP specified by
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 26]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+      the MPLS label carried in the PMSI Tunnel attribute of the
+      received Leaf A-D route.  (However, the packets MAY be filtered
+      before transmission as specified in Section 9.2.3.6).  The intra-
+      AS tunnels are specified in the PMSI Tunnel attribute of all the
+      Intra-AS I-PMSI A-D routes received by the ASBR that the ASBR
+      aggregated into the Inter-AS I-PMSI A-D route.  For each of these
+      intra-AS tunnels, if a non-zero MPLS label is carried in the PMSI
+      Tunnel attribute (i.e., aggregation is used), then only packets
+      received on the inner LSP corresponding to that label MUST be
+      forwarded, not the packets received on the outer LSP, as the outer
+      LSP possibly carries the traffic of other VPNs.
+
+    + If the found Inter-AS I-PMSI A-D route was originated by some
+      other ASBR, then the ASBR sets up its forwarding state such that
+      packets received on the intra-AS tunnel segment, as specified in
+      the PMSI Tunnel attribute of the found Inter-AS I-PMSI A-D route,
+      are transmitted on the one-hop ASBR-ASBR LSP, as specified by the
+      MPLS label carried in the PMSI Tunnel attribute of the Leaf A-D
+      route.
+
+9.2.3.4.  Inter-AS I-PMSI 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.
+
+   If a given Inter-AS I-PMSI A-D route is received via IBGP by a BGP
+   route reflector, the BGP route reflector MUST NOT modify the Next Hop
+   field of the MP_REACH_NLRI attribute when re-advertising the route
+   into IBGP (this is because the information carried in the Next Hop is
+   used for controlling flow of C-multicast routes, as specified in
+   Section 11.2).
+
+   If a given Inter-AS I-PMSI A-D route is advertised within an AS by
+   multiple ASBRs of that AS, the BGP best route selection performed by
+   other PE/ASBR routers within the AS does not require all these
+   PE/ASBR routers to select the route advertised by the same ASBR -- to
+   the contrary, different PE/ASBR routers may select routes advertised
+   by different ASBRs.
+
+   When a PE/ASBR router receives, from one of its IBGP neighbors, a BGP
+   Update message that carries an Inter-AS I-PMSI 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.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 27]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+    + If the router is a PE, then the router imports the route into the
+      VRF(s) that have the matching import Route Targets.
+
+    + 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 I-PMSI A-D route carries the PMSI Tunnel
+      attribute, then the propagated route MUST carry the PMSI Tunnel
+      attribute with the Tunnel Type set to Ingress Replication; the
+      attribute carries no MPLS labels.
+
+    + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
+      attribute with the Tunnel Type set to mLDP P2MP LSP, PIM-SSM tree,
+      PIM-SM tree, or BIDIR-PIM tree, the PE/ASBR SHOULD join as soon as
+      possible the P-multicast tree whose identity is carried in the
+      Tunnel Identifier.
+
+    + If the received Inter-AS I-PMSI 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 it MAY
+      be established after the local PE receives the route.
+
+    + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
+      attribute with the Tunnel Type set to mLDP P2MP LSP, RSVP-TE P2MP
+      LSP, PIM-SSM, PIM-SM tree, or BIDIR-PIM tree, 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 MVPN advertised by the Inter-
+      AS I-PMSI A-D route and rooted at the AS that originated the
+      Inter-AS I-PMSI 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 the
+      ASBR-ASBR inter-AS segment of the inter-AS tunnel.  If the PE/ASBR
+      has local receivers in the MVPN, packets received over the intra-
+      AS segment must be forwarded to the local receivers using the
+      local VRF.
+
+9.2.3.4.1.  Originating Leaf A-D Route into IBGP
+
+   If the Leaf Information Required flag in the PMSI Tunnel attribute of
+   the received Inter-AS I-PMSI A-D route is set to 1, then the PE/ASBR
+   MUST originate a new Leaf A-D route as follows.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 28]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+    + The route carries a single MCAST-VPN NLRI with the Route Key field
+      set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route
+      received from that neighbor and the Originating Router's IP
+      address set to the IP address of the PE/ASBR (this MUST be a
+      routable IP address).
+
+    + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel
+      attribute with the Tunnel Type set to Ingress Replication, then
+      the Leaf A-D route MUST carry the PMSI Tunnel attribute with the
+      Tunnel Type set to Ingress Replication.  The Tunnel Identifier
+      MUST carry a routable address of the PE/ASBR.  The PMSI Tunnel
+      attribute MUST carry a downstream-assigned MPLS label that is used
+      to demultiplex the MVPN traffic received over a unicast tunnel by
+      the PE/ASBR.
+
+    + The PE/ASBR constructs an IP-based Route Target Extended Community
+      by placing the IP address carried in the Next Hop of the received
+      Inter-AS I-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].
+
+    + Once the Leaf A-D route is constructed, the PE/ASBR advertises
+      this route into IBGP.
+
+9.2.3.5.  Leaf A-D Route Received via IBGP
+
+   When an ASBR receives, via IBGP, a Leaf A-D route, if the Route
+   Target carried in the Extended Communities attribute of the route
+   matches one of the ASBR Import RT (auto-)configured on the ASBR, the
+   ASBR performs the following.
+
+   The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has
+   the same value as the Route Key field of the Leaf A-D route.
+
+   The received route may carry either (a) no PMSI Tunnel attribute, or
+   (b) the PMSI Tunnel attribute, but only with the Tunnel Type set to
+   Ingress Replication.
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 29]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   If the received route does not carry the PMSI Tunnel attribute, the
+   ASBR uses the information from the received route to determine the
+   leaves of the P-multicast tree rooted at the ASBR that would be used
+   for the intra-AS segment associated with the found Inter-AS I-PMSI
+   A-D route.  The IP address of a leaf is the IP address carried in the
+   Originating Router's IP address field of the received Leaf A-D route.
+
+   If the received route carries the PMSI Tunnel attribute with the
+   Tunnel Type set to Ingress Replication, the ASBR uses the information
+   carried by the route to construct the intra-AS segment with ingress
+   replication.
+
+9.2.3.6.  Optimizing Bandwidth by IP Filtering on ASBRs
+
+   An ASBR that has a given Inter-AS I-PMSI A-D route MAY discard some
+   of the traffic carried in the tunnel specified in the PMSI Tunnel
+   attribute of this route, if the ASBR determines that there are no
+   downstream receivers for that traffic.
+
+   When BGP is being used to distribute C-multicast routes, an ASBR that
+   has a given Inter-AS I-PMSI A-D route MAY discard traffic from a
+   particular customer multicast source C-S and destined to a particular
+   customer multicast group address C-G that is carried over the tunnel
+   specified in the PMSI Tunnel attribute of the route, if none of the
+   C-multicast routes on the ASBR with RD and Source AS being the same
+   as the RD and Source AS of the Inter-AS I-PMSI A-D route matches the
+   (C-S,C-G) tuple.  A C-multicast route is said to match a (C-S,C-G)
+   tuple, if it is a Source Tree Join route with Multicast Source set to
+   C-S and Multicast Group set to C-G or a Shared Tree Join route with
+   Multicast Group set to C-G.
+
+   The above procedures MAY also apply to an ASBR that originates a
+   given Inter-AS I-PMSI A-D route.  In this case, the ASBR applies them
+   to the traffic carried over the tunnels specified in the PMSI Tunnel
+   attribute of the Intra-AS I-PMSI A-D routes that the ASBR aggregates
+   into the Inter-AS I-PMSI A-D route and whose tails are stitched to
+   the one-hop ASBR-ASBR tunnel specified in the Inter-AS I-PMSI A-D
+   route.
+
+10.  Non-Congruent Unicast and Multicast Connectivity
+
+   It is possible to deploy MVPN such that the multicast routing and the
+   unicast routing are "non-congruent".  For instance, the CEs may be
+   distributing to the PEs a special set of unicast routes that are to
+   be used exclusively for the purpose of upstream multicast hop
+   selection, and not used for unicast routing at all.  (For example,
+   when BGP is the CE-PE unicast routing protocol, the CEs may be using
+   SAFI 2 ("Network Layer Reachability Information used for multicast
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 30]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   forwarding" [IANA-SAFI]), and either IPv4 or IPv6 AFI to distribute a
+   special set of routes that are to be used for, and only for, upstream
+   multicast hop selection.) In such a situation, we will speak of the
+   MVPN as having two VRFs on a given PE: one containing the routes that
+   are used for unicast, the other containing the unicast routes that
+   are used for UMH selection.  We will call the former the "unicast
+   routing VRF" and the latter the "UMH VRF" (upstream-multicast-hop
+   VRF).
+
+   In this document, when we speak without qualification of the MVPN's
+   VRF, then if the MVPN has both a unicast VRF and a UMH VRF, we are
+   speaking of the UMH VRF.  (Of course, if there is no separate UMH
+   VRF, then we are speaking of the unicast VRF.)
+
+   If there is a separate UMH VRF, it MAY have its own import and export
+   Route Targets, different from the ones used by the unicast VRF.
+   These Route Targets MUST be used to control distribution of auto-
+   discovery routes.  In addition, the export Route Targets of the UMH
+   VRF are added to the Route Targets used by the unicast VRF when
+   originating (unicast) VPN-IP routes.  The import Route Targets
+   associated with a given UMH VRF are used to determine which of the
+   received (unicast) VPN-IP routes should be accepted into the UMH VRF.
+
+   If a PE maintains an UMH VRF for that MVPN, then it is RECOMMENDED
+   that the UMH VRF use the same RD as the one used by the unicast VRF
+   of that MVPN.
+
+   If an MVPN site is multihomed to several PEs, then to support non-
+   congruent unicast and multicast connectivity, on each of these PEs,
+   the UMH VRF of the MVPN MUST use its own distinct RD (although on a
+   given PE, the RD used by the UMH VRF SHOULD be the same as the one
+   used by the unicast VRF).
+
+   If an MVPN has a UMH VRF distinct from its unicast VRF, then one
+   option to support non-congruency is to exchange the routes to/from
+   that UMH VRF by using the same AFI/SAFI as used by the routes from
+   the unicast VRF.
+
+   Another option is to exchange the routes to/from the UMH VRF using
+   the IPv4 or IPv6 AFI (as appropriate), but with the SAFI set to SAFI
+   129 "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)"
+   [IANA-SAFI].  The NLRI carried by these routes is defined as follows:
+
+      +---------------------------+
+      |   Length (1 octet)        |
+      +---------------------------+
+      |   Prefix (variable)       |
+      +---------------------------+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 31]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   The use and the meaning of these fields are as follows:
+
+   a) Length:
+
+      The Length field indicates the length, in bits, of the address
+      prefix.
+
+   b) Prefix:
+
+      The Prefix field contains a Route Distinguisher as defined in
+      [RFC4364] prepended to an IPv4 or IPv6 address prefix, followed by
+      enough trailing bits to make the end of the field fall on an octet
+      boundary.  Note that the value of trailing bits is irrelevant.
+
+   These routes MUST carry the VRF Route Import Extended Community.  If,
+   for a given MVPN, BGP is used for exchanging C-multicast routes, or
+   if segmented inter-AS tunnels are used, then these routes MUST also
+   carry the Source AS Extended Community.
+
+   The detailed procedures for selecting forwarder PE in the presence of
+   such routes are outside the scope of this document.  However, this
+   document requires these procedures to preserve the constraints
+   imposed by the single forwarder PE selection procedures, as specified
+   in [MVPN].
+
+11.  Exchange of C-Multicast Routing Information among PEs
+
+   VPN C-Multicast Routing Information is exchanged among PEs by using
+   C-multicast routes that are carried using an MCAST-VPN NLRI.  These
+   routes are originated and propagated as follows.
+
+11.1.  Originating C-Multicast Routes by a PE
+
+   Part of the procedures for constructing MCAST-VPN NLRI depends on the
+   multicast routing protocol between CE and PE (C-multicast protocol).
+
+11.1.1.  Originating Routes: PIM as the C-Multicast Protocol
+
+   The following specifies the construction of MCAST-VPN NLRI of
+   C-multicast routes for the case where the C-multicast protocol is
+   PIM.  These C-multicast routes are originated as a result of updates
+   in the (C-S,C-G), or (C-*,C-G) state learned by a PE via the
+   C-multicast protocol.
+
+   Note that creation and deletion of (C-S,C-G,rpt) states on a PE when
+   the C-multicast protocol is PIM do not result in any BGP actions.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 32]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+11.1.1.1.  Originating Source Tree Join C-Multicast Route
+
+   Whenever (a) a C-PIM instance on a particular PE creates a new
+   (C-S,C-G) state, and (b) the selected upstream PE for C-S (see
+   [MVPN]) is not the local PE, then the local PE MUST originate a
+   C-multicast route of type Source Tree Join.  The Multicast Source
+   field in the MCAST-VPN NLRI of the route is set to C-S; the Multicast
+   Group field is set of C-G.
+
+   This C-multicast route is said to "correspond" to the C-PIM (C-S,C-G)
+   state.
+
+   The semantics of the route are such that the PE has one or more
+   receivers for (C-S,C-G) in the sites connected to the PE (the route
+   has the (C-S,C-G) Join semantics).
+
+   Whenever a C-PIM instance on a particular PE deletes a (C-S,C-G)
+   state, the corresponding C-multicast route MUST be withdrawn.  (The
+   withdrawal of the route has the (C-S,C-G) Prune semantics).  The
+   MCAST-VPN NLRI of the withdrawn route is carried in the
+   MP_UNREACH_NLRI attribute.
+
+11.1.1.2.  Originating Shared Tree Join C-Multicast Route
+
+   Whenever (a) a C-PIM instance on a particular PE creates a new
+   (C-*,C-G) state, and (b) the selected upstream PE for the C-RP
+   corresponding to the C-G (see [MVPN]) is not the local PE, then the
+   local PE MUST originate a C-multicast route of type Shared Tree Join.
+   The Multicast Source field in the MCAST-VPN NLRI of the route is set
+   to the C-RP address.  The Multicast Group field in the MCAST-VPN NLRI
+   is set to the C-G address.
+
+   This C-multicast route is said to "correspond" to the C-PIM (C-*,C-G)
+   state.
+
+   The semantics of the route are such that the PE has one or more
+   receivers for (C-*,C-G) in the sites connected to the PE (the route
+   has the (C-*,C-G) Join semantics).
+
+   Whenever a C-PIM instance on a particular PE deletes a (C-*,C-G)
+   state, the corresponding C-multicast route MUST be withdrawn.  (The
+   withdrawal of the route has the (C-S,C-G) Prune semantics).  The
+   MCAST-VPN NLRI of the withdrawn route is carried in the
+   MP_UNREACH_NLRI attribute.
+
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 33]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+11.1.2.  Originating Routes: mLDP as the C-Multicast Protocol
+
+   The following specifies the construction of the MCAST-VPN NLRI of
+   C-multicast routes for the case where the C-multicast protocol is
+   mLDP [mLDP].
+
+   Whenever a PE receives, from one of its CEs, a P2MP Label Map
+   <X, Y, L> over interface I, where X is the Root Node Address, Y is
+   the Opaque Value, and L is an MPLS label, the PE checks whether it
+   already has state for <X, Y> in the VRF associated with the CE.  If
+   so, then all the PE needs to do in this case is to update its
+   forwarding state by adding <I, L> to the forwarding state associated
+   with <X, Y>.
+
+   If the PE does not have state for <X, Y> in the VRF associated with
+   the CE, then the PE constructs a Source Tree Join C-multicast route
+   whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y
+   as the Multicast Group field.
+
+   Whenever a PE deletes a previously created <X, Y> state that had
+   resulted in originating a C-multicast route, the PE withdraws the
+   C-multicast route.  The MCAST-VPN NLRI of the withdrawn route is
+   carried in the MP_UNREACH_NLRI attribute.
+
+11.1.3.  Constructing the Rest of the C-Multicast Route
+
+   The rest of the C-multicast route is constructed as follows (the same
+   procedures apply to both PIM and mLDP as the C-Multicast protocol).
+
+   The local PE executes the procedures of [MVPN] to find the selected
+   Upstream Multicast Hop (UMH) route and the selected upstream PE for
+   the address carries in the Multicast Source field of MCAST-VPN NLRI.
+
+   From the selected UMH route, the local PE extracts (a) the ASN of the
+   upstream PE (as carried in the Source AS Extended Community of the
+   route), and (b) the C-multicast Import RT of the VRF on the upstream
+   PE (the value of this C-multicast Import RT is the value of the VRF
+   Route Import Extended Community carried by the route).  The Source AS
+   field in the C-multicast route is set to that AS.  The Route Target
+   Extended Community of the C-multicast route is set to that
+   C-multicast Import RT.
+
+   If there is more than one (remote) PE that originates the (unicast)
+   route to the address carried in the Multicast Source field of the
+   MCAST-VPN NLRI, then the procedures for selecting the UMH route and
+   the upstream PE to reach that address are as specified in [MVPN].
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 34]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   If the local and the upstream PEs are in the same AS, then the RD of
+   the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route
+   that contains the address carried in the Multicast Source field.
+
+   The C-multicast route is then advertised into IBGP.
+
+   If the local and the upstream PEs are in different ASes, then the
+   local PE finds in its VRF an Inter-AS I-PMSI A-D route whose Source
+   AS field carries the ASN of the upstream PE.  The RD of the found
+   Inter-AS I-PMSI A-D route is used as the RD of the advertised
+   C-multicast route.  The local PE constructs an IP-based Route Target
+   Extended Community by placing the Next Hop of the found Inter-AS I-
+   PMSI A-D route in the Global Administrator field of this Community,
+   with the Local Administrator field of this Community set to 0; it
+   then adds this Community to the Extended Communities attribute of the
+   C-multicast route.  (Note that this Route Target is the same as the
+   ASBR Import RT of the ASBR identified by the Next Hop of the found
+   Inter-AS I-PMSI A-D route.)
+
+   Inter-AS I-PMSI A-D routes are not used to support non-segmented
+   inter-AS tunnels.  To support non-segmented inter-AS tunnels, if the
+   local and the upstream PEs are in different ASes, the local system
+   finds in its VRF an Intra-AS I-PMSI A-D route from the upstream PE
+   (the Originating Router's IP Address field of that route has the same
+   value as the one carried in the VRF Route Import of the (unicast)
+   route to the address carried in the Multicast Source field).  The RD
+   of the found Intra-AS I-PMSI A-D route is used as the RD of the
+   advertised C-multicast route.  The Source AS field in the C-multicast
+   route is set to value of the Originating Router's IP Address field of
+   the found Intra-AS I-PMSI A-D route.
+
+   The Next Hop field of the MP_REACH_NLRI attribute MUST be set to a
+   routable IP address of the local PE.
+
+   If the Next Hop of the found (Inter-AS or Intra-AS) I-PMSI A-D route
+   is an EBGP neighbor of the local PE, then the PE advertises the C-
+   multicast route to that neighbor.  If the Next Hop of the found
+   (Inter-AS or Intra-AS) I-PMSI A-D route is within the same AS as the
+   local PE, then the PE advertises the C-multicast route into IBGP.
+
+11.1.4.  Unicast Route Changes
+
+   The particular UMH route that is selected by a given PE for a given
+   C-S may be influenced by the network's unicast routing.  In that
+   case, a change in the unicast routing may invalidate prior choices of
+   the UMH route for some C-S.  If this happens, the local PE MUST
+   execute the UMH route selection procedures for C-S again.  If the
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 35]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   result is that a different UMH route is selected, then for all C-G,
+   any previously originated C-multicast routes for (C-S,C-G) MUST be
+   re-originated.
+
+   Similarly, if a unicast routing change results in a change of the UMH
+   route for a C-RP, then for all C-G such that C-RP is the RP
+   associated with C-G, any previously originated C-multicast routes for
+   (C-*,C-G) MUST be re-originated.
+
+11.2.  Propagating C-Multicast Routes by an ASBR
+
+   When an ASBR receives a BGP Update message that carries a C-multicast
+   route, if at least one of the Route Targets of the route matches one
+   of the ASBR Import RTs (auto-)configured on the ASBR, the ASBR finds
+   an Inter-AS I-PMSI A-D route whose RD and Source AS matches the RD
+   and Source AS carried in the C-multicast route.  If no matching route
+   is found, the ASBR takes no further action.  If a matching route is
+   found, the ASBR proceeds as follows.
+
+   To support non-segmented inter-AS tunnels, instead of matching the RD
+   and Source AS carried in the C-multicast route against the RD and
+   Source AS of an Inter-AS I-PMSI A-D route, the ASBR should match it
+   against the RD and the Originating Router's IP Address of the Intra-
+   AS I-PMSI A-D routes.
+
+   The ASBR first checks if it already has one or more C-multicast
+   routes that have the same MCAST-VPN NLRI as the newly received route.
+   If such a route(s) already exists, the ASBR keeps the newly received
+   route, but SHALL NOT re-advertise the newly received route.
+   Otherwise, the ASBR re-advertises the route, as described in this
+   section.
+
+   When an ASBR receives a BGP Update message that carries a withdrawal
+   of a previously advertised C-multicast route, the ASBR first checks
+   if it already has at least one other C-multicast route that has the
+   same MCAST-VPN NLRI.  If such a route already exists, the ASBR
+   processes the withdrawn route, but SHALL NOT re-advertise the
+   withdrawal.  Otherwise, the ASBR re-advertises the withdrawal of the
+   previously advertised C-multicast route, as described below.
+
+   If the ASBR is the ASBR that originated the found Inter-AS I-PMSI A-D
+   route, then before re-advertising the C-multicast route into IBGP,
+   the ASBR removes from the route the Route Target that matches one of
+   the ASBR Import RTs (auto-)configured on the ASBR.
+
+   If the ASBR is not the ASBR that originated the found Inter-AS I-PMSI
+   A-D route, then before re-advertising the C-multicast route, the ASBR
+   modifies the Extended Communities attribute of the C-multicast route
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 36]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   by replacing the Route Target of the route that matches one of the
+   ASBR Import RTs (auto-)configured on the ASBR with a new Route Target
+   constructed as follows.  The new Route Target is an IP-based Route
+   Target that has the Global Administrator field set to the Next Hop of
+   the found Inter-AS I-PMSI A-D route, and Local Administrator field of
+   this Community set to 0.  Note that this newly constructed Route
+   Target is the same as the ASBR Import RT of the ASBR identified by
+   the Next Hop of the found Inter-AS I-PMSI A-D route.  The rest of the
+   Extended Communities attribute of the route SHOULD be passed
+   unmodified.
+
+   The Next Hop field of the MP_REACH_NLRI attribute SHOULD be set to an
+   IP address of the ASBR.
+
+   If the Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or
+   Intra-AS) I-PMSI A-D route is an EBGP neighbor of the ASBR, then the
+   ASBR re-advertises the C-multicast route to that neighbor.  If the
+   Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or Intra-
+   AS) I-PMSI A-D route is an IBGP neighbor of the ASBR, the ASBR re-
+   advertises the C-multicast route into IBGP.  If it is the ASBR that
+   originated the found Inter-AS I-PMSI A-D route in the first place,
+   then the ASBR just re-advertises the C-multicast route into IBGP.
+
+11.3.  Receiving C-Multicast Routes by a PE
+
+   When a PE receives a C-multicast route the PE checks if any of the
+   Route Target Extended Communities carried in the Extended Communities
+   attribute of the route match any of the C-multicast Import RTs
+   associated with the VRFs of any MVPN maintained by the PE.  If no
+   match is found, the PE SHOULD discard the route.  Otherwise, (if a
+   match is found), the PE checks if the address carried in the
+   Multicast Source field of the C-multicast route matches one of the
+   (unicast) VPN-IP routes advertised by PE from the VRF.  If no match
+   is found the PE SHOULD discard the route.  Otherwise, (if a match is
+   found), the PE proceeds as follows, depending on the multicast
+   routing protocol between CE and PE (C-multicast protocol).
+
+11.3.1.  Receiving Routes: PIM as the C-Multicast Protocol
+
+   The following describes procedures when PIM is used as the multicast
+   routing protocol between CE and PE (C-multicast protocol).
+
+   Since C-multicast routing information is disseminated by BGP, PIM
+   messages are never sent from one PE to another.
+
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 37]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+11.3.1.1.  Receiving Source Tree Join C-Multicast Route
+
+   If the received route has the Route Type set to Source Tree Join,
+   then the PE creates a new (C-S,C-G) state in its MVPN-TIB from the
+   Multicast Source and Multicast Group fields in the MCAST-VPN NLRI of
+   the route, if such a state does not already exist.
+
+   If the local policy on the PE is to bind (C-S,C-G) to an S-PMSI, then
+   the PE adds the S-PMSI to the outgoing interface list of the
+   (C-S,C-G) state, if it is not already there.  Otherwise, the PE adds
+   an I-PMSI to the outgoing interface list of the (C-S,C-G) state, if
+   it is not already there.
+
+   When, for a said VRF, the last Source Tree Join C-multicast route for
+   (C-S,C-G) is withdrawn, resulting in the situation where the VRF
+   contains no Source Tree Join C-multicast route for (C-S,C-G), the PE
+   MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the
+   (C-S,C-G) state.  Depending on the (C-S,C-G) state of the PE-CE
+   interfaces, this may result in the PE using PIM procedures to prune
+   itself off the (C-S,C-G) tree.  If C-G is not in the SSM range for
+   the VRF, then removing the I-PMSI/S-PMSI from the outgoing interface
+   list of the (C-S,C-G) state SHOULD be done after a delay that is
+   controlled by a timer.  The value of the timer MUST be configurable.
+
+   The purpose of this timer is to ensure that the PE does not stop
+   forwarding (C-S,C-G) onto a PMSI tunnel until all the PEs of the same
+   MVPN have had time to receive the withdrawal of the Source Active A-D
+   route for (C-S,C-G) (see Section 13.1), and the PE connected to C-RP
+   starts forwarding (C-S,C-G) on the C-RPT.
+
+   Note that before the PE stops forwarding (C-S,C-G), there is a
+   possibility to have (C-S,C-G) packets being sent at the same time on
+   the PMSI by both the local PE and the PE connected to the site that
+   contains C-RP.  This would result in a transient unnecessary traffic
+   on the provider backbone.  However, no duplicates will reach customer
+   hosts subscribed to C-G as long as the downstream PEs apply
+   procedures described in Section 9.1 of [MVPN].
+
+11.3.1.2.  Receiving Shared Tree Join C-Multicast Route
+
+   If the received route has the Route Type set to Shared Tree Join,
+   then the PE creates a new (C-*,C-G) state in its MVPN-TIB with the RP
+   address for that state taken from the Multicast Source, and C-G for
+   that state taken from the Multicast Group fields of the MCAST-VPN
+   NLRI of the route, if such a state does not already exist.  If there
+   is no S-PMSI for (C-*,C-G), then the PE adds I-PMSI to the outgoing
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 38]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   interface list of the state if it is not already there.  If there is
+   an S-PMSI for (C-*,C-G), then the PE adds S-PMSI to the outgoing
+   interface list of the state if it is not already there.
+
+   When, for a said VRF, the last Shared Tree Join C-multicast route for
+   (C-*,C-G) is withdrawn, resulting in the situation where the VRF
+   contains no Shared Tree Join C-multicast route for (C-*,C-G), the PE
+   MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the
+   (C-*,C-G) state.  Depending on the (C-*,C-G) state of the PE-CE
+   interfaces, this may result in the PE using PIM procedures to prune
+   itself off the (C-*,C-G) tree.
+
+11.3.2.  Receiving Routes: mLDP as the C-Multicast Protocol
+
+   The following describes procedures when mLDP is used as the multicast
+   routing protocol between CE and PE (C-multicast protocol).
+
+   When mLDP is used as a C-multicast protocol, the only valid type of a
+   C-multicast route that a PE could receive is a Source Tree Join
+   C-multicast route.
+
+   When the PE receives a Source Tree Join C-multicast route, the PE
+   applies, in the scope of this VRF, the P2MP mLDP procedures for a
+   transit node using the value carried in the Multicast Source field of
+   the route as the C-Root Node Identifier, and the value carried in the
+   Multicast Group of the route as the C-LDP MP Opaque Value Element.
+
+   If there is no S-PMSI for <C-Root Node Identifier, C-LDP MP Opaque
+   Value Element>, then the PE creates and advertises an S-PMSI as
+   described in Section 12 using C-Root Node Identifier as the value for
+   the Multicast Source field of the S-PMSI A-D route and C-LDP MP
+   Opaque Value Element as the value for the Multicast Group field of
+   the route.
+
+   To improve scalability when mLDP is used as the C-Multicast protocol
+   for a given MVPN, within each AS that has sites of that MVPN
+   connected to the PEs of that AS, all the S-PMSIs of that MVPN MAY be
+   aggregated into a single P-multicast tree (by using upstream-assigned
+   labels).
+
+11.4.  C-Multicast Routes Aggregation
+
+   Note that C-multicast routes are "de facto" aggregated by BGP.  This
+   is because the MCAST-VPN NLRIs advertised by multiple PEs, for a
+   C-multicast route for a particular C-S and C-G (or a particular C-*
+   and C-G) of a given MVPN are identical.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 39]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   Hence, a BGP route reflector or ASBR that receives multiple such
+   routes with the same NLRI will re-advertise only one of these routes
+   to other BGP speakers.
+
+   This implies that C-multicast routes for a given (S,G) of a given
+   MVPN originated by PEs that are clients of a given route reflector
+   are aggregated by the route reflector.  For instance, if multiple PEs
+   that are clients of a route reflector, have receivers for a specific
+   SSM channel of a MVPN, they will all advertise an identical NLRI for
+   the Source Tree Join C-multicast route.  However, only one
+   C-multicast route will be advertised by the route reflector for this
+   specific SSM channel of that MVPN, to other PEs and route reflectors
+   that are clients of the route reflector.
+
+   This also implies that an ASBR aggregates all the received
+   C-multicast routes for a given (S,G) (or a given (*,G)) of a given
+   MVPN into a single C-multicast route.
+
+   To further reduce the routing churn due to C-multicast routes
+   changes, a route reflector that re-advertises a C-multicast route
+   SHOULD set the Next Hop field of the MP_REACH_NLRI attribute of the
+   route to an IP address of the route reflector.  Likewise, an ASBR
+   that re-advertises a C-multicast route SHOULD set the Next Hop field
+   of the MP_REACH_NLRI attribute of the route to an IP address of the
+   ASBR.
+
+   Further, a BGP receiver, which receives multiple such routes with the
+   same NLRI for the same C-multicast route, will potentially create
+   forwarding state based on a single C-multicast route.  Per the
+   procedures described in Section 11.3, this forwarding state will be
+   the same as the state that would have been created based on another
+   route with same NLRI.
+
+12.  Using S-PMSI A-D Routes to Bind C-Trees to P-Tunnels
+
+   This section describes BGP-based procedures for using S-PMSIs A-D
+   routes to bind (C-S,C-G) trees to P-tunnels.
+
+12.1.  Originating S-PMSI A-D Routes
+
+   The following describes procedures for originating S-PMSI A-D routes
+   by a PE.
+
+   The PE constructs the MCAST-VPN NLRI of an S-PMSI A-D route for a
+   given (C-S,C-G) as follows.
+
+    + The RD in this NLRI is set to the RD of the MVPN's VRF associated
+      with (C-S,C-G).
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 40]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+    + 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.
+
+    + 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.
+
+    + The Originating Router's IP Address field MUST be set to the IP
+      address that the (local) PE places in the Global Administrator
+      field of the VRF Route Import Extended Community of the VPN-IP
+      routes advertised by the PE.  Note that the <RD, Originating
+      Router's IP address> tuple uniquely identifies a given multicast
+      VRF.
+
+   The PE constructs the rest of the S-PMSI A-D route as follows.
+
+   Depending on the type of 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.
+
+    + 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 12.3.)
+
+      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.
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 41]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+      If the PE supports Route Target Constraint [RT-CONSTRAIN], the PE
+      SHOULD advertise this import Route Target within its own AS using
+      Route Target Constraints.  To constrain distribution of the Route
+      Target Constraint 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 MVPNs, then all these routes
+      MUST carry an MPLS upstream-assigned label [RFC5331].
+
+   If all these aggregated S-PMSIs belong to the same MVPN, and this
+   MVPN uses PIM as its C-multicast routing protocol, then the
+   corresponding S-PMSI A-D routes MAY carry an MPLS upstream-assigned
+   label [RFC5331].  Moreover, in this case, the labels MUST be distinct
+   on a per-MVPN basis and MAY be distinct on a per-route basis.
+
+   If all these aggregated S-PMSIs belong to the MVPN(s) that uses mLDP
+   as its C-multicast routing protocol, then the corresponding S-PMSI
+   A-D routes MUST carry an MPLS upstream-assigned label [RFC5331], and
+   these labels MUST be distinct on a per-route (per-mLDP FEC) basis,
+   irrespective of whether the aggregated S-PMSIs belong to the same or
+   different MVPNs.
+
+   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.
+
+   The route always carries a set of Route Targets.  The default set of
+   Route Targets is determined as follows:
+
+    + If there is a (unicast) VPN-IP route to C-S originated from the
+      VRF, but no (unicast) VPN-IP route to C-RP originated from the
+      VRF, then the set of Route Targets is formed by a set intersection
+      between the set of Route Targets carried in the Intra-AS I-PMSI A-
+      D route originated from the VRF and the set of Route Targets
+      carried by the (unicast) VPN-IP route to C-S.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 42]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+    + If there is no (unicast) VPN-IP route to C-S originated from the
+      VRF, but there is a (unicast) VPN-IP route to C-RP originated from
+      the VRF, then the set of Route Targets is formed by a set
+      intersection between the set of Route Targets carried in the
+      intra-AS I-PMSI A-D route originated from the VRF and the set of
+      Route Targets carried by the (unicast) VPN-IP route to C-RP.
+
+    + If there is a (unicast) VPN-IP route to C-S originated from the
+      VRF, and a (unicast) VPN-IP route to C-RP originated from the VRF,
+      then the set of Route Targets is formed by a set intersection
+      between the set of Route Targets carried in the Intra-AS I-PMSI A-
+      D route originated from the VRF and the set union of Route Targets
+      carried by the (unicast) VPN-IP route to C-S and the (unicast)
+      VPN-IP route to C-RP.
+
+   In each of the above cases, an implementation MUST allow the set of
+   Route Targets carried by the route to be specified by configuration.
+   In the absence of a configured set of Route Targets, the route MUST
+   carry the default set of Route Targets, as specified above.
+
+12.2.  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 9.2.3, except that instead of Inter-AS I-PMSI
+   A-D routes, the procedures apply to S-PMSI A-D routes.
+
+12.2.1.  Merging S-PMSI into an I-PMSI
+
+   Consider the situation where:
+
+    + An ASBR is receiving (or expecting to receive) inter-AS (C-S,C-G)
+      data from upstream via an S-PMSI.
+
+    + The ASBR is sending (or expecting to send) the inter-AS (C-S,C-G)
+      data downstream via an I-PMSI.
+
+   This situation may occur if the upstream providers have a policy of
+   using S-PMSIs but the downstream providers have a policy of using
+   I-PMSIs.  To support this situation, an ASBR MAY, under certain
+   conditions, merge one or more upstream S-PMSIs into a downstream
+   I-PMSI.
+
+   An S-PMSI (corresponding to a particular S-PMSI A-D route) MAY be
+   merged by a particular ASBR into an I-PMSI (corresponding to a
+   particular Inter-AS I-PMSI A-D route) if and only if the following
+   conditions all hold:
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 43]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+    + BGP is used to exchange C-multicast routes.
+
+    + The S-PMSI A-D route and the Inter-AS I-PMSI A-D route originate
+      in the same AS.  The Inter-AS I-PMSI A-D route carries the
+      originating AS in the Source AS field of the NLRI of the route and
+      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 I-PMSI A-D route have
+      exactly the same set of RTs.
+
+    + For each (C-S,C-G) mentioned in the S-PMSI route, if the ASBR has
+      installed a Source Tree Join (C-S,C-G) C-multicast route, then the
+      S-PMSI route was originated by the upstream PE of the C-multicast
+      route.  The address of the upstream PE is carried in the RT of the
+      C-multicast route.  The address of the PE that originated the
+      S-PMSI route is carried in the Originating Router's IP Address
+      field of the MCAST-VPN NLRI of the route.
+
+    + The ASBR supports the optional capability to discard (C-S,C-G)
+      traffic received on an I-PMSI.
+
+   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 I-PMSI A-D route re-
+   advertised by the ASBR.
+
+   IP processing during merge: If an ASBR merges a (C-S,C-G) S-PMSI A-D
+   route into an Inter-AS I-PMSI A-D route, the ASBR MUST discard all
+   (C-S,C-G) traffic it receives on the tunnel advertised in the I-PMSI
+   A-D route.
+
+   An ASBR that merges an S-PMSI A-D route into an Inter-AS I-PMSI A-D
+   route MUST NOT re-advertise the S-PMSI A-D route.
+
+12.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 VRFs 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 VRF (and associated MVPN-TIB) 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 9.2.3.4 except that (a) instead of Inter-AS
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 44]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   I-PMSI A-D routes, the procedures apply to S-PMSI A-D routes and (b)
+   a PE performs procedures specified in that section only if, in
+   addition to the criteria there, one of the following is true:
+
+    + the PE originates a Source Tree Join (C-S,C-G) C-multicast route,
+      and the upstream PE of that route is the PE that originates the
+      S-PMSI A-D route; or
+
+    + the PE does not originate a Source Tree Join (C-S,C-G) C-multicast
+      route, but it originates a Shared Tree Join (C-*,C-G) C-multicast
+      route.  The best (as determined by the BGP route selection
+      procedures) Source Active A-D route for (C-S,C-G) selected by the
+      PE is originated by the same PE as the one that originates the
+      S-PMSI A-D route; or
+
+    + the PE does not originate a Source Tree Join (C-S,C-G), has not
+      received any Source Active A-D routes for (C-S,C-G), but does
+      originate a Shared Tree Join (C-*,C-G) route.  The upstream PE for
+      that route is the PE that originates the received S-PMSI A-D
+      route.
+
+   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.  The Route Key of the Leaf A-D route is set to the
+   MCAST-VPN NLRI of the S-PMSI A-D route.  The rest of the Leaf A-D
+   route is constructed using the same procedures as specified in
+   section 9.2.3.4.1, except that instead of originating Leaf A-D routes
+   in response to receiving Inter-AS I-PMSI A-D routes, the procedures
+   apply to originating Leaf A-D routes in response to receiving S-PMSI
+   A-D routes.
+
+   In addition to the procedures specified in Section 9.2.3.4.1, the PE
+   MUST set up its forwarding path to receive (C-S,C-G) traffic from the
+   tunnel advertised by the S-PMSI A-D route (the PE MUST switch to the
+   S-PMSI).
+
+   If a PE that is a leaf node of a particular Selective tunnel
+   determines that it no longer needs to receive any of (C-S,C-G)s
+   carried over that tunnel, the PE SHOULD prune itself off that tunnel.
+   Procedures for pruning are specific to a particular tunneling
+   technology.
+
+13.  Switching from Shared a C-Tree to a Source C-Tree
+
+   The procedures defined in this section only apply when the
+   C-multicast routing protocol is PIM [RFC4601]; moreover, they only
+   apply for the multicast ASM mode and MUST NOT be applied to multicast
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 45]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   group addresses belonging to the SSM range.  The procedures also MUST
+   NOT be applied when the C-multicast routing protocol is BIDIR-PIM
+   [RFC5015].
+
+   The procedures of this section are applicable only to MVPNs that use
+   both shared (i.e., rooted at a C-RP) and source (i.e., rooted at a
+   C-S) inter-site C-trees.
+
+   These procedures are not applicable to MVPNs that do not use shared
+   inter-site C-trees and rely solely on source inter-site C-trees.  See
+   Section 14 for the procedures applicable to that scenario.
+
+   Whether or not a given MVPN uses both inter-site shared and source
+   C-trees must be known a priori (e.g., via provisioning).
+
+   In the scenario where an MVPN customer switches from a C-RP-based
+   tree (RPT) to the shortest path tree (SPT), in order to avoid packet
+   duplication, choosing of a single consistent upstream PE, as
+   described in [MVPN], may not suffice.  To illustrate this, consider a
+   set of PEs {PE2, PE4, PE6} that are on the C-RP tree for (C-*,C-G)
+   and have chosen a consistent upstream PE, as described in [MVPN], for
+   (C-*,C-G) state.  Further, this upstream PE, say PE1, is using a
+   Multidirectional Inclusive PMSI (MI-PMSI) for (C-*,C-G).  If a site
+   attached to one of these PEs, say PE2, switches to the C-S tree for
+   (C-S,C-G), PE2 generates a Source Tree Join C-multicast route towards
+   the upstream PE that is on the path to C-S, say PE3.  PE3 also uses
+   the MI-PMSI for (C-S,C-G), as PE1 uses for (C-*,C-G).  This results
+   in {PE2, PE4, PE6} receiving duplicate traffic for (C-S,C-G) -- both
+   on the C-RP tree (from PE1) and C-S tree (from PE3).  If it is
+   desirable to suppress receiving duplicate traffic, then it is
+   necessary to choose a single forwarder PE for (C-S,C-G).  The
+   following describes how this is achieved.
+
+13.1.  Source within a Site - Source Active Advertisement
+
+   When, as a result of receiving a Source Tree Join C-multicast route
+   for (C-S,C-G) from some other PE the local PE adds either the S-PMSI
+   or the I-PMSI to the outgoing interface list of the (C-S,C-G) state
+   (see Section 11.3.1.1), the local PE MUST originate a Source Active
+   A-D route if the PE has not originated such route already.  The route
+   carries a single MCAST-VPN NLRI constructed as follows:
+
+    + The RD in this NLRI is set to the RD of the VRF of the MVPN on the
+      PE.
+
+    + The Multicast Source field MUST be set to C-S.  The Multicast
+      Source Length field is set appropriately to reflect this.
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 46]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+    + The Multicast Group field MUST be set to C-G.  The Multicast Group
+      Length field is set appropriately to reflect this.
+
+   The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the
+   IP address that the PE places in the Global Administrator field of
+   the VRF Route Import Extended Community of the VPN-IP routes
+   advertised by the PE from the MVPN's VRF.
+
+   The route SHOULD carry the same set of Route Targets as the Intra-AS
+   I-PMSI A-D route of the MVPN originated by the PE.
+
+   Using the normal BGP procedures, the Source Active A-D route is
+   propagated to all the PEs of the MVPN.
+
+   Note that the advertisement of a Source Active A-D route for a given
+   (C-S,C-G) could be combined, if desired, with the advertisement of an
+   S-PMSI A-D route for the same (C-S,C-G).  This is accomplished by
+   using the same BGP Update message to carry both the NLRI of the
+   S-PMSI A-D route and the NLRI of the Source Active A-D route.
+
+   Note that even if the originating PE advertises both the Source
+   Active A-D route and the S-PMSI A-D route in the same BGP Update
+   message, an implementation cannot assume that all other PEs will
+   receive both of these routes in the same Update message.
+
+   When, as a result of receiving a withdrawal of the previously
+   advertised Source Tree Join C-multicast route for (C-S,C-G), the PE
+   is going to remove the S-PMSI/I-PMSI from the outgoing interface list
+   of the (C-S,C-G) state.  The local PE MUST also withdraw the Source
+   Active A-D route for (C-S,C-G), if such a route has been advertised.
+
+   Note that if the PE is also acting as a C-RP, but inter-site shared
+   trees are being used, the reception of a PIM Register message by the
+   PE does not result in the origination of a Source Active A-D route.
+
+13.2.  Receiving Source Active A-D Route
+
+   When a PE receives a new Source Active A-D route from some other PE,
+   the PE finds a VRF whose import Route Targets match one or more of
+   the Route Targets carried by the route.  If the match is found, then
+   the PE updates the VRF with the received route.
+
+   We say that a given (C-S,C-G) Source Active A-D route stored in a
+   given VRF on a PE matches a given (C-*,C-G) entry present in the
+   MVPN-TIB associated with the VRF if C-G carried by the route is the
+   same as C-G of the entry, and the PE originates a Shared Tree Join
+   C-multicast route for the same C-G as the C-G of the entry.
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 47]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   When (as a result of receiving PIM messages from one of its CEs) a PE
+   creates in one of its MVPN-TIBs a (new) (C-*,C-G) entry with a non-
+   empty outgoing interface list that contains one or more PE-CE
+   interfaces, the PE MUST check if it has any matching Source Active
+   A-D routes.  If there is one or more such matching route, such that
+   the PE does not have (C-S,C-G) state in its MVPN-TIB for (C-S,C-G)
+   carried in the route, then the PE selects one of them (using the BGP
+   route selection procedures), and sets up its forwarding path to
+   receive (C-S,C-G) traffic from the tunnel that the originator of the
+   selected Source Active A-D route uses for sending (C-S,C-G).
+
+   When, as a result of receiving a new Source Active A-D route, a PE
+   updates its VRF with the route, the PE MUST check if the newly
+   received route matches any (C-*,C-G) entries.  If (a) there is a
+   matching entry, (b) the PE does not have (C-S,C-G) state in its MVPN-
+   TIB for (C-S,C-G) carried in the route, and (c) the received route is
+   selected as the best (using the BGP route selection procedures), then
+   the PE sets up its forwarding path to receive (C-S,C-G) traffic from
+   the tunnel the originator of the selected Source Active A-D route
+   uses for sending (C-S,C-G).
+
+   Note that if the PE is also acting as a C-RP, and inter-site shared
+   trees are being used, the BGP Source Active A-D routes do not replace
+   the Multicast Source Discovery Protocol (MSDP) or PIM-based Anycast
+   RP peerings among C-RPs that would be needed to disseminate source
+   discovery information among C-RPs.
+
+13.2.1.  Pruning Sources off the Shared Tree
+
+   In addition to the procedures in the previous section, a PE applies
+   the following procedure when importing a Source Active A-D route for
+   (C-S,C-G) into a VRF.
+
+   The PE finds a (C-*,C-G) entry in the MVPN-TIB whose C-G is the same
+   as the C-G carried in the Multicast Group field of the Source Active
+   A-D route.
+
+   If the outgoing interface list (oif) for the found (C-*,C-G) entry in
+   the MVPN-TIB on the PE contains either I-PMSI or S-PMSI, and the PE
+   does not originate the Source Tree Join C-multicast route for
+   (C-S,C-G) (where C-S is address carried in the Multicast Source field
+   and C-G is the address carried in the Multicast Group field of the
+   received Source Active A-D route), then the PE MUST transition the
+   (C-S,C-G,rpt) downstream state machine on I-PMSI/S-PMSI to the Prune
+   state.  (Conceptually, the C-PIM state machine on the PE will act "as
+   if" it had received Prune (C-S,C-G,rpt) on I-PMSI/S-PMSI, without
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 48]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   actually having received one.)  Depending on the (C-S,C-G,rpt) state
+   of the PE-CE interfaces, this may result in the PE using PIM
+   procedures to prune the C-S off the (C-*,C-G) tree.
+
+   Transitioning the state machine to the Prune state SHOULD be done
+   after a delay that is controlled by a timer.  The value of the timer
+   MUST be configurable.  The purpose of this timer is to ensure that
+   the C-S is not pruned off the shared tree until all PEs have had time
+   to receive the Source Active A-D route for (C-S,C-G).
+
+   Note that before C-S is pruned off the shared tree, there is a
+   possibility to have (C-S,C-G) packets sent at the same time on the
+   PMSI by distinct PEs.  This would result in a transient unnecessary
+   traffic on the provider backbone.  However, no duplicates will reach
+   customer hosts subscribed to C-G as long as the downstream PEs apply
+   procedures described in Section 9.1 of [MVPN].
+
+   The PE MUST keep the (C-S,C-G,rpt) downstream state machine on
+   I-PMSI/S-PMSI in the Prune state for as long as (a) the outgoing
+   interface list (oif) for the found (C-*,C-G) entry in the MVPN-TIB on
+   the PE contains either I-PMSI or S-PMSI, (b) the PE has at least one
+   Source Active A-D route for (C-S,C-G), and (c) the PE does not
+   originate the Source Tree Join C-multicast route for (C-S,C-G).  Once
+   any of these conditions become no longer valid, the PE MUST
+   transition the (C-S,C-G,rpt) downstream state machine on
+   I-PMSI/S-PMSI to the NoInfo state.
+
+   Note that changing the state on the downstream state machine on
+   I-PMSI/S-PMSI, as described above, does not imply exchanging PIM
+   messages over I-PMSI/S-PMSI.
+
+   Also, note that except for the scenario described in the third
+   paragraph of this section, in all other scenarios relying solely on
+   PIM procedures on the PE is sufficient to ensure the correct behavior
+   when pruning sources off the shared tree.
+
+14.  Supporting PIM-SM without Inter-Site Shared C-Trees
+
+   The procedures defined in this section only apply when the
+   C-multicast routing protocol is PIM [RFC4601]; moreover, only apply
+   for the multicast ASM mode, and MUST NOT be applied to multicast
+   group addresses belonging to the SSM range.  The procedures also MUST
+   NOT be applied when the C-multicast routing protocol is BIDIR-PIM
+   [RFC5015].
+
+   The procedures of this section are applicable only to MVPNs that do
+   not use inter-site shared (i.e., rooted at a C-RP) C-trees.
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 49]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   These procedures are not applicable to MVPNs that use both shared and
+   shortest path inter-site C-trees.  See Section 13 for the procedures
+   applicable to that scenario.
+
+   Whether or not a given MVPN uses inter-site shared C-trees must be
+   known a priori (e.g., via provisioning).
+
+14.1.  Discovering Active Multicast Sources
+
+   A PE can obtain information about active multicast sources within a
+   given MVPN in a variety of ways.  One way is for the PE to act as a
+   fully functional customer RP (C-RP) for that MVPN.  Another way is to
+   use PIM Anycast RP procedures [PIM-ANYCAST-RP] to convey information
+   about active multicast sources from one or more of the MVPN C-RPs to
+   the PE.  Yet another way is to use MSDP [MSDP] to convey information
+   about active multicast sources from the MVPN C-RPs to the PE.
+
+   When a PE using any of the above methods first learns of a new
+   (multicast) source within that MVPN, the PE constructs a Source
+   Active A-D route and sends this route to all other PEs that have one
+   or more sites of that MVPN connected to them.  The route carries a
+   single MCAST-VPN NLRI constructed as follows:
+
+    + The RD in this NLRI is set to the RD of the VRF of the MVPN on the
+      PE.
+
+    + The Multicast Source field MUST be set to the source IP address of
+      the multicast data packet carried in the PIM Register message
+      (RP/PIM register case) or of the MSDP Source-Active message (MSDP
+      case).  The Multicast Source Length field is set appropriately to
+      reflect this.
+
+    + The Multicast Group field MUST be set to the group IP address of
+      the multicast data packet carried in the PIM Register message
+      (RP/PIM register case) or of the MSDP Source-Active message (MSDP
+      case).  The Multicast Group Length field is set appropriately to
+      reflect this.
+
+   The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the
+   IP address that the PE places in the Global Administrator field of
+   the VRF Route Import Extended Community of the VPN-IP routes
+   advertised by the PE.
+
+   The route SHOULD carry the same set of Route Targets as the Intra-AS
+   I-PMSI A-D route of the MVPN originated by the PE.
+
+   Using the normal BGP procedures, the Source Active A-D route is
+   propagated to all the PEs of the MVPN.
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 50]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   When a PE that previously advertised a Source Active A-D route for a
+   given (multicast) source learns that the source is no longer active
+   (the PE learns this by using the same mechanism by which the PE
+   learned that the source was active), the PE SHOULD withdraw the
+   previously advertised Source Active route.
+
+14.2.  Receiver(s) within a Site
+
+   A PE follows the procedures specified in Section 11.1, except that
+   the procedures specified in Section 11.1.1.2 are replaced with the
+   procedures specified in this section.
+
+   When a PE receives a new Source Active A-D route, the PE finds a VRF
+   whose import Route Targets match one or more of the Route Targets
+   carried by the route.  If the match is found, then the PE updates the
+   VRF with the received route.
+
+   We say that a given (C-S,C-G) Source Active A-D route stored in a
+   given VRF matches a given (C-*,C-G) entry present in the MVPN-TIB
+   associated with the VRF if C-G carried by the route is the same as
+   C-G of the entry.
+
+   When (as a result of receiving PIM messages from one of its CEs) a PE
+   creates, in one of its MVPN-TIBs, a (new) (C-*,C-G) entry with a non-
+   empty outgoing interface list that contains one or more PE-CE
+   interfaces, the PE MUST check if it has any matching Source Active
+   A-D routes.  If there is one or more such matching routes, and the
+   best path to C-S carried in the matching route(s) is reachable
+   through some other PE, then for each such route the PE MUST originate
+   a Source Tree Join C-multicast route.  If there is one or more such
+   matching routes, and the best path to C-S carried in the matching
+   route(s) is reachable through a CE connected to the PE, then for each
+   such route the PE MUST originate a PIM Join (C-S,C-G) towards the CE.
+
+   When, as a result of receiving a new Source Active A-D route, a PE
+   updates its VRF with the route, the PE MUST check if the newly
+   received route matches any (C-*,C-G) entries.  If there is a matching
+   entry, and the best path to C-S carried in the (A-D) route is
+   reachable through some other PE, the PE MUST originate a Source Tree
+   Join C-multicast route for the (C-S,C-G) carried by the route.  If
+   there is a matching entry, and the best path to C-S carried in the
+   (A-D) route is reachable through a CE connected to the PE, the PE
+   MUST originate a PIM Join (C-S,C-G) towards the CE.
+
+   Construction and distribution of the Source Tree Join C-multicast
+   route follows the procedures specified in Section 11.1.1.1, except
+   that the Multicast Source Length, Multicast Source, Multicast Group
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 51]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   Length, and Multicast Group fields in the MCAST-VPN NLRI of the
+   Source Tree Join C-multicast route are copied from the corresponding
+   field in the Source Active A-D route.
+
+   A PE MUST withdraw a Source Tree Join C-multicast route for (C-S,C-G)
+   if, as a result of having received PIM messages from one of its CEs,
+   the PE creates a Prune (C-S,C-G,rpt) upstream state in one of its
+   MVPN-TIBs but has no (C-S,C-G) Joined state in that MVPN-TIB and had
+   previously advertised the said route.  (This is even if the VRF
+   associated with the MVPN-TIB still has a (C-S,C-G) Source Active A-D
+   route.)
+
+   A PE MUST withdraw a Source Tree Join C-multicast route for (C-S,C-G)
+   if the Source Active A-D route that triggered the advertisement of
+   the C-multicast route is withdrawn.
+
+   When a PE deletes the (C-*,C-G) state (e.g., due to receiving PIM
+   Prune (C-*,C-G) from its CEs), the PE MUST withdraw all the Source
+   Tree Join C-multicast routes for C-G that have been advertised by the
+   PE, except for the routes for which the PE still maintains the
+   corresponding (C-S,C-G) state.
+
+   Even though PIM is used as a C-multicast protocol, procedures
+   described in Section 11.1.1.2 do not apply here, as only the Source
+   Tree Join C-multicast routes are exchanged among PEs.
+
+14.3.  Receiving C-Multicast Routes by a PE
+
+   In this model, the only valid type of a C-multicast route that a PE
+   could receive is a Source Tree Join C-multicast route.  Processing of
+   such a route follows the procedures specified in Section 11.3.1.1.
+
+15.  Carrier's Carrier
+
+   A way to support the Carrier's Carrier model is provided by using
+   mLDP as the CE-PE multicast routing and label distribution protocol,
+   as specified in this document.
+
+   To improve scalability, it is RECOMMENDED that for the Carrier's
+   Carrier scenario within an AS, all the S-PMSIs of a given MVPN be
+   aggregated into a single P-multicast tree (by using upstream-assigned
+   labels).
+
+16.  Scalability Considerations
+
+   A PE should use Route Target Constraint [RT-CONSTRAIN] to advertise
+   the Route Targets that the PE uses for the VRF Route Imports Extended
+   Community (note that doing this requires just a single Route Target
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 52]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   Constraint advertisement by the PE).  This allows each C-multicast
+   route to reach only the relevant PE, rather than all the PEs
+   participating the an MVPN.
+
+   To keep the intra-AS membership/binding information within the AS of
+   the advertising router the BGP Update message originated by the
+   advertising router SHOULD carry the NO_EXPORT Community [RFC1997].
+
+   An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra-
+   AS I-PMSI A-D routes originated within the ASBR's own AS.  Thus,
+   while the Intra-AS I-PMSI A-D routes originated within an AS are at
+   the granularity of <PE, MVPN> within that AS, outside of that AS the
+   (aggregated) Inter-AS I-PMSI A-D routes are at the granularity of
+   <AS, MVPN>.  An Inter-AS I-PMSI A-D route for a given <AS, MVPN>
+   indicates the presence of one or more sites of the MVPN connected to
+   the PEs of the AS.
+
+   For a given inter-AS tunnel, each of its intra-AS segments could be
+   constructed by its own 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 MVPNs may
+   share the same P-multicast tree.
+
+   Since (aggregated) Inter-AS I-PMSI A-D routes may have a granularity
+   of <AS, MVPN>, an MVPN that is present in N ASes would have total of
+   N inter-AS tunnels.  Thus, for a given MVPN, the number of inter-AS
+   tunnels is independent of the number of PEs that have this MVPN.
+
+   Within each Autonomous System, BGP route reflectors can be
+   partitioned among MVPNs present in that Autonomous System so that
+   each partition carries routes for only a subset of the MVPNs
+   supported by the service provider.  Thus, no single route reflector
+   is required to maintain routes for all MVPNs.  Moreover, route
+   reflectors used for MVPN do not have to be used for VPN-IP routes
+   (although they may be used for VPN-IP routes as well).
+
+   As described in Section 11.4, C-multicast routes for a given (S,G) of
+   a given MVPN originated by PEs that are clients of a given route
+   reflector are aggregated by the route reflector.  Therefore, even if,
+   within a route reflector cluster, there are multiple C-multicast
+   routes for a given (S,G) of a given MVPN, outside of the cluster, all
+   these routes are aggregated into a single C-multicast route.
+   Additional aggregation of C-multicast routes occurs at ASBRs, where
+   an ASBR aggregates all the received C-multicast routes for a given
+   (S,G) of a given MVPN into a single C-multicast route.  Moreover,
+   both route reflectors and ASBRs maintain C-multicast routes only in
+   the control plane, but not in the data plane.
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 53]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+16.1.  Dampening C-Multicast Routes
+
+   The rate of C-multicast routing changes advertised by a PE is not
+   necessarily directly proportional to the rate of multicast routing
+   changes within the MVPN sites connected to the PE, as after the first
+   (C-S,C-G) Join originated within a site, all the subsequent Joins for
+   same (C-S,C-G) originated within the sites of the same MVPN connected
+   to the PE do not cause origination of new C-multicast routes by the
+   PE.
+
+   Depending on how multicast VPN is engineered, dynamic addition and
+   removal of P2MP RSVP-TE leaves through advertisement/withdrawal of
+   Leaf A-D routes will happen.  Dampening techniques can be used to
+   limit corresponding processing.
+
+   To lessen the control plane overhead associated with the processing
+   of C-multicast routes, this document proposes OPTIONAL route
+   dampening procedures similar to what is described in [RFC2439].  The
+   following OPTIONAL procedures can be enabled on a PE, ASBR, or BGP
+   Route Reflector advertising or receiving C-multicast routes.
+
+16.1.1.  Dampening Withdrawals of C-Multicast Routes
+
+   A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of
+   withdrawals of C-multicast routes.  An implementation SHOULD provide
+   the ability to control the delay via a configurable timer, possibly
+   with some backoff algorithm to adapt the delay to multicast routing
+   activity.
+
+   Dampening of withdrawals of C-multicast routes does not impede the
+   multicast Join latency observed by MVPN customers, and it also does
+   not impede the multicast leave latency observed by a CE, as multicast
+   forwarding from the VRF will stop as soon as C-multicast state is
+   removed in the VRF.
+
+   The potential drawbacks of dampening of withdrawals of C-multicast
+   routes are as follows:
+
+    + Until the withdrawals are actually sent, multicast traffic for the
+      C-multicast routes in question will be continued to be transmitted
+      to the PE, which will just have to discard it.  Note that the PE
+      may receive useless (multicast) traffic anyway, irrespective of
+      dampening of withdrawals of C-multicast routes due to the use of
+      I-PMSIs.
+
+    + Any state in the upstream PEs that would be removed as a result of
+      processing the withdrawals will remain until the withdrawals are
+      sent.
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 54]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   Discussion on whether the potential drawbacks mentioned above are of
+   any practical significance is outside the scope of this document.
+
+16.1.2.  Dampening Source/Shared Tree Join C-Multicast Routes
+
+   A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of
+   Source/Shared Tree Join C-multicast routes.  An implementation SHOULD
+   provide the ability to control the delay via a configurable timer,
+   possibly with some backoff algorithm to adapt the delay to multicast
+   routing activity.
+
+   Dampening Source/Shared Tree Join C-multicast routes will not impede
+   multicast Join latency observed by a given MVPN, except if the PE
+   advertising the Source/Shared Tree Join C-multicast route for a
+   particular C-S/C-RP is the first to do so for all the sites of the
+   MVPN that share the same upstream PE with respect to the C-S/C-RP.
+
+16.2.  Dampening Withdrawals of Leaf A-D Routes
+
+   Similar to the procedures proposed above for withdrawal of
+   C-multicast routes, dampening can be applied to the withdrawal of
+   Leaf A-D routes.
+
+17.  Security Considerations
+
+   The mechanisms described in this document could reuse the existing
+   BGP security mechanisms [RFC4271] [RFC4272].  The security model and
+   threats specific to Provider Provisioned VPNs, including L3VPNs, are
+   discussed in [RFC4111].  [MVPN] discusses additional threats specific
+   to the use of multicast in L3VPNs.  There is currently work in
+   progress to improve the security of TCP authentication.  When the
+   document is finalized as an RFC, the method defined in [RFC5925]
+   SHOULD be used where authentication of BGP control packets is needed.
+
+   A PE router MUST NOT accept, from CEs routes, with MCAST-VPN SAFI.
+
+   If BGP is used as a CE-PE routing protocol, then when a PE receives a
+   route from a CE, if this route carries the VRF Route Import Extended
+   Community, the PE MUST remove this Community from the route before
+   turning it into a VPN-IP route.  Routes that a PE advertises to a CE
+   MUST NOT carry the VRF Route Import Extended Community.
+
+   It is important to protect the control plane resources within the PE
+   to prevent any one VPN from hogging excessive resources.  This is the
+   subject of the remainder of the Security Considerations section.
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 55]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   When C-multicast routing information is exchanged among PEs using
+   BGP, an implementation SHOULD provide the ability to rate limit BGP
+   messages used for this exchange.  This SHOULD be provided on a per-
+   PE, per-MVPN granularity.
+
+   An implementation SHOULD provide capabilities to impose an upper
+   bound on the number of S-PMSI A-D routes, as well as on how
+   frequently they may be originated.  This SHOULD be provided on a per-
+   PE, per-MVPN granularity.
+
+   In conjunction with the procedures specified in Section 14, an
+   implementation SHOULD provide capabilities to impose an upper bound
+   on the number of Source Active A-D routes, as well as on how
+   frequently they may be originated.  This SHOULD be provided on a per-
+   PE, per-MVPN granularity.
+
+   In conjunction with the procedures specified in Section 13 limiting
+   the amount of (C-S,C-G) state would limit the amount of Source Active
+   A-D route, as in the context of this section, Source Active A-D
+   routes are created in response to Source Tree Join C-multicast
+   routes, and Source Tree Join C-multicast routes are created as a
+   result of creation of (C-S,C-G) state on PEs.  However, to provide an
+   extra level of robustness in the context of these procedures, an
+   implementation MAY provide capabilities to impose an upper bound on
+   the number of Source Active A-D routes, as well as on how frequently
+   they may be originated.  This MAY be provided on a per-PE, per-MVPN
+   granularity.
+
+   Section 16.1.1 describes optional procedures for dampening
+   withdrawals of C-multicast routes.  It is RECOMMENDED that an
+   implementation support such procedures.
+
+   Section 16.1.1 describes optional procedures for dampening
+   withdrawals of Leaf A-D routes.  It is RECOMMENDED that an
+   implementation support such procedures.
+
+18.  IANA Considerations
+
+   This document defines a new BGP Extended Community called "Source
+   AS".  This Community is of an extended type and is transitive.  The
+   Type value for this Community has been allocated from the two-octet
+   AS-Specific Extended Community registry as 0x0009 and from the four-
+   octet AS-Specific Extended Community registry as 0x0209.
+
+   This document defines a new BGP Extended Community called "VRF Route
+   Import" (Type value 0x010b).  This Community is IP address specific,
+   of an extended type, and is transitive.
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 56]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   This document defines a new NLRI, called "MCAST-VPN", to be carried
+   in BGP using multiprotocol extensions.  It has been assigned SAFI 5.
+   Also, SAFI 129 has been assigned to "Multicast for BGP/MPLS IP
+   Virtual Private Networks (VPNs)".
+
+   This document defines a new BGP optional transitive attribute, called
+   "PMSI_TUNNEL".  IANA has assigned the codepoint 22 in the "BGP Path
+   Attributes" registry to the PMSI_TUNNEL attribute.
+
+   This document defines a new BGP optional transitive attribute, called
+   "PE Distinguisher Labels".  IANA has assigned the codepoint 27 in the
+   "BGP Path Attributes" registry to the PE Distinguisher Labels
+   attribute.
+
+19.  Acknowledgements
+
+   We would like to thank Chaitanya Kodeboniya for helpful discussions.
+   We would also like to thank members of the L3VPN IETF Working Group
+   for insightful comments and review.
+
+20.  References
+
+20.1.  Normative References
+
+   [IANA-SAFI] IANA, "Subsequent Address Family Identifiers (SAFI)
+               Parameters", http://www.iana.org.
+
+   [MVPN]      Rosen, E., Ed. and R. Aggarwal, Ed., "Mulitcast in
+               MPLS/BGP IP VPNs", RFC 6513, February 2012.
+
+   [RFC1997]   Chandra, R., Traina, P., and T. Li, "BGP Communities
+               Attribute", RFC 1997, August 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4271]   Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+               Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
+               2006.
+
+   [RFC4360]   Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
+               Communities Attribute", RFC 4360, February 2006.
+
+   [RFC4364]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+               Networks (VPNs)", RFC 4364, February 2006.
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 57]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   [RFC4601]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+               Protocol Specification (Revised)", RFC 4601, August 2006.
+
+   [RFC4659]   De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
+               "BGP-MPLS IP Virtual Private Network (VPN) Extension for
+               IPv6 VPN", RFC 4659, September 2006.
+
+   [RFC4760]   Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
+               "Multiprotocol Extensions for BGP-4", RFC 4760, January
+               2007.
+
+20.2.  Informative References
+
+   [mLDP]      Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
+               Thomas, "Label Distribution Protocol Extensions for
+               Point-to-Multipoint and Multipoint-to-Multipoint Label
+               Switched Paths", RFC 6388, November 2011.
+
+   [MSDP]      Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
+               Discovery Protocol (MSDP)", RFC 3618, October 2003.
+
+   [PIM-ANYCAST-RP]
+               Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
+               Independent Multicast (PIM)", RFC 4610, August 2006.
+
+   [RFC5331]   Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
+               Label Assignment and Context-Specific Label Space", RFC
+               5331, August 2008.
+
+   [RT-CONSTRAIN]
+               Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
+               R., Patel, K., and J. Guichard, "Constrained Route
+               Distribution for Border Gateway Protocol/MultiProtocol
+               Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
+               Private Networks (VPNs)", RFC 4684, November 2006.
+
+   [RFC2439]   Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
+               Flap Damping", RFC 2439, November 1998.
+
+   [RFC4111]   Fang, L., Ed., "Security Framework for Provider-
+               Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
+               July 2005.
+
+   [RFC4272]   Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
+               4272, January 2006.
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 58]
+
+RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012
+
+
+   [RFC4607]   Holbrook, H. and B. Cain, "Source-Specific Multicast for
+               IP", RFC 4607, August 2006.
+
+   [RFC4875]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
+               Yasukawa, Ed., "Extensions to Resource Reservation
+               Protocol - Traffic Engineering (RSVP-TE) for Point-to-
+               Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
+               2007.
+
+   [RFC5015]   Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
+               "Bidirectional Protocol Independent Multicast (BIDIR-
+               PIM)", RFC 5015, October 2007.
+
+   [RFC5925]   Touch, J., Mankin, A., and R. Bonica, "The TCP
+               Authentication Option", RFC 5925, June 2010.
+
+Authors' Addresses
+
+   Rahul Aggarwal
+   Juniper Networks
+   1194 North Mathilda Ave.
+   Sunnyvale, CA 94089
+   EMail: raggarwa_1@yahoo.com
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA, 01719
+   EMail: erosen@cisco.com
+
+   Thomas Morin
+   France Telecom - Orange
+   2, avenue Pierre-Marzin
+   22307 Lannion Cedex
+   France
+   EMail: thomas.morin@orange.com
+
+   Yakov Rekhter
+   Juniper Networks
+   1194 North Mathilda Ave.
+   Sunnyvale, CA 94089
+   EMail: yakov@juniper.net
+
+
+
+
+
+
+
+
+
+Aggarwal, et al.             Standards Track                   [Page 59]
+