GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7900

Internet Engineering Task Force (IETF) Y. Rekhter, Ed. Request for Comments: 7900 E. Rosen, Ed. Updates: 6513, 6514, 6625 Juniper Networks, Inc. Category: Standards Track R. Aggarwal ISSN: 2070-1721 Arktan

                                                                Y. Cai
                                                         Alibaba Group
                                                              T. Morin
                                                                Orange
                                                             June 2016
               Extranet Multicast in BGP/IP MPLS VPNs

Abstract

 Previous RFCs specify the procedures necessary to allow IP multicast
 traffic to travel from one site to another within a BGP/MPLS IP VPN
 (Virtual Private Network).  However, it is sometimes desirable to
 allow multicast traffic whose source is in one VPN to be received by
 systems that are in another VPN.  This is known as a "Multicast VPN
 (MVPN) extranet".  This document updates RFCs 6513, 6514, and 6625 by
 specifying the procedures that are necessary in order to provide
 extranet MVPN service.

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 7841.
 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/rfc7900.

Rekhter, et al. Standards Track [Page 1] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

Copyright Notice

 Copyright (c) 2016 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
    1.1. Terminology ................................................4
    1.2. Scope ......................................................7
         1.2.1. Customer Multicast Control Protocols ................7
         1.2.2. Provider Multicast Control Protocols ................7
    1.3. Clarification on Use of Route Distinguishers ...............8
    1.4. Overview ...................................................9
 2. Extranets and Overlapping Address Spaces .......................12
    2.1. Ambiguity: P-Tunnel with Extranet/Non-extranet Flows ......14
    2.2. Ambiguity: P-Tunnel with Multiple Extranet Flows ..........16
    2.3. Preventing Misdelivery in These Scenarios .................18
         2.3.1. Do Not Deliver Packets from the Wrong P-tunnel .....18
         2.3.2. Policies to Prevent Ambiguity on a P-Tunnel ........20
 3. Extranet Transmission Models ...................................21
    3.1. Transmitting an Extranet C-Flow on a Single PMSI ..........21
         3.1.1. Without Extranet Separation ........................22
         3.1.2. With Extranet Separation ...........................22
    3.2. Transmitting an Extranet C-Flow over Multiple PMSIs .......23
 4. Distribution of Routes That Match C-S/C-RP Addresses ...........23
    4.1. UMH-Eligible Routes .......................................23
         4.1.1. Extranet Separation ................................24
    4.2. Distribution of Unicast Routes Matching C-RPs and DRs .....25
    4.3. Route Targets and Ambiguous UMH-Eligible Routes ...........26
    4.4. Dynamically Marking Extranet Routes .......................27
         4.4.1. The Extranet Source Extended Community .............27
         4.4.2. Distribution of Extranet Source Extended
                Community ..........................................29
    4.5. The Extranet Separation Extended Community ................30

Rekhter, et al. Standards Track [Page 2] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 5. Origination and Distribution of BGP A-D Routes .................30
    5.1. Route Targets of UMH-Eligible Routes and A-D Routes .......30
    5.2. Considerations for Particular Inclusive Tunnel Types ......33
         5.2.1. RSVP-TE P2MP or Ingress Replication ................33
         5.2.2. Ingress Replication ................................34
 6. When PIM Is the PE-PE C-Multicast Control Plane ................35
    6.1. Provisioning VRFs with RTs ................................36
         6.1.1. Incoming and Outgoing Extranet RTs .................36
         6.1.2. UMH-Eligible Routes and RTs ........................37
         6.1.3. PIM C-Instance Reverse Path Forwarding
                Determination ......................................37
    6.2. "Single PMSI per C-Flow" Model ............................38
         6.2.1. Forming the MI-PMSIs ...............................38
         6.2.2. S-PMSIs ............................................41
         6.2.3. Sending PIM Control Packets ........................42
         6.2.4. Receiving PIM Control Packets ......................43
         6.2.5. Sending and Receiving Data Packets .................43
    6.3. "Multiple PMSIs per C-Flow" Model .........................43
         6.3.1. Forming the MI-PMSIs ...............................44
 7. When BGP Is the PE-PE C-Multicast Control Plane ................46
    7.1. Originating C-Multicast Routes ............................46
    7.2. Originating A-D Routes without Extranet Separation ........47
         7.2.1. Intra-AS I-PMSI A-D Routes .........................47
         7.2.2. S-PMSI A-D Routes ..................................47
         7.2.3. Source Active A-D Routes ...........................48
                7.2.3.1. When Inter-Site Shared Trees Are Used .....48
                7.2.3.2. When Inter-Site Shared Trees Are
                         Not Used ..................................49
    7.3. Originating A-D Routes with Extranet Separation ...........49
         7.3.1. Intra-AS I-PMSI A-D Routes .........................49
         7.3.2. S-PMSI A-D Routes ..................................50
         7.3.3. Source Active A-D Routes ...........................52
    7.4. Determining the Expected P-Tunnel for a C-Flow ............52
         7.4.1. (C-S,C-G) S-PMSI A-D Routes ........................54
         7.4.2. (C-S,C-*) S-PMSI A-D Routes ........................54
         7.4.3. (C-*,C-G) S-PMSI A-D Routes ........................55
         7.4.4. (C-*,C-*) S-PMSI A-D Routes ........................56
         7.4.5. I-PMSI A-D Routes ..................................56
    7.5. Packets Arriving from the Wrong P-Tunnel ..................57
 8. Multiple Extranet VRFs on the Same PE ..........................57
 9. IANA Considerations ............................................58
 10. Security Considerations .......................................59
 11. References ....................................................61
    11.1. Normative References .....................................61
    11.2. Informative References ...................................62
 Acknowledgments ...................................................64
 Contributors ......................................................64
 Authors' Addresses ................................................65

Rekhter, et al. Standards Track [Page 3] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

1. Introduction

 Previous RFCs [RFC6513] [RFC6514] specify the procedures necessary to
 allow IP multicast traffic to travel from one site to another within
 a BGP/MPLS IP VPN (Virtual Private Network).  However, it is
 sometimes desirable to allow multicast traffic whose source is in one
 VPN to be received by systems that are in another VPN.  This is known
 as an "extranet Multicast VPN (MVPN)".  This document specifies the
 procedures that are necessary in order to provide extranet MVPN
 functionality.
 This document updates RFCs 6513, 6514, and 6625 by specifying the
 procedures that are necessary in order to provide extranet MVPN
 service.

1.1. Terminology

 This document uses terminology from [RFC6513] and in particular uses
 the prefixes "C-" and "P-" as specified in Section 3.1 of [RFC6513],
 and "A-D routes" for "auto-discovery routes".
 The term "Upstream Multicast Hop" (UMH) is used as defined in
 [RFC6513].
 The term "UMH-eligible route" is used to mean "route eligible for UMH
 determination", as defined in Section 5.1.1 of [RFC6513].  We will
 say that a given UMH-eligible route or unicast route "matches" a
 given IP address, in the context of a given Virtual Routing and
 Forwarding table (VRF), if the address prefix of the given route is
 the longest match in that VRF for the given IP address.  We will
 sometimes say that a route "matches" a particular host if the route
 matches an IP address of the host.
 We follow the terminology of Section 3.2 of [RFC6625] when talking of
 a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route
 being "installed".  That is, we say that an S-PMSI A-D route is
 "installed" (in a given VRF) if it has been selected by the BGP
 decision process as the preferred route for its Network Layer
 Reachability Information (NLRI).  We also follow the terminology of
 Section 3.2 of [RFC6625] when saying that an S-PMSI A-D route has
 been "originated by a given PE"; this means that the given Provider
 Edge's (PE's) IP address is contained in the Originating Router's IP
 Address field in the NLRI of the route.

Rekhter, et al. Standards Track [Page 4] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 We use the following additional terminology and notation:
 o  Extranet C-source: a multicast source, in a given VPN, that is
    allowed by policy to send multicast traffic to receivers that are
    in other VPNs.
 o  Extranet C-receiver: a multicast receiver, in a given VPN, that is
    allowed by policy to receive multicast traffic from extranet
    C-sources that are in other VPNs.
 o  Extranet C-flow: a multicast flow (with a specified C-source
    address and C-group address) with the following properties: its
    source is an extranet C-source, and it is allowed by policy to
    have extranet C-receivers.
 o  Extranet C-group: a multicast group address that is in the
    "Any-Source Multicast" (ASM) group address range and that is
    allowed by policy to have extranet C-sources and extranet
    C-receivers that are not all in the same VPN.  Note that we will
    sometimes refer to "Source-Specific Multicast (SSM) C-group
    addresses" (i.e., C-group addresses in the SSM group address
    range) but will never call them "extranet C-groups".
    N.B.: Any source of traffic for an extranet C-group is considered
    to be an extranet C-source, and any receiver of traffic addressed
    to an extranet C-group is considered to be an extranet C-receiver.
 o  Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet
    C-group; it is allowed by policy to receive PIM Register messages
    [RFC7761] from outside its VPN and to send multicast data packets
    to extranet C-receivers outside its VPN.
 o  Host(C-S,A): the host (or, if C-S is an "anycast address", the set
    of hosts) denoted by the address C-S in the context of VPN-A.  For
    example, if a particular C-source in VPN-A has address C-S, then
    Host(C-S,A) refers to that C-source.
 o  "SAFI n" route: a BGP route whose Address Family Identifier (AFI)
    is either 1 (IPv4) or 2 (IPv6) and whose Subsequent Address Family
    Identifier (SAFI) is "n".
 o  PTA: PMSI Tunnel Attribute [RFC6514].

Rekhter, et al. Standards Track [Page 5] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Note that a given extranet C-source is not necessarily allowed to
 transmit to every extranet C-receiver; policy determines which
 extranet C-sources are allowed to transmit to which extranet
 C-receivers.  However, in the case of an extranet (ASM) C-group, all
 transmitters to the group are allowed to transmit to all the
 receivers of the group, and all the receivers of the group are
 allowed to receive from all transmitters to the group.
 We say that a given VRF "contains" or "has" a multicast C-source (or
 that the C-source is "in" the VRF) if that C-source is in a site
 connected to that VRF and the VRF originates a UMH-eligible route
 (see Section 4) that matches the address of the C-source.
 We say that a given VRF "contains" or "has" a multicast C-receiver
 (or that the C-receiver is "in" the VRF) if that C-receiver is in a
 site connected to that VRF.
 We say that a given VRF "contains" or "has" the C-RP for a given ASM
 group (or that the C-RP is "in" the VRF) if that C-RP is in a site
 connected to that VRF and the VRF originates a unicast route and a
 (possibly different, possibly the same) UMH-eligible route (see
 Section 4) whose respective address prefixes match the C-RP address.
 [RFC6513] allows a set of "P-tunnels" (defined in Section 3.2 of
 [RFC6513]) to be aggregated together and transported via an outer
 P-tunnel; i.e., it allows for the use of hierarchical Label Switched
 Paths (LSPs) as P-tunnels.  A two-level hierarchical LSP, for
 example, can be thought of as a set of "inner tunnels" aggregated
 into an outer tunnel.  In this document, when we speak of a P-tunnel,
 we are always speaking of the innermost P-tunnel, i.e., of a P-tunnel
 at the lowest hierarchical level.  P-tunnels are identified in the
 PMSI Tunnel attributes ("PTAs" in this document) [RFC6514] of BGP
 auto-discovery (A-D) routes.  Two PTAs that have the same Tunnel Type
 and Tunnel Identifier fields but different MPLS label fields are thus
 considered to identify two different P-tunnels.  (That is, for the
 purposes of this document, the MPLS label included in the PTA, if
 any, is considered to be part of the tunnel identifier.)
 We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D
 route contains (C-S,C-G) if its Multicast Source field contains C-S
 and its Multicast Group field contains C-G.  If either or both of
 these fields are encoded as a wildcard, we will say that the NLRI
 contains (C-*,C-*) (both fields encoded as wildcards), (C-*,C-G)
 (Multicast Source field encoded as a wildcard), or (C-S,C-*)
 (Multicast Group field encoded as a wildcard).

Rekhter, et al. Standards Track [Page 6] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 We use the term "VPN security violation" to refer to any situation in
 which a packet is delivered to a particular VPN, even though, by
 policy, it should not be delivered to that VPN.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 [RFC2119].

1.2. Scope

1.2.1. Customer Multicast Control Protocols

 This document presumes that the VPN customer is using PIM - Sparse
 Mode (PIM-SM) [RFC7761] as the multicast control protocol at the
 customer sites.  PIM-SM may be used in either the ASM service model
 or the SSM service model; this document covers both cases.  Support
 for other customer IP multicast control protocols (e.g., [RFC5015],
 PIM - Dense Mode) is outside the scope of this document.  Support for
 the use of MPLS multicast control protocols (e.g., [RFC6388]
 [RFC4875]) by customer sites is also outside the scope of this
 document.
 When a VPN customer uses ASM, the customer routers need to be able to
 map from a C-group address to a C-RP address.  These mappings can be
 provisioned in each router, or they can be discovered dynamically
 through protocols such as the Bootstrap Router (BSR) mechanism
 [RFC5059].  However, it cannot be assumed that such protocols will
 automatically work in the context of an extranet.  Discussion of the
 use of such protocols in an extranet is outside the scope of this
 document.

1.2.2. Provider Multicast Control Protocols

 [RFC6513] allows either PIM or BGP to be used as the protocol for
 distributing customer multicast routing information.  Except where
 otherwise specified, such as in Sections 6 and 7, the procedures of
 this document cover both cases.

Rekhter, et al. Standards Track [Page 7] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

1.3. Clarification on Use of Route Distinguishers

 [RFC4364] requires that every VRF be associated with one or more
 Route Distinguishers (RDs).  Each VPN-IPv4 or VPN-IPv6 route that is
 exported from a particular VRF contains, in its NLRI, an RD that is
 associated with that VRF.
 [RFC4364] allows a given RD to be associated with more than one VRF,
 as long as all the VRFs associated with that RD belong to the same
 VPN.  However, in the most common deployment model, each RD is
 associated with one and only one VRF.  [RFC6513] and [RFC6514]
 presuppose this deployment model.  That is, [RFC6513] and [RFC6514]
 presuppose that every RD is associated with one and only one VRF.  We
 will call this the "unique VRF per RD" condition.
 [RFC6514] defines the MCAST-VPN address family, which has a number of
 route types.  Each Intra-Autonomous System (Intra-AS) "Inclusive
 Provider Multicast Service Interface" (I-PMSI) A-D route, S-PMSI A-D
 route, and Source Active A-D route, when exported from a given VRF,
 contains, in its NLRI, an RD that is associated with the VRF.
 [RFC6513] and [RFC6514] also discuss a class of routes known as
 "UMH-eligible" routes; when a UMH-eligible route is exported from a
 given VRF, its NLRI contains an RD of the VRF.
 [RFC6514] also defines MCAST-VPN routes whose NLRIs do not contain an
 RD of the VRF from which they are exported: the C-multicast Join
 routes and the Leaf A-D routes.
 Those route types that, when exported from a given VRF, contain (in
 their NLRIs) an RD of the VRF, will be known in this document as
 "local-RD routes".
 Given the "unique VRF per RD" condition, if one sees that two
 local-RD routes have the same RD, one can infer that the two routes
 originated from the same VRF.  This inference can be drawn even if
 the two routes do not have the same SAFI, as long as the two routes
 are both local-RD routes.
 This document builds upon [RFC6513] and [RFC6514]; therefore, the
 "unique VRF per RD" condition is REQUIRED.
 [RFC6514] presupposes a further requirement on the use of RDs in the
 local-RD routes exported from a given VRF.  Suppose that a given VRF
 exports a Source Active A-D route containing (C-S,C-G).  That VRF
 will also export a UMH-eligible route matching C-S.  [RFC6514]
 presupposes that the UMH-eligible route and the Source Active A-D
 route have the same RD.

Rekhter, et al. Standards Track [Page 8] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 In most cases, not only is a given RD associated with only a single
 VRF, but a given VRF is associated with only a single RD.  We will
 call this the "unique RD per VRF" condition.  When this condition
 holds, all the local-RD routes exported from a given VRF will have
 the same RD.  This ensures that the presupposition of the previous
 paragraph will hold, i.e., that the RD in a Source Active A-D route
 exported from a given VRF will have the same RD as the corresponding
 UMH-eligible route exported from the same VRF.
 Section 7.3 of this document describes a procedure known as "extranet
 separation".  When extranet separation is NOT being used, it is
 REQUIRED by this document that the "unique RD per VRF" condition
 hold.  This ensures that all the local-RD routes exported from a
 given VRF will have the same RD.
 When extranet separation is used, a VRF that contains both extranet
 sources and non-extranet sources MUST be configured with two RDs.
 One of these RDs is known as the "default RD", and the other is known
 as the "extranet RD".  It MUST be known by configuration which RD is
 the default RD and which is the extranet RD.
 When a VRF is configured with only one RD, we will refer to that RD
 as the "default RD".
 In general, local-RD routes exported from a given VRF will contain
 the default RD.  However, when extranet separation is used, some of
 the local-RD routes exported from the VRF will contain the
 extranet RD.  Details concerning the exported routes that contain
 the extranet RD can be found in Sections 4.1 and 7.3.
 Note that the "unique VRF per RD" condition applies to the
 extranet RD as well as the default RD.  That is, a given extranet RD
 is associated with a unique VRF.

