Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7900

Extranet Multicast in BGP/IP MPLS VPNs

Pages: 65
Proposed Standard
Updates:  651365146625
Updated by:  8534
Part 2 of 3 – Pages 21 to 45
First   Prev   Next

Top   ToC   RFC7900 - Page 21   prevText

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

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

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

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).
Top   ToC   RFC7900 - Page 27
   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.
Top   ToC   RFC7900 - Page 28
   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.
Top   ToC   RFC7900 - Page 29

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

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
Top   ToC   RFC7900 - Page 31
   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).
Top   ToC   RFC7900 - Page 32
   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.
Top   ToC   RFC7900 - Page 33
   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.
Top   ToC   RFC7900 - Page 34
   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.
Top   ToC   RFC7900 - Page 35
   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.
Top   ToC   RFC7900 - Page 36
   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.
Top   ToC   RFC7900 - Page 37
   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].
Top   ToC   RFC7900 - Page 38
   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.
Top   ToC   RFC7900 - Page 39
   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
Top   ToC   RFC7900 - Page 40
   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.
Top   ToC   RFC7900 - Page 41
   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.
Top   ToC   RFC7900 - Page 42
   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.
Top   ToC   RFC7900 - Page 43
   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.
Top   ToC   RFC7900 - Page 44
   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.
Top   ToC   RFC7900 - Page 45
   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.


(next page on part 3)

Next Section