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 3 of 3 – Pages 46 to 65
First   Prev   None

Top   ToC   RFC7900 - Page 46   prevText

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

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

7.1. Originating C-Multicast Routes

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

7.2. Originating A-D Routes without Extranet Separation

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

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

7.2.2. S-PMSI A-D Routes

Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose that R-SP is used to bind some or all of the extranet C-flows from a given extranet C-source to a given selective P-tunnel. Let R-UMH be a UMH-eligible route that is exported from VRF-S and matches the given extranet C-source. In that case, R-SP and R-UMH MUST have at least one RT in common. Further, the RTs carried by these two routes MUST be such that every VRF that imports R-UMH also imports R-SP. These rules apply whether or not R-SP uses wildcards [RFC6625].
Top   ToC   RFC7900 - Page 48
   An implementation MUST allow the set of RTs carried by the S-PMSI A-D
   routes to be specified by configuration.  In the absence of such
   configuration, an S-PMSI A-D route originated by a given VRF, say
   VRF-X, MUST carry a default set of RTs, as specified by the following
   rules:

   1.  By default, an S-PMSI A-D route originated by VRF-X for a given
       (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the UMH-eligible
       route originated by VRF-X that matches C-S.

   2.  By default, an S-PMSI A-D route originated by VRF-X for a given
       (C-*,C-G) carries as its RTs a set union of all RT(s) of the
       UMH-eligible route(s) matching the multicast C-sources contained
       in VRF-X that could originate traffic for that C-G.  Moreover, if
       the VRF contains (as defined in Section 1.1) the C-RP of C-G,
       then this set union also includes the RT(s) of the UMH-eligible
       route matching C-RP and the RT(s) of the unicast VPN-IP route
       matching C-RP.

   3.  By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X
       is to be used for both extranet and non-extranet traffic, it
       carries the same RTs that would be carried (as specified in
       Section 7.2.1) by an I-PMSI A-D route originated by VRF-X if that
       I-PMSI A-D route were advertising an inclusive P-tunnel for
       carrying both extranet and non-extranet traffic.  In general, a
       given VRF would not originate both (a) an S-PMSI A-D route
       advertising a (C-*,C-*) selective P-tunnel for both extranet and
       non-extranet traffic and (b) an I-PMSI A-D route advertising an
       inclusive P-tunnel for both extranet and non-extranet traffic, as
       the inclusive P-tunnel would not get used in that case.

7.2.3. Source Active A-D Routes

7.2.3.1. When Inter-Site Shared Trees Are Used
This section applies when inter-site shared trees are used, as specified in Section 13 of [RFC6514]. If VRF-S exports a Source Active A-D route that contains C-S in the Multicast Source field of its NLRI and VRF-S also exports a UMH-eligible route matching C-S, the Source Active A-D route MUST carry at least one RT in common with the UMH-eligible route. The RT MUST be chosen such that the following condition holds: if a VRF, say VRF-R, contains an extranet C-receiver allowed by policy to receive extranet traffic from C-S, then VRF-R imports both the UMH-eligible route and the Source Active A-D route.
Top   ToC   RFC7900 - Page 49
   By default, a Source Active A-D route for a given (C-S,C-G), exported
   by a given VRF, carries the same set of RTs as the UMH-eligible route
   matching C-S that is exported from that VRF.

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

7.3. Originating A-D Routes with Extranet Separation

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

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

This section applies when VRF-S is using extranet separation AND when VRF-S is using an inclusive P-tunnel to carry some or all of the extranet C-flows that it needs to transmit to other VRFs. If VRF-S contains both extranet C-sources and non-extranet C-sources, and inclusive P-tunnels are used to carry both extranet C-flows and non-extranet C-flows, then there MUST be two Inclusive Tunnels from VRF-S, one of which is to be used only to carry extranet C-flows (the "extranet inclusive P-tunnel") and one of which is to be used only to carry non-extranet C-flows (the "non-extranet inclusive P-tunnel").
Top   ToC   RFC7900 - Page 50
   In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes.
   Their respective NLRIs MUST of course have different RDs.  One of the
   Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel
   in its PTA.  This route MUST have the VRF's extranet RD in its NLRI.
   The other route identifies the non-extranet inclusive P-tunnel in its
   PTA.  This route MUST have the VRF's default RD in its PTA.

   If VRF-S uses an inclusive P-tunnel for carrying extranet traffic but
   does not use an inclusive P-tunnel for carrying non-extranet traffic,
   then of course only a single Intra-AS I-PMSI A-D route need be
   originated.  The PTA of this route identifies the "extranet inclusive
   P-tunnel".  The NLRI of that route MUST contain the VRF's
   extranet RD.

   An Intra-AS I-PMSI A-D route whose PTA identifies an extranet
   inclusive P-tunnel MUST carry the Extranet Separation Extended
   Community defined in Section 4.5.

   The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies
   the "extranet inclusive P-tunnel" MUST be chosen such that the
   following condition holds: if a VRF (call it "VRF-R") imports a
   UMH-eligible route from VRF-S and that route matches an extranet
   C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route.

   Note that when extranet separation is used, it is possible to use an
   inclusive P-tunnel for non-extranet traffic while using only
   selective P-tunnels for extranet traffic.  It is also possible to use
   an inclusive P-tunnel for extranet traffic while using only selective
   P-tunnels for non-extranet traffic.

7.3.2. S-PMSI A-D Routes

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

   o  A selective P-tunnel MUST NOT carry C-flows from both extranet and
      non-extranet C-sources.

   o  If it is desired to use a (C-*,C-*) S-PMSI to carry extranet
      traffic and also use a (C-*,C-*) S-PMSI to carry non-extranet
      traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated.
      These two routes MUST have different RDs in their respective NLRI
      fields, and their respective PTAs MUST identify different
      P-tunnels.  If the route advertises a P-tunnel that carries only
      non-extranet traffic, the route's NLRI MUST contain the VRF's
      default RD.  If the route advertises a P-tunnel that carries only
      extranet traffic, the route's NLRI MUST contain the VRF's
      extranet RD.

   o  In the following cases, an S-PMSI A-D route exported from the VRF
      MUST have the VRF's extranet RD in its NLRI:

      *  The S-PMSI A-D route is a (C-S,C-G) or a (C-S,C-*) S-PMSI A-D
         route, and C-S is an extranet C-source.

      *  The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G
         is an extranet C-group.

      In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI
      A-D route MUST have the VRF's default RD in its NLRI.

   o  A (C-*,C-*) S-PMSI A-D route advertising a P-tunnel that is used
      to carry extranet traffic MUST carry the Extranet Separation
      Extended Community defined in Section 4.5.

   An implementation MUST allow the set of RTs carried by the S-PMSI A-D
   routes to be specified by configuration.  In the absence of such
   configuration, an S-PMSI A-D route originated by a given VRF, say
   VRF-X, MUST carry a default set of RTs, as specified by the following
   rules:

   1.  Rule 1 of Section 7.2.2 applies.

   2.  By default, if C-G is an extranet C-group, rule 2 of
       Section 7.2.2 applies.

   3.  By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X
       is to be used for extranet traffic, it carries the same RTs that
       would be carried (as specified in Section 7.3.1) by an I-PMSI A-D
       route originated by VRF-X if that I-PMSI A-D route were
Top   ToC   RFC7900 - Page 52
       advertising an inclusive P-tunnel for carrying extranet traffic.
       In general, a given VRF would not originate both an S-PMSI A-D
       route advertising a (C-*,C-*) selective P-tunnel for extranet
       traffic and an I-PMSI A-D route advertising an inclusive P-tunnel
       for extranet traffic, as the inclusive P-tunnel would not get
       used in that case.

7.3.3. Source Active A-D Routes

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

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

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

   In order to find the expected P-tunnel for a given C-flow, the
   upstream PE of the C-flow is first determined.  Then, the S-PMSI A-D
   routes originated by that PE are examined, and their NLRIs compared
   to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for
   reception".  (If there is no S-PMSI A-D route that matches a given
   C-flow, the expected P-tunnel for that C-flow may have been
   advertised in an I-PMSI A-D route; see Section 7.4.5.)

   The rules for determining, in non-extranet cases, whether a given
   C-flow is a "match for reception" for a given S-PMSI A-D route are
   given in Section 3.2 of [RFC6625].  Note that we use the terms
   "installed" and "originated" as they are defined in Section 3.2 of
   [RFC6625].  (See also Section 1.1 of this document.)

   This specification provides additional rules for determining whether
   a given S-PMSI A-D route is a "match for reception" for a given
   (C-S/C-RP,C-G).  Note that these rules all assume the context of a
   particular VRF into which the A-D route has been imported.

   The rules given in [RFC6625] for determining whether a given S-PMSI
   A-D route is a "match for transmission" remain unchanged.

   Suppose that a PE has originated a C-multicast Shared Tree Join for
   (C-*,C-G) but has not originated a C-multicast Source Tree Join for
   (C-S,C-G).  Suppose also that the PE has received and installed a
   Source Active A-D route for (C-S,C-G).  As described in Section 13.2
   of [RFC6514], the PE must receive the (C-S,C-G) traffic from the
   tunnel the originator of the installed Source Active A-D route uses
   for sending (C-S,C-G).

   The originator of the installed Source Active A-D route is determined
   as follows:

   1.  Look at the "UMH Route Candidate Set" for C-S, as defined in
       Section 5.1.3 of [RFC6513].

   2.  From that set, select a subset of UMH routes to C-S, such that
       each route in the subset has at least one RT in common with the
       Source Active A-D route and at least one of the RTs in common is
       an import RT of the VRF.

   3.  From that subset, find the route whose RD is the same as the RD
       from the NLRI of the Source Active A-D route.
