RFC 7900
Extranet Multicast in BGP/IP MPLS VPNs
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.
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].
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.
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").
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].
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
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
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.
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.
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
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.
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.
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)
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
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.
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>.
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>.
[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>.
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
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