1.4. Overview

 Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN
 functionality as specified in [RFC6513] and/or [RFC6514].  In the
 simplest configuration, VPN-S is a collection of VRFs, each of which
 is configured with a particular Route Target (RT) value (call it
 "RT-S") as its import RT and as its export RT.  Similarly, VPN-R is a
 collection of VRFs, each of which is configured with a particular RT
 value (call it "RT-R") as its import RT and as its export RT.

Rekhter, et al. Standards Track [Page 9] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 In this configuration, multicast C-receivers contained in a VPN-R VRF
 cannot receive multicast data traffic from multicast C-sources
 contained in a VPN-S VRF.  If it is desired to allow this, one needs
 to create an MVPN "extranet".  Creating an extranet requires
 procedures in addition to those specified in [RFC6513], [RFC6514],
 and [RFC6625]; this document specifies these additional procedures.
 In the example above, the additional procedures will allow a selected
 set of routes exported from the VPN-S VRFs (i.e., from the VRFs
 containing extranet C-sources) to be imported into the VPN-R VRFs
 (i.e., into the VRFs containing extranet C-receivers).  These routes
 include the routes that are to be eligible for use as UMH routes (see
 Section 5.1 of [RFC6513]) in the extranet, as well as a selected set
 of BGP A-D routes (Intra-AS I-PMSI A-D routes, S-PMSI A-D routes, and
 Source Active A-D routes).  Importing these routes into the VPN-R
 VRFs makes it possible to determine, in the context of a VPN-R VRF,
 that a particular C-multicast Join needs to be delivered to a
 particular VPN-S VRF.  It also makes it possible to determine, in the
 context of a VPN-R VRF, the P-tunnel through which the aforementioned
 VPN-S VRF sends a particular C-flow.
 Depending on the type of P-tunnel used, it may also be necessary for
 Leaf A-D routes to be exported by one or more VPN-R VRFs and imported
 into a VPN-S VRF.
 There are no extranet-specific procedures governing the use and
 distribution of BGP C-multicast routes.
 If PIM is used as the PE-PE protocol for distributing C-multicast
 routing information, additional BGP A-D routes must be exported from
 the VPN-R VRFs and imported into the VPN-S VRFs, so that the VPN-S
 VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM
 control messages.  Details can be found in Section 6.
 The simple example above describes an extranet created from two
 MVPNs, one of which contains extranet C-sources and one of which
 contains extranet C-receivers.  However, the procedures described in
 this document allow for much more complicated scenarios.
 For instance, an extranet may contain extranet C-sources and/or
 extranet C-receivers from an arbitrary number of VPNs, not just from
 two VPNs.  An extranet C-receiver in VPN-R may be allowed to receive
 multicast traffic from extranet C-sources in VPN-A, VPN-B, and VPN-C.
 Similarly, extranet C-sources in VPN-S may be allowed to send
 multicast traffic to multicast C-receivers that are in VPN-A, VPN-B,
 VPN-C, etc.

Rekhter, et al. Standards Track [Page 10] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 A given VPN customer may desire that only some of its multicast
 C-sources be treated as extranet C-sources.  This can be accomplished
 by appropriate provisioning of the import and export RTs of that
 customer's VRFs (as well as the VRFs of other VPNs that contain
 extranet C-receivers for extranet C-flows of the given customer).
 A given VPN customer may desire that some of its extranet C-sources
 can transmit only to a certain set of VPNs while other of its
 extranet C-sources can transmit only to a different set of VPNs.
 This can be accomplished by provisioning the VRFs to export different
 routes with different RTs.
 In all these cases, the VPN customers set the policies, and the
 Service Provider (SP) implements the policies by the way it
 provisions the import and export RTs of the VRFs.  It is assumed that
 the customer communicates to the SP the set of extranet C-source
 addresses and the set of VPNs to which each C-source can transmit.
 (Recall that every C-source that can transmit to an extranet C-group
 is an extranet C-source and must be able to transmit to any VPN that
 has receivers for that group.  This must be taken into account when
 the provisioning is done.)  This customer/SP communication is part of
 the service provisioning process and is outside the scope of this
 document.
 It is possible that an extranet C-source will transmit both extranet
 C-flows and non-extranet C-flows.  However, if extranet C-receiver
 C-R can receive extranet C-flows from extranet C-source C-S, the
 procedures of this document do not prevent C-R from requesting and
 receiving the non-extranet flows that are transmitted by C-S.
 Therefore, allowing an extranet C-source to transmit non-extranet
 C-flows is NOT RECOMMENDED.  However, the SP has no control over the
 set of C-flows transmitted by a given C-source and can do no more
 than communicate this recommendation to its customers.
 (Alternatively, the customer and SP may coordinate on setting up
 filters to prevent unauthorized flows from being sent to a customer
 site; such a procedure is outside the scope of this document.)  See
 Section 10 ("Security Considerations") for additional discussion of
 this issue.
 Whenever a VPN is provisioned, there is a risk that errors in
 provisioning may result in an unintended cross-connection of VPNs.
 This would create a security problem for the customers.  When
 provisioning an extranet, attention to detail is particularly
 important, as an extranet intentionally cross-connects VPNs.  Care
 must always be taken to ensure that the cross-connections are
 according to the policy agreed upon by the SP and its customers.

Rekhter, et al. Standards Track [Page 11] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Additionally, if one is connecting two VPNs that have overlapping
 address spaces, one has to be sure that the inter-VPN traffic neither
 originates from nor is destined to the part of the address space that
 is in the overlap.  Other problems that can arise due to overlapping
 address spaces are discussed in Section 2.

2. Extranets and Overlapping Address Spaces

 As specified in [RFC4364], the address space of one VPN may overlap
 with the address space of another.  A given address may be
 "ambiguous" in that it denotes one system within VPN-A and a
 different system within VPN-B.  In the notation of Section 1.1,
 if an address C-S is ambiguous between VPN-A and VPN-B, then
 Host(C-S,A) != Host(C-S,B).  However, any given address C-S MUST be
 unambiguous (i.e., MUST denote a single system) in the context of a
 given VPN.
 When a set of VRFs belonging to different VPNs are combined into an
 extranet, it is no longer sufficient for an address to be unambiguous
 only within the context of a single VPN:
 1.  Suppose that C-S is the address of a given extranet C-source
     contained in VPN-A.  Now consider the set of VPNs
     {VPN-B, VPN-C, ...} containing extranet C-receivers that are
     allowed by policy to receive extranet C-flows from VPN-A's C-S.
     The address C-S MUST be unambiguous among this entire set of VPNs
     {VPN-A, VPN-B, VPN-C, ...}; i.e., Host(C-S,A) == Host(C-S,B) ==
     Host(C-S,C).
     The implication is that C-S in VPN-A is not necessarily an
     extranet C-source for all VPNs that contain extranet C-receivers;
     policy MUST be used to ensure that C-S is an extranet C-source
     for a given VPN, say VPN-B, only if C-S is unambiguous between
     VPN-A and VPN-B.
 2.  If a given VRF contains extranet C-receivers for a given extranet
     C-source, then the address of this C-source MUST be unambiguous
     among all the extranet C-sources for which there are C-receivers
     in the VRF.  This is true whether or not C-sources are in VRFs
     that belong to the same VPN or different VPNs.
     The implication is that if C-S in VRF-X is ambiguous with C-S in
     VRF-Y, then there MUST NOT be any VRF, say VRF-Z, containing
     C-receivers that are allowed by policy to receive extranet
     C-flows from both C-S in VRF-X and C-S in VRF-Y.

Rekhter, et al. Standards Track [Page 12] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Note: A VPN customer may be using anycast addresses.  An anycast
 address is intentionally ambiguous, as it denotes a set of systems
 rather than a single system.  In this document, we will consider an
 anycast address to be unambiguous in a given context as long as it
 denotes the same set of systems whenever it occurs in that context.
 A multicast C-group address, say C-G, may also be ambiguous in that
 it may be used for one multicast group in VPN-A and for an entirely
 different multicast group in VPN-B.  If a set of MVPNs are combined
 into an extranet and C-G is an extranet C-group, it is necessary to
 ensure that C-G is unambiguous among the entire set of VPNs whose
 VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers
 for that C-group.  This may require, as part of the provisioning
 process, customer/SP communication that is outside the scope of this
 document.
 Subject to these restrictions, the SP has complete control over the
 distribution of routes in an MVPN.  This control is exerted by
 provisioning either (1) the export RTs on the VRFs that originate the
 routes (i.e., the VRFs that contain the extranet C-sources) or
 (2) the import RTs on the VRFs that receive the routes (i.e., the
 VRFs that contain the extranet C-receivers), or both.
 Some of the rules and restrictions on provisioning the RTs are
 applicable to all extranets; these are specified in Section 4.
 Sections 6 and 7 list additional rules and restrictions that are
 applicable only to particular extranet scenarios.
 Even if all the RTs are provisioned according to the above rules and
 restrictions, it is still possible for a single P-tunnel to contain
 multicast data packets whose source and/or group addresses are
 ambiguous in the context of the set of PEs that receive data from the
 P-tunnel.  That is, the above rules and restrictions are necessary,
 but not sufficient, to prevent address ambiguity from causing
 misdelivery of traffic.  To prevent such misdelivery, additional
 procedures or policies must be used.
 Sections 2.1 and 2.2 describe scenarios in which a given P-tunnel may
 carry data packets with ambiguous addresses.  The additional
 procedures and policies needed to prevent misdelivery of data in
 those scenarios are outlined in Section 2.3.  (The detailed
 procedures described in Sections 6 and 7 incorporate the
 considerations discussed in Section 2.3.)

Rekhter, et al. Standards Track [Page 13] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

2.1. Ambiguity: P-Tunnel with Extranet/Non-extranet Flows

 In the following, we will use the notation "VRF A-n" to mean "VRF n
 of VPN-A".
 If VPN-A and VPN-B have overlapping address spaces and are part of
 the same extranet, then the following problem may exist, as
 illustrated in Figure 1.
 C-S2(A)  C-S1                                      Join(C-S2(A),G)
   \      /                                              /
    \    /                                              /
  +-------+---+   P1: (C-S1,G), (C-S2(A),G)     +---+--------+
  |VRF A-1|   |---------------------------------|   |VRF A-2 |
  +-------+PE1|                                 |PE2+--------+
  |VRF B-1|   |---------------------------------|   |VRF B-2 |
  +-------+---+   P2: (C-S2(B),G)               +---+--------+
      /                                               /    \
     /                                               /      \
   C-S2(B)                             Join(C-S2(B),G)   Join(C-S1,G)
    Figure 1: Ambiguity of Extranet and Non-extranet Source Address
 Suppose that:
 o  C-G is an SSM C-group used in VPN-A and VPN-B.
 o  VRF A-1, on PE1, contains an extranet C-source, with IP address
    C-S1, that is allowed to have receivers in VPN-B.  VRF A-1 thus
    exports to VPN-B a UMH-eligible route matching C-S1.
 o  In addition, VRF A-1 contains a non-extranet C-source with IP
    address C-S2.  VRF A-1 exports a UMH-eligible route matching C-S2
    to other VPN-A VRFs but NOT to VPN-B.
 o  VRF B-1, also on PE1, contains a non-extranet C-source with IP
    address C-S2.  A UMH-eligible route matching C-S2 is thus exported
    from VRF B-1 to other VRFs in VPN-B.
 o  Host(C-S2,A) != Host(C-S2,B).  That is, C-S2 is an ambiguous
    address in any extranet that contains both VPN-A VRFs and VPN-B
    VRFs.
 o  VRF B-2, on some other PE, say PE2, requests the multicast flow
    (C-S1,C-G).  In the context of VRF B-2, C-S1 matches the route
    exported from VRF A-1.  Thus, B-2's request to receive the
    (C-S1,C-G) flow is transmitted to VRF A-1.

