draft-ietf-bess-mvpn-global-table-mcast-02.txt   draft-ietf-bess-mvpn-global-table-mcast-03.txt 
BESS Working Group Z. Zhang BESS Working Group Z. Zhang
Internet-Draft L. Giuliano Internet-Draft L. Giuliano
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: January 21, 2016 Juniper Networks, Inc. Expires: March 20, 2016 Juniper Networks, Inc.
K. Subramanian K. Subramanian
Cisco Systems, Inc. Cisco Systems, Inc.
D. Pacella D. Pacella
Verizon Verizon
July 20, 2015 September 17, 2015
Global Table Multicast with BGP-MVPN Procedures Global Table Multicast with BGP-MVPN Procedures
draft-ietf-bess-mvpn-global-table-mcast-02 draft-ietf-bess-mvpn-global-table-mcast-03
Abstract Abstract
RFC6513, RFC6514, and other RFCs describe protocols and procedures RFC6513, RFC6514, and other RFCs describe protocols and procedures
which a Service Provider (SP) may deploy in order offer Multicast which a Service Provider (SP) may deploy in order offer Multicast
Virtual Private Network (Multicast VPN or MVPN) service to its Virtual Private Network (Multicast VPN or MVPN) service to its
customers. Some of these procedures use BGP to distribute VPN- customers. Some of these procedures use BGP to distribute VPN-
specific multicast routing information across a backbone network. specific multicast routing information across a backbone network.
With a small number of relatively minor modifications, the very same With a small number of relatively minor modifications, the very same
BGP procedures can also be used to distribute multicast routing BGP procedures can also be used to distribute multicast routing
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 21, 2016. This Internet-Draft will expire on March 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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 14 2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 14
2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14 2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14
2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14 2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14
2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14 2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14
2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14 2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14
2.8.2. Optional Additional Constraints on Distribution . . . 15 2.8.2. Optional Additional Constraints on Distribution . . . 15
2.9. C-multicast Source/Shared Tree Joins . . . . . . . . . . 16 2.9. C-multicast Source/Shared Tree Joins . . . . . . . . . . 16
3. Differences from other MVPN-like GTM Procedures . . . . . . . 17 3. Differences from other MVPN-like GTM Procedures . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Additional Contributors . . . . . . . . . . . . . . . . . . . 18 6. Additional Contributors . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
[RFC4364] specifies architecture, protocols, and procedures that a [RFC4364] specifies architecture, protocols, and procedures that a
Service Provider (SP) can use to provide Virtual Private Network Service Provider (SP) can use to provide Virtual Private Network
(VPN) service to its customers. In that architecture, one or more (VPN) service to its customers. In that architecture, one or more
Customer Edge (CE) routers attach to a Provider Edge (PE) router. Customer Edge (CE) routers attach to a Provider Edge (PE) router.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
process. A route reflector receiving both routes may thus choose to process. A route reflector receiving both routes may thus choose to
redistribute just one of the routes to S, the one chosen by the redistribute just one of the routes to S, the one chosen by the
bestpath algorithm. Different route reflectors may even choose bestpath algorithm. Different route reflectors may even choose
different routes to redistribute (i.e., one route reflector may different routes to redistribute (i.e., one route reflector may
choose the route to S via PBR1 as the bestpath, while another chooses choose the route to S via PBR1 as the bestpath, while another chooses
the route to S via PBR2 as the bestpath). As a result, some PBRs may the route to S via PBR2 as the bestpath). As a result, some PBRs may
receive only the route to S via PBR1 and some may receive only the receive only the route to S via PBR1 and some may receive only the
route to S via PBR2. In that case, it is impossible to ensure that route to S via PBR2. In that case, it is impossible to ensure that
all PBRs will choose the same route to S. all PBRs will choose the same route to S.
The SFS procedure works in VPN context as along the following The SFS procedure works in VPN context as long as the following
assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2, assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2,
then VRF-x and VRF-y have been configured with different RDs. In VPN then VRF-x and VRF-y have been configured with different RDs. In VPN
context, the route to S is of SAFI 128 or 129, and thus has an RD in context, the route to S is of SAFI 128 or 129, and thus has an RD in
its NLRI. So the route to S via PE1 will not have the same NLRI as its NLRI. So the route to S via PE1 will not have the same NLRI as
the route to S via PE2. As a result, all PEs will see both routes, the route to S via PE2. As a result, all PEs will see both routes,
and the PEs can implement a procedure that ensures that they all pick and the PEs can implement a procedure that ensures that they all pick
the same route to S. the same route to S.
That is, the SFS procedure of [RFC6513] relies on the UMH-eligible That is, the SFS procedure of [RFC6513] relies on the UMH-eligible
routes being of SAFI 128 or 129, and relies on certain VRFs being routes being of SAFI 128 or 129, and relies on certain VRFs being
skipping to change at page 18, line 19 skipping to change at page 18, line 19
4. IANA Considerations 4. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
5. Security Considerations 5. Security Considerations
The security considerations of this document are primarily the The security considerations of this document are primarily the
security considerations of the base protocols, as discussed in security considerations of the base protocols, as discussed in
[RFC6514], [RFC4601], and [RFC5294]. [RFC6514], [RFC4601], and [RFC5294].
This document makes use of a BGP SAFI (MCAST-VPN routes) that was The protocols and procedures described in this document make use of a
originally designed for use in VPN contexts only. It also makes use type of route (routes with the "MCAST-VPN" BGP SAFI) that was
of various BGP path attributes and extended communities (VRF Route originally designed for use in VPN contexts only. The protocols and
Import Extended Community, Source AS Extended Community, Route Target procedures described in this document also make use of various BGP
Extended Community) that were originally intended for use in VPN path attributes and extended communities (VRF Route Import Extended
contexts. If these routes and/or attributes leak out into "the Community, Source AS Extended Community, Route Target Extended
wild", multicast data flows may be distributed in an unintended and/ Community) that were originally intended for use in VPN contexts. If
or unauthorized manner. these routes, attributes, and/or extended communities leak out into
"the wild", multicast data flows may be distributed in an unintended
and/or unauthorized manner.
Internet providers often make extensive use of BGP communities (ie, When VPNs are provisioned, each VRF is configured with import RTs and
adding, deleting, modifying communities throughout a network). As export RTs. These RTs constrain the distribution and the import of
such, care should be taken to avoid deleting or modifying the VRF the VPN routes, making it difficult to cause a route to be
distributed to and imported by a VRF that is not authorized to import
that route. Additionally, VPN routes do not go into the "global
table" with the "ordinary Internet routes" (i.e., non-VPN routes),
and non-VPN routes do not impact the flow of multicast data within a
VPN. In GTM, some of these protections against improper
distribution/import of the routes is lost -- import of the routes is
not restricted to VRFs, and the RT infrastructure that controls the
distribution of routes among the VRFs is not present when routes are
exported from and imported into global tables.
Internet Service Providers often make extensive use of BGP extended
communities, sometimes adding, deleting, and/or modifying a route's
extended communities as the route is distributed throughout the
network. Care should be taken to avoid deleting or modifying the VRF
Route Import Extended Community and Source AS Extended Community. Route Import Extended Community and Source AS Extended Community.
Incorrect manipulation of these ECs may result in multicast streams Incorrect manipulation of these extended communities may result in
being lost or misrouted. multicast streams being lost or misrouted.
The procedures of this document require certain BGP routes to carry The procedures of this document require certain BGP routes to carry
IP multicast group addresses. Generally such group addresses are IP multicast group addresses. Generally such group addresses are
only valid within a certain scope. If a BGP route containing a group only valid within a certain scope. If a BGP route containing a group
address is distributed outside the boundaries where the group address address is distributed outside the boundaries where the group address
is meaningful, unauthorized distribution of multicast data flows may is meaningful, unauthorized distribution of multicast data flows may
occur. occur.
6. Additional Contributors 6. Additional Contributors
Jason Schiller Jason Schiller
Google Google
Suite 400 Suite 400
1818 Library Street 1818 Library Street
Reston, Virginia 20190 Reston, Virginia 20190
United States United States
Email: jschiller@google.com Email: jschiller@google.com
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
skipping to change at page 20, line 4 skipping to change at page 20, line 12
China China
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
7. Acknowledgments 7. Acknowledgments
The authors and contributors would like to thank Rahul Aggarwal, The authors and contributors would like to thank Rahul Aggarwal,
Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas
and comments. and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, 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>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
skipping to change at page 20, line 41 skipping to change at page 21, line 7
"Advertisement of Multiple Paths in BGP", internet-draft "Advertisement of Multiple Paths in BGP", internet-draft
draft-ietf-idr-add-paths-10, October 2014. draft-ietf-idr-add-paths-10, October 2014.
[MVPN-extranet] [MVPN-extranet]
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet- Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet-
draft draft-ietf-bess-mvpn-extranet-02, May 2015. draft draft-ietf-bess-mvpn-extranet-02, May 2015.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <http://www.rfc-editor.org/info/rfc4684>. November 2006, <http://www.rfc-editor.org/info/rfc4684>.
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", RFC 5294, Independent Multicast (PIM)", RFC 5294,
 End of changes. 13 change blocks. 
23 lines changed or deleted 45 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/