tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7900

Proposed STD
Pages: 65
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: BESS

Extranet Multicast in BGP/IP MPLS VPNs

Part 1 of 3, p. 1 to 21
None       Next RFC Part

Updates:    6513    6514    6625


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

[Page 2] 
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

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

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

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

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

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

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

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

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

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

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

Top      ToC       Page 13 
   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.)

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

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

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

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

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

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

Top      ToC       Page 20 
   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

Top      ToC       Page 21 
   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).



(page 21 continued on part 2)

Next RFC Part