Top   ToC   RFC7900 - Page 54
   4.  The upstream PE is the PE identified in the VRF Route Import
       Extended Community of that route.

   5.  The upstream AS is the AS identified in the Source AS Extended
       Community of that route.

   If step 2 results in an empty set or step 3 fails to find a route,
   then the upstream PE of the Source Active A-D route cannot be
   determined, and it is necessary to act as if the Source Active A-D
   route had not been installed.  (A subsequent change to the UMH Route
   Candidate Set for C-S may require that a new attempt be made to
   determine the upstream PE.)

   Once the upstream PE is determined, the P-tunnel over which the flow
   is expected is determined according to the procedures already
   described in this section.

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

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

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

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

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

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

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

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

7.4.5. I-PMSI A-D Routes

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

   o  If the selected upstream AS is the local AS or segmented Inter-AS
      P-tunnels are not being used to instantiate I-PMSIs, then look in
      the VRF for an installed Intra-AS I-PMSI A-D route, R-AD, such
      that (a) R-AD is originated by the selected upstream PE, (b) R-AD
      has at least one RT in common with R-UMH, (c) at least one of the
      common RTs is an import RT of the local VRF, and (d) either R-AD
      and R-UMH both carry the Extranet Separation Extended Community or
      neither carries the Extranet Separation Extended Community.

      The PTA of R-AD specifies the P-tunnel over which the traffic of
      the given C-flow is expected.

   o  If the selected upstream AS is not the local AS and segmented
      Inter-AS P-tunnels are being used to instantiate I-PMSIs, then
      look in the VRF for an installed Inter-AS I-PMSI A-D route, R-AD,
      such that (a) the Source AS field of R-AD's NLRI contains the AS
      number of the selected upstream AS, (b) R-AD has at least one RT
      in common with R-UMH, (c) at least one of the common RTs is an
      import RT of the local VRF, and (d) either R-AD and R-UMH both
      carry the Extranet Separation Extended Community or neither
      carries the Extranet Separation Extended Community.

      The PTA of R-AD specifies the P-tunnel over which the traffic of
      the given C-flow is expected.