Rekhter, et al. Standards Track [Page 14] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 o  VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by
    transmitting that traffic on P-tunnel P1.
 o  VRF B-2 joins P-tunnel P1 in order to receive the (C-S1,C-G)
    traffic.
 o  VRF A-2, on PE2, requests the (non-extranet) multicast flow
    (C-S2,C-G).  In the context of VRF A-2, C-S2 matches the route
    exported from VRF A-1.  Thus, A-2's request to receive the
    (C-S2,C-G) traffic is transmitted to VRF A-1.
 o  VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by
    transmitting that traffic on P-tunnel P1.
 o  VRF A-2 joins P-tunnel P1 in order to receive the (C-S2,C-G)
    traffic.
 o  VRF B-2 requests the (non-extranet) multicast flow (C-S2,C-G).  In
    the context of VRF B-2, C-S2 matches the route exported from VRF
    B-1.  Thus, B-2's request to receive the (C-S2,C-G) flow is
    transmitted to VRF B-1.
 o  VRF B-1 responds to VRF B-2's request for (C-S2,C-G) traffic by
    transmitting that traffic on P-tunnel P2.
 o  VRF B-2 joins P-tunnel P2.
 Since VRF B-2 has joined P-tunnel P1 and P-tunnel P2, it will receive
 (C-S2,C-G) traffic on both P-tunnels.  The (C-S2,C-G) traffic that
 VRF B-2 needs to receive is traveling on P-tunnel P2; this (C-S2,C-G)
 traffic must be forwarded by B-2 to any attached customer sites that
 have C-receivers for it.  But B-2 MUST discard the (C-S2,C-G) traffic
 that it receives on P1, as this is not the traffic that it has
 requested.  If the (C-S2,C-G) traffic arriving on P1 were forwarded
 to B-2's customer sites, the C-receivers would not be able to
 distinguish the two flows, and the result would be a corrupted data
 stream.
 Note that the procedures of Section 9.1.1 of [RFC6513] ("Discarding
 Packets from Wrong PE") will not cause VRF B-2 to discard the
 (C-S2,C-G) traffic that arrives on tunnel P1, because P1 and P2 have
 the same upstream PE.
 Therefore, it is necessary to EITHER (1) prevent the above scenario
 from occurring OR (2) ensure that multicast data packets will be
 discarded if they arrive on the wrong P-tunnel (even if they arrive
 from the expected PE).  See Section 2.3 for further discussion of
 this issue.

Rekhter, et al. Standards Track [Page 15] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

2.2. Ambiguity: P-Tunnel with Multiple Extranet Flows

 Figure 2 illustrates another example of how overlapping address
 spaces may cause a problem.

C-S2(A2D) C-S1(A2C) Join(C-S2(A2D),G)

   \      /                                              /
    \    /                                              /
  +-------+---+ P1: (C-S1(A2C),G), (C-S2(A2D),G)+---+--------+
  |VRF A-1|   |---------------------------------|   |VRF D-1 |
  +-------+PE1|                                 |PE2+--------+
  |VRF B-1|   |---------------------------------|   |VRF C-1 |
  +-------+---+ P2: (C-S2(B2C),G)               +---+--------+
      /                                              /  \
     /                                              /    \
   C-S2(B2C)                                       /      \
                                                 Join     Join
                                          (C-S2(B2C),G)  (C-S1(A2C),G)
           Figure 2: Ambiguity of Extranet Source Addresses
 Suppose that:
 o  C-G is an SSM C-group address that is used in VPN-A, VPN-B, VPN-C,
    and VPN-D.
 o  VRF A-1, on PE1, contains an extranet C-source, with IP address
    C-S1, that is allowed by policy to have C-receivers in VPN-C (but
    not in VPN-D).  VRF A-1 thus exports a UMH-eligible route matching
    C-S1 to VPN-C.
 o  In addition, VRF A-1 contains an extranet C-source, with IP
    address C-S2, that is allowed by policy to have C-receivers in
    VPN-D (but not in VPN-C).  VRF A-1 thus exports a UMH-eligible
    route matching C-S2 to VPN-D.
 o  VRF B-1, also on PE1, contains an extranet C-source, with IP
    address C-S2, that is allowed by policy to have C-receivers in
    VPN-C (but not in VPN-D).  VRF B-1 thus exports a UMH-eligible
    route matching C-S2 to VPN-C.
 o  Host(C-S2,A) != Host(C-S2,B).  That is, C-S2 is an ambiguous
    address in any extranet that contains both VPN-A VRFs and
    VPN-B VRFs.

Rekhter, et al. Standards Track [Page 16] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 o  VRF C-1, on some other PE, say PE2, requests the extranet
    multicast flow (C-S1,C-G).  In the context of VRF C-1, C-S1
    matches the route exported from VRF A-1.  Thus, C-1's request to
    receive the (C-S1,C-G) flow is transmitted to VRF A-1.
 o  VRF A-1 responds to VRF C-1's request for (C-S1,C-G) traffic by
    transmitting that traffic on P-tunnel P1.
 o  VRF C-1 joins P-tunnel P1 in order to receive the (C-S1,C-G)
    traffic.
 o  VRF C-1 requests the extranet multicast flow (C-S2,C-G).  In the
    context of VRF C-1, C-S2 matches the route exported from VRF B-1.
    Thus, C-1's request to receive the (C-S2,C-G) flow is transmitted
    to VRF B-1.
 o  VRF B-1 responds by transmitting its (C-S2,C-G) traffic on
    P-tunnel P2.
 o  VRF C-1 joins P-tunnel P2 in order to receive the (C-S2,C-G)
    traffic.
 o  VRF D-1, on PE2, requests the extranet multicast flow (C-S2,C-G).
    In the context of VRF D-1, C-S2 matches the route exported from
    VRF A-1.  Thus, D-1's request to receive the (C-S2,C-G) flow is
    transmitted to VRF A-1.
 o  VRF A-1 responds by transmitting its (C-S2,C-G) traffic on
    P-tunnel P1.
 o  VRF D-1 joins P-tunnel P1 in order to receive the (C-S2,C-G)
    traffic.
 In this example, VRF A-1 has chosen to use the same P-tunnel, P1, to
 carry both its (C-S2,C-G) traffic and the (C-S1,C-G) traffic.  VRF
 C-1 has joined tunnel P1 in order to receive the (C-S1,C-G) traffic
 from VRF A-1, which means that VRF C-1 will also receive the unwanted
 (C-S2,C-G) traffic from P1.  VRF C-1 is also expecting (C-S2,C-G)
 traffic from VRF B-1; this traffic will be received from P2.  Thus,
 VRF C-1 is receiving (C-S2,C-G) traffic on both tunnels, and both
 C-flows arrive from the expected PE, PE1.
 Therefore, it is necessary to EITHER (1) prevent the above scenario
 from occurring OR (2) ensure that VRF C-1 discards any (C-S,C-G)
 traffic that arrives from the wrong P-tunnel.  See Section 2.3 for
 further discussion of this issue.

Rekhter, et al. Standards Track [Page 17] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Note that the ambiguity described in this section (Section 2.2) would
 not occur if C-G were an (ASM) extranet C-group.  In that case, the
 scenario would violate the rule, given previously in Section 2,
 requiring that all sources sending to a particular ASM extranet
 C-group must have addresses that are unambiguous over all the MVPNs
 receiving traffic for that C-group.

2.3. Preventing Misdelivery in These Scenarios

 There are two ways to prevent the scenarios discussed in Sections 2.1
 and 2.2 from resulting in misdelivery of data; these techniques are
 discussed in Sections 2.3.1 and 2.3.2, respectively.

2.3.1. Do Not Deliver Packets from the Wrong P-tunnel

 Consider a particular C-flow that has receivers in a particular VRF.
 Sections 6 and 7 describe a set of procedures that enable an egress
 PE to determine the "expected P-tunnel" for that C-flow in the
 context of that VRF.  If a PE receives packets of the C-flow (as
 determined by the IP source and/or destination address of the
 packet), it checks to see if the packet was received on the expected
 P-tunnel for that VRF.  If so, the packet is delivered to the VRF
 (and thus to the C-flow's receivers in that VRF).  If not, the packet
 is not delivered to the VRF.
 Note that at a given egress PE, the wrong P-tunnel for one VRF may be
 the correct P-tunnel for another.
 These procedures, if applied at every PE that joins a given P-tunnel,
 are sufficient to prevent misdelivery of traffic in the scenarios
 discussed in Sections 2.1 and 2.2.
 IF these procedures cannot be applied by every PE that is attached to
 a given extranet, then the policies of Section 2.3.2 MUST be applied
 at every VRF containing C-sources for that extranet.
 In some cases, however, it may be safe to deliver packets that arrive
 from other than the expected P-tunnel.  Suppose that it is known that
 every packet gets transmitted on only a single P-tunnel.  (This will
 be the case if the "single PMSI per C-flow" transmission model,
 discussed in Section 3.1, is being used.)  Suppose also that it is
 known that T1 and T2 carry only packets that arrived at the same
 ingress PE, over one or more VRF interfaces that are associated with
 the same VRF (i.e., that there is a particular VRF that is the
 ingress VRF for ALL the packets carried by T1 or T2).  In this case,
 if T1 is the expected P-tunnel for a given (C-S,C-G), it is NOT
 necessary to discard (S,G) packets that arrive over T2.

Rekhter, et al. Standards Track [Page 18] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 It is not always possible to determine whether two P-tunnels are
 carrying packets from the same ingress VRF.  However, in some cases,
 this can be determined by examination of the A-D routes in which the
 tunnels have been advertised.
 Consider the following example:
 o  Tunnel T1 is a Point-to-Multipoint (P2MP) multipoint Label
    Distribution Protocol (mLDP) or RSVP-TE P-tunnel advertised in an
    Intra-AS I-PMSI A-D route (call it "R1").
 o  Tunnel T2 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an
    S-PMSI A-D route (call it "R2").
 o  The respective NLRIs of R1 and R2 contain the same RD value.
 o  The MPLS Label field of R1's PTA is zero, and the MPLS label value
    of R2's PTA is zero.
 In this example, it can be concluded that T1 and T2 are carrying
 packets from the same ingress VRF.  Thus, if T1 is the expected
 P-tunnel for a (C-S,C-G) flow, (S,G) packets from T2 can be safely
 delivered to the egress VRF; they do not need to be discarded.
 Similarly, if T2 is the expected P-tunnel for a (C-S,C-G) flow, (S,G)
 packets from T1 can be safely delivered to the egress VRF.
 Another example is the following:
 o  Tunnel T3 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a
    (C-*,C-*) S-PMSI A-D route (call it "R3").
 o  Tunnel T4 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a
    (C-S,C-G) S-PMSI A-D route (call it "R4").
 o  The respective NLRIs of R3 and R4 contain the same RD value.
 o  The MPLS Label field of R3's PTA is zero, and the MPLS label value
    of R4's PTA is zero.
 In this example, it can be concluded that T3 and T4 are carrying
 packets from the same ingress VRF.  Thus, if T3 is the expected
 P-tunnel for a (C-S,C-G) flow, (S,G) packets from T4 can be safely
 delivered to the egress VRF; they do not need to be discarded.
 Similarly, if T4 is the expected P-tunnel for a (C-S,C-G) flow,
 (S,G) packets from T3 can be safely delivered to the egress VRF.

Rekhter, et al. Standards Track [Page 19] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 When Ingress Replication (IR) P-tunnels are being used, please see
 [MVPN-IR], especially Section 7 ("The PTA's 'MPLS Label' Field") for
 a discussion of how to determine when packets from other than the
 expected P-tunnel must be discarded.

2.3.2. Policies to Prevent Ambiguity on a P-Tunnel

 For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI
 contains (C-S,C-G) or (C-S,C-*), the ambiguities described in
 Sections 2.1 and 2.2 can be prevented by provisioning a policy that
 assigns, to such P-tunnels, only flows from the same C-source.
 However, it is not always possible to determine, through inspection
 of the control messages, whether this policy has been deployed.  For
 instance, suppose that (1) a given VRF has imported a set of S-PMSI
 A-D routes, (2) each route in the set has bound only a single
 (C-S1,C-G1) to a single P-tunnel, and (3) each route in the set
 identifies a different P-tunnel in its PTA than the P-tunnel
 identified by the PTA of any other route in the set.  One cannot
 infer from this that there is no ambiguity, as the same P-tunnel may
 also have been advertised in an S-PMSI A-D route that is not imported
 by the given VRF, and that S-PMSI A-D route may have bound
 (C-S2,C-G2) to the P-tunnel, where C-S1 != C-S2.
 Therefore, in order to determine that a given P-tunnel (advertised in
 a (C-S,C-G) or (C-S,C-*) S-PMSI A-D route) carries only C-flows from
 a single C-source, a PE must have a priori knowledge (through
 provisioning) that this policy has been deployed.  In the remainder
 of this document, we will refer to this policy as the "single
 C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy.  Note that this
 policy is only applicable to P-tunnels that are advertised only in
 (C-S,C-G) or (C-S,C-*) S-PMSI A-D routes.
 Of course, if a P-tunnel is advertised in (a) an I-PMSI A-D route,
 (b) an S-PMSI A-D route whose NLRI contains (C-*,C-*), or (c) an
 S-PMSI A-D route whose NLRI contains (C-*,C-G), then it is always
 possible for the P-tunnel to contain traffic from multiple C-sources;
 there is no policy that can prevent that.
 However, if a P-tunnel advertised in a (C-*,C-G) S-PMSI A-D route
 contains only traffic addressed to a single C-G, the address
 uniqueness rules of Section 2 prevent the C-source addresses from
 being ambiguous; the set of C-sources transmitting to a particular
 extranet C-group address must be unambiguous over the set of MVPNs
 that have receivers for that C-group.  So, for P-tunnels that are
 advertised in (C-*,C-G) S-PMSI A-D routes, the ambiguities described
 in Sections 2.1 and 2.2 can be prevented by provisioning a policy

Rekhter, et al. Standards Track [Page 20] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 that assigns to such P-tunnels only flows to the same extranet
 C-group.  We will refer to this policy as the "single C-group per
 (C-*,C-G) P-tunnel" policy.
 These considerations can be summarized as follows.  IF the procedures
 referenced in Section 2.3.1 cannot be applied, then the PEs MUST be
 provisioned so that all of the following conditions hold true for the
 VRFs that contain extranet C-sources:
 o  the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy
    is provisioned,
 o  either no (C-*,C-G) S-PMSI A-D routes are advertised or the
    "single C-group per (C-*,C-G) P-tunnel" policy is provisioned,
 o  no P-tunnels are advertised in I-PMSI A-D routes, and
 o  no (C-*,C-*) S-PMSI A-D routes are advertised.
 Section 3 of this document describes a procedure known as "extranet
 separation".  When extranet separation is used, the ambiguity
 described in Section 2.1 is prevented.  However, the ambiguity
 described in Section 2.2 is not prevented by extranet separation.
 Therefore, the use of extranet separation is not a sufficient
 condition for avoiding the use of the procedures discussed in
 Section 2.3.1.  Extranet separation is, however, implied by the
 policies discussed in this section (Section 2.3.2).

3. Extranet Transmission Models

 This document specifies several "extranet transmission" models.  A
 given VRF containing extranet C-sources or C-receivers MUST use only
 one of these models.  Further, if VRF-S contains extranet C-sources,
 VRF-R contains extranet C-receivers, and it is allowed by policy for
 an extranet C-receiver in VRF-R to receive a C-flow from an extranet
 C-source in VRF-S, then VRF-S and VRF-R MUST use the same extranet
 transmission model.  The model used by a given VRF is determined by
 provisioning.

3.1. Transmitting an Extranet C-Flow on a Single PMSI

 In one extranet transmission model, which we call the "transmitting
 an extranet C-flow on a single PMSI" model or, more simply, the
 "single PMSI per C-flow" model, a PE transmitting a packet of an
 extranet C-flow transmits it on only a single PMSI.  If the PMSI is
 instantiated by a multicast P-tunnel, this means that the PE
 transmits the packet on a single P-tunnel.  Of course, if the PE is a
 replication point for that multicast P-tunnel, the packet is

Rekhter, et al. Standards Track [Page 21] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 transmitted more than once by the PE.  Similarly, if the PMSI is
 instantiated by IR, each packet may be transmitted multiple times.
 It is still the case, though, that the packet is transmitted only on
 one PMSI.
 This document provides procedures for supporting this transmission
 model using either BGP or PIM as the PE-PE C-multicast control
 protocol.
 There are two variants of this transmission model: "without extranet
 separation" and "with extranet separation".

3.1.1. Without Extranet Separation

 In this variant, multicast data traffic from extranet C-sources and
 from non-extranet C-sources may be carried in the same P-tunnel.
 This document provides procedures for supporting this variant using
 either BGP or PIM as the PE-PE C-multicast control protocol.

3.1.2. With Extranet Separation

 In this variant, multicast data traffic from extranet C-sources and
 from non-extranet C-sources are never carried in the same P-tunnel.
 Under certain circumstances, this can reduce the amount of multicast
 data traffic that is delivered unnecessarily to certain PE routers.
 It also eliminates the ambiguity discussed in Section 2.1.
 By definition, when extranet separation is used, the following rule
 MUST be applied:
    Traffic from extranet C-sources MUST NOT be carried in the same
    P-tunnel as traffic from non-extranet C-sources.
 This rule does not impact those VRFs that contain only non-extranet
 C-sources, nor does it impact those VRFs that contain only extranet
 C-sources.  However, if a particular VRF contains both kinds of
 C-sources, it will need to advertise some P-tunnels that are used for
 carrying only extranet C-flows and some that are used only for
 carrying non-extranet C-flows.
 This document provides procedures for supporting extranet separation
 when BGP is used as the PE-PE C-multicast control protocol.  Support
 for extranet separation using PIM as the PE-PE C-multicast control
 protocol is outside the scope of this document.

Rekhter, et al. Standards Track [Page 22] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

3.2. Transmitting an Extranet C-Flow over Multiple PMSIs

 The second extranet transmission model is called the "transmitting an
 extranet C-flow over multiple PMSIs" model or, more simply, the
 "multiple PMSIs per C-flow" model.  In this model, a PE may transmit
 the packets of an extranet C-flow on several different PMSIs.
 Support for extranet separation with this model is outside the scope
 of this document.
 This document provides procedures for supporting this transmission
 model when PIM is used as the PE-PE C-multicast control protocol.
 Support for this transmission model when BGP is used as the PE-PE
 C-multicast control protocol is outside the scope of this document.

4. Distribution of Routes That Match C-S/C-RP Addresses

4.1. UMH-Eligible Routes

 As described in Section 5.1 of [RFC6513], in order for a C-flow
 (C-S,C-G) to be carried across the SP backbone, a VRF that has
 multicast receivers for that C-flow must import a route that matches
 C-S, and this route must be "eligible for UMH selection".  In this
 document, we will refer to these routes as "UMH-eligible extranet
 C-source routes".
 The UMH-eligible extranet C-source routes do not necessarily have to
 be unicast routes; they MAY be SAFI 129 routes (see Section 5.1.1 of
 [RFC6513]).  For example, suppose that one wants a VPN-R C-receiver
 to be able to receive extranet C-flows from C-sources in VPN-S but
 does not want any VPN-R system to be able to send unicast traffic to
 those C-sources.  One can achieve this by using SAFI 129 routes as
 the UMH-eligible routes exported from VPN-S and imported by VPN-R.
 Since SAFI 129 routes are used only for UMH determination and not for
 unicast routing, this allows the multicast traffic to be forwarded
 properly but does not create unicast routes to the C-sources.
 If a customer is using PIM-SM in the ASM model and one or more
 customer sites have C-receivers that are allowed by policy to join a
 (C-*,C-G) tree, where C-G is an extranet C-group, then any VRF with
 C-receivers for that group MUST import a UMH-eligible route that
 matches C-RP, where C-RP is the Rendezvous Point (RP) address
 for C-G.
 The UMH-eligible extranet C-source and C-RP routes do not have to be
 "host routes".  That is, they can be routes whose IPv4 address
 prefixes are not 32 bits in length or whose IPv6 address prefixes are
 not 128 bits in length.  So, it is possible for a UMH-eligible

Rekhter, et al. Standards Track [Page 23] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 extranet C-source route to match the address of an extranet C-source
 and to also match the address of a non-extranet C-source.  However,
 if such a route is exported from a VPN-S VRF and imported by a VPN-R
 VRF, VPN-R receivers will be able to receive C-flows from any
 non-extranet C-sources whose addresses match that route.  To prevent
 this, the VPN-S VRF SHOULD be provisioned such that it will NOT
 export a UMH-eligible route that matches (in the context of the VPN-R
 VRF) both extranet C-sources and non-extranet C-sources.  Failure to
 follow this rule may result in a VPN security violation.  (See
 Section 10.)
 In general, one does not want ALL the routes from the VPN-S VRFs to
 be exported to all the VPN-R VRFs, as only a subset of the routes in
 the VPN-S VRFs will be UMH-eligible extranet C-source routes.  Route
 distribution is, as is always the case for a BGP/MPLS IP VPN
 [RFC4364], controlled by Route Targets (RTs).  A variety of route
 distribution policies can be created by appropriately provisioning
 the import and export RTs of the various VRFs.
 For example, the VPN-S VRFs that contain extranet C-sources could be
 configured to apply an export RT whose value is "RT-A-extranet" to
 the routes that match the extranet C-sources.  The VPN-R VRFs that
 contain extranet C-receivers allowed to receive extranet C-flows
 from VPN-S extranet C-sources could then be configured with
 "RT-A-extranet" as an import RT.
 Arbitrarily complex policies can be created by suitable manipulation
 of the import and export RTs.

4.1.1. Extranet Separation

 If extranet separation is being used and a given VRF is exporting
 UMH-eligible routes for both extranet C-sources and non-extranet
 C-sources, then the VRF MUST be configured not only with its
 default RD but also with an extranet RD.  The exported UMH-eligible
 routes MUST contain the extranet RD in their NLRIs.

Rekhter, et al. Standards Track [Page 24] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

4.2. Distribution of Unicast Routes Matching C-RPs and DRs

 Consider a C-source, C-S, that may transmit to a particular extranet
 C-group, C-G.
 In order to follow the procedures of [RFC7761],
 o  The "first-hop designated router (DR)" for C-S needs to be able to
    unicast PIM Register messages to a C-RP that services C-G.
 o  The C-RPs servicing C-G need to be able to unicast PIM
    Register-Stop messages to the DR for C-S.
 It follows that if a VRF contains C-S but does not contain a C-RP for
 C-G, then the VRF MUST import a unicast route matching a C-RP for
 C-G.  Note that the unicast route matching the C-RP is needed whether
 or not the VRF has also imported a SAFI 129 route matching the C-RP.
 (If the VRF also contains receivers for C-G and UMH determination is
 being done using SAFI 129 routes, both a unicast route and a SAFI 129
 matching C-RP route are needed.)
 Similarly, if a VRF contains a C-RP for C-G but does not contain C-S,
 the VRF MUST import a unicast route matching the DR for C-S.  Note
 that the unicast route matching the DR for C-S is needed even if UMH
 determination is being done using SAFI 129 routes; in that case, if
 the VRF also contains receivers for C-G, it needs to import a
 SAFI 129 route matching C-S and a unicast route matching the DR
 for C-S.
 If, for a particular extranet C-group, C-G, the customer is using
 "anycast-RP" [RFC3446] [RFC4610] or the Multicast Source Discovery
 Protocol (MSDP) [RFC3618], then all the C-RPs serving C-G need to
 send unicast messages to each other.  Thus, any VRF that contains a
 C-RP for C-G needs to import unicast routes matching ALL the other
 C-RPs that serve C-G.
 The need to distribute these unicast routes is usually not a problem
 as long as all the C-sources and C-RPs for C-G are in the same MVPN.
 If, however, the C-sources are not all in the same MVPN, great care
 must be taken to ensure that the unicast routes mentioned above are
 properly distributed.
 There may be scenarios in which all the C-sources for C-G are in the
 same MVPN, but there are receivers in different VPNs, and some or all
 of the VPNs with receivers have their own C-RPs for C-G.  In this
 case, care must be taken to ensure that the C-RPs can all unicast to
 each other.

Rekhter, et al. Standards Track [Page 25] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

4.3. Route Targets and Ambiguous UMH-Eligible Routes

 This section imposes a constraint on the way RTs are assigned to
 (a) UMH-eligible routes and (b) the BGP A-D routes that advertise
 P-tunnels (i.e., BGP A-D routes that contain a PTA).  The constraint
 specified here applies to any extranet for which the ambiguity
 described in Section 2.2 is possible.  (The conditions under which
 such ambiguity is possible are also described in Section 2.2.)
 We want to ensure that, in any given VRF, the UMH-eligible route
 matching a given extranet C-source has an RT in common with every BGP
 A-D route that advertises a P-tunnel that may be used to carry
 extranet multicast traffic from that C-source.  We also want to
 ensure that the UMH-eligible route matching a given extranet C-source
 does not have any RT in common with any BGP A-D route that advertises
 a P-tunnel that may be used to carry any multicast traffic from a
 different C-source that has the same IP address.  This enables us to
 determine whether traffic that appears to be from the given C-source
 is really arriving on the wrong P-tunnel and hence is really from a
 different C-source with the same IP address.
 Suppose that an IP address C-S is used in VPN-A as the address of one
 system and used in VPN-B as the address of a different system.  In
 this case, one or more VPN-A VRFs may export a VPN-IP route whose
 NLRI is <RD1,S>, and one or more VPN-B VRFs may export a VPN-IP route
 whose NLRI is <RD2,S>, where RD1 != RD2.  Consider two routes -- R1
 and R2 -- for which the following conditions all hold:
 o  R1 and R2 are UMH-eligible extranet C-source or C-RP routes, or
    are unicast routes matching a C-RP.
 o  R1 is exported from a VRF of VPN-A, while R2 is exported from a
    VRF of a different VPN, say VPN-B.
 o  R1's NLRI specifies IP address prefix S/n.
 o  R2's NLRI specifies IP address prefix S/m.
 o  m >= n (S/m is either the same as or more specific than S/n).
 o  There is some host address H such that:
  • H denotes a different system in VPN-A than in VPN-B, and
  • H/m == S/m (so either S/m or S/n might be a longest match for H

in some VRF).

Rekhter, et al. Standards Track [Page 26] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 We impose the following constraint: RTs MUST be assigned in such a
 way that R1 and R2 do not have any RT in common.
 (This constraint is not as onerous as it may seem.  Typically, R1 and
 R2 would not have an RT in common, as that might result in their
 being imported into the same VRF, making the address H ambiguous in
 that VRF.)
 Sections 6 and 7 specify procedures for determining if a received
 C-flow has been received over the expected P-tunnel.  Those
 procedures will not work if this constraint is violated.  (The
 constraint described in this section is necessary, but not
 sufficient, for the procedures of Sections 6 and 7 to work;
 additional constraints that cover the assignment of RTs to BGP A-D
 routes are given in subsequent sections.)

4.4. Dynamically Marking Extranet Routes

4.4.1. The Extranet Source Extended Community

 Sections 4.1, 4.2, and 4.3 place specific requirements on the way in
 which certain VPN-IP routes are distributed.  In order to ensure that
 these requirements are met, a VPN customer must tell its SP which
 routes are the matching routes for extranet C-sources and C-RPs.
 This may be done as part of the provisioning process.  Note that this
 does not necessarily require customer/provider interaction every time
 the customer adds a new extranet C-source or C-RP, but only when the
 IP address of the new C-source or C-RP does not match an existing
 route that is already being distributed as a VPN-IP extranet route.
 Nevertheless, it seems worthwhile to support an OPTIONAL mechanism
 that allows a customer to dynamically mark certain routes as being
 extranet routes.
 To facilitate this, we define a new Transitive Opaque Extended
 Community (see [RFC4360], [RFC7153], and Section 9 of this document):
 the Extranet Source Extended Community.  When a Customer Edge (CE)
 router advertises (via BGP) a route to a PE router and the AFI/SAFI
 of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source
 Extended Community MAY be attached to the route.  The value field of
 the Extended Community MUST be set to zero.  By placing this Extended
 Community on a particular route, a CE router indicates to a PE router
 that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied
 to that route.  That is, the CE router may use this Extended
 Community to indicate to the PE router that a particular route is to
 be treated as a route that matches the address of an extranet source
 and is to be exported accordingly to other VPNs.  A PE router that
 interprets this Extended Community MUST ignore the contents of the
 value field.

Rekhter, et al. Standards Track [Page 27] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Whether a CE router uses the Extranet Source Extended Community is
 determined by the configuration of the CE router.  If used, the set
 of routes to which the Extended Community is attached is also
 determined by configuration of the CE.  Note that a particular PE
 router may or may not support the use of the Extranet Source Extended
 Community by a particular CE router; this is determined by the
 service agreement between the SP and its customer.
 If a CE is advertising SAFI 2 routes to the PE as the UMH-eligible
 extranet C-source and C-RP routes and the CE is using the Extranet
 Source Extended Community, it is important that the CE attach that
 Extended Community to the SAFI 2 routes, rather than just to the
 corresponding SAFI 1 routes.  Otherwise, extranet receivers may not
 be able to join the (C-S,C-G) or (C-*,C-G) multicast trees.
 However, if the C-sources and the C-RPs for a given extranet C-group
 are not all in the same VPN, the Extended Community would also have
 to be attached to the SAFI 1 routes that match the C-RP addresses and
 to the SAFI 1 routes that match the addresses of the first-hop
 designated routers for all the C-sources.  Otherwise, the first-hop
 routers might not be able to send PIM Register messages to the C-RPs,
 and the C-RPs might not be able to send PIM Register-Stop messages to
 the first-hop routers.
 While this Extended Community allows a customer to inform the SP
 dynamically that certain routes are "extranet routes", it does not
 allow a customer to control the set of RTs that the route will carry
 when it is redistributed as a VPN-IP route.  Thus, it is only useful
 when all the extranet routes from a given VRF are exported with
 exactly the same set of RTs.  (cf. Section 4.3.1 of [RFC4364], which
 does provide a mechanism that, if properly supported by the SP,
 allows the customer to determine the set of RTs carried by a VPN-IP
 route.)  A CE SHOULD NOT attach the Extranet Source Extended
 Community to any route for which it uses another method of specifying
 the RTs to be carried by that route.  A CE SHOULD NOT attach the
 Extranet Source Extended Community to a route unless all the extranet
 routes from the CE's VPN are intended to carry the same set of RTs.
 A PE SHOULD ignore the Extranet Source Extended Community if it
 appears on a route that the CE should not have put it on.  A PE that
 ignores the Extranet Source Extended Community SHOULD NOT follow the
 procedures of Section 4.4.2.
 Note that misconfiguration on the CE router can result in the
 Extranet Source Extended Community being mistakenly attached to a
 route that is not intended to be exported as an extranet route.  This
 could result in a VPN security violation.

Rekhter, et al. Standards Track [Page 28] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

4.4.2. Distribution of Extranet Source Extended Community

 Suppose that a PE receives from a CE a route (call it "R") with the
 Extranet Source Extended Community.  The PE must determine (via the
 considerations discussed in Section 4.4.1) whether it should ignore
 that Extended Community on route R; if it should ignore the Extended
 Community, the procedures described in this section are not followed.
 Otherwise, when the PE originates a VPN-IP route corresponding to
 route R, the PE MUST attach this Extended Community to that route.
 A Route Reflector MUST NOT add or remove the Extranet Source Extended
 Community from the VPN-IP routes reflected by the Route Reflector,
 including the case where VPN-IP routes received via Internal BGP
 (IBGP) are reflected to External BGP (EBGP) peers (inter-AS
 option (c); see Section 10 of [RFC4364]).  The value of the Extended
 Community MUST NOT be changed by the Route Reflector.
 When re-advertising VPN-IP routes, Autonomous System Border Routers
 (ASBRs) MUST NOT add/remove the Extranet Source Extended Community
 from these routes.  This includes inter-AS options (b) and (c) (see
 Section 10 of [RFC4364]).  The value of the Extended Community
 MUST NOT be changed by the ASBRs.
 When a PE advertises (via BGP) IP routes to a CE, these routes
 MUST NOT carry the Extranet Source Extended Community unless the
 PE-CE connection is actually an inter-AS option (a) connection (see
 Section 10 of [RFC4364]).  When the PE-CE connection is not an
 inter-AS option (a) connection, a CE that receives an IP route with
 the Extranet Source Extended Community MUST remove it from the route
 before re-advertising the route.
 The rules for attaching the Extranet Source Extended Community to a
 VPN-IP route, and the rules for propagating that Extended Community,
 are needed in order to support the scenario in which a VPN contains
 an option (a) interconnect (see Section 10 of [RFC4364]).  At the
 option (a) interconnect, the VPN-IP route gets translated back to an
 IP route, and the RTs are stripped off before the IP route is
 propagated.  If the Extranet Source Extended Community has also been
 stripped off, there is no way for the router at the other end of the
 option (a) interconnect to know that the route represents an extranet
 source.  Thus, the technique of using the Extranet Source Extended
 Community to dynamically signal that a particular route represents an
 extranet source will not work correctly across an option (a)
 interconnect unless the rules in this section are followed.

Rekhter, et al. Standards Track [Page 29] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

4.5. The Extranet Separation Extended Community

 We define a new Transitive Opaque Extended Community: the Extranet
 Separation Extended Community (see [RFC4360], [RFC7153], and
 Section 9 of this document).  This Extended Community is used only
 when extranet separation is being used.  Its value field MUST be set
 to zero upon origination, MUST be ignored upon reception, and MUST be
 passed unchanged by intermediate routers.  A Route Reflector MUST NOT
 add or remove the Extranet Separation Extended Community from the
 routes it reflects, including the case where routes received via IBGP
 are reflected to EBGP peers (inter-AS option (c); see Section 10 of
 [RFC4364]).
 If a VRF has been provisioned to use extranet separation and that VRF
 has been provisioned to transmit any extranet C-flows on a P-tunnel
 that it advertises in an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D
 route, then any UMH-eligible routes that are exported from that VRF
 following the procedures of Sections 4.1, 4.2, and 4.3 MUST carry the
 Extranet Separation Extended Community.  In addition, if an I-PMSI
 A-D route and/or (C-*,C-*) S-PMSI A-D route exported from that VRF is
 used to carry extranet traffic, that A-D route MUST also carry the
 Extranet Separation Extended Community.  Further details may be found
 in Sections 7.3, 7.4.4, and 7.4.5.

5. Origination and Distribution of BGP A-D Routes

 Except where otherwise specified, this section describes procedures
 and restrictions that are independent of the PE-PE C-multicast
 control protocol.

5.1. Route Targets of UMH-Eligible Routes and A-D Routes

 Suppose that there is an extranet C-flow such that:
 o  The extranet C-source of that C-flow is in VRF A-1.
 o  One or more extranet C-receivers of that C-flow are in VRF B-1.
 In this case, VRF A-1 MUST export a UMH-eligible route that matches
 the extranet C-source address, and VRF B-1 MUST import that route.
 In addition, VRF A-1 MUST export an Intra-AS I-PMSI A-D route or an
 S-PMSI A-D route specifying the P-tunnel through which it will send
 the data traffic of the given extranet C-flow, and VRF B-1 MUST
 import that route.  If BGP is the PE-PE C-multicast control protocol,
 then under certain conditions (as specified in [RFC6514]), VRF A-1
 may also need to export a Source Active A-D route specifying that it
 contains a source of the given C-flow, and VRF B-1 must import that
 Source Active A-D route.  That is, in order for VRF B-1 to receive a

Rekhter, et al. Standards Track [Page 30] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 C-flow from a given extranet C-source contained in VRF A-1, VRF A-1
 MUST export a set of A-D routes that are "about" that source, and VRF
 B-1 MUST import them.
 One way to ensure this is to provision an RT that is carried by all
 the routes exported from VRF A-1 that are "about" a given extranet
 C-source and also provision this RT as an import RT at any VRF (such
 as VRF B-1) that is allowed to receive extranet flows from that
 source.
 If the "single PMSI per C-flow" transmission model is being used
 (with or without extranet separation), there is an additional
 requirement, stated below, regarding the way RTs are provisioned, as
 the RTs carried by a UMH-eligible route that matches a given extranet
 C-source may need to be used to identify the A-D routes that are
 "about" that source.
 Consider the following scenario:
 o  IP address S is the address of one system in VPN-A and the address
    of a different system in VPN-B.
 o  VRF A-1 on PE1 exports UMH-eligible route R1, which is a matching
    route for S.
 o  VRF A-1 on PE1 exports an A-D route P1 whose PTA identifies a
    P-tunnel through which VRF A-1 may send traffic whose C-source is
    S, where one of the following conditions holds:
  • P1 is an I-PMSI A-D route, OR
  • P1 is an S-PMSI A-D route whose NLRI contains (C-*,C-*) or

(C-*,C-G), OR

  • P1 is an S-PMSI A-D route whose NLRI contains (C-S,C-G) or

(C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*)

       P-tunnel" policy is not provisioned, OR
  • P1 is a Source Active A-D route whose NLRI contains (C-S,C-G).

Rekhter, et al. Standards Track [Page 31] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 o  VRF B-1 on PE1 exports a UMH-eligible route R2, which is a
    matching route for S.
 o  VRF B-1 on PE1 exports an A-D route P2 whose PTA identifies a
    P-tunnel on which VRF B-1 may send traffic whose C-source is S,
    where one of the following conditions holds:
  • P2 is an I-PMSI A-D route, OR
  • P2 is an S-PMSI A-D route whose NLRI specifies (C-*,C-*) or

(C-*,C-G), OR

  • P2 is an S-PMSI A-D whose NLRI specifies (C-S,C-G) or

(C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*)

       P-tunnel" policy is not provisioned, OR
  • P2 is a Source Active A-D route whose NLRI contains (C-S,C-G).
 As implied by the rules of Section 4.1, there MUST NOT be any RT that
 is common to both R1 and R2.  In addition, the following set of rules
 for RT assignment MUST be followed when extranets are supported.
 These rules support all the extranet transmission models described in
 this specification:
 o  There MUST NOT be any RT that is carried by both P1 and P2.
 o  The intersection of the set of RTs carried by P1 and the set of
    RTs carried by R1 MUST be non-null, and any VRF that imports both
    P1 and R1 MUST be configured with an import RT from this
    intersection.
 o  The intersection of the set of RTs carried by P2 and the set of
    RTs carried by R2 MUST be non-null, and any VRF that imports both
    P2 and R2 MUST be configured with an import RT from this
    intersection.

Rekhter, et al. Standards Track [Page 32] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Suppose that VRF C-1 on PE2 imports P1 and R1 from VRF A-1 while also
 importing P2 from VRF B-1.  Since
 o  R1 is VRF C-1's route to S,
 o  R1 has an RT in common with P1, and
 o  R1 has no RT in common with P2,
 it can be concluded that VRF C-1 should expect that multicast traffic
 from S will arrive on the P-tunnel specified in P1.  See Sections 6
 and 7 for more details on determining the expected P-tunnel for a
 given extranet C-flow.
 While the assignment of import and export RTs to routes is a
 deployment and provisioning issue rather than a protocol issue, it
 should be understood that failure to follow these rules is likely to
 result in VPN security violations.

5.2. Considerations for Particular Inclusive Tunnel Types

 An Inclusive Tunnel (sometimes referred to as an "Inclusive Tree";
 see Section 2.1.1 of [RFC6513]) is a tunnel that, by default, carries
 all the multicast traffic of a given MVPN that enters the backbone
 network via a particular PE.  An Inclusive Tunnel is advertised in
 the PTA of an I-PMSI A-D route.

5.2.1. RSVP-TE P2MP or Ingress Replication

 This section applies when Inclusive Tunnels are created using either
 RSVP-TE P2MP or IR.
 Suppose that a VRF, say VRF-S, contains a given extranet C-source
 C-S, and VRF-S advertises in its Intra-AS I-PMSI A-D route either a
 P2MP RSVP-TE P-tunnel or an IR P-tunnel to carry extranet traffic.
 In order for VRF-S to set up the P2MP RSVP-TE or IR P-tunnel, it must
 know all the PEs that are leaf nodes of the P-tunnel, and to learn
 this it must import an Intra-AS I-PMSI A-D route from every VRF that
 needs to receive data through that tunnel.
 Therefore, if VRF-R contains an extranet C-receiver that is allowed
 by policy to receive extranet flows from C-S, the RT(s) carried by
 the Intra-AS I-PMSI A-D routes originated by VRF-R MUST be such that
 those Intra-AS I-PMSI A-D routes will be imported into VRF-S.

Rekhter, et al. Standards Track [Page 33] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 In the case of IR, this has the following consequence: if an egress
 PE has n VRFs with receivers for a flow that VRF-S transmits on its
 I-PMSI, that egress PE will receive n copies of the same packet, one
 for each of the n VRFs.
 Note that Section 9.1.1 of [RFC6514] prohibits the "Leaf Information
 Required" flag from being set in the PTA of an Intra-AS I-PMSI A-D
 route.  If this prohibition is ever removed, the requirement of this
 section will apply only if VRF-S does not set that flag.

5.2.2. Ingress Replication

 This section applies only when Inclusive Tunnels are created via IR.
 [RFC6513] and [RFC6514] specify procedures that allow I-PMSIs to be
 instantiated by IR.  The concept of an IR P-tunnel, and the
 procedures for supporting IR P-tunnels, are explained more fully in
 [MVPN-IR].  An IR P-tunnel can be thought of as a P2MP tree in which
 a packet is transmitted from one node on the tree to another by being
 encapsulated and sent through a unicast tunnel.
 As discussed in Section 2, when I-PMSIs are used to support
 extranets, egress PEs MUST have the ability to discard customer
 multicast data packets that arrive on the wrong P-tunnel.  When
 I-PMSIs are instantiated by IR, this implies that the following two
 procedures MUST be followed:
 1.  One of the following three procedures MUST be followed:
     a.  the "Single Forwarder Selection" procedures of Section 9.1.2
         of [RFC6513]
     b.  the "native PIM methods" of Section 9.1.3 of [RFC6513]
     c.  the unicast encapsulation used to transmit packets along the
         IR P-tunnel is such as to enable the receiving node to
         identify the transmitting node (note that this would not be
         the case if, for example, the unicast tunnels were MP2P LSPs)
     and
 2.  If a PE assigns an MPLS label value in the PTA of an Intra-AS or
     Inter-AS I-PMSI A-D route that it originates, that label value
     MUST NOT appear in the PTA of any other I-PMSI or S-PMSI A-D
     route originated by the same PE.

Rekhter, et al. Standards Track [Page 34] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Failure to follow these procedures would make it impossible to
 discard packets that arrive on the wrong P-tunnel and thus could lead
 to duplication of data.
 If it is desired to support extranets while also using IR to
 instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs
 instead of I-PMSIs.  (See [RFC6625], as well as Sections 7.2.2,
 7.3.2, and 7.4.4 of this document.)  This has much the same effect in
 the data plane, and there are no restrictions on the type of unicast
 tunnel that can be used for instantiating S-PMSIs.
 Section 6.4.5 of [RFC6513] describes a way to support VPNs using
 I-PMSIs that are instantiated by IR, using no S-PMSIs, but using
 "explicit tracking" to ensure that a C-flow goes only to egress PEs
 that have receivers for it.  This document does not provide
 procedures to support extranets using that model.

6. When PIM Is the PE-PE C-Multicast Control Plane

 As specified in [RFC6513], when PIM is used as the PE-PE C-multicast
 control plane for a particular MVPN, there is a "Multidirectional
 Inclusive Provider Multicast Service Interface" (MI-PMSI) for that
 MVPN, and all the PEs of that MVPN must be able to send and receive
 on that MI-PMSI.  Associated with each VRF of the MVPN is a PIM
 C-instance, and the PIM C-instance treats the MI-PMSI as if it were a
 LAN interface.  That is, the "ordinary" PIM procedures run over the
 MI-PMSI just as they would over a real LAN interface, except that the
 data-plane and control-plane "Reverse Path Forwarding (RPF) checks"
 need to be modified.  Section 5.2 of [RFC6513] specifies the RPF
 check modifications for non-extranet MVPN service.
 For example, suppose that there are two VPNs: VPN-S and VPN-R.  In
 the absence of extranet support, all the VRFs of VPN-S are connected
 via one MI-PMSI (call it "the VPN-S MI-PMSI"), and all the VRFs of
 VPN-R are connected via another ("the VPN-R MI-PMSI").  If we want to
 provide extranet service in which the extranet C-sources are attached
 to some set of VPN-S VRFs while the extranet C-receivers are attached
 to some set of VPN-R VRFs, then we have two choices:
 1.  either the VPN-R VRFs need to join the VPN-S MI-PMSI, or
 2.  the VPN-S VRFs need to join the VPN-R MI-PMSI.
 The first choice is used to support the "single PMSI per C-flow"
 transmission model.  The second choice is used to support the
 "multiple PMSIs per C-flow" transmission model.

Rekhter, et al. Standards Track [Page 35] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Procedures for both models are described below.
 To support these models, it must be possible to determine which
 I-PMSI A-D routes are associated with the VPN-S I-PMSI and which
 I-PMSI A-D routes are associated with the VPN-R I-PMSI.  Procedures
 are given for assigning RTs to these routes in a way that makes this
 determination possible.
 Both models allow the use of S-PMSIs to carry multicast data traffic.
 If a VRF containing receivers can receive from multiple MI-PMSIs,
 each S-PMSI must be uniquely associated with a particular MI-PMSI.
 Procedures are given for assigning RTs to these routes in a way that
 makes this determination possible.
 All the procedures specified in Sections 3, 4, and 5 still apply.
 Note that there are no special extranet procedures for Inter-AS
 I-PMSI A-D routes or for Leaf A-D routes.  Source Active A-D routes
 are not used when PIM is the PE-PE C-multicast protocol.

6.1. Provisioning VRFs with RTs

6.1.1. Incoming and Outgoing Extranet RTs

 In the absence of extranet service, suppose that each VRF of a given
 VPN (call it "VPN-S") is configured with RT-S as its import and
 export RT, and that each VRF of a second VPN (call it "VPN-R") is
 configured with RT-R as its import and export RT.  We will refer to
 RT-S and RT-R as "non-extranet RTs".
 Now suppose that VPN-S contains some extranet C-sources and VPN-R
 contains some extranet C-receivers that are allowed by policy to
 receive extranet C-flows from the VPN-S extranet C-sources.
 To set up this S-to-R extranet, provisioning an additional RT (call
 it "RT-S-to-R") whose value is, in general, distinct from RT-S and
 RT-R is REQUIRED.
 A VPN-S VRF that contains extranet C-sources allowed to transmit to
 VPN-R MUST be configured with RT-S-to-R as an "Outgoing Extranet RT".
 A VPN-R VRF that contains extranet C-receivers allowed to receive
 packets from VPN-S MUST be configured with RT-S-to-R as an "Incoming
 Extranet RT".
 Note that the terms "Incoming" and "Outgoing" in this context refer
 to the direction of multicast data packets relative to the VRF.

Rekhter, et al. Standards Track [Page 36] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 The Incoming Extranet RTs and Outgoing Extranet RTs that are
 configured for a given VRF serve as import RTs for that VRF.  They
 also serve as export RTs, but only for specific routes as specified
 in Section 6.1.2 below.
 Note that any VRF that contains both extranet C-sources and extranet
 C-receivers MUST be configured with both Outgoing Extranet RTs and
 Incoming Extranet RTs.
 A VRF MAY be configured with more than one Incoming Extranet RT
 and/or Outgoing Extranet RT.
 If it happens to be the case that all C-sources in VPN-S are extranet
 C-sources allowed to transmit to VPN-R, then VPN-S VRFs MAY be
 configured such that RT-S is both a non-extranet RT and an Outgoing
 Extranet RT, and VPN-R VRFs MAY be configured such that RT-S is an
 Incoming Extranet RT.

6.1.2. UMH-Eligible Routes and RTs

 Suppose that R1 is a route exported from a VPN-S VRF and matching an
 extranet C-source that is allowed by policy to transmit to VPN-R.  In
 that case, R1 MUST carry the Outgoing Extranet RT used for the S-to-R
 extranet.  This will cause the route to be imported into the VPN-R
 VRFs that have extranet C-receivers that are allowed by policy to
 receive from VPN-S.
 The rules of Section 4 regarding RTs and ambiguous addresses still
 apply.

6.1.3. PIM C-Instance Reverse Path Forwarding Determination

 Suppose that a PIM control message (call it "M") is received by a
 given VRF (call it "VRF-V") from a particular P-tunnel T.  In order
 to process control message M, the PIM C-instance associated with
 VRF-V may need to do an "RPF determination" (see Section 5.2.2 of
 [RFC6513]) for a particular IP prefix S.  RPF determination is based
 upon the rules for UMH selection as specified in Section 5.1 of
 [RFC6513].

Rekhter, et al. Standards Track [Page 37] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 This document specifies an additional constraint on the UMH selection
 procedure.  When doing RPF determination for a PIM control message
 received over a P-tunnel, a route matching prefix S is not considered
 to be eligible for UMH selection unless there is an RT (call it
 "RT1"), configured as one of VRF-V's Outgoing Extranet RTs, such that
 the following two conditions both hold:
 1.  The route matching S is exported from VRF-V carrying RT1, and
 2.  An I-PMSI A-D route advertising P-tunnel T (in its PTA) has been
     imported into VRF-V, and that I-PMSI A-D route carries RT1.

6.2. "Single PMSI per C-Flow" Model

 In this model, if a VPN-S VRF has extranet multicast C-sources and a
 VPN-R VRF has extranet multicast C-receivers allowed by policy to
 receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins
 the MI-PMSI that VPN-S uses for its non-extranet traffic.

6.2.1. Forming the MI-PMSIs

 Consider a VPN-S VRF that has extranet C-sources.  Per [RFC6513],
 each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing
 a PTA specifying the P-tunnel to be used as part of the VPN-S
 MI-PMSI.  In the absence of extranet service, this route carries the
 VRF's non-extranet RT, RT-S.  When extranet service is provided
 (using the "single PMSI per C-flow" model), this route MUST also
 carry each of the VRF's Outgoing Extranet RTs.
 Consider a VPN-R VRF that has extranet C-receivers.  Per [RFC6513],
 each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing
 a PTA specifying the P-tunnel to be used as part of the VPN-R
 MI-PMSI.  This route carries the VRF's non-extranet RT, RT-R.  When
 extranet service is provided (using the "single PMSI per C-flow"
 model), the VPN-R VRF MUST also originate one or more additional
 Intra-AS I-PMSI A-D routes.  It MUST originate one additional
 Intra-AS I-PMSI A-D route for each Incoming Extranet RT with which it
 has been configured; each such route will carry exactly one of the
 configured Incoming Extranet RTs.
 Note that when a VRF originates more than one Intra-AS I-PMSI A-D
 route, each of them MUST contain a different RD in its NLRI.  In
 addition, we add the requirement that any pair of such routes
 MUST NOT contain an RT in common.

Rekhter, et al. Standards Track [Page 38] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 A VRF with extranet C-sources MUST join the P-tunnels advertised in
 the imported I-PMSI A-D routes that carry its non-extranet RT or any
 of its Outgoing Extranet RTs.  This set of P-tunnels will be treated
 as instantiating a single MI-PMSI; the associated PIM C-instance will
 treat that MI-PMSI as a single LAN and will run PIM procedures on
 that LAN, as specified in [RFC6513].  The fact that the MI-PMSI
 attaches to VRFs of different VPNs is not known to the PIM C-instance
 of the VRF containing the sources.
 A VRF with extranet C-receivers MUST join the P-tunnels advertised in
 all the imported I-PMSI A-D routes.  The set of P-tunnels advertised
 in the I-PMSI A-D routes that carry a particular Incoming Extranet RT
 are treated as instantiating a particular MI-PMSI.  So, a VRF with
 C-receivers will "see" several MI-PMSIs, one corresponding to the
 non-extranet, and as many as one for each configured Incoming
 Extranet RT.  The PIM C-instance associated with the VRF will treat
 each of these MI-PMSIs as a separate LAN interface.
 As an example, suppose that:
 o  All VPN-R VRFs are configured with RT-R as a non-extranet import
    and export RT, and
 o  VPN-R VRFs with extranet receivers are configured with RT-S-to-R
    as an Incoming Extranet RT, and
 o  VPN-S VRFs with extranet transmitters are configured with:
  • RT-S as a non-extranet import and export RT
  • a list of IP addresses that are the addresses of the extranet

sources

  • RT-S-to-R as an Outgoing Extranet RT
 VPN-S VRFs will then export UMH-eligible routes matching extranet
 C-sources, and these routes will carry both RT-S and RT-S-to-R.  Each
 VPN-S VRF will also export an Intra-AS I-PMSI A-D route that carries
 both RT-S and RT-S-to-R.
 VPN-R VRFs will originate and export two Intra-AS I-PMSI A-D routes:
 one carrying RT-R and one carrying RT-S-to-R.  The Intra-AS I-PMSI
 A-D route with RT-S-to-R will be imported into the VPN-S VRFs.
 VPN-R will regard all the I-PMSI A-D routes it has exported or
 imported with RT-S-to-R as part of a single MI-PMSI.  VPN-R will
 regard all the I-PMSI A-D routes it has exported or imported with
 RT-R as part of a second MI-PMSI.  The PIM C-instance associated with

Rekhter, et al. Standards Track [Page 39] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 a VPN-R VRF will treat the two MI-PMSIs as two separate LAN
 interfaces.  However, the VPN-S VRFs will regard all the I-PMSI A-D
 routes imported with RT-S or RT-S-to-R as establishing only a single
 MI-PMSI.  One can think of this as follows: the VPN-R VRFs have
 joined the VPN-S MI-PMSI as well as the VPN-R MI-PMSI.
 Extranets consisting of more than two VPNs are easily supported as
 follows.  Suppose that there are three VPNs: VPN-A, VPN-B, and VPN-C.
 VPN-A and VPN-B have extranet C-sources, and VPN-C contains receivers
 for both VPN-A extranet C-sources and VPN-B extranet C-sources.  In
 this case, the VPN-C VRFs that have receivers for both VPN-A and
 VPN-B sources may be provisioned as follows.  These VPN-C VRFs may be
 provisioned with RT-C as a non-extranet RT, and with RT-A-to-C and
 RT-B-to-C as Incoming Extranet RTs.  In this case, the VPN-C VRFs
 that are so provisioned will originate three Intra-AS I-PMSI A-D
 routes (each with a different RD in its NLRI), each of which carries
 exactly one of the three RTs just mentioned.  The VPN-B VRFs with
 extranet C-sources will be provisioned with RT-B-to-C as an Outgoing
 Extranet RT, and the VPN-A VRFs will be provisioned with RT-A-to-C as
 an Outgoing Extranet RT.  The result will be that the PIM C-instance
 associated with a VPN-C VRF will see three LAN interfaces: one for
 the non-extranet and one for each of the two extranets.  This
 generalizes easily to the case where there are VPN-C receivers in
 n different extranets (i.e., receiving extranet flows whose sources
 are in n different VPNs).
 Suppose again that there are three VPNs -- VPN-A, VPN-B, and VPN-C --
 but in this example VPN-A is the only one with extranet sources while
 VPN-B and VPN-C both have receivers for the VPN-A extranet sources.
 This can be provisioned as either one extranet or two extranets.
 To provision it as one extranet, the VPN-A VRFs are configured with
 one Outgoing Extranet RT (call it "RT-A-extranet").  The VPN-B and
 VPN-C VRFs with extranet receivers will be provisioned with
 RT-A-extranet as the Incoming Extranet RT.  Thus, the VPN-B and VPN-C
 VRFs will each originate two Intra-AS I-PMSI A-D routes: one for the
 non-extranet and one for the extranet.  From a given VRF, the
 Intra-AS I-PMSI A-D route for the extranet will carry RT-A-extranet
 but will not share any RT with the non-extranet A-D routes exported
 from the same VRF.
 The result is that the VPN-B and VPN-C VRFs each belong to two
 MI-PMSIs: one for the extranet and one for the intranet.  The MI-PMSI
 for the extranet attaches VPN-A VRFs, VPN-B VRFs, and VPN-C VRFs.

Rekhter, et al. Standards Track [Page 40] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Alternatively, one could provision the VPN-A VRFs so that some
 UMH-eligible extranet source routes carry an RT that we will call
 "RT-A-to-B" and some carry an RT that we will call "RT-A-to-C".  The
 VPN-A VRFs would be configured with both of these as Outgoing
 Extranet RTs.  To allow an extranet flow from a VPN-A source to have
 both VPN-B and VPN-C receivers, the UMH-eligible route for that
 source would carry both RTs.  VPN-B VRFs (but not VPN-C VRFs) would
 be provisioned with RT-A-to-B as an Incoming Extranet RT.  VPN-C VRFs
 (but not VPN-B VRFs) would be provisioned with RT-A-to-C as an
 Incoming Extranet RT.
 Following the rules above, if any VPN-A extranet source is to have
 both VPN-B and VPN-C receivers, the VPN-B and VPN-C VRFs will each
 originate two I-PMSI A-D routes: one for the extranet and one for the
 non-extranet.  The single Intra-AS I-PMSI A-D route originated by the
 VPN-A VRFs will have both RT-A-to-B and RT-A-to-C among its RTs (as
 well as VPN-A's non-extranet RT).  The extranet I-PMSI A-D route
 originated from a VPN-B VRF would have RT-A-to-B, and the extranet
 I-PMSI A-D route originated from a VPN-C VRF would have RT-A-to-C.
 If a given VRF contains both extranet C-receivers and extranet
 C-sources, the procedures described above still work, as the VRF will
 be configured with both Incoming Extranet RTs and Outgoing Extranet
 RTs; the VRF functions as both a VPN-S VRF and a VPN-R VRF.

6.2.2. S-PMSIs

 When PIM is used as the PE-PE C-multicast control plane, every S-PMSI
 is considered to be part of the "emulated LAN" that "corresponds" to
 a particular MI-PMSI.
 When the bindings of C-flows to particular S-PMSIs are announced via
 S-PMSI Join messages (Section 7 of [RFC6513]) sent on the MI-PMSI,
 the S-PMSI is considered to be part of the same LAN interface as the
 corresponding MI-PMSI.
 When the bindings of C-flows to particular S-PMSIs are announced via
 S-PMSI A-D routes, any S-PMSI A-D route exported from that VRF MUST
 have an RT in common with exactly one of the Intra-AS A-D routes
 exported from that VRF, and this MUST be one of the VRF's Outgoing
 Extranet RTs.  Further, the S-PMSI A-D route MUST NOT have an RT in
 common with any other Intra-AS A-D route exported from a VRF on the
 same PE.  A given S-PMSI A-D route will be considered to "correspond"
 to the MI-PMSI of the Intra-AS I-PMSI A-D route (originated from the
 same PE) with which it shares an RT.

Rekhter, et al. Standards Track [Page 41] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 The MI-PMSI that corresponds to a given S-PMSI is determined as
 follows:
 o  If (1) there is an Intra-AS I-PMSI A-D route originated by the
    same PE that originated the S-PMSI A-D route, (2) those two routes
    have an RT in common, and (3) that RT is one of the VRF's Incoming
    Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated
    with that Intra-AS I-PMSI A-D route.
 o  Otherwise, if (1) there is an Inter-AS I-PMSI A-D route originated
    in the same AS as the S-PMSI A-D route, (2) those two routes have
    an RT in common, and (3) that RT is one of the VRF's Incoming
    Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated
    with that Inter-AS I-PMSI A-D route.
 o  Otherwise, there must be a configuration error (a violation of the
    requirements of Sections 3, 4, and 5 of this document).
 When wildcard S-PMSIs are used, the rules given in [RFC6625] for
 determining whether a given S-PMSI A-D route is a "match for
 reception" to a given (C-S,C-G) or (C-*,C-G) are modified as follows:
    A given S-PMSI A-D route MUST NOT be considered to be a "match for
    reception" for a given (C-S,C-G) or (C-*,C-G) state UNLESS that
    S-PMSI A-D route "corresponds" (as defined above) to the MI-PMSI
    that is the incoming interface for the given state.
 The rules given in [RFC6625] for determining whether a given S-PMSI
 A-D route is a "match for transmission" are unchanged.

6.2.3. Sending PIM Control Packets

 Suppose that a PE, say PE1, receives a PIM Join(S,G) from a CE, over
 a VRF interface that is associated with a VPN-R VRF.  The PE does the
 RPF check for S by looking up S in the VPN-R VRF.  The PIM C-instance
 associated with that VRF must determine the correct P-tunnel over
 which to send a PIM Join(S,G) to other PEs.
 To do this, PE1 finds, in the VRF associated with the interface over
 which the Join was received, the selected UMH route for S, following
 the procedures of Section 5.1 of [RFC6513].  PE1 determines the set
 of RTs carried by that route.  PE1 then checks to see if there is an
 Intra-AS I-PMSI A-D route, currently originated by PE1, that has an
 RT in common with the selected UMH route for S.

Rekhter, et al. Standards Track [Page 42] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 If the rules of Sections 3, 4, and 5 have been followed, each of
 PE1's selected UMH routes will share an RT with a single one of PE1's
 currently originated Intra-AS I-PMSI A-D routes.  If this is so, the
 Join is sent on the P-tunnel advertised in the PTA of that route.
 Otherwise, the Join MUST NOT be sent.
 In essence, this procedure makes the RPF check for C-S resolve to the
 MI-PMSI that is serving as the next-hop "interface" to C-S.
 If a PE receives a PIM Join(*,G) from a CE, the procedure for doing
 the RPF check is the same, except that the selected UMH route will be
 a route to the C-RP associated with the C-G group.

6.2.4. Receiving PIM Control Packets

 When a PIM C-instance receives a PIM control message from a P-tunnel,
 it needs to identify the message's incoming interface.  This incoming
 interface is the MI-PMSI of which the P-tunnel is a part.

6.2.5. Sending and Receiving Data Packets

 The rules for choosing the PMSI on which to send a multicast data
 packet are as specified in [RFC6513] and [RFC6625], with one new
 restriction: a VPN-S VRF always transmits a multicast data packet
 either on the VPN-S MI-PMSI or on an S-PMSI that corresponds to the
 VPN-S MI-PMSI.  From the perspective of the PIM C-instance, there is
 only one outgoing interface.
 When a PIM C-instance receives a multicast data packet from a given
 P-tunnel and that P-tunnel is being used to instantiate an MI-PMSI,
 the MI-PMSI of which the P-tunnel is a part (see Sections 6.2.1 and
 6.2.2) is considered to be the packet's incoming interface.  If the
 packet is received on a P-tunnel that was advertised in an S-PMSI A-D
 route, the packet's incoming interface is the MI-PMSI to which that
 S-PMSI route corresponds, as defined in Section 6.2.2.  Ordinary PIM
 rules for data-plane RPF checks apply.
 Following ordinary PIM procedures, packets arriving from an
 unexpected incoming interface are discarded.  This eliminates any
 problems due to the ambiguities described in Sections 2.1 and 2.2.

6.3. "Multiple PMSIs per C-Flow" Model

 In this model, if a VPN-S VRF has extranet multicast C-sources and a
 VPN-R VRF has extranet multicast C-receivers allowed by policy to
 receive from the C-sources in the VPN-S VRF, then the VPN-S VRF joins
 the MI-PMSI that VPN-R uses for its non-extranet traffic.

Rekhter, et al. Standards Track [Page 43] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 In the "single PMSI per C-flow" transmission model (as described in
 Section 6.2), a PE that needs to transmit a multicast data packet to
 a set of other PEs transmits the packet on a single PMSI.  This means
 that if a packet needs to be transmitted from a VPN-A VRF and
 received at a VPN-B VRF and a VPN-C VRF, there must be some P-tunnel
 from which the VPN-B and VPN-C VRFs can both receive packets.
 In the "multiple PMSIs per C-flow" transmission model, a PE that
 needs to transmit a multicast data packet to a set of other PEs may
 transmit the packet on several different PMSIs.  (Of course, any
 given packet is transmitted only once on a given P-tunnel.)  For
 example, if a C-flow (C-S,C-G) has a VPN-A C-source, a VPN-B
 receiver, and a VPN-C receiver, there could be one PMSI that the
 VPN-A VRF uses to transmit the packet to the VPN-B VRFs and
 another PMSI that the VPN-A VRF uses to transmit the packet to the
 VPN-C VRFs.

6.3.1. Forming the MI-PMSIs

 Consider a VPN-R VRF that has extranet C-receivers.  Per [RFC6513],
 each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing
 a PTA specifying the P-tunnel to be used as part of the VPN-R
 MI-PMSI.  In the absence of extranet service, this route carries the
 VRF's non-extranet RT, RT-R.  When extranet service is provided
 (using the "single PMSI per C-flow" model), this route MUST also
 carry each of the VRF's Incoming Extranet RTs.
 Consider a VPN-S VRF that has extranet C-sources.  Per [RFC6513],
 each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing
 a PTA specifying the P-tunnel to be used as part of the VPN-S
 MI-PMSI.  This route carries the VRF's non-extranet RT, RT-S.  When
 extranet service is provided using the "multiple PMSIs per C-flow"
 model, the VPN-S VRF MUST also originate one or more additional
 Intra-AS I-PMSI A-D routes.  It MUST originate one additional
 Intra-AS I-PMSI A-D route for each Outgoing Extranet RT with which it
 has been configured; each such route will have a distinct RD and will
 carry exactly one of the configured Outgoing Extranet RTs.
 As with the "single PMSI per C-flow" transmission model, VRFs
 containing extranet C-receivers need to import UMH-eligible extranet
 C-source routes from VRFs containing C-sources.  This is ensured by
 the rules of Sections 3, 4, and 5.
 However, in the "multiple PMSIs per C-flow" model, a VRF containing
 only C-receivers originates only a single Intra-AS I-PMSI A-D route
 carrying the non-extranet RT and all the Incoming Extranet RTs.

Rekhter, et al. Standards Track [Page 44] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes
 that carry the non-extranet RT or one of the Incoming Extranet RTs,
 the P-tunnels specified in the PTA of all such routes are considered
 to be part of the same MI-PMSI.  That is, the associated PIM
 C-instance will treat them as part of a single interface.
 In this model, it is the VRF containing extranet C-sources that MUST
 originate multiple Intra-AS I-PMSI A-D routes.  Each such route MUST
 have a distinct RD, and the set of RTs carried by any one of these
 routes MUST be disjoint from the set carried by any other.  There
 MUST be one such route for each of the VRF's Outgoing Extranet RTs,
 and each such route MUST carry exactly one of the VRF's Outgoing
 Extranet RTs.  The VRFs containing extranet C-sources MUST also
 import all the A-D routes originated by the VRFs containing extranet
 C-receivers.  If a set of originated and/or imported Intra-AS I-PMSI
 A-D routes have an RT in common and that RT is one of the VRF's
 Outgoing Export RTs, then those routes are considered to be "about"
 the same MI-PMSI.  The PIM C-instance of the VRF treats each MI-PMSI
 as a LAN interface.
 In effect, if VPN-S has only extranet C-sources and VPN-R has only
 extranet C-receivers, this model has the VPN-S VRFs join the VPN-R
 MI-PMSI.  The VPN-S VRFs will thus be attached to multiple MI-PMSIs,
 while the VPN-R VRFs are attached to only one.  The fact that the
 VPN-R MI-PMSI is attached to VPN-S VRFs is not known to the PIM
 C-instance at the VPN-R VRFs.
 If a VPN-A VRF has extranet C-sources allowed to send to C-receivers
 in a VPN-B VRF and the VPN-B VRF has C-sources allowed to send to
 C-receivers in the VPN-A VRF, the above procedures still work as
 specified.
 Following normal PIM procedures, when the PIM C-instance at a VRF
 with extranet C-sources receives a Join(C-S,C-G) or a Join(C-*,C-G)
 over an MI-PMSI, it may create (C-S,C-G) or (C-*,C-G) state, and the
 MI-PMSI over which the Join was received may be added to the set of
 outgoing interfaces for that multicast state.  If n MI-PMSIs are
 added to the outgoing interface list for a particular multicast
 state, a multicast data packet may need to be replicated n times and
 transmitted once on each of the n MI-PMSIs.
 Since all of the multicast data packets received from another PE are
 received over a single emulated LAN, it is not necessary to have any
 special procedures to determine a packet's incoming interface.  The
 ambiguities described in Sections 2.1 and 2.2 do not occur, because a
 VPN-R VRF can only receive multicast data traffic that has been
 requested by a VPN-R VRF.

Rekhter, et al. Standards Track [Page 45] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

7. When BGP Is the PE-PE C-Multicast Control Plane

 This document assumes that if BGP is used as the PE-PE C-multicast
 control plane, the "single PMSI per C-flow" model is used.
 Procedures for providing the "multiple PMSIs per C-flow" model with
 BGP C-multicast are outside the scope of this document.
 When BGP is used as the C-multicast control plane, the "single PMSI
 per C-flow" model may be used either with or without extranet
 separation.  (Recall that "extranet separation" means that no
 P-tunnel can carry traffic from both extranet sources and
 non-extranet sources.)  In either case, the data traffic may be
 carried on Inclusive Tunnels only, Selective Tunnels only (known as
 the "S-PMSI only" model), or a combination of Inclusive Tunnels and
 Selective Tunnels.  This is determined by provisioning.  The
 procedures specified below support all three choices.
 Note that there are no special extranet procedures for Inter-AS
 I-PMSI A-D routes or for Leaf A-D routes.

7.1. Originating C-Multicast Routes

 This section applies whether extranet separation is used or not.
 When it is necessary to originate a C-multicast Source Tree Join for
 (C-S,C-G), a PE must follow the procedures of Section 11.1.3
 ("Constructing the Rest of the C-Multicast Route") of [RFC6514] to
 find the selected UMH route for C-S.  When it is necessary to
 originate a C-multicast Shared Tree Join for (C-*,C-G), where C-G is
 an ASM group, a PE must follow the procedures of that section to find
 the selected UMH route for C-G's C-RP.
 Section 11.1.3 of [RFC6514] specifies how information from the
 selected UMH route is used to find an Intra-AS I-PMSI A-D route or an
 Inter-AS I-PMSI A-D route.  Information from that I-PMSI A-D route is
 then used to construct part of the C-multicast route.
 For extranets, the rules given in Section 7.4.5 of this document are
 used to find the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D
 route that "corresponds" to the selected UMH route; the rules in
 Section 7.4.5 replace the rules given in Section 11.1.3 of [RFC6514]
 for finding the Inter-AS or Intra-AS I-PMSI A-D route.
 Information from this I-PMSI A-D route is then used, as specified in
 Section 11.1.3 of [RFC6514], to construct the C-multicast route.

Rekhter, et al. Standards Track [Page 46] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

7.2. Originating A-D Routes without Extranet Separation

7.2.1. Intra-AS I-PMSI A-D Routes

 Consider a VRF (call it "VRF-S") that contains extranet C-sources and
 exports UMH-eligible routes matching those C-sources.  The VRF may
 also originate and export an Intra-AS I-PMSI A-D route.
 As specified in [RFC6514], if exactly one Intra-AS I-PMSI A-D route
 is originated by and exported from VRF-S, the RTs carried by that
 route MUST be chosen such that every VRF that imports a UMH-eligible
 route from VRF-S also imports this Intra-AS I-PMSI A-D route.
 If inclusive P-tunnels are being used to carry extranet C-flows,
 there are additional requirements on the way the RTs carried by the
 Intra-AS I-PMSI A-D routes must be chosen, as specified in the
 following paragraph.
 If VRF-S is using inclusive P-tunnels but is not using extranet
 separation, there is one inclusive P-tunnel rooted at VRF-S, and this
 tunnel carries both extranet and non-extranet C-flows.  This
 Inclusive Tunnel is identified in the PTA of the Intra-AS I-PMSI A-D
 route originated from VRF-S.  The set of RTs carried by this Intra-AS
 I-PMSI A-D route MUST be chosen so as to ensure that every VRF that
 imports a UMH-eligible route from this VRF-S also imports this
 Intra-AS I-PMSI A-D route.  Further, the set of RTs carried by this
 Intra-AS I-PMSI A-D route MUST be chosen such that it has at least
 one RT in common with every UMH-eligible route that is exported from
 the VRF.

7.2.2. S-PMSI A-D Routes

 Let R-SP be an S-PMSI A-D route that is exported from VRF-S.  Suppose
 that R-SP is used to bind some or all of the extranet C-flows from a
 given extranet C-source to a given selective P-tunnel.  Let R-UMH be
 a UMH-eligible route that is exported from VRF-S and matches the
 given extranet C-source.  In that case, R-SP and R-UMH MUST have at
 least one RT in common.  Further, the RTs carried by these two routes
 MUST be such that every VRF that imports R-UMH also imports R-SP.
 These rules apply whether or not R-SP uses wildcards [RFC6625].

Rekhter, et al. Standards Track [Page 47] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 An implementation MUST allow the set of RTs carried by the S-PMSI A-D
 routes to be specified by configuration.  In the absence of such
 configuration, an S-PMSI A-D route originated by a given VRF, say
 VRF-X, MUST carry a default set of RTs, as specified by the following
 rules:
 1.  By default, an S-PMSI A-D route originated by VRF-X for a given
     (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the UMH-eligible
     route originated by VRF-X that matches C-S.
 2.  By default, an S-PMSI A-D route originated by VRF-X for a given
     (C-*,C-G) carries as its RTs a set union of all RT(s) of the
     UMH-eligible route(s) matching the multicast C-sources contained
     in VRF-X that could originate traffic for that C-G.  Moreover, if
     the VRF contains (as defined in Section 1.1) the C-RP of C-G,
     then this set union also includes the RT(s) of the UMH-eligible
     route matching C-RP and the RT(s) of the unicast VPN-IP route
     matching C-RP.
 3.  By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X
     is to be used for both extranet and non-extranet traffic, it
     carries the same RTs that would be carried (as specified in
     Section 7.2.1) by an I-PMSI A-D route originated by VRF-X if that
     I-PMSI A-D route were advertising an inclusive P-tunnel for
     carrying both extranet and non-extranet traffic.  In general, a
     given VRF would not originate both (a) an S-PMSI A-D route
     advertising a (C-*,C-*) selective P-tunnel for both extranet and
     non-extranet traffic and (b) an I-PMSI A-D route advertising an
     inclusive P-tunnel for both extranet and non-extranet traffic, as
     the inclusive P-tunnel would not get used in that case.

7.2.3. Source Active A-D Routes

7.2.3.1. When Inter-Site Shared Trees Are Used

 This section applies when inter-site shared trees are used, as
 specified in Section 13 of [RFC6514].
 If VRF-S exports a Source Active A-D route that contains C-S in the
 Multicast Source field of its NLRI and VRF-S also exports a
 UMH-eligible route matching C-S, the Source Active A-D route MUST
 carry at least one RT in common with the UMH-eligible route.  The RT
 MUST be chosen such that the following condition holds: if a VRF, say
 VRF-R, contains an extranet C-receiver allowed by policy to receive
 extranet traffic from C-S, then VRF-R imports both the UMH-eligible
 route and the Source Active A-D route.

Rekhter, et al. Standards Track [Page 48] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 By default, a Source Active A-D route for a given (C-S,C-G), exported
 by a given VRF, carries the same set of RTs as the UMH-eligible route
 matching C-S that is exported from that VRF.

7.2.3.2. When Inter-Site Shared Trees Are Not Used

 This section applies when inter-site shared trees are not used, as
 specified in Section 14 of [RFC6514].
 Suppose that a VRF, say VRF-X, contains the C-RP for a given extranet
 C-group, say C-G.  If C-S is an active source for C-G, then,
 following the procedures of Section 14.1 of [RFC6514], VRF-X may
 export a Source Active A-D route that contains C-S in the Multicast
 Source field of its NLRI.  With the following text, this document
 replaces the rule specified in Section 14.1 of [RFC6514] for
 constructing the RT(s) carried by such a route: VRF-X MUST be
 configured such that the Source Active A-D route for (C-S,C-G)
 carries the same set of RTs as the UMH-eligible route matching C-S
 that is exported from the VRF(s) containing C-S.  This way, if a VRF,
 say VRF-R, contains an extranet C-receiver allowed by policy to
 receive extranet traffic from C-S, then VRF-R imports both the
 UMH-eligible route and the Source Active A-D route.

7.3. Originating A-D Routes with Extranet Separation

 If a VRF contains both extranet C-sources and non-extranet C-sources,
 it MUST be configured with both a default RD and an extranet RD (see
 Section 1.3).  The use of these RDs is explained in the following
 subsections.

7.3.1. Intra-AS I-PMSI A-D Routes

 This section applies when VRF-S is using extranet separation AND when
 VRF-S is using an inclusive P-tunnel to carry some or all of the
 extranet C-flows that it needs to transmit to other VRFs.
 If VRF-S contains both extranet C-sources and non-extranet C-sources,
 and inclusive P-tunnels are used to carry both extranet C-flows and
 non-extranet C-flows, then there MUST be two Inclusive Tunnels from
 VRF-S, one of which is to be used only to carry extranet C-flows (the
 "extranet inclusive P-tunnel") and one of which is to be used only to
 carry non-extranet C-flows (the "non-extranet inclusive P-tunnel").

Rekhter, et al. Standards Track [Page 49] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes.
 Their respective NLRIs MUST of course have different RDs.  One of the
 Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel
 in its PTA.  This route MUST have the VRF's extranet RD in its NLRI.
 The other route identifies the non-extranet inclusive P-tunnel in its
 PTA.  This route MUST have the VRF's default RD in its PTA.
 If VRF-S uses an inclusive P-tunnel for carrying extranet traffic but
 does not use an inclusive P-tunnel for carrying non-extranet traffic,
 then of course only a single Intra-AS I-PMSI A-D route need be
 originated.  The PTA of this route identifies the "extranet inclusive
 P-tunnel".  The NLRI of that route MUST contain the VRF's
 extranet RD.
 An Intra-AS I-PMSI A-D route whose PTA identifies an extranet
 inclusive P-tunnel MUST carry the Extranet Separation Extended
 Community defined in Section 4.5.
 The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies
 the "extranet inclusive P-tunnel" MUST be chosen such that the
 following condition holds: if a VRF (call it "VRF-R") imports a
 UMH-eligible route from VRF-S and that route matches an extranet
 C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route.
 Note that when extranet separation is used, it is possible to use an
 inclusive P-tunnel for non-extranet traffic while using only
 selective P-tunnels for extranet traffic.  It is also possible to use
 an inclusive P-tunnel for extranet traffic while using only selective
 P-tunnels for non-extranet traffic.

7.3.2. S-PMSI A-D Routes

 Let R-SP be an S-PMSI A-D route that is exported from VRF-S.  Suppose
 that R-SP is used to bind some or all of the extranet C-flows from a
 given extranet C-source to a given selective P-tunnel.  Let R-UMH be
 a UMH-eligible route that is exported from VRF-S and matches the
 given extranet C-source.  In that case, R-SP and R-UMH MUST have at
 least one RT in common.  Further, the RTs carried by these two routes
 MUST be such that every VRF that imports R-UMH also imports R-SP.
 These rules apply whether or not R-SP uses wildcards [RFC6625].

Rekhter, et al. Standards Track [Page 50] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 The following rules, specific to the use of extranet separation,
 apply:
 o  A selective P-tunnel MUST NOT carry C-flows from both extranet and
    non-extranet C-sources.
 o  If it is desired to use a (C-*,C-*) S-PMSI to carry extranet
    traffic and also use a (C-*,C-*) S-PMSI to carry non-extranet
    traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated.
    These two routes MUST have different RDs in their respective NLRI
    fields, and their respective PTAs MUST identify different
    P-tunnels.  If the route advertises a P-tunnel that carries only
    non-extranet traffic, the route's NLRI MUST contain the VRF's
    default RD.  If the route advertises a P-tunnel that carries only
    extranet traffic, the route's NLRI MUST contain the VRF's
    extranet RD.
 o  In the following cases, an S-PMSI A-D route exported from the VRF
    MUST have the VRF's extranet RD in its NLRI:
  • The S-PMSI A-D route is a (C-S,C-G) or a (C-S,C-*) S-PMSI A-D

route, and C-S is an extranet C-source.

  • The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G

is an extranet C-group.

    In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI
    A-D route MUST have the VRF's default RD in its NLRI.
 o  A (C-*,C-*) S-PMSI A-D route advertising a P-tunnel that is used
    to carry extranet traffic MUST carry the Extranet Separation
    Extended Community defined in Section 4.5.
 An implementation MUST allow the set of RTs carried by the S-PMSI A-D
 routes to be specified by configuration.  In the absence of such
 configuration, an S-PMSI A-D route originated by a given VRF, say
 VRF-X, MUST carry a default set of RTs, as specified by the following
 rules:
 1.  Rule 1 of Section 7.2.2 applies.
 2.  By default, if C-G is an extranet C-group, rule 2 of
     Section 7.2.2 applies.
 3.  By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X
     is to be used for extranet traffic, it carries the same RTs that
     would be carried (as specified in Section 7.3.1) by an I-PMSI A-D
     route originated by VRF-X if that I-PMSI A-D route were

Rekhter, et al. Standards Track [Page 51] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

     advertising an inclusive P-tunnel for carrying extranet traffic.
     In general, a given VRF would not originate both an S-PMSI A-D
     route advertising a (C-*,C-*) selective P-tunnel for extranet
     traffic and an I-PMSI A-D route advertising an inclusive P-tunnel
     for extranet traffic, as the inclusive P-tunnel would not get
     used in that case.

7.3.3. Source Active A-D Routes

 The procedures of Section 7.2.3 apply.
 However, if a Source Active A-D route is exported from a given VRF
 and the route contains C-S, where C-S is an extranet C-source, then
 the RD of the route's NLRI MUST be the extranet RD of the VRF.
 Otherwise, the RD is the default RD of the VRF.

7.4. Determining the Expected P-Tunnel for a C-Flow

 This section applies whether extranet separation is used or not.
 In the context of a VRF with receivers for a particular C-flow, a PE
 must determine the P-tunnel over which packets of that C-flow are
 expected to arrive.  This is done by finding an I-PMSI or S-PMSI A-D
 route that "matches" the flow.  The matching A-D route will contain a
 PTA that specifies the P-tunnel being used to carry the traffic of
 that C-flow.  We will refer to this P-tunnel as the "expected
 P-tunnel" for the C-flow.  (Note that, per [MVPN-IR], if the PTA
 specifies a tunnel of type "Ingress Replication" (IR), the identifier
 of the P-tunnel is actually the NLRI of the I-PMSI or S-PMSI A-D
 route.  If the PTA specifies a tunnel type other than IR, the
 identifier of the P-tunnel is found in the Tunnel Identifier field of
 the PTA.)
 A PE that needs to receive a given (C-S,C-G) or (C-*,C-G) C-flow MUST
 join the expected P-tunnel for that C-flow, and the PE MUST remain
 joined to the P-tunnel as long as (1) the PE continues to need to
 receive the given C-flow and (2) the P-tunnel continues to remain the
 expected P-tunnel for that C-flow.  Procedures for joining and
 leaving a tunnel depend, of course, on the tunnel type.
 If a PTA specifies a non-zero MPLS label for a tunnel that is not an
 IR tunnel, then the PE originating the A-D route containing that PTA
 is advertising an aggregate P-tunnel.  The aggregate P-tunnel can be
 thought of as an outer P-tunnel multiplexing some number of inner
 P-tunnels.  The inner P-tunnels are demultiplexed by means of the
 MPLS label in the PTA.  In this document, when we talk of the
 "expected P-tunnel" in the context of an aggregate P-tunnel, we refer

Rekhter, et al. Standards Track [Page 52] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 to a particular inner P-tunnel, not to the outer P-tunnel.  It is
 this "inner P-tunnel" that is the expected P-tunnel for a given
 C-flow.
 In order to find the expected P-tunnel for a given C-flow, the
 upstream PE of the C-flow is first determined.  Then, the S-PMSI A-D
 routes originated by that PE are examined, and their NLRIs compared
 to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for
 reception".  (If there is no S-PMSI A-D route that matches a given
 C-flow, the expected P-tunnel for that C-flow may have been
 advertised in an I-PMSI A-D route; see Section 7.4.5.)
 The rules for determining, in non-extranet cases, whether a given
 C-flow is a "match for reception" for a given S-PMSI A-D route are
 given in Section 3.2 of [RFC6625].  Note that we use the terms
 "installed" and "originated" as they are defined in Section 3.2 of
 [RFC6625].  (See also Section 1.1 of this document.)
 This specification provides additional rules for determining whether
 a given S-PMSI A-D route is a "match for reception" for a given
 (C-S/C-RP,C-G).  Note that these rules all assume the context of a
 particular VRF into which the A-D route has been imported.
 The rules given in [RFC6625] for determining whether a given S-PMSI
 A-D route is a "match for transmission" remain unchanged.
 Suppose that a PE has originated a C-multicast Shared Tree Join for
 (C-*,C-G) but has not originated a C-multicast Source Tree Join for
 (C-S,C-G).  Suppose also that the PE has received and installed a
 Source Active A-D route for (C-S,C-G).  As described in Section 13.2
 of [RFC6514], the PE must receive the (C-S,C-G) traffic from the
 tunnel the originator of the installed Source Active A-D route uses
 for sending (C-S,C-G).
 The originator of the installed Source Active A-D route is determined
 as follows:
 1.  Look at the "UMH Route Candidate Set" for C-S, as defined in
     Section 5.1.3 of [RFC6513].
 2.  From that set, select a subset of UMH routes to C-S, such that
     each route in the subset has at least one RT in common with the
     Source Active A-D route and at least one of the RTs in common is
     an import RT of the VRF.
 3.  From that subset, find the route whose RD is the same as the RD
     from the NLRI of the Source Active A-D route.

Rekhter, et al. Standards Track [Page 53] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 4.  The upstream PE is the PE identified in the VRF Route Import
     Extended Community of that route.
 5.  The upstream AS is the AS identified in the Source AS Extended
     Community of that route.
 If step 2 results in an empty set or step 3 fails to find a route,
 then the upstream PE of the Source Active A-D route cannot be
 determined, and it is necessary to act as if the Source Active A-D
 route had not been installed.  (A subsequent change to the UMH Route
 Candidate Set for C-S may require that a new attempt be made to
 determine the upstream PE.)
 Once the upstream PE is determined, the P-tunnel over which the flow
 is expected is determined according to the procedures already
 described in this section.

7.4.1. (C-S,C-G) S-PMSI A-D Routes

 When extranet functionality is being provided, an S-PMSI A-D route
 whose NLRI contains (C-S,C-G) is NOT considered to be a "match for
 reception" for a given C-flow (C-S,C-G) unless one of the following
 conditions holds (in addition to the conditions specified in
 [RFC6625]):
 o  the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is
    provisioned, or
 o  the selected UMH route for C-S has at least one RT in common with
    the S-PMSI A-D route, and at least one of the common RTs is an
    import RT of the VRF.

7.4.2. (C-S,C-*) S-PMSI A-D Routes

 When extranet functionality is being provided, an S-PMSI A-D route
 whose NLRI contains (C-S,C-*) is NOT considered to be a "match for
 reception" for a given C-flow (C-S,C-G) unless one of the following
 conditions holds (in addition to the conditions specified in
 [RFC6625]):
 o  the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is
    provisioned, or
 o  the selected UMH route for C-S has at least one RT in common with
    the S-PMSI A-D route, and at least one of the common RTs is an
    import RT of the VRF.

Rekhter, et al. Standards Track [Page 54] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

7.4.3. (C-*,C-G) S-PMSI A-D Routes

 When extranet functionality is being provided, an S-PMSI A-D route
 whose NLRI contains (C-*,C-G) is NOT considered to be a "match for
 reception" for a given C-flow (C-S,C-G) in a given VRF unless either
 condition 1 or condition 2 below holds (in addition to the conditions
 specified in [RFC6625]):
 1.  The given VRF has currently originated a C-multicast Shared Tree
     Join route for (C-*,C-G), and
     a.  (C-*,C-G) matches an installed (C-*,C-G) S-PMSI A-D route
         (according to [RFC6625]) in the given VRF, and
     b.  either
         i.     the "single C-group per (C-*,C-G) P-tunnel" policy has
                been provisioned, or
         ii.    the RTs of that S-PMSI A-D route form a non-empty
                intersection with the RTs carried in the VRF's
                selected UMH route for C-RP of that C-G, or
         iii.   installed in the VRF is at least one (C-S,C-G) Source
                Active A-D route that was originated by the same PE as
                the (C-*,C-G) S-PMSI A-D route.
 2.  The given VRF does not have a currently originated C-multicast
     Shared Tree Join for (C-*,C-G), but
     a.  there are one or more values for C-S for which the VRF has a
         currently originated Source Tree Join C-multicast route for
         (C-S,C-G), and
     b.  the (C-* C-G) S-PMSI A-D route matches (according to
         [RFC6625]) each such (C-S,C-G), and
     c.  either
         i.    the "single C-group per (C-*,C-G) P-tunnel" policy has
               been provisioned, or
         ii.   the RTs of that S-PMSI A-D route form a non-empty
               intersection with the RTs carried in the VRF's selected
               UMH routes for each such C-S

Rekhter, et al. Standards Track [Page 55] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

     If a VRF has an installed (C-*,C-G) S-PMSI A-D route but does not
     have a (C-S,C-G) or (C-*,C-G) multicast state that matches that
     route for reception, the procedures of Section 12.3 ("Receiving
     S-PMSI A-D Routes by PEs") of [RFC6514] are not invoked for that
     route.  If those multicast states are created at some later time
     when the route is still installed, the procedures of Section 12.3
     of [RFC6514] are invoked at that time.

7.4.4. (C-*,C-*) S-PMSI A-D Routes

 A (C-*,C-*) S-PMSI A-D route (call it "R-AD") is NOT considered to be
 a "match for reception" for a given C-flow (C-S,C-G) or (C-*,C-G)
 unless the following conditions hold (in addition to the conditions
 specified in [RFC6625]):
 o  The selected UMH route (call it "R-UMH") for C-S or for C-G's
    C-RP, respectively, has at least one RT in common with R-AD, and
    at least one of the common RTs is an import RT of the VRF.
 o  Either R-AD and R-UMH both carry the Extranet Separation Extended
    Community or neither carries the Extranet Separation Extended
    Community.

7.4.5. I-PMSI A-D Routes

 If a particular egress VRF in a particular egress PE contains no
 matching S-PMSI A-D routes for a particular C-flow, then the C-flow
 is expected to arrive (at that egress VRF) on an inclusive P-tunnel.
 Suppose that an egress PE has originated a (C-S,C-G) C-multicast
 Source Tree Join.  Let R-UMH be the selected UMH route (in the given
 egress VRF) for C-S.  As specified in [RFC6514], the selected
 upstream PE for (C-S,C-G) is determined from the VRF Route Import
 Extended Community of R-UMH, and the "selected upstream AS" for the
 flow is determined from the Source AS Extended Community of R-UMH.
 Suppose that an egress PE has originated a (C-*,C-G) C-multicast
 Shared Tree Join but has not originated a (C-S,C-G) C-multicast
 Source Tree Join.  If the egress VRF does not have a (C-S,C-G) Source
 Active A-D route installed, the selected upstream PE is determined
 from the VRF Route Import Extended Community of the installed
 UMH-eligible route matching C-RP, where C-RP is the RP for the group
 C-G.  The selected upstream AS for the flow is determined from the
 Source AS Extended Community of that route.  If the egress VRF does
 have a (C-S,C-G) Source Active A-D route installed, the selected
 upstream PE and upstream AS are determined as specified in
 Section 7.4.  In either case, let R-UMH be the installed UMH-eligible
 route matching C-S.

Rekhter, et al. Standards Track [Page 56] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 The inclusive P-tunnel that is expected to be carrying a particular
 C-flow is found as follows:
 o  If the selected upstream AS is the local AS or segmented Inter-AS
    P-tunnels are not being used to instantiate I-PMSIs, then look in
    the VRF for an installed Intra-AS I-PMSI A-D route, R-AD, such
    that (a) R-AD is originated by the selected upstream PE, (b) R-AD
    has at least one RT in common with R-UMH, (c) at least one of the
    common RTs is an import RT of the local VRF, and (d) either R-AD
    and R-UMH both carry the Extranet Separation Extended Community or
    neither carries the Extranet Separation Extended Community.
    The PTA of R-AD specifies the P-tunnel over which the traffic of
    the given C-flow is expected.
 o  If the selected upstream AS is not the local AS and segmented
    Inter-AS P-tunnels are being used to instantiate I-PMSIs, then
    look in the VRF for an installed Inter-AS I-PMSI A-D route, R-AD,
    such that (a) the Source AS field of R-AD's NLRI contains the AS
    number of the selected upstream AS, (b) R-AD has at least one RT
    in common with R-UMH, (c) at least one of the common RTs is an
    import RT of the local VRF, and (d) either R-AD and R-UMH both
    carry the Extranet Separation Extended Community or neither
    carries the Extranet Separation Extended Community.
    The PTA of R-AD specifies the P-tunnel over which the traffic of
    the given C-flow is expected.

7.5. Packets Arriving from the Wrong P-Tunnel

 Any packets that arrive on a P-tunnel other than the expected
 P-tunnel (as defined in Section 7.4) MUST be discarded unless it is
 known that all the packets carried by both P-tunnels are from the
 same ingress VRF.  (See Section 2.3.1 for a more detailed discussion
 of when to discard packets from other than the expected P-tunnel.)
 Note that packets arriving on the wrong P-tunnel are to be discarded
 even if they are arriving from the expected PE.

8. Multiple Extranet VRFs on the Same PE

 When multiple VRFs that contain extranet receivers for a given
 extranet source are present on the same PE, this PE becomes a single
 leaf of the P-tunnel used for sending (multicast) traffic from that
 source to these extranet receivers.  The PE MUST be able to replicate
 this traffic to the multiple VRFs.  Specific procedures for doing so
 are local to the PE and are outside the scope of this document.

Rekhter, et al. Standards Track [Page 57] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 Two or more VRFs on the same PE may import the same S-PMSI A-D route.
 If this S-PMSI A-D route contains a PTA that has its "Leaf
 Information Required" flag set, it may be necessary for the PE to
 originate a Leaf A-D route whose NLRI is computed from the NLRI of
 the S-PMSI A-D route.  (Details are provided in [RFC6514].)  Note
 that for a given S-PMSI A-D route, the PE can originate only one
 corresponding Leaf A-D route, even if the S-PMSI A-D route is
 imported into multiple VRFs.  This Leaf A-D route can thus be thought
 of as originating from several VRFs.  It MUST NOT be withdrawn by the
 PE until there are no longer any VRFs originating it.
 [RFC6514] specifies conditions under which a PE originates a
 C-multicast Source Tree Join or a C-multicast Shared Tree Join, based
 on the (*,G) and (S,G) states associated with a given VRF.  It also
 specifies the procedure for computing the NLRI of each such route.
 While a given PE may contain two or more VRFs that have (extranet)
 receivers for the same extranet C-flow, the PE cannot originate more
 than one BGP route with a given NLRI.  If there are multiple VRFs,
 each of which has state that is sufficient to cause a given
 C-multicast route to be originated, the route can be thought of as
 originating from several VRFs.  It MUST NOT be withdrawn by the PE
 until there is no longer any VRF with multicast state sufficient to
 cause the route to be originated.
 For a given extranet, the site(s) that contains the extranet
 source(s) and the site(s) that contains the extranet receiver(s) may
 be connected to the same PE.  In this scenario, the procedures by
 which (multicast) traffic from these sources is delivered to these
 receivers are local to the PE and are outside the scope of this
 document.
 An implementation MUST support multiple extranet VRFs on a PE.

9. IANA Considerations

 IANA has allocated two new codepoints from the "First Come First
 Served" [RFC5226] range of the "Transitive Opaque Extended Community
 Sub-Types" registry (under the top-level registry "Border Gateway
 Protocol (BGP) Extended Communities" registry).
 o  Extranet Source Extended Community (0x04)
 o  Extranet Separation Extended Community (0x05)

Rekhter, et al. Standards Track [Page 58] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

10. Security Considerations

 The security considerations of [RFC6513] and [RFC6514] are
 applicable.
 As is the case with any application of technology based upon
 [RFC4364], misconfiguration of the RTs may result in VPN security
 violations (i.e., may result in a packet being delivered to a VPN
 where, according to policy, it is not supposed to go).
 In those cases where the set of extranet sources of a particular VRF
 are manually configured, improper configuration of the VRF can result
 in VPN security violations -- traffic from a host that is not an
 extranet source may be treated as if it were traffic from an extranet
 source.
 Section 4.4 specifies the optional use of a new Extended Community --
 the Extranet Source Extended Community.  Security considerations
 regarding the use and distribution of that Extended Community are
 discussed in that section.
 The procedures of this document do not provide encryption of the data
 flows that are sent across the SP backbone network.  Hence, these
 procedures do not by themselves ensure the privacy or integrity of
 the data against attacks on the backbone network.
 In general, different VPNs are allowed to have overlapping IP address
 spaces; i.e., a host in one VPN may have the same IP address as a
 host in another.  This is safe because the customer routes from a
 given VPN do not pass into other VPNs.  Even if there are overlapping
 address spaces among VPNs, the routes that are known at any given VPN
 site are unambiguous, as long as the address space of that VPN is
 unambiguous.  However, this is not necessarily true when extranet
 service is provided.  If an extranet C-receiver in VPN-R is to be
 able to receive multicast traffic from an extranet C-source in VPN-S,
 then the address of the VPN-S extranet C-source must be imported into
 one or more VPN-R VRFs.  If that address is also the address of a
 VPN-R non-extranet C-source, then a system attempting to receive an
 extranet C-flow from the VPN-R extranet C-source may instead receive
 a non-extranet C-flow from the VPN-S C-source.  Otherwise, a VPN
 security violation may result.
 That is, when provisioning an extranet between two VPNs that have
 overlapping address spaces, one must ensure that the IP addresses of
 the extranet sources and the extranet receivers are not from the
 overlapping part of the address space.  This document specifies that
 if a route is imported into a given VRF, all addresses that match
 that route must be unambiguous in the context of that VRF.  Improper

Rekhter, et al. Standards Track [Page 59] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 provisioning of the extranet source addresses or improper
 provisioning of the RTs may cause this rule to be violated and may
 result in a VPN security violation.
 It is possible that a given multicast C-source is the source of
 multiple flows, some of which are intended to be extranet C-flows and
 some of which are intended to be non-extranet flows.  However, the
 procedures of this document will allow any C-receiver that is able to
 receive the extranet C-flows from a given C-source to also receive
 the non-extranet C-flows from that source.  As a result, VPN security
 violations may result if any system is a C-source for both extranet
 and non-extranet C-flows.  However, the set of C-flows transmitted by
 a given C-source is not under the control of the SP.  SPs who offer
 the extranet MVPN service must make sure that this potential for VPN
 security violations is clearly understood by the customers who
 administer the C-sources.
 This specification does not require that UMH-eligible routes be "host
 routes"; they may be less specific routes.  So, it is possible for
 the NLRI of a UMH-eligible route to contain an address prefix that
 matches the address of both an extranet C-source and a non-extranet
 C-source.  If such a route is exported from a VPN-S VRF and imported
 by a VPN-R VRF, C-receivers contained in VPN-R will be able to
 receive C-flows from the non-extranet C-sources whose addresses match
 that route.  This may result in VPN security violations.  Service
 providers who offer the extranet MVPN service must make sure that
 this is clearly understood by the customers who administer the
 distribution of routes from CE routers to PE routers.
 If the address ambiguities described in Sections 2.1 and 2.2 are not
 prohibited by deployment of the policies described in Section 2.3.2,
 VRFs must be able to discard traffic that arrives on the wrong
 P-tunnel (as specified in Sections 2.3.1 and 7.5).  Otherwise, VPN
 security violations may occur.

Rekhter, et al. Standards Track [Page 60] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
            Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
            February 2006, <http://www.rfc-editor.org/info/rfc4360>.
 [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
            Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364,
            February 2006, <http://www.rfc-editor.org/info/rfc4364>.
 [RFC6513]  Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
            MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513,
            February 2012, <http://www.rfc-editor.org/info/rfc6513>.
 [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
            Encodings and Procedures for Multicast in MPLS/BGP IP
            VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
            <http://www.rfc-editor.org/info/rfc6514>.
 [RFC6625]  Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
            Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
            RFC 6625, DOI 10.17487/RFC6625, May 2012,
            <http://www.rfc-editor.org/info/rfc6625>.
 [RFC7153]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP
            Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
            March 2014, <http://www.rfc-editor.org/info/rfc7153>.
 [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
            Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
            Multicast - Sparse Mode (PIM-SM): Protocol Specification
            (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761,
            March 2016, <http://www.rfc-editor.org/info/rfc7761>.

Rekhter, et al. Standards Track [Page 61] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

11.2. Informative References

 [MVPN-IR]  Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
            Replication Tunnels in Multicast VPN", Work in Progress,
            draft-ietf-bess-ir-03, April 2016.
 [RFC3446]  Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
            Rendevous Point (RP) mechanism using Protocol Independent
            Multicast (PIM) and Multicast Source Discovery Protocol
            (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003,
            <http://www.rfc-editor.org/info/rfc3446>.
 [RFC3618]  Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
            Discovery Protocol (MSDP)", RFC 3618,
            DOI 10.17487/RFC3618, October 2003,
            <http://www.rfc-editor.org/info/rfc3618>.
 [RFC4610]  Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
            Independent Multicast (PIM)", RFC 4610,
            DOI 10.17487/RFC4610, August 2006,
            <http://www.rfc-editor.org/info/rfc4610>.
 [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,
            DOI 10.17487/RFC4875, May 2007,
            <http://www.rfc-editor.org/info/rfc4875>.
 [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
            "Bidirectional Protocol Independent Multicast
            (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015,
            October 2007, <http://www.rfc-editor.org/info/rfc5015>.
 [RFC5059]  Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
            "Bootstrap Router (BSR) Mechanism for Protocol Independent
            Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059,
            January 2008, <http://www.rfc-editor.org/info/rfc5059>.

Rekhter, et al. Standards Track [Page 62] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            DOI 10.17487/RFC5226, May 2008,
            <http://www.rfc-editor.org/info/rfc5226>.
 [RFC6388]  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, DOI 10.17487/RFC6388, November 2011,
            <http://www.rfc-editor.org/info/rfc6388>.

Rekhter, et al. Standards Track [Page 63] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

Acknowledgments

 The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini
 Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt
 Windisch for their contributions to this work.
 We also wish to thank Lizhong Jin and Rishabh Parekh for their
 reviews and comments.
 Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and
 for providing the ASCII art appearing in Section 2.

Contributors

 Below is a list of other contributing authors, in alphabetical order:
 Wim Henderickx
 Nokia
 Copernicuslaan 50
 Antwerp  2018
 Belgium
 Email: wim.henderickx@nokia.com
 Praveen Muley
 Nokia
 Email: Praveen.Muley@nokia.com
 Ray Qiu
 Juniper Networks, Inc.
 1194 North Mathilda Avenue
 Sunnyvale, CA  94089
 United States
 Email: rqiu@juniper.net
 IJsbrand Wijnands
 Cisco Systems, Inc.
 De Kleetlaan 6a
 Diegem  1831
 Belgium
 Email: ice@cisco.com

Rekhter, et al. Standards Track [Page 64] RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016

Authors' Addresses

 Yakov Rekhter (editor)
 Juniper Networks, Inc.
 1194 North Mathilda Avenue
 Sunnyvale, CA  94089
 United States
 Eric C. Rosen (editor)
 Juniper Networks, Inc.
 10 Technology Park Drive
 Westford, Massachusetts  01886
 United States
 Email: erosen@juniper.net
 Rahul Aggarwal
 Arktan
 Email: raggarwa_1@yahoo.com
 Yiqun Cai
 Alibaba Group
 400 S El Camino Real #400
 San Mateo, CA  94402
 United States
 Email: yiqun.cai@alibaba-inc.com
 Thomas Morin
 Orange
 2 Avenue Pierre-Marzin
 22307 Lannion Cedex
 France
 Email: thomas.morin@orange.com

Rekhter, et al. Standards Track [Page 65]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7900.txt · Last modified: 2016/06/21 23:44 (external edit)