rfc7900v1.txt   rfc7900.txt 
skipping to change at page 3, line 27 skipping to change at page 3, line 27
7.3. Originating A-D Routes with Extranet Separation . . . . . 47 7.3. Originating A-D Routes with Extranet Separation . . . . . 47
7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 47 7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 47
7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 48 7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 48
7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 49 7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 49
7.4. Determining the Expected P-Tunnel for a C-Flow . . . . . 49 7.4. Determining the Expected P-Tunnel for a C-Flow . . . . . 49
7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 51 7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 51
7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52 7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52
7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 52 7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 52
7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 53 7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 53
7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 53 7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 53
7.5. Packets Arriving from the Wrong P-Tunnel . . . . . . . . 55 7.5. Packets Arriving from the Wrong P-Tunnel . . . . . . . . 54
8. Multiple Extranet VRFs on the Same PE . . . . . . . . . . . . 55 8. Multiple Extranet VRFs on the Same PE . . . . . . . . . . . . 55
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
10. Security Considerations . . . . . . . . . . . . . . . . . . . 56 10. Security Considerations . . . . . . . . . . . . . . . . . . . 56
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
11.1. Normative References . . . . . . . . . . . . . . . . . . 58 11.1. Normative References . . . . . . . . . . . . . . . . . . 58
11.2. Informative References . . . . . . . . . . . . . . . . . 59 11.2. Informative References . . . . . . . . . . . . . . . . . 58
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
Previous RFCs [RFC6513] [RFC6514] specify the procedures necessary to Previous RFCs [RFC6513] [RFC6514] specify the procedures necessary to
allow IP multicast traffic to travel from one site to another within allow IP multicast traffic to travel from one site to another within
a BGP/MPLS IP VPN (Virtual Private Network). However, it is a BGP/MPLS IP VPN (Virtual Private Network). However, it is
sometimes desirable to allow multicast traffic whose source is in one sometimes desirable to allow multicast traffic whose source is in one
VPN to be received by systems that are in another VPN. This is known VPN to be received by systems that are in another VPN. This is known
as an "extranet Multicast VPN (MVPN)". This document specifies the as an "extranet Multicast VPN (MVPN)". This document specifies the
procedures that are necessary in order to provide extranet MVPN procedures that are necessary in order to provide extranet MVPN
skipping to change at page 4, line 18 skipping to change at page 4, line 18
the prefixes "C-" and "P-" as specified in Section 3.1 of [RFC6513], the prefixes "C-" and "P-" as specified in Section 3.1 of [RFC6513],
and "A-D routes" for "auto-discovery routes". and "A-D routes" for "auto-discovery routes".
The term "Upstream Multicast Hop" (UMH) is used as defined in The term "Upstream Multicast Hop" (UMH) is used as defined in
[RFC6513]. [RFC6513].
The term "UMH-eligible route" is used to mean "route eligible for UMH The term "UMH-eligible route" is used to mean "route eligible for UMH
determination", as defined in Section 5.1.1 of [RFC6513]. We will determination", as defined in Section 5.1.1 of [RFC6513]. We will
say that a given UMH-eligible route or unicast route "matches" a say that a given UMH-eligible route or unicast route "matches" a
given IP address, in the context of a given Virtual Routing and given IP address, in the context of a given Virtual Routing and
Forwarding (VRF) table, if the address prefix of the given route is Forwarding table (VRF), if the address prefix of the given route is
the longest match in that VRF for the given IP address. We will the longest match in that VRF for the given IP address. We will
sometimes say that a route "matches" a particular host if the route sometimes say that a route "matches" a particular host if the route
matches an IP address of the host. matches an IP address of the host.
We follow the terminology of Section 3.2 of [RFC6625] when talking of We follow the terminology of Section 3.2 of [RFC6625] when talking of
a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route
being "installed". That is, we say that an S-PMSI A-D route is being "installed". That is, we say that an S-PMSI A-D route is
"installed" (in a given VRF) if it has been selected by the BGP "installed" (in a given VRF) if it has been selected by the BGP
decision process as the preferred route for its Network Layer decision process as the preferred route for its Network Layer
Reachability Information (NLRI). We also follow the terminology of Reachability Information (NLRI). We also follow the terminology of
skipping to change at page 4, line 45 skipping to change at page 4, line 45
o Extranet C-source: a multicast source, in a given VPN, that is o Extranet C-source: a multicast source, in a given VPN, that is
allowed by policy to send multicast traffic to receivers that are allowed by policy to send multicast traffic to receivers that are
in other VPNs. in other VPNs.
o Extranet C-receiver: a multicast receiver, in a given VPN, that is o Extranet C-receiver: a multicast receiver, in a given VPN, that is
allowed by policy to receive multicast traffic from extranet allowed by policy to receive multicast traffic from extranet
C-sources that are in other VPNs. C-sources that are in other VPNs.
o Extranet C-flow: a multicast flow (with a specified C-source o Extranet C-flow: a multicast flow (with a specified C-source
address and C-group address) whose source is an extranet C-source address and C-group address) with the following properties: its
and who is allowed by policy to have extranet C-receivers. source is an extranet C-source, and it is allowed by policy to
have extranet C-receivers.
o Extranet C-group: a multicast group address that is in the o Extranet C-group: a multicast group address that is in the
"Any-Source Multicast" (ASM) group address range and that is "Any-Source Multicast" (ASM) group address range and that is
allowed by policy to have extranet C-sources and extranet allowed by policy to have extranet C-sources and extranet
C-receivers that are not all in the same VPN. Note that we will C-receivers that are not all in the same VPN. Note that we will
sometimes refer to "Source-Specific Multicast (SSM) C-group sometimes refer to "Source-Specific Multicast (SSM) C-group
addresses" (i.e., C-group addresses in the SSM group address addresses" (i.e., C-group addresses in the SSM group address
range) but will never call them "extranet C-groups". range) but will never call them "extranet C-groups".
N.B.: Any source of traffic for an extranet C-group is considered N.B.: Any source of traffic for an extranet C-group is considered
skipping to change at page 13, line 32 skipping to change at page 13, line 32
/ / \ / / \
/ / \ / / \
C-S2(B) Join(C-S2(B),G) Join(C-S1,G) C-S2(B) Join(C-S2(B),G) Join(C-S1,G)
Figure 1: Ambiguity of Extranet and Non-extranet Source Address Figure 1: Ambiguity of Extranet and Non-extranet Source Address
Suppose that: Suppose that:
o C-G is an SSM C-group used in VPN-A and VPN-B. o C-G is an SSM C-group used in VPN-A and VPN-B.
o VRF A-1, on PE1, contains an extranet C-source, whose IP address o VRF A-1, on PE1, contains an extranet C-source, with IP address
is C-S1, that is allowed to have receivers in VPN-B. VRF A-1 thus C-S1, that is allowed to have receivers in VPN-B. VRF A-1 thus
exports to VPN-B a UMH-eligible route matching C-S1. exports to VPN-B a UMH-eligible route matching C-S1.
o VRF A-1 also contains a non-extranet C-source whose IP address is o In addition, VRF A-1 contains a non-extranet C-source with IP
C-S2. VRF A-1 exports a UMH-eligible route matching C-S2 to other address C-S2. VRF A-1 exports a UMH-eligible route matching C-S2
VPN-A VRFs but NOT to VPN-B. to other VPN-A VRFs but NOT to VPN-B.
o VRF B-1, also on PE1, contains a non-extranet C-source whose IP o VRF B-1, also on PE1, contains a non-extranet C-source with IP
address is C-S2. A UMH-eligible route matching C-S2 is thus address C-S2. A UMH-eligible route matching C-S2 is thus exported
exported from VRF B-1 to other VRFs in VPN-B. from VRF B-1 to other VRFs in VPN-B.
o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous
address in any extranet that contains both VPN-A VRFs and VPN-B address in any extranet that contains both VPN-A VRFs and VPN-B
VRFs. VRFs.
o VRF B-2, on some other PE, say PE2, requests the multicast flow o VRF B-2, on some other PE, say PE2, requests the multicast flow
(C-S1,C-G). In the context of VRF B-2, C-S1 matches the route (C-S1,C-G). In the context of VRF B-2, C-S1 matches the route
exported from VRF A-1. Thus, B-2's request to receive the exported from VRF A-1. Thus, B-2's request to receive the
(C-S1,C-G) flow is transmitted to VRF A-1. (C-S1,C-G) flow is transmitted to VRF A-1.
skipping to change at page 15, line 31 skipping to change at page 15, line 31
Join Join Join Join
(C-S2(B2C),G) (C-S1(A2C),G) (C-S2(B2C),G) (C-S1(A2C),G)
Figure 2: Ambiguity of Extranet Source Addresses Figure 2: Ambiguity of Extranet Source Addresses
Suppose that: Suppose that:
o C-G is an SSM C-group address that is used in VPN-A, VPN-B, VPN-C, o C-G is an SSM C-group address that is used in VPN-A, VPN-B, VPN-C,
and VPN-D. and VPN-D.
o VRF A-1, on PE1, contains an extranet C-source whose IP address is o VRF A-1, on PE1, contains an extranet C-source, with IP address
C-S1 and who is allowed by policy to have C-receivers in VPN-C C-S1, that is allowed by policy to have C-receivers in VPN-C (but
(but not in VPN-D). VRF A-1 thus exports a UMH-eligible route not in VPN-D). VRF A-1 thus exports a UMH-eligible route matching
matching C-S1 to VPN-C. C-S1 to VPN-C.
o VRF A-1 also contains an extranet C-source whose IP address is o In addition, VRF A-1 contains an extranet C-source, with IP
C-S2 and who is allowed by policy to have C-receivers in VPN-D address C-S2, that is allowed by policy to have C-receivers in
(but not in VPN-C). VRF A-1 thus exports a UMH-eligible route VPN-D (but not in VPN-C). VRF A-1 thus exports a UMH-eligible
matching C-S2 to VPN-D. route matching C-S2 to VPN-D.
o VRF B-1, also on PE1, contains an extranet C-source whose IP o VRF B-1, also on PE1, contains an extranet C-source, with IP
address is C-S2 and who is allowed by policy to have C-receivers address C-S2, that is allowed by policy to have C-receivers in
in VPN-C (but not in VPN-D). VRF B-1 thus exports a UMH-eligible VPN-C (but not in VPN-D). VRF B-1 thus exports a UMH-eligible
route matching C-S2 to VPN-C. route matching C-S2 to VPN-C.
o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous
address in any extranet that contains both VPN-A VRFs and VPN-B address in any extranet that contains both VPN-A VRFs and VPN-B
VRFs. VRFs.
o VRF C-1, on some other PE, say PE2, requests the extranet o VRF C-1, on some other PE, say PE2, requests the extranet
multicast flow (C-S1,C-G). In the context of VRF C-1, C-S1 multicast flow (C-S1,C-G). In the context of VRF C-1, C-S1
matches the route exported from VRF A-1. Thus, C-1's request to matches the route exported from VRF A-1. Thus, C-1's request to
receive the (C-S1,C-G) flow is transmitted to VRF A-1. receive the (C-S1,C-G) flow is transmitted to VRF A-1.
skipping to change at page 20, line 47 skipping to change at page 20, line 47
3.1. Transmitting an Extranet C-Flow on a Single PMSI 3.1. Transmitting an Extranet C-Flow on a Single PMSI
In one extranet transmission model, which we call the "transmitting In one extranet transmission model, which we call the "transmitting
an extranet C-flow on a single PMSI" model or, more simply, the 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 "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 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 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 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 replication point for that multicast P-tunnel, the packet is
transmitted more than once by the PE. Similarly, if the PMSI is transmitted more than once by the PE. Similarly, if the PMSI is
instantiated by a set of unicast tunnels (i.e., via IR), each packet instantiated by IR, each packet may be transmitted multiple times.
may be transmitted multiple times. It is still the case, though, It is still the case, though, that the packet is transmitted only on
that the packet is transmitted only on one PMSI. one PMSI.
This document provides procedures for supporting this transmission This document provides procedures for supporting this transmission
model using either BGP or PIM as the PE-PE C-multicast control model using either BGP or PIM as the PE-PE C-multicast control
protocol. protocol.
There are two variants of this transmission model: "without extranet There are two variants of this transmission model: "without extranet
separation" and "with extranet separation". separation" and "with extranet separation".
3.1.1. Without Extranet Separation 3.1.1. Without Extranet Separation
skipping to change at page 22, line 35 skipping to change at page 22, line 35
be unicast routes; they MAY be SAFI 129 routes (see Section 5.1.1 of 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 [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 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 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 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. 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 Since SAFI 129 routes are used only for UMH determination and not for
unicast routing, this allows the multicast traffic to be forwarded unicast routing, this allows the multicast traffic to be forwarded
properly but does not create unicast routes to the C-sources. properly but does not create unicast routes to the C-sources.
If a customer is using PIM-SM in any-source mode and one or more 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 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-*,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 C-receivers for that group MUST import a UMH-eligible route that
matches C-RP, where C-RP is the Rendezvous Point (RP) address matches C-RP, where C-RP is the Rendezvous Point (RP) address
for C-G. for C-G.
The UMH-eligible extranet C-source and C-RP routes do not have to be 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 "host routes". That is, they can be routes whose IPv4 address
prefixes are not 32 bits in length or whose IPv6 address prefixes are 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 not 128 bits in length. So, it is possible for a UMH-eligible
skipping to change at page 44, line 27 skipping to change at page 44, line 27
find the selected UMH route for C-S. When it is necessary 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 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 an ASM group, a PE must follow the procedures of that section to find
the selected UMH route for C-G's C-RP. the selected UMH route for C-G's C-RP.
Section 11.1.3 of [RFC6514] specifies how information from the 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 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 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. then used to construct part of the C-multicast route.
For extranets, this specification modifies the procedures of For extranets, the rules given in Section 7.4.5 of this document are
Section 11.1.3 of [RFC6514] as follows. The rules given in used to find the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D
Section 7.4.5 ("I-PMSI A-D Routes") of this document are used to find route that "corresponds" to the selected UMH route; the rules in
the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D route that Section 7.4.5 replace the rules given in Section 11.1.3 of [RFC6514]
"corresponds" to the selected UMH route. (That is, the rules given for finding the Inter-AS or Intra-AS I-PMSI A-D route.
in Section 7.4.5 of this document 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 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. Section 11.1.3 of [RFC6514], to construct the C-multicast route.
7.2. Originating A-D Routes without Extranet Separation 7.2. Originating A-D Routes without Extranet Separation
7.2.1. Intra-AS I-PMSI A-D Routes 7.2.1. Intra-AS I-PMSI A-D Routes
Consider a VRF (call it "VRF-S") that contains extranet C-sources and Consider a VRF (call it "VRF-S") that contains extranet C-sources and
exports UMH-eligible routes matching those C-sources. The VRF may exports UMH-eligible routes matching those C-sources. The VRF may
 End of changes. 14 change blocks. 
37 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/