7.5. Packets Arriving from the Wrong P-Tunnel

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

8. Multiple Extranet VRFs on the Same PE

When multiple VRFs that contain extranet receivers for a given extranet source are present on the same PE, this PE becomes a single leaf of the P-tunnel used for sending (multicast) traffic from that source to these extranet receivers. The PE MUST be able to replicate this traffic to the multiple VRFs. Specific procedures for doing so are local to the PE and are outside the scope of this document.
Top   ToC   RFC7900 - Page 58
   Two or more VRFs on the same PE may import the same S-PMSI A-D route.
   If this S-PMSI A-D route contains a PTA that has its "Leaf
   Information Required" flag set, it may be necessary for the PE to
   originate a Leaf A-D route whose NLRI is computed from the NLRI of
   the S-PMSI A-D route.  (Details are provided in [RFC6514].)  Note
   that for a given S-PMSI A-D route, the PE can originate only one
   corresponding Leaf A-D route, even if the S-PMSI A-D route is
   imported into multiple VRFs.  This Leaf A-D route can thus be thought
   of as originating from several VRFs.  It MUST NOT be withdrawn by the
   PE until there are no longer any VRFs originating it.

   [RFC6514] specifies conditions under which a PE originates a
   C-multicast Source Tree Join or a C-multicast Shared Tree Join, based
   on the (*,G) and (S,G) states associated with a given VRF.  It also
   specifies the procedure for computing the NLRI of each such route.
   While a given PE may contain two or more VRFs that have (extranet)
   receivers for the same extranet C-flow, the PE cannot originate more
   than one BGP route with a given NLRI.  If there are multiple VRFs,
   each of which has state that is sufficient to cause a given
   C-multicast route to be originated, the route can be thought of as
   originating from several VRFs.  It MUST NOT be withdrawn by the PE
   until there is no longer any VRF with multicast state sufficient to
   cause the route to be originated.

   For a given extranet, the site(s) that contains the extranet
   source(s) and the site(s) that contains the extranet receiver(s) may
   be connected to the same PE.  In this scenario, the procedures by
   which (multicast) traffic from these sources is delivered to these
   receivers are local to the PE and are outside the scope of this
   document.

   An implementation MUST support multiple extranet VRFs on a PE.

