draft-ietf-bess-mvpn-extranet-02.txt   draft-ietf-bess-mvpn-extranet-03.txt 
BESS Working Group Y. Rekhter, Ed. BESS Working Group Y. Rekhter, Ed.
Internet-Draft E. Rosen, Ed. Internet-Draft E. Rosen, Ed.
Updates: 6513,6514,6625 (if approved) Juniper Networks, Inc. Updates: 6513,6514,6625 (if approved) Juniper Networks, Inc.
Intended status: Standards Track R. Aggarwal Intended status: Standards Track R. Aggarwal
Expires: November 8, 2015 Arktan Expires: April 14, 2016 Arktan
Y. Cai Y. Cai
Microsoft Microsoft
T. Morin T. Morin
Orange Orange
May 7, 2015 October 12, 2015
Extranet Multicast in BGP/IP MPLS VPNs Extranet Multicast in BGP/IP MPLS VPNs
draft-ietf-bess-mvpn-extranet-02 draft-ietf-bess-mvpn-extranet-03
Abstract Abstract
Previous RFCs specify the procedures necessary to allow IP multicast Previous RFCs specify the procedures necessary to allow IP multicast
traffic to travel from one site to another within a BGP/MPLS IP VPN traffic to travel from one site to another within a BGP/MPLS IP VPN
(Virtual Private Network). However, it is sometimes desirable to (Virtual Private Network). However, it is sometimes desirable to
allow multicast traffic whose source is in one VPN to be received by allow multicast traffic whose source is in one VPN to be received by
systems that are in another VPN. This is known as a "Multicast VPN systems that are in another VPN. This is known as a "Multicast VPN
(MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by
specifying the procedures that are necessary in order to provide MVPN specifying the procedures that are necessary in order to provide MVPN
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2015. This Internet-Draft will expire on April 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 12 skipping to change at page 4, line 12
8. Multiple Extranet VRFs on the same 8. Multiple Extranet VRFs on the same
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
10. Security Considerations . . . . . . . . . . . . . . . . . . . 55 10. Security Considerations . . . . . . . . . . . . . . . . . . . 55
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56
12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 56 12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.1. Normative References . . . . . . . . . . . . . . . . . . 57 13.1. Normative References . . . . . . . . . . . . . . . . . . 57
13.2. Informative References . . . . . . . . . . . . . . . . . 58 13.2. Informative References . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
Previous RFCs ([RFC6513], [RFC6514]) specify the procedures necessary Previous RFCs ([RFC6513], [RFC6514]) specify the procedures necessary
to allow IP multicast traffic to travel from one site to another to allow IP multicast traffic to travel from one site to another
within a BGP/MPLS IP VPN (Virtual Private Network). However, it is within 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 MVPN". This document specifies the procedures that as an "extranet MVPN". This document specifies the procedures that
are necessary in order to provide Extranet MVPN functionality. are necessary in order to provide Extranet MVPN functionality.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D
route contains (C-S,C-G) if its "Multicast Source" field contains C-S route contains (C-S,C-G) if its "Multicast Source" field contains C-S
and its "Multicast Group" field contains C-G. If either or both of and its "Multicast Group" field contains C-G. If either or both of
these fields is encoded as a wildcard, we will say that the NLRI these fields is encoded as a wildcard, we will say that the NLRI
contains (C-*,C-*) (both fields encoded as wildcard), or (C-*,C-G) contains (C-*,C-*) (both fields encoded as wildcard), or (C-*,C-G)
(multicast source field encoded as wildcard) or (C-S,C-*) (multicast (multicast source field encoded as wildcard) or (C-S,C-*) (multicast
group field encoded as wildcard). group field encoded as wildcard).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when and only when appearing in all capital letters, are "OPTIONAL" in this document are to be interpreted as described in
to be interpreted as described in [RFC2119]. [RFC2119].
1.2. Scope 1.2. Scope
1.2.1. Customer Multicast Control Protocols 1.2.1. Customer Multicast Control Protocols
This document presumes that the VPN customer is using "PIM Sparse This document presumes that the VPN customer is using "PIM Sparse
Mode", operating in either "Source-Specific Mode" (SSM) or "Any Mode", operating in either "Source-Specific Mode" (SSM) or "Any
Source Mode" (ASM), as the multicast control protocol at the customer Source Mode" (ASM), as the multicast control protocol at the customer
sites. Support for other customer IP multicast control protocols sites. Support for other customer IP multicast control protocols
(e.g., [RFC5015], PIM "Dense Mode") is outside the scope of this (e.g., [RFC5015], PIM "Dense Mode") is outside the scope of this
skipping to change at page 12, line 9 skipping to change at page 12, line 9
ensure that C-G is unambiguous among the entire set of VPNs whose ensure that C-G is unambiguous among the entire set of VPNs whose
VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers
for that C-group. This may require, as part of the provisioning for that C-group. This may require, as part of the provisioning
process, customer/SP communication that is outside the scope of this process, customer/SP communication that is outside the scope of this
document. document.
Subject to these restrictions, the SP has complete control over the Subject to these restrictions, the SP has complete control over the
distribution of routes in an MVPN. This control is exerted either by distribution of routes in an MVPN. This control is exerted either by
provisioning the export RTs on the VRFs that originate the routes provisioning the export RTs on the VRFs that originate the routes
(i.e., on the VRFs that contain the extranet C-sources), or by (i.e., on the VRFs that contain the extranet C-sources), or by
provisioning the the import RTs on the VRFs that receive the routes provisioning the import RTs on the VRFs that receive the routes
(i.e., on the VRFs that contain the extranet C-receivers), or both. (i.e., on the VRFs that contain the extranet C-receivers), or both.
Some of the rules and restrictions on provisioning the RTs are Some of the rules and restrictions on provisioning the RTs are
applicable to all extranets; these are specified in Section 4. applicable to all extranets; these are specified in Section 4.
Sections 6 and 7 add additional rules and restrictions that are Sections 6 and 7 add additional rules and restrictions that are
applicable only to particular extranet scenarios. applicable only to particular extranet scenarios.
Even if all the RTs are provisioned according according to the above Even if all the RTs are provisioned according to the above rules and
rules and restrictions, it is still possible for a single P-tunnel to restrictions, it is still possible for a single P-tunnel to contain
contain multicast data packets whose source and/or group addresses multicast data packets whose source and/or group addresses are
are ambiguous in the context of the set of PEs that receive data from ambiguous in the context of the set of PEs that receive data from the
the P-tunnel. That is, the above rules and restrictions are P-tunnel. That is, the above rules and restrictions are necessary,
necessary, but not sufficient, to prevent address ambiguity from but not sufficient, to prevent address ambiguity from causing
causing misdelivery of traffic. To prevent such misdelivery, misdelivery of traffic. To prevent such misdelivery, additional
additional procedures or policies must be used. procedures or policies must be used.
Sections 2.1 and 2.2 describe scenarios in which a given P-tunnel may Sections 2.1 and 2.2 describe scenarios in which a given P-tunnel may
carry data packets with ambiguous addresses. The additional carry data packets with ambiguous addresses. The additional
procedures and policies needed to prevent misdelivery of data in procedures and policies needed to prevent misdelivery of data in
those scenarios are outlined in those Section 2.3. (The detailed those scenarios are outlined in those Section 2.3. (The detailed
procedures described in Sections 6 and 7 incorporate the procedures described in Sections 6 and 7 incorporate the
considerations of Section 2.3.) considerations of Section 2.3.)
2.1. Ambiguity: P-tunnel with Extranet/Non-Extranet Flows 2.1. Ambiguity: P-tunnel with Extranet/Non-Extranet Flows
skipping to change at page 13, line 47 skipping to change at page 13, line 47
VRFs. VRFs.
o VRF B-2, on some other PE, say PE2, requests to receive the o VRF B-2, on some other PE, say PE2, requests to receive the
multicast flow (C-S1,C-G). In the context of VRF B-2, C-S1 multicast flow (C-S1,C-G). In the context of VRF B-2, C-S1
matches the route exported from VRF A-1. Thus B-2's request to matches the route exported from VRF A-1. Thus B-2's request to
receive the (C-S1,C-G) flow is transmitted to VRF A-1. receive the (C-S1,C-G) flow is transmitted to VRF A-1.
o VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by o VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by
transmitting that traffic on P-tunnel P1. transmitting that traffic on P-tunnel P1.
o VRF B-2 joins P-tunnel P1, in order to receiver the (C-S1,C-G) o VRF B-2 joins P-tunnel P1, in order to receive the (C-S1,C-G)
traffic. traffic.
o VRF A-2, on PE2, requests to receive the (non-extranet) multicast o VRF A-2, on PE2, requests to receive the (non-extranet) multicast
flow (C-S2,C-G). In the context of VRF A-2, C-S2 matches the flow (C-S2,C-G). In the context of VRF A-2, C-S2 matches the
route exported from VRF A-1. Thus A-2's request to receive the route exported from VRF A-1. Thus A-2's request to receive the
(C-S2,C-G) traffic is transmitted to VRF A-1. (C-S2,C-G) traffic is transmitted to VRF A-1.
o VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by o VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by
transmitting that traffic on P-tunnel P1. transmitting that traffic on P-tunnel P1.
skipping to change at page 26, line 11 skipping to change at page 26, line 11
routes are the matching routes for extranet C-sources and C-RPs. routes are the matching routes for extranet C-sources and C-RPs.
This may be done as part of the provisioning process. Note that this This may be done as part of the provisioning process. Note that this
does not necessarily require customer/provider interaction every time does not necessarily require customer/provider interaction every time
the customer adds a new extranet C-source or C-RP, but only when the the customer adds a new extranet C-source or C-RP, but only when the
IP address of the new C-source or C-RP does not match an existing IP address of the new C-source or C-RP does not match an existing
route that is already being distributed as a VPN-IP extranet route. route that is already being distributed as a VPN-IP extranet route.
Nevertheless, it seems worthwhile to support an OPTIONAL mechanism Nevertheless, it seems worthwhile to support an OPTIONAL mechanism
that allows a customer to dynamically mark certain routes as being that allows a customer to dynamically mark certain routes as being
extranet routes. extranet routes.
To facilitate this, we define a new transitive opaque extended To facilitate this, we define a new Transitive Opaque Extended
community, the "Extranet Source" extended community. When a CE Community, the "Extranet Source" Extended Community. When a CE
router advertises (via BGP) a route to a PE router, and the AFI/SAFI router advertises (via BGP) a route to a PE router, and the AFI/SAFI
of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source
extended community MAY be attached to the route. The value field of Extended Community MAY be attached to the route. The value field of
the extended community MUST be set to zero. By placing this extended the Extended Community MUST be set to zero. By placing this Extended
community on a particular route, a CE router indicates to a PE router Community on a particular route, a CE router indicates to a PE router
that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied
to that route. That is, the CE router may use this extended to that route. That is, the CE router may use this Extended
community to indicate to the PE router that a particular route is to Community to indicate to the PE router that a particular route is to
be treated as a route that matches the address of an extranet source, be treated as a route that matches the address of an extranet source,
and exported accordingly to other VPNs. and exported accordingly to other VPNs.
Whether a CE router uses the Extranet Source extended community is Whether a CE router uses the Extranet Source Extended Community is
determined by the configuration of the CE router. If used, the set determined by the configuration of the CE router. If used, the set
of routes to which the extended community is attached is also of routes to which the Extended Community is attached is also
determined by configuration of the CE. Note that a particular PE determined by configuration of the CE. Note that a particular PE
router may or may not support the use of the Extranet Source extended router may or may not support the use of the Extranet Source Extended
community by a particular CE router; this is determined by the Community by a particular CE router; this is determined by the
service agreement between the SP and its customer. service agreement between the SP and its customer.
If a CE is advertising SAFI-2 routes to the PE as the UMH-eligible If a CE is advertising SAFI-2 routes to the PE as the UMH-eligible
extranet C-source and C-RP routes, and if the CE is using the extranet C-source and C-RP routes, and if the CE is using the
Extranet Source extended community, it is important that the CE Extranet Source Extended Community, it is important that the CE
attach that extended community to the SAFI-2 routes, rather than just attach that Extended Community to the SAFI-2 routes, rather than just
to the corresponding SAFI-1 routes. Otherwise extranet receivers may to the corresponding SAFI-1 routes. Otherwise extranet receivers may
not be able to join the (C-S,C-G) or (C-*,C-G) multicast trees. not be able to join the (C-S,C-G) or (C-*,C-G) multicast trees.
However, if the C-sources and the C-RPs for a given extranet C-group However, if the C-sources and the C-RPs for a given extranet C-group
are not all in the same VPN, the extended community would also have are not all in the same VPN, the Extended Community would also have
to be attached to the SAFI-1 routes that match the C-RP addresses and to be attached to the SAFI-1 routes that match the C-RP addresses and
to the SAFI-1 routes that match the addresses of the first hop to the SAFI-1 routes that match the addresses of the first hop
designated routers for all the C-sources. Otherwise, the first hop designated routers for all the C-sources. Otherwise, the first hop
routers might not be able to send PIM Register messages to the C-RPs, routers might not be able to send PIM Register messages to the C-RPs,
and the C-RPs might not be able to send PIM Register-Stop messages to and the C-RPs might not be able to send PIM Register-Stop messages to
the first hop routers. the first hop routers.
While this extended community allows a customer to inform the SP While this Extended Community allows a customer to inform the SP
dynamically that certain routes are "extranet routes", it does not dynamically that certain routes are "extranet routes", it does not
allow a customer to control the set of RTs that the route will carry allow a customer to control the set of RTs that the route will carry
when it is redistributed as a VPN-IP route. Thus it is only useful when it is redistributed as a VPN-IP route. Thus it is only useful
when all the extranet routes from a given VRF are exported with when all the extranet routes from a given VRF are exported with
exactly the same set of RTs. (Cf. Section 4.3.1 of [RFC4364], which exactly the same set of RTs. (Cf. Section 4.3.1 of [RFC4364], which
does provide a mechanism that, if properly supported by the SP, does provide a mechanism that, if properly supported by the SP,
allows the customer to determine the set of RTs carried by a VPN-IP allows the customer to determine the set of RTs carried by a VPN-IP
route.) route.)
Note that misconfiguration on the CE router can result in the Note that misconfiguration on the CE router can result in the
Extranet Source extended community being mistakenly attached to a Extranet Source Extended Community being mistakenly attached to a
route that is not intended to be exported as an extranet route. This route that is not intended to be exported as an extranet route. This
could result in a VPN security violation. could result in a VPN security violation.
4.4.2. Distribution of Extranet Source Extended Community 4.4.2. Distribution of Extranet Source Extended Community
When a PE receives from a CE a route with the Extranet Source When a PE receives from a CE a route with the Extranet Source
extended community, the corresponding VPN-IP route originated by the Extended Community, the corresponding VPN-IP route originated by the
PE MUST carry this extended community. PE MUST carry this Extended Community.
A Route Reflector MUST NOT add/remove the Extranet Source extended A Route Reflector MUST NOT add/remove the Extranet Source Extended
community from the VPN-IP routes reflected by the Route Reflector, Community from the VPN-IP routes reflected by the Route Reflector,
including the case where VPN-IP routes received via IBGP are including the case where VPN-IP routes received via IBGP are
reflected to EBGP peers (inter-AS option (c), see [RFC6513] reflected to EBGP peers (inter-AS option (c), see [RFC6513]
Section 10). Section 10).
When re-advertising VPN-IP routes, ASBRs MUST NOT add/remove the When re-advertising VPN-IP routes, ASBRs MUST NOT add/remove the
Extranet Source extended community from these routes. This includes Extranet Source Extended Community from these routes. This includes
inter-AS options (a) and (b) (see [RFC6513] Section 10). inter-AS options (a) and (b) (see [RFC6513] Section 10).
When a PE advertises (via BGP) IP routes to a CE, these routes MUST When a PE advertises (via BGP) IP routes to a CE, these routes MUST
NOT carry the Extranet Source extended community, unless the PE-CE NOT carry the Extranet Source Extended Community, unless the PE-CE
connection is actually an inter-AS option (a) connection (see connection is actually an inter-AS option (a) connection (see
[RFC6513] Section 10). When the PE-CE connection is not an inter-AS [RFC6513] Section 10). When the PE-CE connection is not an inter-AS
option (a) connection, a CE that receives an IP route with the option (a) connection, a CE that receives an IP route with the
Extranet Source extended community MUST remove it from the route Extranet Source Extended Community MUST remove it from the route
before readvertising the route. before readvertising the route.
4.5. The 'Extranet Separation' Extended Community 4.5. The 'Extranet Separation' Extended Community
We define a new transitive opaque extended community, the "Extranet We define a new Transitive Opaque Extended Community, the "Extranet
Separation" extended community. This extended community is used only Separation" Extended Community. This Extended Community is used only
when extranet separation is being used. Its value field MUST be set when extranet separation is being used. Its value field MUST be set
to zero upon origination, MUST be ignored upon reception, and MUST be to zero upon origination, MUST be ignored upon reception, and MUST be
passed unchanged by intermediate routers. passed unchanged by intermediate routers.
If a VRF has been provisioned to use extranet separation, and if that If a VRF has been provisioned to use extranet separation, and if that
VRF has been provisioned to transmit any extranet C-flows on a VRF has been provisioned to transmit any extranet C-flows on a
P-tunnel that it advertises in an I-PMSI A-D route or a (C-*,C-*) P-tunnel that it advertises in an I-PMSI A-D route or a (C-*,C-*)
S-PMSI A-D route, then any UMH-eligible routes that are exported from S-PMSI A-D route, then any UMH-eligible routes that are exported from
that VRF following the procedures of Sections 4.1, 4.2, and 4.3 MUST that VRF following the procedures of Sections 4.1, 4.2, and 4.3 MUST
carry the Extranet Separation extended community. In addition, if an carry the Extranet Separation Extended Community. In addition, if an
I-PMSI A-D route and/or (C-*,C-*) S-PMSI A-D route, exported from I-PMSI A-D route and/or (C-*,C-*) S-PMSI A-D route, exported from
that VRF, is used to carry extranet traffic, that A-D route MUST also that VRF, is used to carry extranet traffic, that A-D route MUST also
carry the Extranet Separation extended community. Further details carry the Extranet Separation Extended Community. Further details
may be found in Sections 7.3, 7.4.4, and 7.4.5. may be found in Sections 7.3, 7.4.4, and 7.4.5.
5. Origination and Distribution of BGP A-D Routes 5. Origination and Distribution of BGP A-D Routes
Except where otherwise specified, this section describes procedures Except where otherwise specified, this section describes procedures
and restrictions that are independent of the PE-PE C-multicast and restrictions that are independent of the PE-PE C-multicast
control protocol. control protocol.
5.1. Route Targets of UMH-eligible Routes and A-D Routes 5.1. Route Targets of UMH-eligible Routes and A-D Routes
skipping to change at page 30, line 52 skipping to change at page 30, line 52
that VRF-S advertises in its Intra-AS I-PMSI A-D route either a P2MP that VRF-S advertises in its Intra-AS I-PMSI A-D route either a P2MP
RSVP-TE P-tunnel or an Ingress Replication P-tunnel to carry extranet RSVP-TE P-tunnel or an Ingress Replication P-tunnel to carry extranet
traffic. traffic.
In order for VRF-S to set up the P2MP RSVP-TE or Ingress Replication In order for VRF-S to set up the P2MP RSVP-TE or Ingress Replication
P-tunnel, it must know all the PEs that are leaf nodes of the P-tunnel, it must know all the PEs that are leaf nodes of the
P-tunnel, and to learn this it MUST import an Intra-AS I-PMSI A-D P-tunnel, and to learn this it MUST import an Intra-AS I-PMSI A-D
route from every VRF that needs to receive data through that tunnel. route from every VRF that needs to receive data through that tunnel.
Therefore if VRF-R contains an extranet C-receiver that is allowed by Therefore if VRF-R contains an extranet C-receiver that is allowed by
policy to receive extranet flows from C-S, the the RT(s) carried by policy to receive extranet flows from C-S, the RT(s) carried by the
the Intra-AS I-PMSI A-D routes originated by VRF-R must be such that Intra-AS I-PMSI A-D routes originated by VRF-R must be such that
those Intra-AS I-PMSI A-D routes will be imported into VRF-S. those Intra-AS I-PMSI A-D routes will be imported into VRF-S.
In the case of Ingress Replication, this has the following In the case of Ingress Replication, this has the following
consequence. If an egress PE has n VRFs with receivers for a flow consequence. If an egress PE has n VRFs with receivers for a flow
that VRF-S transmits on its I-PMSI, that egress PE will receive n that VRF-S transmits on its I-PMSI, that egress PE will receive n
copies of the same packet, one for each of the n VRFs. copies of the same packet, one for each of the n VRFs.
Note that Section 9.1.1 of [RFC6514] prohibits the Leaf Information Note that Section 9.1.1 of [RFC6514] prohibits the Leaf Information
Required flag from being set in the PTA of an Intra-AS I-PMSI A-D Required flag from being set in the PTA of an Intra-AS I-PMSI A-D
route. If this prohibition is ever removed, the requirement of this route. If this prohibition is ever removed, the requirement of this
skipping to change at page 31, line 46 skipping to change at page 31, line 46
a. the "Single Forwarder Selection" procedures of [RFC6513] a. the "Single Forwarder Selection" procedures of [RFC6513]
Section 9.1.2, Section 9.1.2,
b. the "Native PIM Methods" procedures of [RFC6513] b. the "Native PIM Methods" procedures of [RFC6513]
Section 9.1.3 Section 9.1.3
c. the unicast encapsulation used to transmit packets along the c. the unicast encapsulation used to transmit packets along the
IR P-tunnel must be such as to enable the receiving node to IR P-tunnel must be such as to enable the receiving node to
identify the transmitting node (note that this would not be identify the transmitting node (note that this would not be
the case if, e.,g., the unicast tunnels were MP2P LSPs); the case if, e.g., the unicast tunnels were MP2P LSPs);
and and
2. If a PE assigns an MPLS label value in the PMSI Tunnel attribute 2. If a PE assigns an MPLS label value in the PMSI Tunnel attribute
of an Intra-AS or Inter-AS I-PMSI A-D route that it originates, of an Intra-AS or Inter-AS I-PMSI A-D route that it originates,
that label value MUST NOT appear in the PMSI Tunnel attribute of that label value MUST NOT appear in the PMSI Tunnel attribute of
any other I-PMSI or S-PMSI A-D route originated by the same PE. any other I-PMSI or S-PMSI A-D route originated by the same PE.
Failure to follow these procedures would make it impossible to Failure to follow these procedures would make it impossible to
discard packets that arrive on the wrong P-tunnel, and thus could discard packets that arrive on the wrong P-tunnel, and thus could
skipping to change at page 35, line 22 skipping to change at page 35, line 22
the MI-PMSI that VPN-S uses for its non-extranet traffic. the MI-PMSI that VPN-S uses for its non-extranet traffic.
6.2.1. Forming the MI-PMSIs 6.2.1. Forming the MI-PMSIs
Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513],
each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing
a PMSI Tunnel Attribute (PTA) specifying the P-tunnel to be used as a PMSI Tunnel Attribute (PTA) specifying the P-tunnel to be used as
part of the VPN-S MI-PMSI. In the absence of extranet service, this part of the VPN-S MI-PMSI. In the absence of extranet service, this
route carries the VRF's non-extranet RT, RT-S. When extranet service route carries the VRF's non-extranet RT, RT-S. When extranet service
is provided (using the "single PMSI per C-flow" model), this route is provided (using the "single PMSI per C-flow" model), this route
MUST also carry EACH of the VRF's Outgoing Extranet RTs. MUST also carry each of the VRF's Outgoing Extranet RTs.
Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513],
each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing
a PTA specifying the P-tunnel to be used as part of the VPN-R MI- a PTA specifying the P-tunnel to be used as part of the VPN-R MI-
PMSI. This route carries the VRF's non-extranet RT RT-R. When PMSI. This route carries the VRF's non-extranet RT RT-R. When
extranet service is provided (using the "single PMSI per C-flow" extranet service is provided (using the "single PMSI per C-flow"
model), the VPN-R VRF MUST also originate one or more additional model), the VPN-R VRF MUST also originate one or more additional
Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra- Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra-
AS I-PMSI A-D route for each Incoming Extranet RT with which it has AS I-PMSI A-D route for each Incoming Extranet RT with which it has
been configured; each such route will carry exactly one of the been configured; each such route will carry exactly one of the
skipping to change at page 41, line 22 skipping to change at page 41, line 22
is provided (using the "single PMSI per C-flow" model), this route is provided (using the "single PMSI per C-flow" model), this route
MUST also carry each of the VRF's Incoming Extranet RTs. MUST also carry each of the VRF's Incoming Extranet RTs.
Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513],
each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing
a PTA specifying the P-tunnel to be used as part of the VPN-S MI- a PTA specifying the P-tunnel to be used as part of the VPN-S MI-
PMSI. This route carries the VRF's non-extranet RT RT-S. When PMSI. This route carries the VRF's non-extranet RT RT-S. When
extranet service is provided using the "multiple PMSI per C-flow" extranet service is provided using the "multiple PMSI per C-flow"
model, the VPN-S VRF MUST also originate one or more additional model, the VPN-S VRF MUST also originate one or more additional
Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra- Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra-
AS I-PMSI A-D route for each outgiong extranet RT with which it has AS I-PMSI A-D route for each outgoing extranet RT with which it has
been configured; each such route will have a distinct RD, and will been configured; each such route will have a distinct RD, and will
carry exactly one of the configured Outgoing Extranet RTs. carry exactly one of the configured Outgoing Extranet RTs.
As with the "single PMSI per C-flow" transmission model, VRFs As with the "single PMSI per C-flow" transmission model, VRFs
containing extranet C-receivers need to import UMH-eligible extranet containing extranet C-receivers need to import UMH-eligible extranet
C-source routes from VRFs containing C-sources. This is ensured by C-source routes from VRFs containing C-sources. This is ensured by
the rules of 3, 4, and 5. the rules of 3, 4, and 5.
However, in the "multiple PMSIs per C-flow model", a VRF containing However, in the "multiple PMSIs per C-flow model", a VRF containing
only C-receivers originates only a single Intra-AS I-PMSI A-D route, only C-receivers originates only a single Intra-AS I-PMSI A-D route,
skipping to change at page 45, line 28 skipping to change at page 45, line 28
If VRF-S exports a Source Active A-D route that contains C-S in the If VRF-S exports a Source Active A-D route that contains C-S in the
Multicast Source field of its NLRI, and if that VRF also exports a Multicast Source field of its NLRI, and if that VRF also exports a
UMH-eligible route matching C-S, the Source Active A-D route MUST 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 carry at least one RT in common with the UMH-eligible route. The RT
must be chosen such that the following condition holds: if VRF-R must be chosen such that the following condition holds: if VRF-R
contains an extranet C-receiver allowed by policy to receive extranet 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 traffic from C-S, then VRF-R imports both the UMH-eligible route and
the Source Active A-D route. the Source Active A-D route.
By default, a Source Active A-D route for a given (C,S,C-G), exported 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 by a given VRF, carries the same set of RTs as the UMH-eligible route
matching C-S that is exported from that VRF. matching C-S that is exported from that VRF.
7.2.3.2. When Inter-Site Shared Trees Are Not Used 7.2.3.2. When Inter-Site Shared Trees Are Not Used
This section applies when Inter-Site Shared Trees are not used, as This section applies when Inter-Site Shared Trees are not used, as
specified in [RFC6514] Section 14. specified in [RFC6514] Section 14.
Suppose a VRF, say VRF-X, contains the C-RP for a given extranet Suppose 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 C-group, say C-G. If C-S is an active source for C-G, then following
skipping to change at page 46, line 41 skipping to change at page 46, line 41
in its PTA. This route must have the VRF's "default RD" in its PTA. 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, If VRF-S uses an inclusive P-tunnel for carrying extranet traffic,
but does not use an inclusive P-tunnel for carrying non-extranet 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 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 be originated. The PTA of this route identifies the "extranet
inclusive P-tunnel". The NLRI of that route must contain the VRF's inclusive P-tunnel". The NLRI of that route must contain the VRF's
extranet RD. extranet RD.
An Intra-AS I-PMSI A-D route whose PTA identifies an extranet An Intra-AS I-PMSI A-D route whose PTA identifies an extranet
inclusive P-tunnel MUST carry the Extranet Separation extended inclusive P-tunnel MUST carry the Extranet Separation Extended
community defined in Section 4.5. Community defined in Section 4.5.
The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies 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 the "extranet inclusive P-tunnel" MUST be chosen such that the
following condition holds: if a VRF (call it VRF-R) imports a UMH- following condition holds: if a VRF (call it VRF-R) imports a UMH-
eligible route from VRF-S, and if that route matches an extranet eligible route from VRF-S, and if that route matches an extranet
C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route. 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 Note that when extranet separation is used, it is possible to use an
inclusive P-tunnel for non-extranet traffic while using only inclusive P-tunnel for non-extranet traffic while using only
selective P-tunnels for extranet traffic. It is also possible to use selective P-tunnels for extranet traffic. It is also possible to use
skipping to change at page 47, line 49 skipping to change at page 47, line 49
route, and C-S is an extranet C-source. 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 * The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G
is an extranet C-group. is an extranet C-group.
In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI 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. 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 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 to carry extranet traffic MUST carry the Extranet Separation
extended community defined in Section 4.5. Extended Community defined in Section 4.5.
An implementation MUST allow the set of RTs carried by the S-PMSI A-D 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 routes to be specified by configuration. In the absence of such
configuration, an S-PMSI A-D route originated by a given VRF X MUST configuration, an S-PMSI A-D route originated by a given VRF X MUST
carry a default set of RTs, as specified by the following rules: carry a default set of RTs, as specified by the following rules:
1. Rule 1 of Section 7.2.2 applies. 1. Rule 1 of Section 7.2.2 applies.
2. By default, if C-G is an extranet C-group, rule 2 of 2. By default, if C-G is an extranet C-group, rule 2 of
Section 7.2.2 applies. Section 7.2.2 applies.
skipping to change at page 52, line 36 skipping to change at page 52, line 36
A (C-*,C-*) S-PMSI A-D Route (call it "R-AD") is NOT considered to be 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) 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 unless the following conditions hold (in addition to the conditions
specified in [RFC6625]: specified in [RFC6625]:
o the selected UMH route (call it "R-UMH") for C-S or for C-G's C-RP 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 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. 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 o either R-AD and R-UMH both carry the Extranet Separation Extended
community, or neither carries the Extranet Separation extended Community, or neither carries the Extranet Separation Extended
community. Community.
7.4.5. I-PMSI A-D Routes 7.4.5. I-PMSI A-D Routes
If a particular egress VRF in a particular egress PE contains no If a particular egress VRF in a particular egress PE contains no
matching S-PMSI A-D routes for a particulalr C-flow, then the C-flow matching S-PMSI A-D routes for a particulalr C-flow, then the C-flow
is expected to arrive (at that egress VRF) on an inclusive P-tunnel. 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 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 Source Tree Join. Let R-UMH be the selected UMH route (in the given
egress VRF) or C-S. As specified in [RFC6514], the selected upstream egress VRF) or C-S. As specified in [RFC6514], the selected upstream
PE for (C-S,C-G) is determined from the VRF Route Import RT of R-UMH, PE for (C-S,C-G) is determined from the VRF Route Import RT of R-UMH,
and the "selected upstream AS" for the flow is determined from the and the "selected upstream AS" for the flow is determined from the
Source AS Extended Community of R-UMH. Source AS Extended Community of R-UMH.
Suppose that an egress PE has originated a (C-*,C-G) C-Multicast 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 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 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 Active A-D route installed, the selected upstream PE is determined
from the VRF Route Import EC of the installed UMH-eligible route from the VRF Route Import EC of the installed UMH-eligible route
matching C-RP, where C-RP is the RP for the group C-G. The selected matching C-RP, where C-RP is the RP for the group C-G. The selected
upstream AS for the flow is detemined from the Source AS EC of that upstream AS for the flow is determined from the Source AS EC of that
route. If the egress VRF does have a (C-S,C-G) Source Active A-D 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 route installed, the selected upstream PE and upstream AS are
determined as specified in Section 7.4. In either case, let R-UMH be determined as specified in Section 7.4. In either case, let R-UMH be
the installed UMH-eligible route matching C-S. the installed UMH-eligible route matching C-S.
The inclusive P-tunnel that is expected to be carrying a particular The inclusive P-tunnel that is expected to be carrying a particular
C-flow is found as follows: C-flow is found as follows:
o If the selected upstream AS is the local AS, or if segmented o If the selected upstream AS is the local AS, or if segmented
Inter-AS P-tunnels are not being used to instantiate I-PMSIs, then 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, look in the VRF for an installed Intra-AS I-PMSI A-D route, R-AD,
such that (a) R-AD originated by the selected upstream PE, (b) such that (a) R-AD originated by the selected upstream PE, (b)
R-AD has at least one an RT in common with R-UMH, (c) at least one R-AD has at least one an 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 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 R-AD and R-UMH both carry the Extranet Separation Extended
community, or neither carries the Extranet Separation extended Community, or neither carries the Extranet Separation Extended
community. Community.
The PTA of R-AD specifies the P-tunnel over which traffic of the The PTA of R-AD specifies the P-tunnel over which traffic of the
given C-flow is expected. given C-flow is expected.
o If the selected upstream AS is not the local AS, and if segmented o If the selected upstream AS is not the local AS, and if segmented
Inter-AS P-tunnels are being used to instantiate I-PMSIs, then 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, 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 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 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 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 import RT of the local VRF, and (d) either R-AD and R-UMH both
carry the Extranet Separation extended community, or neither carry the Extranet Separation Extended Community, or neither
carries the Extranet Separation extended community. carries the Extranet Separation Extended Community.
The PTA of R-AD specifies the P-tunnel over which traffic of the The PTA of R-AD specifies the P-tunnel over which traffic of the
given C-flow is expected. given C-flow is expected.
7.5. Packets Arriving from the Wrong P-tunnel 7.5. Packets Arriving from the Wrong P-tunnel
Any packets that arrive on a P-tunnel other than the expected 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 P-tunnel (as defined in Section 7.4) MUST be discarded, unless it is
know that all the packets carried by both P-tunnels are from the same know 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 ingress VRF. (See Section 2.3.1 for a more detailed discussion of
skipping to change at page 55, line 7 skipping to change at page 55, line 7
and the site(s) that contain the extranet receiver(s) may be and the site(s) that contain the extranet receiver(s) may be
connected to the same PE. In this scenario, the procedures by which connected to the same PE. In this scenario, the procedures by which
(multicast) traffic from these sources is delivered to these (multicast) traffic from these sources is delivered to these
receivers is a local matter to the PE, and outside the scope of this receivers is a local matter to the PE, and outside the scope of this
document. document.
An implementation MUST support multiple extranet VRFs on a PE. An implementation MUST support multiple extranet VRFs on a PE.
9. IANA Considerations 9. IANA Considerations
IANA is requested to allocate two new codepoints from the "Transitive IANA is requested to allocate two new codepoints from the "First
Opaque Extended Community Sub-Types" Registry: Come, First Served" range of the "Transitive Opaque Extended
Community Sub-Types" Registry (under the top-level registry: "Border
Gateway Protocol (BGP) Extended Communities"). [TO BE REMOVED: This
registration should take place at the following location:
http://www.iana.org/assignments/bgp-extended-communities/bgp-
extended-communities.xhtml#trans-opaque]
o A codepoint for "Extranet Source Extended Community" o A codepoint for "Extranet Source Extended Community"
o A codepoint for "Extranet Separation Extended Community" o A codepoint for "Extranet Separation Extended Community"
10. Security Considerations 10. Security Considerations
The security considerations of [RFC6513] and [RFC6514] are The security considerations of [RFC6513] and [RFC6514] are
applicable. applicable.
skipping to change at page 56, line 22 skipping to change at page 56, line 27
that route. This may result in VPN security violations. Service that route. This may result in VPN security violations. Service
providers who offer the extranet MVPN service must make sure that providers who offer the extranet MVPN service must make sure that
this is clearly understood by the customers who administer the this is clearly understood by the customers who administer the
distribution of routes from CE to PE routers. distribution of routes from CE to PE routers.
If the address ambiguities described in Sections 2.1 and 2.2 are not If the address ambiguities described in Sections 2.1 and 2.2 are not
prohibited by policy, VRFs MUST be able to discard traffic that prohibited by policy, VRFs MUST be able to discard traffic that
arrives on the wrong P-tunnel; otherwise VPN security violations may arrives on the wrong P-tunnel; otherwise VPN security violations may
occur. occur.
Section 4.4 specifies the OPTIONAL use of a new extended community, Section 4.4 specifies the OPTIONAL use of a new Extended Community,
the Extranet Source extended community. Security considerations the Extranet Source Extended Community. Security considerations
regarding the use and distribution of that extended community are regarding the use and distribution of that Extended Community are
discussed in that section. discussed in that section.
11. Acknowledgments 11. Acknowledgments
The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini
Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt
Windisch for their contributions to this work. Windisch for their contributions to this work.
We also wish to thank Lizhong Jin and Rishabh Parekh for their We also wish to thank Lizhong Jin and Rishabh Parekh for their
reviews and comments. reviews and comments.
skipping to change at page 57, line 39 skipping to change at page 57, line 39
Diegem 1831 Diegem 1831
Belgium Belgium
Email: ice@cisco.com Email: ice@cisco.com
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
VPNs", RFC 6513, February 2012. 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 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
"Wildcards in Multicast VPN Auto-Discovery Routes", RFC Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
6625, May 2012. RFC 6625, DOI 10.17487/RFC6625, May 2012,
<http://www.rfc-editor.org/info/rfc6625>.
13.2. Informative References 13.2. Informative References
[MVPN-IR] Rosen, E., Subramanian, K., and Z. Zhang, "Ingress [MVPN-IR] Rosen, E., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", internet-draft Replication Tunnels in Multicast VPN", internet-draft
draft-ietf-bess-ir-01, May 2015. draft-ietf-bess-ir-01, May 2015.
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol Multicast (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January 2003. (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003,
<http://www.rfc-editor.org/info/rfc3446>.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Protocol (MSDP)", RFC 3618, October 2003. 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 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610, August 2006. Independent Multicast (PIM)", RFC 4610,
DOI 10.17487/RFC4610, August 2006,
<http://www.rfc-editor.org/info/rfc4610>.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
"Extensions to Resource Reservation Protocol - Traffic Yasukawa, Ed., "Extensions to Resource Reservation
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Switched Paths (LSPs)", RFC 4875, May 2007. 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, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. 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, [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent "Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, January 2008. Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January
2008, <http://www.rfc-editor.org/info/rfc5059>.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
"Label Distribution Protocol Extensions for Point-to- Thomas, "Label Distribution Protocol Extensions for Point-
Multipoint and Multipoint-to-Multipoint Label Switched to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<http://www.rfc-editor.org/info/rfc6388>.
Authors' Addresses Authors' Addresses
Yakov Rekhter (editor) Yakov Rekhter (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
United States United States
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
 End of changes. 54 change blocks. 
90 lines changed or deleted 114 lines changed or added

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