draft-ietf-bess-mvpn-extranet-05.txt   draft-ietf-bess-mvpn-extranet-06.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: June 23, 2016 Arktan Expires: July 15, 2016 Arktan
Y. Cai Y. Cai
Microsoft Microsoft
T. Morin T. Morin
Orange Orange
December 21, 2015 January 12, 2016
Extranet Multicast in BGP/IP MPLS VPNs Extranet Multicast in BGP/IP MPLS VPNs
draft-ietf-bess-mvpn-extranet-05 draft-ietf-bess-mvpn-extranet-06
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 June 23, 2016. This Internet-Draft will expire on July 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 27, line 49 skipping to change at page 27, line 49
Suppose a PE receives from a CE a route, call it R, with the Extranet Suppose a PE receives from a CE a route, call it R, with the Extranet
Source Extended Community. The PE must determine (via the Source Extended Community. The PE must determine (via the
considerations of Section 4.4.1) whether it should ignore that considerations of Section 4.4.1) whether it should ignore that
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 or 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). The value of the Extended Community MUST NOT be changed Section 10). The value of the Extended Community MUST NOT be changed
by the route reflector. 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 (b) and (c) (see [RFC6513] Section 10). The value inter-AS options (b) and (c) (see [RFC6513] Section 10). The value
of the Extended Community MUST NOT be changed by the ASBRs. of the Extended Community MUST NOT be changed by the ASBRs.
skipping to change at page 28, line 41 skipping to change at page 28, line 41
work correctly across an Option (a) interconnect unless the rules work correctly across an Option (a) interconnect unless the rules
this section are followed. 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 (see [RFC4360], [RFC7153], and Separation" Extended Community (see [RFC4360], [RFC7153], and
Section 9 of this document). This Extended Community is used only 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. A Route Reflector MUST NOT
add or remove the Extranet Separation Extended Community from the
routes it reflects, including the case where routes received via IBGP
are reflected to EBGP peers (inter-AS option (c), see [RFC6513]
Section 10).
If a VRF has been provisioned to use extranet separation, and if that If a VRF has been provisioned to use extranet separation, and if that
VRF has been provisioned to transmit any extranet C-flows on a VRF has been provisioned to transmit any extranet C-flows on a
P-tunnel that it advertises in an I-PMSI A-D route or a (C-*,C-*) P-tunnel that it advertises in an I-PMSI A-D route or a (C-*,C-*)
S-PMSI A-D route, then any UMH-eligible routes that are exported from S-PMSI A-D route, then any UMH-eligible routes that are exported from
that VRF following the procedures of Sections 4.1, 4.2, and 4.3 MUST that VRF following the procedures of Sections 4.1, 4.2, and 4.3 MUST
carry the Extranet Separation Extended Community. In addition, if an carry the Extranet Separation Extended Community. In addition, if an
I-PMSI A-D route and/or (C-*,C-*) S-PMSI A-D route, exported from I-PMSI A-D route and/or (C-*,C-*) S-PMSI A-D route, exported from
that VRF, is used to carry extranet traffic, that A-D route MUST also that VRF, is used to carry extranet traffic, that A-D route MUST also
carry the Extranet Separation Extended Community. Further details carry the Extranet Separation Extended Community. Further details
 End of changes. 7 change blocks. 
7 lines changed or deleted 11 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/