9. IANA Considerations

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

10. Security Considerations

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

   It is possible that a given multicast C-source is the source of
   multiple flows, some of which are intended to be extranet C-flows and
   some of which are intended to be non-extranet flows.  However, the
   procedures of this document will allow any C-receiver that is able to
   receive the extranet C-flows from a given C-source to also receive
   the non-extranet C-flows from that source.  As a result, VPN security
   violations may result if any system is a C-source for both extranet
   and non-extranet C-flows.  However, the set of C-flows transmitted by
   a given C-source is not under the control of the SP.  SPs who offer
   the extranet MVPN service must make sure that this potential for VPN
   security violations is clearly understood by the customers who
   administer the C-sources.

   This specification does not require that UMH-eligible routes be "host
   routes"; they may be less specific routes.  So, it is possible for
   the NLRI of a UMH-eligible route to contain an address prefix that
   matches the address of both an extranet C-source and a non-extranet
   C-source.  If such a route is exported from a VPN-S VRF and imported
   by a VPN-R VRF, C-receivers contained in VPN-R will be able to
   receive C-flows from the non-extranet C-sources whose addresses match
   that route.  This may result in VPN security violations.  Service
   providers who offer the extranet MVPN service must make sure that
   this is clearly understood by the customers who administer the
   distribution of routes from CE routers to PE routers.

   If the address ambiguities described in Sections 2.1 and 2.2 are not
   prohibited by deployment of the policies described in Section 2.3.2,
   VRFs must be able to discard traffic that arrives on the wrong
   P-tunnel (as specified in Sections 2.3.1 and 7.5).  Otherwise, VPN
   security violations may occur.
Top   ToC   RFC7900 - Page 61

11. References

11.1. Normative References

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

11.2. Informative References

[MVPN-IR] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress Replication Tunnels in Multicast VPN", Work in Progress, draft-ietf-bess-ir-03, April 2016. [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003, <http://www.rfc-editor.org/info/rfc3446>. [RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, <http://www.rfc-editor.org/info/rfc3618>. [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, DOI 10.17487/RFC4610, August 2006, <http://www.rfc-editor.org/info/rfc4610>. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <http://www.rfc-editor.org/info/rfc5015>. [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, <http://www.rfc-editor.org/info/rfc5059>.
Top   ToC   RFC7900 - Page 63
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
              <http://www.rfc-editor.org/info/rfc6388>.
Top   ToC   RFC7900 - Page 64

Acknowledgments

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

Contributors

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

Authors' Addresses

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