Internet DRAFT - draft-zzhang-mboned-mvpn-global-table-mcast
draft-zzhang-mboned-mvpn-global-table-mcast
Network Working Group Zhang
Internet-Draft Giuliano
Intended status: Informational Juniper Networks
Expires: August 20, 2013 Pacella
Verizon
February 16, 2013
Global Table Multicast with BGP-MVPN Procedures
draft-zzhang-mboned-mvpn-global-table-mcast-00.txt
Abstract
This document describes a way to implement Global Table Multicast,
aka Internet Multicast, using BGP encodings and procedures for MVPN
as specified in [RFC6514].
No protocol modification/extension is required. This is purely for
informational and clarifying purposes only.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 20, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Zhang, et al. Expires August 20, 2013 [Page 1]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IBGP session between BRs and non-BRs . . . . . . . . . . . 5
3.2. Non-BGP RPF Routes or BGP RPF routes not originated by
the BRs . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Zhang, et al. Expires August 20, 2013 [Page 2]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
1. Introduction
[RFC6513] and [RFC6514] specify procedures and encodings to implement
Multicast for L3VPNs (MVPN). [RFC6513] specifies general concepts
and procedures that apply to PIM-based and/or BGP-based C-Multicast
State Signaling (referred to PIM-MVPN and BGP-MVPN respectively), and
[RFC6514] specifies BGP procedures and encodings used by both PIM-
MVPN and BGP-MVPN.
While [RFC6513] and [RFC6514] assume the context of VPN, they can be
used to implement Global (vs. VRF) Table Multicast as well, without
any protocol modification/extension, even though the RFCs do not
explicitly mention it.
Consider a provider network where the "core" part of it uses MPLS
P2MP LSPs or Ingress Replication over either P2P LSPs (with RSVP-TE)
or MP2P LSPs (with LDP) instead of PIM to carry multicast traffic
among the border routers (BRs) of the core. Those BRs run PIM on
interfaces connected to other routers outside the core.
This document describes how Global Table Multicast can be implemented
using BGP-MVPN procedures. We start with a simple reference scenario
below, and also discuss one slightly different scenario and another
special one.
With Global Table Multicast implemented by BGP-MVPN procedures, all
the features/characteristics of BGP-MVPN apply, including scaling,
aggregation, flexible choice of provider tunnels, support for PIM-DM/
ASM/SSM/Bidir as PE-CE multicast protocol, BSR and AUTO-RP as RP-to-
group mapping protocols, etc.
Zhang, et al. Expires August 20, 2013 [Page 3]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Zhang, et al. Expires August 20, 2013 [Page 4]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
3. Operation
In the simplest reference scenario, the BRs advertise to each other
RPF routes to multicast sources via iBGP (with or without RRs in the
middle) with Next Hop set to themselves. The routes could have been
learned from other non-BRs via eBGP or IGP.
Conceptually and functionally, those BRs are just like MVPN PEs:
connections to other routers outside the core can be treated as PE-CE
interfaces and MVPN procedures can run among the PEs (i.e., BRs) for
Discovery, Tunnel Binding, and Multicast State Signaling.
With that, using BGP-MVPN procedures for Global Table Multicast is
straightforward and requires almost no further clarification.
However, some popular practices are described below.
By default, RD 0:0 is used when advertising A-D routes for Global
Table Multicast, though an implementation MAY support the
configuration and use of a different RD value.
Similarly, when constructing the C-multicast Import RT as specified
in Section 7 of [RFC6514], it is RECOMMENDED that the Local
Administrator field is set to 0, though an implementation MAY use any
value that can uniquely associate it to the global routing table (vs.
a VRF).
3.1. IBGP session between BRs and non-BRs
In the simple reference scenario above, it is assumed that the BRs
learn RPF routes from non-BRs via eBGP or IGP. The assumption is to
illustrate the analogy to a true VPN environment. In another
deployment scenario, the BRs could have learned the RPF routes over
those iBGP sessions to non-BRs. If the BRs act as RRs and reflect
the RPF routes to other BRs with polices to attach VRF Route Import
Extended Community and Source AS Extended Community, BGP-MVPN
procedures can still be used as described earlier. Even if the BRs
do not act as RRs, the scenario could be considered analogous to what
[RFC6368] describes. As long as BRs re-advertise those RPF routes
with the above mentioned communities, BGP-MVPN procedures can be used
as described earlier. Note that they do not even need to use the
push/pop procedures in [RFC6368] - the only requirement is for the
BRs to re-advertise the routes learned over iBGP sessions from non-
BRs to other BRs over iBGP sessions.
3.2. Non-BGP RPF Routes or BGP RPF routes not originated by the BRs
With true MVPN, the PEs advertise the RPF routes themselves as VPN-IP
routes, and attach a VRF Route Import Extended Community that has the
Zhang, et al. Expires August 20, 2013 [Page 5]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
C-multicast Import RT value for the VRF associated with the routes.
The VRF Route Import Extended Community is extracted by egress PEs
and attached to their C-Multicast Routes as Route Target Extended
Community to control the distribution to and importation by relevant
ingress PEs.
With Global Table Multicast, in both the simple reference scenario
and the above mentioned variance, the BRs do (re-)advertise the RPF
routes as required for BGP-MVPN. However, in other situations, it is
possible that the RPF routes are not advertised by the BRs via BGP at
all, hence they may not carry the VRF Route Import Extended
Community.
Consider the following example:
|---- Site 1 -------|
EBGP
src--CPE1-----GW1/CE1 -------BR1/PE1
\ /|
|\ / |
| \IBGP / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
|/ \ |
/ \|
rcv--CPE2-----GW2/CE2 -------BR2/PE2
EBGP IBGP
|---- Site 2 -------|
There is a full-mesh of IBGP sessions among provider routers GW1/BR1/
BR2/GW2. EBGP sessions run between CPE1/GW1 and between CPE2/GW2.
Border routers BR1/BR2 run BGP-MVPN procedures for Global Table
Multicast. GW1 learns of BGP route to the src from CPE1 and
advertises it to BRx/GW2.
Because GW1 does not run MVPN, BR2's route to the src (learned from
GW1 instead of BR1) does not have the VRF Route Import Extended
Community. Therefore, it would not be able to correctly attach a
Route Target Extended Community corresponding to BR1 in its
C-Multicast Routes.
Zhang, et al. Expires August 20, 2013 [Page 6]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
To handle that situation, BR2 performs the following recursively.
Note that the route in the following procedure is either the RPF
route for the source itself, or the route to the Next Hop of the BGP
route in the previous recursion.
o If the route is a BGP route with a VRF Route Import Extended
Community, that VRF Route Import Extended Community is used.
o If the route is a BGP route without a VRF Route Import Extended
Community, get the route to the Next Hop and recurse.
o If the route is an IGP route with a RSVP-TE LSP as next hop, and
the LSP endpoint is a BR that advertises an Intra-AS I-PMSI A-D
route (BR1 in the above example), a VRF Route Import Extended
Community is constructed as BR_addr:0 to be associated with the
RPF route, where the BR_addr is the Originating Router's IP
Address of the Intra-AS I-PMSI A-D route.
If the above procedure does not produce a usable VRF Route Import
Extended Community, then the RPF route is considered a local route
(vs. a remote route that is associated with a remote BR). Note that
the special process is necessary only if the BRs (that run MVPN
procedures) do not advertise the RPF routes via BGP and include VRF
Route Import Extended Community in such routes.
Constructing the VRF Route Import as BR_addr:0 by an egress BR in the
above special situation explains why it is RECOMMENDED that the Local
Administrator is set to 0 when an ingress BR constructs its
C-Multicast Import RT - the zero value is a special value agreed on
apriori by all (vs. a local value that is normally picked by the
ingress router and signaled via the VRF Route Import Extended
Community).
Zhang, et al. Expires August 20, 2013 [Page 7]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
4. Security Considerations
This document raises no new security issues. Security considerations
for the base protocol are covered in [RFC6514].
Zhang, et al. Expires August 20, 2013 [Page 8]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
5. IANA Considerations
This document has no IANA considerations.
This section should be removed by the RFC Editor prior to final
publication.
Zhang, et al. Expires August 20, 2013 [Page 9]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
6. Acknowledgements
The authors would like to thank Rahul Aggarwal and Yakov Rehkter for
their comments and suggestions.
Zhang, et al. Expires August 20, 2013 [Page 10]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
7.2. Informative References
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, September 2011.
Zhang, et al. Expires August 20, 2013 [Page 11]
Internet-Draft Global Table Multicast with BGP-MVPN February 2013
Authors' Addresses
Jeffrey Zhang
Juniper Networks
10 Technology Park Dr.
Westford, MA 01886
US
Email: zzhang@juniper.net
Lenny Giuliano
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
US
Email: lenny@juniper.net
Dante J. Pacella
Verizon Communications
22001 Loudoun County Parkway
Ashburn, VA 20147
Email: dante.j.pacella@verizonbusiness.com
Zhang, et al. Expires August 20, 2013 [Page 12]
