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.

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

   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

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.

   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.

   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.

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.

   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.

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.

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:

      +---------------------------------+
      |  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).

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

   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.

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.

   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.

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