draft-ietf-bess-mvpn-extranet-04.txt   draft-ietf-bess-mvpn-extranet-05.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: May 20, 2016 Arktan Expires: June 23, 2016 Arktan
Y. Cai Y. Cai
Microsoft Microsoft
T. Morin T. Morin
Orange Orange
November 17, 2015 December 21, 2015
Extranet Multicast in BGP/IP MPLS VPNs Extranet Multicast in BGP/IP MPLS VPNs
draft-ietf-bess-mvpn-extranet-04 draft-ietf-bess-mvpn-extranet-05
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 May 20, 2016. This Internet-Draft will expire on June 23, 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 3, line 8 skipping to change at page 3, line 8
Matching C-RPs and DRs . . . . . . . . . . . . . . . . . 23 Matching C-RPs and DRs . . . . . . . . . . . . . . . . . 23
4.3. Route Targets and Ambiguous 4.3. Route Targets and Ambiguous
UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 24 UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 24
4.4. Dynamically Marking Extranet 4.4. Dynamically Marking Extranet
Routes . . . . . . . . . . . . . . . . . . . . . . . . . 26 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1. The Extranet Source Extended 4.4.1. The Extranet Source Extended
Community . . . . . . . . . . . . . . . . . . . . . . 26 Community . . . . . . . . . . . . . . . . . . . . . . 26
4.4.2. Distribution of Extranet Source Extended 4.4.2. Distribution of Extranet Source Extended
Community . . . . . . . . . . . . . . . . . . . . . . 27 Community . . . . . . . . . . . . . . . . . . . . . . 27
4.5. The 'Extranet Separation' Extended Community . . . . . . 28 4.5. The 'Extranet Separation' Extended Community . . . . . . 28
5. Origination and Distribution of BGP A-D Routes . . . . . . . 28 5. Origination and Distribution of BGP A-D Routes . . . . . . . 29
5.1. Route Targets of UMH-eligible Routes and A-D 5.1. Route Targets of UMH-eligible Routes and A-D
Routes . . . . . . . . . . . . . . . . . . . . . . . . . 28 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Considerations for Particular Inclusive Tunnel 5.2. Considerations for Particular Inclusive Tunnel
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1. RSVP-TE P2MP or Ingress 5.2.1. RSVP-TE P2MP or Ingress
Replication . . . . . . . . . . . . . . . . . . . . . 31 Replication . . . . . . . . . . . . . . . . . . . . . 31
5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 31 5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 32
6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 33 6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 33
6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 34 6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 34
6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 34 6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 34
6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 35 6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 35
6.1.3. PIM C-Instance Reverse Path Forwarding 6.1.3. PIM C-Instance Reverse Path Forwarding
Determination . . . . . . . . . . . . . . . . . . . . 35 Determination . . . . . . . . . . . . . . . . . . . . 35
6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 35 6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 36
6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 35 6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 36
6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 38 6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 40 6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 40
6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 40 6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 41
6.2.5. Sending and Receiving Data Packets . . . . . . . . . 40 6.2.5. Sending and Receiving Data Packets . . . . . . . . . 41
6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 41 6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 41
6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 41 6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 42
7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 43 7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 43
7.1. Originating C-multicast Routes . . . . . . . . . . . . . 43 7.1. Originating C-multicast Routes . . . . . . . . . . . . . 44
7.2. Originating A-D Routes Without Extranet 7.2. Originating A-D Routes Without Extranet
Separation . . . . . . . . . . . . . . . . . . . . . . . 44 Separation . . . . . . . . . . . . . . . . . . . . . . . 44
7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 44 7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 44
7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 45 7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 45
7.2.3. Source Active A-D Routes . . . . . . . . . . . . . . 45 7.2.3. Source Active A-D Routes . . . . . . . . . . . . . . 46
7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 45 7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 46
7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 46 7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 46
7.3. Originating A-D Routes With Extranet Separation . . . . . 46 7.3. Originating A-D Routes With Extranet Separation . . . . . 47
7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 46 7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 47
7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 47 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 . . . . . . . . . . . . . 51 7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52
7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 51 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 . . . . . . . . 54 7.5. Packets Arriving from the Wrong P-tunnel . . . . . . . . 54
8. Multiple Extranet VRFs on the same 8. Multiple Extranet VRFs on the same
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
10. Security Considerations . . . . . . . . . . . . . . . . . . . 55 10. Security Considerations . . . . . . . . . . . . . . . . . . . 56
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 57 12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 58
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.1. Normative References . . . . . . . . . . . . . . . . . . 58 13.1. Normative References . . . . . . . . . . . . . . . . . . 58
13.2. Informative References . . . . . . . . . . . . . . . . . 59 13.2. Informative References . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
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
skipping to change at page 5, line 43 skipping to change at page 5, line 43
o Host(C-S,A): the host (or if C-S is an "anycast address", the set o Host(C-S,A): the host (or if C-S is an "anycast address", the set
of hosts) denoted by the address C-S in the context of VPN-A. For of hosts) denoted by the address C-S in the context of VPN-A. For
example, if a particular C-source in VPN A has address C-S, then example, if a particular C-source in VPN A has address C-S, then
Host(C-S,A) refers to that C-source. Host(C-S,A) refers to that C-source.
o SAFI-n route: a BGP route whose Address Family Identifier (AFI) is o SAFI-n route: a BGP route whose Address Family Identifier (AFI) is
either 1 (IPv4) or 2 (IPv6), and whose Subsequent Address Family either 1 (IPv4) or 2 (IPv6), and whose Subsequent Address Family
Identifier (SAFI) is "n". Identifier (SAFI) is "n".
o PTA: PMSI Tunnel attribute [RFC6514].
Note that a given extranet C-source is not necessarily allowed to Note that a given extranet C-source is not necessarily allowed to
transmit to every extranet C-receiver; policy determines which transmit to every extranet C-receiver; policy determines which
extranet C-sources are allowed to transmit to which extranet extranet C-sources are allowed to transmit to which extranet
C-receivers. However, in the case of an extranet (ASM) C-group, all C-receivers. However, in the case of an extranet (ASM) C-group, all
transmitters to the group are allowed to transmit to all the transmitters to the group are allowed to transmit to all the
receivers of the group, and all the receivers of the group are receivers of the group, and all the receivers of the group are
allowed to receive from all transmitters to the group. allowed to receive from all transmitters to the group.
We say that a given VRF "contains" or "has" a multicast C-source (or We say that a given VRF "contains" or "has" a multicast C-source (or
that the C-source is "in" the VRF), if that C-source is in a site that the C-source is "in" the VRF), if that C-source is in a site
skipping to change at page 10, line 10 skipping to change at page 10, line 10
Depending on the type of P-tunnel used, it may also be necessary for Depending on the type of P-tunnel used, it may also be necessary for
Leaf A-D routes to be exported by one or more VPN-R VRFs and imported Leaf A-D routes to be exported by one or more VPN-R VRFs and imported
into a VPN-S VRF. into a VPN-S VRF.
There are no extranet-specific procedures governing the use and There are no extranet-specific procedures governing the use and
distribution of BGP C-Multicast routes. distribution of BGP C-Multicast routes.
If PIM is used as the PE-PE protocol for distributing C-multicast If PIM is used as the PE-PE protocol for distributing C-multicast
routing information, additional BGP A-D routes must be exported from routing information, additional BGP A-D routes must be exported from
the VPN-R VRFs and imported into the VPN-S VRFS, so that the VPN-S the VPN-R VRFs and imported into the VPN-S VRFs, so that the VPN-S
VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM
control messages. Details can be found in Section 6. control messages. Details can be found in Section 6.
The simple example above describes an extranet created from two The simple example above describes an extranet created from two
MVPNs, one of which contains extranet C-sources and one of which MVPNs, one of which contains extranet C-sources and one of which
contains extranet C-receivers. However, the procedures described in contains extranet C-receivers. However, the procedures described in
this document allow for much more complicated scenarios. this document allow for much more complicated scenarios.
For instance, an extranet may contain extranet C-sources and/or For instance, an extranet may contain extranet C-sources and/or
extranet C-receivers from an arbitrary number of VPNs, not just from extranet C-receivers from an arbitrary number of VPNs, not just from
skipping to change at page 26, line 23 skipping to change at page 26, line 23
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 (see [RFC4360], [RFC7153], and Section 9 of this document)
router advertises (via BGP) a route to a PE router, and the AFI/SAFI the "Extranet Source" Extended Community. When a CE router
of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source advertises (via BGP) a route to a PE router, and the AFI/SAFI of the
route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source
Extended Community MAY be attached to the route. The value field of 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. A PE router that interprets
this Extended Community MUST ignore the contents of the value field.
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
skipping to change at page 27, line 49 skipping to change at page 28, line 4
Extended Community on route R. If so, the procedures of the current Extended Community on route R. If so, the procedures of the current
Section are not followed. Section are not followed.
Otherwise, when the PE originates a VPN-IP route corresponding to Otherwise, when the PE originates a VPN-IP route corresponding to
route R, the PE MUST attach this Extended Community to that route. route R, the PE MUST attach this Extended Community to that route.
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). The value of the Extended Community MUST NOT be changed
by the route reflector.
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 (b) and (c) (see [RFC6513] Section 10). The value
of the Extended Community MUST NOT be changed by the ASBRs.
When a PE advertises (via BGP) IP routes to a CE, these routes MUST 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.
The rules for attaching the Extranet Source Extended Community to a
VPN-IP route, and the rules for propagating that Extended Community,
are needed in order to support the scenario in which a VPN contains
an Option (a) interconnect (see Section 10 of [RFC4364]). At the
Option (a) interconnect, the VPN-IP route gets translated back to an
IP route, and the RTs are stripped off before the IP route is
propagated. If the Extranet Source EC has also been stripped off,
there is no way for the router at the other end of the Option (a)
interconnect to know that the route represents an extranet source.
Thus the technique of using the Extranet Source EC to dynamically
signal that a particular route represents an extranet source will not
work correctly across an Option (a) interconnect unless the rules
this section are followed.
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 (see [RFC4360], [RFC7153], and
Section 9 of this document). This Extended Community is used only
when extranet separation is being used. Its value field MUST be set 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
skipping to change at page 53, line 29 skipping to change at page 53, line 49
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 Extended
and the "selected upstream AS" for the flow is determined from the Community of R-UMH, and the "selected upstream AS" for the flow is
Source AS Extended Community of R-UMH. determined from the 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 Extended Community of the installed UMH-
matching C-RP, where C-RP is the RP for the group C-G. The selected eligible route matching C-RP, where C-RP is the RP for the group C-G.
upstream AS for the flow is determined from the Source AS EC of that The selected upstream AS for the flow is determined from the Source
route. If the egress VRF does have a (C-S,C-G) Source Active A-D AS Extended Community of that route. If the egress VRF does have a
route installed, the selected upstream PE and upstream AS are (C-S,C-G) Source Active A-D route installed, the selected upstream PE
determined as specified in Section 7.4. In either case, let R-UMH be and upstream AS are determined as specified in Section 7.4. In
the installed UMH-eligible route matching C-S. 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 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
skipping to change at page 56, line 5 skipping to change at page 56, line 29
10. Security Considerations 10. Security Considerations
The security considerations of [RFC6513] and [RFC6514] are The security considerations of [RFC6513] and [RFC6514] are
applicable. applicable.
As is the case with any application of technology based upon As is the case with any application of technology based upon
[RFC4364], misconfiguration of the RTs may result in VPN security [RFC4364], misconfiguration of the RTs may result in VPN security
violations (i.e., may result in a packet being delivered to a VPN violations (i.e., may result in a packet being delivered to a VPN
where, according to policy, it is not supposed to go). where, according to policy, it is not supposed to go).
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 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 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 host in another. This is safe because the customer routes from a
given VPN do not pass into other VPNs. Even if there is overlapping given VPN do not pass into other VPNs. Even if there is overlapping
address space among VPNs, the routes that are known at any given VPN address space among VPNs, the routes that are known at any given VPN
site are unambiguous, as long as the address space of that VPN is site are unambiguous, as long as the address space of that VPN is
unambiguous. However, this is not necessarily true when extranet unambiguous. However, this is not necessarily true when extranet
service is provided. If an extranet C-receiver in VPN-R is to be 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, 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 then the address of the VPN-S extranet C-source must be imported into
skipping to change at page 58, line 43 skipping to change at page 59, line 5
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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 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, Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006, DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>. <http://www.rfc-editor.org/info/rfc4601>.
skipping to change at page 59, line 19 skipping to change at page 59, line 33
[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, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012, RFC 6625, DOI 10.17487/RFC6625, May 2012,
<http://www.rfc-editor.org/info/rfc6625>. <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>.
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-02, October 2015. draft-ietf-bess-ir-02, October 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, DOI 10.17487/RFC3446, January 2003, (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003,
 End of changes. 32 change blocks. 
45 lines changed or deleted 80 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/