draft-ietf-bess-mvpn-extranet-03.txt   draft-ietf-bess-mvpn-extranet-04.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: April 14, 2016 Arktan Expires: May 20, 2016 Arktan
Y. Cai Y. Cai
Microsoft Microsoft
T. Morin T. Morin
Orange Orange
October 12, 2015 November 17, 2015
Extranet Multicast in BGP/IP MPLS VPNs Extranet Multicast in BGP/IP MPLS VPNs
draft-ietf-bess-mvpn-extranet-03 draft-ietf-bess-mvpn-extranet-04
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 April 14, 2016. This Internet-Draft will expire on May 20, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1. Customer Multicast Control 1.2.1. Customer Multicast Control
Protocols . . . . . . . . . . . . . . . . . . . . . . 6 Protocols . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2. Provider Multicast Control 1.2.2. Provider Multicast Control
Protocols . . . . . . . . . . . . . . . . . . . . . . 7 Protocols . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Clarification on Use of Route 1.3. Clarification on Use of Route
Distinguishers . . . . . . . . . . . . . . . . . . . . . 7 Distinguishers . . . . . . . . . . . . . . . . . . . . . 7
1.4. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Extranets and Overlapping Address 2. Extranets and Overlapping Address
Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Ambiguity: P-tunnel with 2.1. Ambiguity: P-tunnel with
Extranet/Non-Extranet Flows . . . . . . . . . . . . . . . 12 Extranet/Non-Extranet Flows . . . . . . . . . . . . . . . 13
2.2. Ambiguity: P-tunnel with Multiple 2.2. Ambiguity: P-tunnel with Multiple
Extranet Flows . . . . . . . . . . . . . . . . . . . . . 14 Extranet Flows . . . . . . . . . . . . . . . . . . . . . 15
2.3. Preventing Misdelivery in These 2.3. Preventing Misdelivery in These
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 17 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1. Do Not Deliver Packets from the 'Wrong' P-tunnel . . 17 2.3.1. Do Not Deliver Packets from the 'Wrong' P-tunnel . . 17
2.3.2. Policies to Prevent Ambiguity on a P-tunnel . . . . . 18 2.3.2. Policies to Prevent Ambiguity on a P-tunnel . . . . . 19
3. Extranet Transmission Models . . . . . . . . . . . . . . . . 20 3. Extranet Transmission Models . . . . . . . . . . . . . . . . 20
3.1. Transmitting an Extranet C-flow on a Single PMSI . . . . 20 3.1. Transmitting an Extranet C-flow on a Single PMSI . . . . 20
3.1.1. Without Extranet Separation . . . . . . . . . . . . . 21 3.1.1. Without Extranet Separation . . . . . . . . . . . . . 21
3.1.2. With Extranet Separation . . . . . . . . . . . . . . 21 3.1.2. With Extranet Separation . . . . . . . . . . . . . . 21
3.2. Transmitting an Extranet C-flow over Multiple PMSIs . . . 21 3.2. Transmitting an Extranet C-flow over Multiple PMSIs . . . 21
4. Distribution of Routes that Match 4. Distribution of Routes that Match
C-S/C-RP Addresses . . . . . . . . . . . . . . . . . . . . . 22 C-S/C-RP Addresses . . . . . . . . . . . . . . . . . . . . . 22
4.1. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 22 4.1. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 22
4.1.1. Extranet Separation . . . . . . . . . . . . . . . . . 23 4.1.1. Extranet Separation . . . . . . . . . . . . . . . . . 23
4.2. Distribution of Unicast Routes 4.2. Distribution of Unicast Routes
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 . . . . . . . . . . . . . . . . . . . . . . . . . 25 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1. The Extranet Source Extended 4.4.1. The Extranet Source Extended
Community . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . 27 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 . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Considerations for Particular Inclusive Tunnel 5.2. Considerations for Particular Inclusive Tunnel
Types . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1. RSVP-TE P2MP or Ingress 5.2.1. RSVP-TE P2MP or Ingress
Replication . . . . . . . . . . . . . . . . . . . . . 30 Replication . . . . . . . . . . . . . . . . . . . . . 31
5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 31 5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 31
6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 32 6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 33
6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 33 6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 34
6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 33 6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 34
6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . . . . . . 34 Determination . . . . . . . . . . . . . . . . . . . . 35
6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 35 6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 35
6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 35 6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 35
6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 38 6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 39 6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 40
6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 39 6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 40
6.2.5. Sending and Receiving Data Packets . . . . . . . . . 40 6.2.5. Sending and Receiving Data Packets . . . . . . . . . 40
6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 40 6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 41
6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 41 6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 41
7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 42 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 . . . . . . . . . . . . . 43
7.2. Originating A-D Routes Without Extranet 7.2. Originating A-D Routes Without Extranet
Separation . . . . . . . . . . . . . . . . . . . . . . . 43 Separation . . . . . . . . . . . . . . . . . . . . . . . 44
7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 43 7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 44
7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 44 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 . . . . . . . . . . . . . . 45
7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 45 7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 45
7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 45 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 . . . . . 46
7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 46 7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 46
7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 47 7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 47
7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 48 7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 49
7.4. Determining the Expected P-tunnel for a C-flow . . . . . 48 7.4. Determining the Expected P-tunnel for a C-flow . . . . . 49
7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 50 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 . . . . . . . . . . . . . 51
7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 51 7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 51
7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52 7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 53
7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 52 7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 53
7.5. Packets Arriving from the Wrong P-tunnel . . . . . . . . 53 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
10. Security Considerations . . . . . . . . . . . . . . . . . . . 55 10. Security Considerations . . . . . . . . . . . . . . . . . . . 55
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 56 12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 57
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.1. Normative References . . . . . . . . . . . . . . . . . . 57 13.1. Normative References . . . . . . . . . . . . . . . . . . 58
13.2. Informative References . . . . . . . . . . . . . . . . . 58 13.2. Informative References . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 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
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 4, line 43 skipping to change at page 4, line 43
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 Table (VRF), 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
an S-PMSI A-D route being "installed". That is, we say that an a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route
S-PMSI A-D route is "installed" (in a given VRF) if it has been being "installed". That is, we say that an S-PMSI A-D route is
selected by the BGP decision process as the preferred route for its "installed" (in a given VRF) if it has been selected by the BGP
NLRI. We also follow the terminology of Section 3.2 of [RFC6625] decision process as the preferred route for its NLRI. We also follow
when saying that an S-PMSI A-D route has been "originated by a given the terminology of Section 3.2 of [RFC6625] when saying that an
PE"; this means that the given PE's IP address is contained in the S-PMSI A-D route has been "originated by a given PE"; this means that
"Originating Router's IP Address" field in the NLRI of the route. the given PE's IP address is contained in the "Originating Router's
IP Address" field in the NLRI of the route.
We use the following additional terminology and notation: We use the following additional terminology and notation:
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) whose source is an extranet C-source,
and which is allowed by policy to have extranet C-receivers. and which is allowed by policy to have extranet C-receivers.
o Extranet C-group: a multicast group address that is in the "Any o Extranet C-group: a multicast group address that is in the "Any
Source Multicast" (ASM) group address range, and that is allowed Source Multicast" (ASM) group address range, and that is allowed
by policy to have Extranet C-sources and Extranet C-receivers that by policy to have Extranet C-sources and Extranet C-receivers that
are not all in the same VPN. Note that we will sometimes refer to are not all in the same VPN. Note that we will sometimes refer to
"SSM C-group addresses" (i.e., to C-group addresses in the SSM "Source-Specific Multicast" (SSM) C-group addresses" (i.e., to
group address range), but will never call them "extranet C-group addresses in the SSM group address range), but will never
C-groups". 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
to be an extranet C-source, and any receiver of traffic addressed to be an extranet C-source, and any receiver of traffic addressed
to an extranet C-group is considered to be an extranet C-receiver. to an extranet C-group is considered to be an extranet C-receiver.
o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet
C-group; it is allowed by policy to receive PIM register messages C-group; it is allowed by policy to receive PIM register messages
[RFC4601] from outside its VPN, and to send multicast data packets [RFC4601] from outside its VPN, and to send multicast data packets
to extranet C-receivers outside its VPN. to extranet C-receivers outside its VPN.
skipping to change at page 6, line 40 skipping to change at page 6, line 40
any, is considered to be part of the tunnel identifier.) any, is considered to be part of the tunnel identifier.)
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).
We use the term "VPN security violation" to refer to any situation in
which a packet is delivered to a particular VPN, even though, by
policy, it should not be delivered to that VPN.
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" in this document are to be interpreted as described in "OPTIONAL" in this document are 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
skipping to change at page 7, line 41 skipping to change at page 7, line 49
[RFC4364] allows a given RD to be associated with more than one VRF, [RFC4364] allows a given RD to be associated with more than one VRF,
as long as all the VRFs associated with that RD belong to the same as long as all the VRFs associated with that RD belong to the same
VPN. However, in the most common deployment model, each RD is VPN. However, in the most common deployment model, each RD is
associated with one and only one VRF. [RFC6513] and [RFC6514] associated with one and only one VRF. [RFC6513] and [RFC6514]
presuppose this deployment model. That is, [RFC6513] and [RFC6514] presuppose this deployment model. That is, [RFC6513] and [RFC6514]
presuppose that every RD is associated with one and only one VRF. We presuppose that every RD is associated with one and only one VRF. We
will call this the "unique VRF per RD" condition. will call this the "unique VRF per RD" condition.
[RFC6514] defines the MCAST-VPN address family, which has a number of [RFC6514] defines the MCAST-VPN address family, which has a number of
route types. Each Intra-AS I-PMSI A-D route, S-PMSI A-D route, and route types. Each Intra-AS "Inclusive Provider Multicast Service
Source Active A-D route, when exported from a given VRF, contains, in Interface" (I-PMSI) A-D route, S-PMSI A-D route, and Source Active
its NLRI, an RD that is associated with the VRF. [RFC6513] and A-D route, when exported from a given VRF, contains, in its NLRI, an
[RFC6514] also discuss a class of routes known as "UMH-eligible" RD that is associated with the VRF. [RFC6513] and [RFC6514] also
routes; when a UMH-eligible route is exported from a given VRF, its discuss a class of routes known as "UMH-eligible" routes; when a UMH-
NLRI contains an RD of the VRF. eligible route is exported from a given VRF, its NLRI contains an RD
of the VRF.
[RFC6514] also defines MCAST-VPN routes whose NLRIs do not contain an [RFC6514] also defines MCAST-VPN routes whose NLRIs do not contain an
RD of the VRF from which they are exported: the C-multicast Join RD of the VRF from which they are exported: the C-multicast Join
routes and the Leaf A-D routes. routes and the Leaf A-D routes.
Those route types that, when exported from a given VRF, contain (in Those route types that, when exported from a given VRF, contain (in
their NLRIs) an RD of the VRF, will be known in this document as their NLRIs) an RD of the VRF, will be known in this document as
"local-RD routes". "local-RD routes".
Given the "unique VRF per RD condition", if one sees that two local- Given the "unique VRF per RD condition", if one sees that two local-
RD routes have the same RD, one can infer that the two routes RD routes have the same RD, one can infer that the two routes
originated from the same VRF. This inference can be drawn even if originated from the same VRF. This inference can be drawn even if
the two routes do not have the same SAFI, as long as the two routes the two routes do not have the same SAFI, as long as the two routes
are both local-RD routes. are both local-RD routes.
This document builds upon [RFC6513] and [RFC6514], and therefore This document builds upon [RFC6513] and [RFC6514]; therefore the
REQUIREs the "unique VRF per RD" condition. "unique VRF per RD" condition is REQUIRED.
[RFC6514] presupposes a further requirement on the use of RDs in the [RFC6514] presupposes a further requirement on the use of RDs in the
local-RD routes exported from a given VRF. Suppose a given VRF local-RD routes exported from a given VRF. Suppose a given VRF
exports a Source Active A-D route containing (C-S,C-G). That VRF exports a Source Active A-D route containing (C-S,C-G). That VRF
will also export a UMH-eligible route matching C-S. [RFC6514] will also export a UMH-eligible route matching C-S. [RFC6514]
presupposes that the UMH-eligible route and the Source Active A-D presupposes that the UMH-eligible route and the Source Active A-D
route have the same RD. route have the same RD.
In most cases, not only is a given RD associated with a single VRF, In most cases, not only is a given RD associated with only a single
but a given VRF is associated with a single RD. We will call this VRF, but a given VRF is associated with only a single RD. We will
the "unique RD per VRF" condition. When this condition holds, all call this the "unique RD per VRF" condition. When this condition
the local-RD routes exported from a given VRF will have the same RD. holds, all the local-RD routes exported from a given VRF will have
This ensures that the presupposition of the previous paragraph will the same RD. This ensures that the presupposition of the previous
hold, i.e., that the RD in a Source Active A-D route exported from a paragraph will hold, i.e., that the RD in a Source Active A-D route
given VRF will have the same RD as the corresponding UMH-eligible exported from a given VRF will have the same RD as the corresponding
route exported from the same VRF. UMH-eligible route exported from the same VRF.
Section 7.3 of this document describes a procedure known as "Extranet Section 7.3 of this document describes a procedure known as "Extranet
Separation". When Extranet Separation is NOT being used, this Separation". When Extranet Separation is NOT being used, it is
document REQUIREs that the "unique RD per VRF" condition hold. This REQUIRED by this document that the "unique RD per VRF" condition
ensures that all the local-RD routes exported from a given VRF will hold. This ensures that all the local-RD routes exported from a
have the same RD. given VRF will have the same RD.
When Extranet Separation is used, a VRF that contains both extranet When Extranet Separation is used, a VRF that contains both extranet
sources and non-extranet sources MUST be configured with two RDs: the sources and non-extranet sources MUST be configured with two RDs.
"default RD" (discussed above) and the "extranet RD". The "unique One of these RDs is known as the "default RD", and the other is known
VRF per RD" condition also applies to the "extranet RD", i.e., a as the "extranet RD". It MUST be known by configuration which RD is
given extranet RD is associated with a unique VRF. Details the default RD and which is the extranet RD.
concerning the exported routes that contain the extranet RD can be
found in Sections 4.1 and 7.3. When a VRF is configured with only one RD, we will refer to that RD
as the "default RD".
In general, local-RD routes exported from a given VRF will contain
the default RD. However, when Extranet Separation is used, some of
the local-RD routes exported from the VRF will contain the extranet
RD. Details concerning the exported routes that contain the extranet
RD can be found in Sections 4.1 and 7.3.
Note that the "unique VRF per RD" condition applies to the extranet
RD as well as to the default RD. That is, a given extranet RD is
associated with a unique VRF.
1.4. Overview 1.4. Overview
Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN
functionality as specified in [RFC6513] and/or [RFC6514]. In the functionality as specified in [RFC6513] and/or [RFC6514]. In the
simplest configuration, VPN-S is a collection of VRFs, each of which simplest configuration, VPN-S is a collection of VRFs, each of which
is configured with a particular Route Target (RT) value (call it "RT- is configured with a particular Route Target (RT) value (call it "RT-
S") as its import RT and as its export RT. Similarly, VPN-R is a S") as its import RT and as its export RT. Similarly, VPN-R is a
collection of VRFs, each of which is configured with a particular RT collection of VRFs, each of which is configured with a particular RT
value (call it "RT-R") as its import RT and as its export RT. value (call it "RT-R") as its import RT and as its export RT.
skipping to change at page 11, line 6 skipping to change at page 11, line 24
document.) See the "Security Considerations" section (Section 10) document.) See the "Security Considerations" section (Section 10)
for additional discussion of this issue. for additional discussion of this issue.
2. Extranets and Overlapping Address Spaces 2. Extranets and Overlapping Address Spaces
As specified in [RFC4364], the address space of one VPN may overlap As specified in [RFC4364], the address space of one VPN may overlap
with the address space of another. A given address may be with the address space of another. A given address may be
"ambiguous", in that it denotes one system within VPN-A and a "ambiguous", in that it denotes one system within VPN-A and a
different system within VPN-B. In the notation of Section 1.1, if an different system within VPN-B. In the notation of Section 1.1, if an
address C-S is ambiguous between VPNs A and B, then Host(C-S,A) != address C-S is ambiguous between VPNs A and B, then Host(C-S,A) !=
Host(C-S,B). However, any given address C-S must be unambiguous Host(C-S,B). However, any given address C-S MUST be unambiguous
(i.e., denotes a single system) in the context of a given VPN. (i.e., MUST denote a single system) in the context of a given VPN.
When a set of VRFs belonging to different VPNs are combined into an When a set of VRFs belonging to different VPNs are combined into an
extranet, it is no longer sufficient for an address to be unambiguous extranet, it is no longer sufficient for an address to be unambiguous
only within the context of a single VPN: only within the context of a single VPN:
1. Suppose C-S is the address of a given extranet C-source contained 1. Suppose C-S is the address of a given extranet C-source contained
in VPN-A. Now consider the set of VPNs {VPN-B, VPN-C, ...} in VPN-A. Now consider the set of VPNs {VPN-B, VPN-C, ...}
containing extranet C-receivers that are allowed by policy to containing extranet C-receivers that are allowed by policy to
receive extranet C-flows from VPN-A's C-S. The address C-S MUST receive extranet C-flows from VPN-A's C-S. The address C-S MUST
be unambiguous among this entire set of VPNs (VPN-A, VPN-B, VPN- be unambiguous among this entire set of VPNs (VPN-A, VPN-B, VPN-
skipping to change at page 12, line 29 skipping to change at page 12, line 47
multicast data packets whose source and/or group addresses are multicast data packets whose source and/or group addresses are
ambiguous in the context of the set of PEs that receive data from the ambiguous in the context of the set of PEs that receive data from the
P-tunnel. That is, the above rules and restrictions are necessary, P-tunnel. That is, the above rules and restrictions are necessary,
but not sufficient, to prevent address ambiguity from causing but not sufficient, to prevent address ambiguity from causing
misdelivery of traffic. To prevent such misdelivery, additional misdelivery of traffic. To prevent such misdelivery, 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 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
In the following, we will use the notation "VRF A-n" to mean "VRF n In the following, we will use the notation "VRF A-n" to mean "VRF n
of VPN-A". of VPN-A".
If VPN-A and VPN-B have overlapping address spaces, and are part of If VPN-A and VPN-B have overlapping address spaces, and are part of
the same extranet, then the following problem may exist, as the same extranet, then the following problem may exist, as
skipping to change at page 22, line 16 skipping to change at page 22, line 19
model when PIM as the PE-PE C-multicast control protocol. Support model when PIM as the PE-PE C-multicast control protocol. Support
for this transmission model when BGP is used as the PE-PE C-multicast for this transmission model when BGP is used as the PE-PE C-multicast
control protocol is outside the scope of this document. control protocol is outside the scope of this document.
4. Distribution of Routes that Match C-S/C-RP Addresses 4. Distribution of Routes that Match C-S/C-RP Addresses
4.1. UMH-Eligible Routes 4.1. UMH-Eligible Routes
As described in Section 5.1 of [RFC6513], in order for a C-flow As described in Section 5.1 of [RFC6513], in order for a C-flow
(C-S,C-G) to be carried across the SP backbone, a VRF that has (C-S,C-G) to be carried across the SP backbone, a VRF that has
multicast receivers for that C-flow MUST import a route that matches multicast receivers for that C-flow must import a route that matches
C-S, and this route must be "eligible for UMH selection". In this C-S, and this route must be "eligible for UMH selection". In this
document, we will refer to these routes as "UMH-eligible extranet document, we will refer to these routes as "UMH-eligible extranet
C-source routes". C-source routes".
The UMH-eligible extranet C-source routes do not necessarily have to The UMH-eligible extranet C-source routes do not necessarily have to
be unicast routes. If one wants, e.g., a VPN-R C-receiver to be able be unicast routes; they MAY be SAFI-129 routes (see Section 5.1.1 of
to receive extranet C-flows from C-sources in VPN-S, but one does not [RFC6513]). For example, suppose one wants a VPN-R C-receiver to be
want any VPN-R system to be able to send unicast traffic to those able to receive extranet C-flows from C-sources in VPN-S, but one
C-sources, then the UMH-eligible routes exported from VPN-S and does not want any VPN-R system to be able to send unicast traffic to
imported by VPN-R MAY be SAFI-129 routes (see Section 5.1.1 of those C-sources. One can achieve this by using SAFI-129 routes as
[RFC6513]). The SAFI-129 routes are used only for UMH determination, the UMH-eligible routes exported from VPN-S and imported by VPN-R.
but not for unicast routing. Since SAFI-129 routes are used only for UMH determination, but not
for unicast routing, this allows the multicast traffic to be
forwarded properly, but does not create unicast routes to the
C-sources.
If a customer is using PIM-SM in ASM mode, and one or more customer If a customer is using PIM-SM in ASM mode, and one or more customer
sites have C-receivers that are allowed by policy to join a (C-*,C-G) 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-receivers 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 matches C-RP, for that group MUST import a UMH-eligible route that matches C-RP,
where C-RP is the Rendezvous Point (RP) address for C-G. where C-RP is the Rendezvous Point (RP) address 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 prefixes are not 32 bits in length, or whose IPv6 address prefixes
skipping to change at page 23, line 42 skipping to change at page 23, line 48
In order to follow the procedures of [RFC4601], In order to follow the procedures of [RFC4601],
o the "first hop designated router" (DR) of C-S needs to be able to o the "first hop designated router" (DR) of C-S needs to be able to
unicast "PIM Register Messages" to a C-RP that services C-G; unicast "PIM Register Messages" to a C-RP that services C-G;
o the C-RPs servicing C-G need to be able to unicast "PIM Register- o the C-RPs servicing C-G need to be able to unicast "PIM Register-
Stop Messages" to the DR of C-S. Stop Messages" to the DR of C-S.
It follows that if a VRF contains C-S, but does not contain a C-RP It follows that if a VRF contains C-S, but does not contain a C-RP
for C-G, then the VRF must import a unicast route matching a C-RP for for C-G, then the VRF MUST import a unicast route matching a C-RP for
C-G. Note that the unicast route matching the C-RP is needed whether C-G. Note that the unicast route matching the C-RP is needed whether
or not the VRF has also imported a SAFI-129 route matching the C-RP. or not the VRF has also imported a SAFI-129 route matching the C-RP.
(If the VRF also contains receivers for C-G, and if UMH determination (If the VRF also contains receivers for C-G, and if UMH determination
is being done using SAFI-129 routes, both a unicast route and a is being done using SAFI-129 routes, both a unicast route and a
SAFI-129 matching C-RP route are needed.) SAFI-129 matching C-RP route are needed.)
Similarly, if a VRF contains a C-RP for C-G, but does not contain Similarly, if a VRF contains a C-RP for C-G, but does not contain
C-S, the VRF must import a unicast route matching the DR for C-S. C-S, the VRF MUST import a unicast route matching the DR for C-S.
Note that the unicast route matching the DR for C-S is needed even if Note that the unicast route matching the DR for C-S is needed even if
UMH determination is being done using SAFI-129 routes; in that case, UMH determination is being done using SAFI-129 routes; in that case,
if the VRF also contains receivers for C-G, it needs to import a if the VRF also contains receivers for C-G, it needs to import a
SAFI-129 route matching C-S and a unicast route matching the DR for SAFI-129 route matching C-S and a unicast route matching the DR for
C-S. C-S.
If, for a particular extranet C-group, C-G, the customer is using If, for a particular extranet C-group, C-G, the customer is using
"anycast-RP"([RFC3446], [RFC4610]) or MSDP [RFC3618], then all the "anycast-RP"([RFC3446], [RFC4610]) or MSDP [RFC3618], then all the
C-RPs serving C-G need to send unicast messages to each other. Thus C-RPs serving C-G need to send unicast messages to each other. Thus
any VRF that contains a C-RP for C-G needs to import unicast routes any VRF that contains a C-RP for C-G needs to import unicast routes
skipping to change at page 27, line 8 skipping to change at page 27, line 18
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.) A CE SHOULD NOT attach the Extranet Source Extended
Community to any route for which it uses another method of specifying
the RTs to be carried by that route. A CE SHOULD NOT attach the
Extranet Source Extended Community to a route unless all the extranet
routes from the CE's VPN are intended to carry the same set of RTs.
A PE SHOULD ignore the Extranet Source Extended Community if it
appears on a route that the CE should not have put it on. A PE that
ignores the Extranet Source Extended Community SHOULD NOT follow the
procedures of Section 4.4.2.
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 Suppose a PE receives from a CE a route, call it R, with the Extranet
Extended Community, the corresponding VPN-IP route originated by the Source Extended Community. The PE must determine (via the
PE MUST carry this Extended Community. considerations of Section 4.4.1) whether it should ignore that
Extended Community on route R. If so, the procedures of the current
Section are not followed.
Otherwise, when the PE originates a VPN-IP route corresponding to
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).
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).
skipping to change at page 28, line 24 skipping to change at page 28, line 50
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
Suppose there is an extranet C-flow such that: Suppose there is an extranet C-flow such that:
o The extranet C-source of that C-flow is in VRF A-1. o The extranet C-source of that C-flow is in VRF A-1.
o One or more extranet C-receivers of that C-flow are in VRF B-1. o One or more extranet C-receivers of that C-flow are in VRF B-1.
In this case VRF A-1 must export a UMH-eligible route that matches In this case VRF A-1 MUST export a UMH-eligible route that matches
the extranet C-source address, and VRF B-1 must import that route. the extranet C-source address, and VRF B-1 MUST import that route.
In addition, VRF A-1 must export an Intra-AS I-PMSI A-D route or an In addition, VRF A-1 MUST export an Intra-AS I-PMSI A-D route or an
S-PMSI A-D route specifying the P-tunnel through which it will send S-PMSI A-D route specifying the P-tunnel through which it will send
the data traffic of the given extranet C-flow, and VRF B-1 must the data traffic of the given extranet C-flow, and VRF B-1 MUST
import that route. If BGP is the PE-PE C-multicast control protocol, import that route. If BGP is the PE-PE C-multicast control protocol,
then under certain conditions (as specified in [RFC6514]), VRF A-1 then under certain conditions (as specified in [RFC6514]), VRF A-1
may also need to export a Source Active A-D route specifying that it may also need to export a Source Active A-D route specifying that it
contains a source of the given C-flow, and VRF B-1 must import that contains a source of the given C-flow, and VRF B-1 must import that
Source Active A-D route. That is, in order for VRF B-1 to receive a Source Active A-D route. That is, in order for VRF B-1 to receive a
C-flow from, a given extranet C-source contained in VRF A-1, VRF A-1 C-flow from, a given extranet C-source contained in VRF A-1, VRF A-1
must export a set of A-D routes that are "about" that source, and VRF MUST export a set of A-D routes that are "about" that source, and VRF
B-1 must import them. B-1 MUST import them.
One way to ensure this is to provision an RT that is carried by all One way to ensure this is to provision an RT that is carried by all
the routes exported from VRF A-1 that are "about" a given extranet the routes exported from VRF A-1 that are "about" a given extranet
C-source, and to provision this RT as an import RT at any VRF (such C-source, and to provision this RT as an import RT at any VRF (such
as VRF B-1) that is allowed to receive extranet flows from source. as VRF B-1) that is allowed to receive extranet flows from source.
If the "single PMSI per C-flow" transmission model is being used If the "single PMSI per C-flow" transmission model is being used
(with or without extranet separation), there is a an additional (with or without extranet separation), there is a an additional
requirement, stated below, on the way RTs are provisioned, as the RTs requirement, stated below, on the way RTs are provisioned, as the RTs
carried by a UMH-eligible route that matches a given extranet carried by a UMH-eligible route that matches a given extranet
skipping to change at page 30, line 36 skipping to change at page 31, line 12
and Section 7 for more details on determining the expected P-tunnel and Section 7 for more details on determining the expected P-tunnel
for a given extranet C-flow. for a given extranet C-flow.
While the assignment of import and export RTs to routes is a While the assignment of import and export RTs to routes is a
deployment and provisioning issue rather than a protocol issue, it deployment and provisioning issue rather than a protocol issue, it
should be understood that failure to follow these rules is likely to should be understood that failure to follow these rules is likely to
result in VPN security violations. result in VPN security violations.
5.2. Considerations for Particular Inclusive Tunnel Types 5.2. Considerations for Particular Inclusive Tunnel Types
An Inclusive Tunnel (sometimes referred to as an "Inclusive Tree",
see Section 2.1.1 of [RFC6513]) is a tunnel that, by default, carries
all the multicast traffic of a given MVPN that enters the backbone
network via a particular PE. An Inclusive Tunnel is advertised in
the PTA of an I-PMSI A-D route.
5.2.1. RSVP-TE P2MP or Ingress Replication 5.2.1. RSVP-TE P2MP or Ingress Replication
This section applies when Inclusive Tunnels are created using either This section applies when Inclusive Tunnels are created using either
RSVP-TE P2MP or Ingress Replication. RSVP-TE P2MP or Ingress Replication.
Suppose a VRF, VRF-S, contains a given extranet C-source C-S, and Suppose a VRF, VRF-S, contains a given extranet C-source C-S, and
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 RT(s) carried by the policy to receive extranet flows from C-S, the RT(s) carried by 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 44 skipping to change at page 32, line 27
1. One of the following three procedures MUST be followed: 1. One of the following three procedures MUST be followed:
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 is 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
lead to duplication of data. lead to duplication of data.
If it is desired to support extranet while also using IR to If it is desired to support extranet while also using IR to
instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs
instead of I-PMSIs. (See [RFC6625] and Sections 7.2.2, 7.3.2, and instead of I-PMSIs. (See [RFC6625], as well as Sections 7.2.2,
7.4.4 of this document.) This has much the same effect in the data 7.3.2, and 7.4.4 of this document.) This has much the same effect in
plane, and there are no restrictions on the type of unicast tunnel the data plane, and there are no restrictions on the type of unicast
that can be used for instantiating S-PMSIs. tunnel that can be used for instantiating S-PMSIs.
Section 6.4.5 of [RFC6513] describes a way to support VPNs using Section 6.4.5 of [RFC6513] describes a way to support VPNs using
I-PMSIs that are instantiated by IR, using no S-PMSIs, but using I-PMSIs that are instantiated by IR, using no S-PMSIs, but using
"explicit tracking" to ensure that a C-flow goes only to egress PEs "explicit tracking" to ensure that a C-flow goes only to egress PEs
that have receivers for it. This document does not provide that have receivers for it. This document does not provide
procedures to support extranet using that model. procedures to support extranet using that model.
6. When PIM is the PE-PE C-multicast Control Plane 6. When PIM is the PE-PE C-multicast Control Plane
As specified in [RFC6513], when PIM is used as the PE-PE C-multicast As specified in [RFC6513], when PIM is used as the PE-PE C-multicast
control plane for a particular MVPN, there is an MI-PMSI for that control plane for a particular MVPN, there is a "Multidirectional
Inclusive Provider Multicast Serivce Interface" (MI-PMSI) for that
MVPN, and all the PEs of that MVPN must be able to send and receive MVPN, and all the PEs of that MVPN must be able to send and receive
on that MI-PMSI. Associated with each VRF of the MVPN is a PIM on that MI-PMSI. Associated with each VRF of the MVPN is a PIM
C-instance, and the PIM C-instance treats the MI-PMSI as if it were a C-instance, and the PIM C-instance treats the MI-PMSI as if it were a
LAN interface. That is, the "ordinary" PIM procedures run over the LAN interface. That is, the "ordinary" PIM procedures run over the
MI-PMSI just as they would over a real LAN interface, except that the MI-PMSI just as they would over a real LAN interface, except that the
data plane and control plane "RPF checks" need to be modified. data plane and control plane "RPF checks" need to be modified.
Section 5.2 of [RFC6513] specifies the RPF check modifications for Section 5.2 of [RFC6513] specifies the RPF check modifications for
non-extranet MVPN service. non-extranet MVPN service.
For example, suppose that there are two VPNs, VPN-S and VPN-R. In For example, suppose that there are two VPNs, VPN-S and VPN-R. In
skipping to change at page 33, line 38 skipping to change at page 34, line 23
In the absence of extranet service, suppose that each VRF of a given In the absence of extranet service, suppose that each VRF of a given
VPN, call it VPN-S, is configured with RT-S as its import and export VPN, call it VPN-S, is configured with RT-S as its import and export
RT, and that each VRF of a second VPN, call it VPN-R, is configured RT, and that each VRF of a second VPN, call it VPN-R, is configured
with RT-R as its import and export RT. We will refer to RT-S and with RT-R as its import and export RT. We will refer to RT-S and
RT-R as "non-extranet RTs". RT-R as "non-extranet RTs".
Now suppose that VPN-S contains some extranet C-sources, and VPN-R Now suppose that VPN-S contains some extranet C-sources, and VPN-R
contains some extranet C-receivers that are allowed by policy to contains some extranet C-receivers that are allowed by policy to
receive extranet C-flows from the VPN-S extranet C-sources. receive extranet C-flows from the VPN-S extranet C-sources.
To set up this S-to-R extranet, it is necessary to provision an To set up this S-to-R extranet, it is REQUIRED to provision an
additional RT, call it RT-S-to-R, whose value is, in general, additional RT, call it RT-S-to-R, whose value is, in general,
distinct from RT-S and RT-R. distinct from RT-S and RT-R.
A VPN-S VRF that contains extranet C-sources allowed to transmit to A VPN-S VRF that contains extranet C-sources allowed to transmit to
VPN-R must be configured with RT-S-to-R as an "Outgoing Extranet RT". VPN-R MUST be configured with RT-S-to-R as an "Outgoing Extranet RT".
A VPN-R VRF that contains extranet C-receivers allowed to received A VPN-R VRF that contains extranet C-receivers allowed to received
from VPN-S must be configured with RT-S-to-R as an "Incoming Extranet from VPN-S MUST be configured with RT-S-to-R as an "Incoming Extranet
RT". RT".
Note that the terms "Incoming" and "Outgoing" in this context refer Note that the terms "Incoming" and "Outgoing" in this context refer
to the direction of multicast data packets relative to the VRF. to the direction of multicast data packets relative to the VRF.
The Incoming Extranet RTs and Outgoing Extranet RTs that are The Incoming Extranet RTs and Outgoing Extranet RTs that are
configured for a given VRF serve as import RTs for that VRF. They configured for a given VRF serve as import RTs for that VRF. They
also serve as export RTs, but only for specific routes as specified also serve as export RTs, but only for specific routes as specified
in Section 6.1.2 below. in Section 6.1.2 below.
Note that any VRF that contains both extranet C-sources and extranet Note that any VRF that contains both extranet C-sources and extranet
C-receivers MUST be configured with both Outgoing and Incoming C-receivers MUST be configured with both Outgoing and Incoming
Extranet RTs. Extranet RTs.
A VRF may be configured with more than one Incoming and/or Outgoing A VRF MAY be configured with more than one Incoming and/or Outgoing
Extranet RT. Extranet RT.
If it happens to be the case that all C-sources in VPN-S are extranet If it happens to be the case that all C-sources in VPN-S are extranet
C-sources allowed to transmit to VPN-R, then VPN-S VRFs may be C-sources allowed to transmit to VPN-R, then VPN-S VRFs MAY be
configured such that RT-S is both a non-extranet RT and an Outgoing configured such that RT-S is both a non-extranet RT and an Outgoing
Extranet RT, and VPN-R VRFs may be configured such that RT-S is an Extranet RT, and VPN-R VRFs MAY be configured such that RT-S is an
Incoming Extranet RT. Incoming Extranet RT.
6.1.2. UMH-eligible Routes and RTs 6.1.2. UMH-eligible Routes and RTs
Suppose R1 is a route, exported from a VPN-S VRF, matching an Suppose R1 is a route, exported from a VPN-S VRF, matching an
extranet C-source that is allowed by policy to transmit to VPN-R. extranet C-source that is allowed by policy to transmit to VPN-R.
Then R1 MUST carry the Outgoing Extranet RT used for the S-to-R Then R1 MUST carry the Outgoing Extranet RT used for the S-to-R
extranet. This will cause the route to be imported into the VPN-R extranet. This will cause the route to be imported into the VPN-R
VRFs that have extranet C-receivers that are allowed by policy to VRFs that have extranet C-receivers that are allowed by policy to
receive from VPN-S. receive from VPN-S.
skipping to change at page 41, line 41 skipping to change at page 42, line 24
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,
carrying the non-extranet RT and all the Incoming Extranet RTs. carrying the non-extranet RT and all the Incoming Extranet RTs.
When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes
that carry the non-extranet RT or one of the Incoming Extranet RTs, that carry the non-extranet RT or one of the Incoming Extranet RTs,
the P-tunnels specified in the PTA of all such routes are considered the P-tunnels specified in the PTA of all such routes are considered
to be part of the same MI-PMSI. I.e., the associated PIM C-instance to be part of the same MI-PMSI. I.e., the associated PIM C-instance
will treat them as part of a single interface. will treat them as part of a single interface.
In this model, it is the VRF containing extranet C-sources that must In this model, it is the VRF containing extranet C-sources that MUST
originate multiple Intra-AS I-PMSI A-D routes. Each such route must originate multiple Intra-AS I-PMSI A-D routes. Each such route MUST
have a distinct RD, and the set of RTs carried by any one of these have a distinct RD, and the set of RTs carried by any one of these
routes must be disjoint from the set carried by any other. There routes MUST be disjoint from the set carried by any other. There
must be one such route for each of the VRF's Outgoing Extranet RTs, MUST be one such route for each of the VRF's Outgoing Extranet RTs,
and Each such route must carry exactly one of the VRF's Outgoing and each such route MUST carry exactly one of the VRF's Outgoing
Extranet RTs. The VRFs containing extranet C-sources MUST also Extranet RTs. The VRFs containing extranet C-sources MUST also
import all the A-D routes originated by the VRFs containing extranet import all the A-D routes originated by the VRFs containing extranet
C-receivers. If a set of originated and/or imported Intra-AS I-PMSI C-receivers. If a set of originated and/or imported Intra-AS I-PMSI
A-D routes have an RT in common, and that RT is one of the VRF's A-D routes have an RT in common, and that RT is one of the VRF's
Outgoing Export RTs, then those routes are considered to be "about" Outgoing Export RTs, then those routes are considered to be "about"
the same MI-PMSI. The PIM C-instance of the VRF treats each MI-PMSI the same MI-PMSI. The PIM C-instance of the VRF treats each MI-PMSI
as a LAN Interface. as a LAN Interface.
In effect, if VPN-S has only extranet C-sources and VPN-R has only In effect, if VPN-S has only extranet C-sources and VPN-R has only
extranet C-receivers, this model has the VPN-S VRFs join the VPN-R extranet C-receivers, this model has the VPN-S VRFs join the VPN-R
skipping to change at page 43, line 29 skipping to change at page 44, line 11
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 extranet, this specification modifies the procedures of For extranet, this specification modifies the procedures of
Section 11.1.3 of [RFC6514] as follows. The rules given in Section 11.1.3 of [RFC6514] as follows. The rules given in
Section 7.4.5 ("I-PMSI A-D Routes") of this document are used to find Section 7.4.5 ("I-PMSI A-D Routes") of this document are used to find
the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D route that the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D route that
"corresponds to" to the selected UMH route. (That is, the rules of "corresponds to" the selected UMH route. (That is, the rules of
Section 7.4.5 of this document replace the rules given 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 Section 11.1.3 of [RFC6514] for finding the Inter-AS or Intra-AS
I-PMSI A-D route.) 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
skipping to change at page 45, line 23 skipping to change at page 46, line 9
7.2.3.1. When Inter-Site Shared Trees Are Used 7.2.3.1. When Inter-Site Shared Trees Are Used
This section applies when Inter-Site Shared Trees are used, as This section applies when Inter-Site Shared Trees are used, as
specified in [RFC6514] Section 13. specified in [RFC6514] Section 13.
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
skipping to change at page 46, line 27 skipping to change at page 47, line 10
If VRF-S contains both extranet C-sources and non-extranet C-sources, If VRF-S contains both extranet C-sources and non-extranet C-sources,
and if inclusive P-tunnels are used to carry both extranet C-flows and if inclusive P-tunnels are used to carry both extranet C-flows
and non-extranet C-flows, then there MUST be two inclusive tunnels and non-extranet C-flows, then there MUST be two inclusive tunnels
from VRF-S, one of which is to be used only to carry extranet C-flows from VRF-S, one of which is to be used only to carry extranet C-flows
(the "extranet inclusive P-tunnel"), and one of which is to be used (the "extranet inclusive P-tunnel"), and one of which is to be used
only to carry non-extranet C-flows (the "non-extranet inclusive only to carry non-extranet C-flows (the "non-extranet inclusive
P-tunnel"). P-tunnel").
In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes. In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes.
Their respective NLRIs must of course have different RDs. One of the Their respective NLRIs MUST of course have different RDs. One of the
Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel
in its PTA. This route must have the VRF's "extranet RD" in its in its PTA. This route MUST have the VRF's "extranet RD" in its
NLRI. The other route identifies the non-extranet inclusive P-tunnel NLRI. The other route identifies the non-extranet inclusive P-tunnel
in its PTA. This route must have the VRF's "default RD" in its PTA. 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
skipping to change at page 55, line 24 skipping to change at page 55, line 48
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.
As is the case with any application of technology based upon
[RFC4364], misconfiguration of the RTs may result in VPN security
violations (i.e., may result in a packet being delivered to a VPN
where, according to policy, it is not supposed to go).
In 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
one or more VPN-R VRFs. If that address is also the address of a one or more VPN-R VRFs. If that address is also the address of a
VPN-R non-extranet C-source, then a system attempting to receive an VPN-R non-extranet C-source, then a system attempting to receive an
extranet C-flow from the VPN-R extranet C-source may instead receive extranet C-flow from the VPN-R extranet C-source may instead receive
a non-extranet C-flow from the VPN-S C-source. This would result in a non-extranet C-flow from the VPN-S C-source. This would result in
a VPN security violation. a VPN security violation.
To avoid this, this document specifies that if a route is imported To avoid this, this document specifies that if a route is imported
into a given VRF, all addresses that are match that route must be into a given VRF, all addresses that match that route must be
unambiguous in the context of that VRF. Improper provisioning of the unambiguous in the context of that VRF. Improper provisioning of the
RTs may cause this rule to be violated, and hence result in a VPN RTs may cause this rule to be violated, and hence result in a VPN
security violation. security violation.
It is possible that a given multicast C-source is the source of It is possible that a given multicast C-source is the source of
multiple flows, some of which are intended to be extranet C-flows, multiple flows, some of which are intended to be extranet C-flows,
and some of which are intended to be non-extranet flows. However, and some of which are intended to be non-extranet flows. However,
the procedures of this document will allow any C-receiver that is the procedures of this document will allow any C-receiver that is
able to receive the extranet C-flows from a given C-source to also able to receive the extranet C-flows from a given C-source to also
receive the non-extranet C-flows from that source. As a result, VPN receive the non-extranet C-flows from that source. As a result, VPN
skipping to change at page 56, line 23 skipping to change at page 57, line 6
matches the address of both an extranet C-source and a non-extranet matches the address of both an extranet C-source and a non-extranet
C-source. If such a route is exported from a VPN-S VRF and imported C-source. If such a route is exported from a VPN-S VRF and imported
by a VPN-R VRF, C-receivers contained in VPN-R will be able to by a VPN-R VRF, C-receivers contained in VPN-R will be able to
receive C-flows from the non-extranet C-sources whose addresses match receive C-flows from the non-extranet C-sources whose addresses match
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.
skipping to change at page 58, line 23 skipping to change at page 59, line 23
[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>.
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-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,
<http://www.rfc-editor.org/info/rfc3446>. <http://www.rfc-editor.org/info/rfc3446>.
[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, Discovery Protocol (MSDP)", RFC 3618,
DOI 10.17487/RFC3618, October 2003, DOI 10.17487/RFC3618, October 2003,
 End of changes. 70 change blocks. 
129 lines changed or deleted 175 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/