Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6514

BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs

Pages: 59
Proposed Standard
Errata
Updated by:  65156625738574417582789979007902798885349081
Part 1 of 3 – Pages 1 to 16
None   None   Next

Top   ToC   RFC6514 - Page 1
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.
Top   ToC   RFC6514 - Page 2

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
Top   ToC   RFC6514 - Page 3
   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
Top   ToC   RFC6514 - Page 4

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.
Top   ToC   RFC6514 - Page 5
   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.
Top   ToC   RFC6514 - Page 6
   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.
Top   ToC   RFC6514 - Page 7

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.
Top   ToC   RFC6514 - Page 8
   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.
Top   ToC   RFC6514 - Page 9

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.
Top   ToC   RFC6514 - Page 10

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:
Top   ToC   RFC6514 - Page 11
      +---------------------------------+
      |  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).
Top   ToC   RFC6514 - Page 12
   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].
Top   ToC   RFC6514 - Page 13
   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.
Top   ToC   RFC6514 - Page 14

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.
Top   ToC   RFC6514 - Page 15
   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.
Top   ToC   RFC6514 - Page 16
   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].



(page 16 continued on part 2)

Next Section