Internet DRAFT - draft-renwei-mpls-bgp-big-label
draft-renwei-mpls-bgp-big-label
MPLS Working Group R. Li
Internet-Draft L. Han
Intended status: Standards Track Huawei Technologies
Expires: January 02, 2014 July 01, 2013
Carrying Big Labels in BGP-4
draft-renwei-mpls-bgp-big-label-00.txt
Abstract
When BGP is used to distribute a particular route, it can also be
used to distribute an MPLS label which is mapped to that route. In
some cases, for example, when L3VPN is used to access and connect to
virtual networks in data centers, there may be 16 millions of VPN
instances on a router. In order to map MPLS labels to VPN instances,
big labels are required. This document specifies the method to carry
and distribute such big labels by piggybacking the big label mapping
information for an IP route in the BGP Update message that is used to
distribute the route itself.
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 January 02, 2014.
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
carefully, as they describe your rights and restrictions with respect
Li & Han Expires January 02, 2014 [Page 1]
Internet-Draft Carrying Big Labels in BGP-4 July 2013
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Big Labels . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. AFI/SAFI . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Big Label in NLRI . . . . . . . . . . . . . . . . . . . . . . 6
6. Capability Anouncement . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Network virtualization and server virtualization are being designed
and deployed in data center networks, and new data encapsulation
methods and protocols are being defined and specified, for example,
VXLAN, NVGRE and NVO3. The general idea is to add a new virtual
network header so that a physical network can be used to support
millions (16M) of virtualized overlaid networks. Network overlay
virtualization have placed a new requirement on the access method to
such virtulized networks.
BGP/MPLS IP VPNs of [RFC2547] and [RFC4364], provide a market-proven
technology and solution for end-to-end IP VPNs. In BGP/MPLS IP VPNs,
all the customer sites are connected to the service provider networks
Li & Han Expires January 02, 2014 [Page 2]
Internet-Draft Carrying Big Labels in BGP-4 July 2013
through PE-CE link. It is desirable to extend the BGP/MPLS scheme so
that customers can access their virtualized networks hosted in a data
center by using BGP/MPLS IP VPNs.
In the data plane of BGP/MPLS IP VPNs, the customer VPN/VRF instances
are represented by an MPLS label (VPN label) locally assgined by the
PE connecting to CE. Since MPLS labels are 20 bits long, a PE can
maximally support 1 million VPNs/VRFs, but PE is required to support
16 millions of virtual networks that are being standardized in VXLAN,
NVGRE and NVO3. When BGP/MPLS IP VPNs are extended to access
virtualized networks in data centers, [I-D.draft-renwei-l3vpn-big-
label] describes several use cases and solutions to use big labels to
represent the VPN and maps them to virtual network instances.
The big label information mapped to VPN routes can be carried and
distributed by BGP-4 in the framework of [RFC3107]. This document
specifies the method to carry and distribute such big labels by
piggybacking the big label mapping information for an IP route in the
BGP Update message that is used to distribute the route itself.
1.1. Requirement 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].
1.2. Terminology
The following terms are used in this document:
PE
Provider Edge, the provider edge router connected to CE.
CE
Customer Edge, the customer edge router connected to PE
MPLS LSR
MPLS label switch router
IANA
Internet Assigned Numbers Authority
AFI
Address Family Identifier
SAFI
Subsequent Address Family Identifier
Li & Han Expires January 02, 2014 [Page 3]
Internet-Draft Carrying Big Labels in BGP-4 July 2013
2. Motivation
This document tries to make L3 VPN BGP signaling work with the MPLS
big label specified in [I-D.draft-renwei-mpls-big-label]. With the
proposed method, the MPLS big label can be carried in BGP NLRI and
mapped to BGP routes.
The extension of BGP is used to connect a customer site to its
virtualized network hosted in a data center by using, for example,
VXLAN, NVGRE or NVO3.
Take NVO3 as an example. NVO3 is an on-going effort to standardize
solutions to data center virtualizaiton with the goal of providing
viable data encapsulation and protocols across a scaling range of a
few thousand VMs to several million VMs running on greater than one
hundred thousand physical servers. NVO3 considers approaches to
multi-tenancy that reside at the network layer rather than using
traditional isolation mechanisms that rely on the underlying layer 2
technology (e.g. VLANs).
Based on NVO3 framework and problem statement, NVO3 will deliver 16
million virtual networks in a physical data center.
..................................
. .
. +------------+ .
. |+----+ +---+| .
. || | |VM || .
. /+|NVE | +---+| .
. / || | +---+| .
-----+ +----------------+ . +------------+ || | |VM || .
| | | . | | |+----+ +---+| .
+---+--+ +------+ +---+---+--+ NVO3 | | Server | .
| CE |---| PE | MPLS | PE-NVE | network | +------------+ .
|device| |device| network | device | over L3 | .
+---+--+ +------+ +---+---+--+ network | +------------+ .
| / | | . | | |+----+ +---+| .
-----+ / +----------------+ . +------------+ || | |VM || .
/ . \ ||NVE | +---+| .
-----+ / . \+| | +---+| .
| / . || | |VM || .
+---+--+ . |+----+ +---+| .
| CE | . | Server | .
|device| . Data Center +------------+ .
+---+--+ ..................................
|
-----+
Li & Han Expires January 02, 2014 [Page 4]
Internet-Draft Carrying Big Labels in BGP-4 July 2013
Potentially, PE-NVE needs to support 16 million of VRFs. The
extension of BGP described in this document can be used between PE-
NVE and PE for the purpose of association between L3VPN labels and
network virtualizaiton instances in the NVO3 network.
3. Big Labels
A PE device uses VPN labels to find the associated VRFs for VPN
packet forwarding. When L3VPN is used to access and connect a
virtual network hosted in a data center by using VXLAN, NVGRE or
NVO3, a label space having a minimal set of 16 million labels is
required.
The document [I-D.draft-renwei-mpls-big-label] specifies an encoding
format by adding a new label value field to the common label as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Big Label Indicator | Exp |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Big Label Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Big Label Indicator is a reserved MPLS label. The currently
unassigned reserved label range is 4-6 and 8-12. We will temporarily
use label 8 for big label indicator, but the final value will be
assigned by IANA. The Big Label Value is a 32-bit value.
When an MPLS LSR receivs an MPLS packet, it reads out the MPLS label.
If the MPLS label is a Big Label Indicator, it will use the
subsequent 32-bit value as the MPLS label for the forwarding purpose.
In what follows, we will describe how BGP-4 carries and distributes
such big labels for IP routes.
4. AFI/SAFI
In BGP-4, label mapping information is carried as part of the Network
Layer Reachability Information (NLRI) in the Multiprotocol Extensions
of BGP-4 [RFC2858].
Li & Han Expires January 02, 2014 [Page 5]
Internet-Draft Carrying Big Labels in BGP-4 July 2013
The AFI indicates, as usual, the address family of the associated
route. The fact that the NLRI carries an MPLS big label is indicated
by using a SAFI value, to be requested to IANA. The SAFI value 4 is
currently assigned for common labels. The currently unassigned range
is 8-63. Before IANA assigns an official SAFI value for big labels,
8 is temporarily used as the SAFI value to indicate that it carries
big labels.
5. Big Label in NLRI
The Network Layer Reachability Information carrying big labels is
encoded as one or more triples of the form (length, label, prefix),
whose fields are described as follows:
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Label (4 octets) |
+---------------------------+
| Prefix (variable) |
+---------------------------+
a. Length: The Length field indicates the length in bits of the
address prefix plus the label.
b. Label: The Label field carries a 4-octet Big Label Value of the
big label format specified in [I-D.draft-renwei-mpls-big-label].
Note that the Big Label Indicator is not carried in NLRI;
instead, it will be assigned by IANA. In the data plane, when
encoding a packet for forwarding, both the Big Label Indicator
and Big Label Value must be encoded in the MPLS header as
specified in [I-D.draft-renwei-mpls-big-label].
c. Prefix: The Prefix field contains address prefixes followed by
enough trailing bits to make the end of the field fall on an
octet boundary. Note that the value of trailing bits is
irrelevant.
All rules and restrictions applicable to the SAFI value 4 is also
applicable to the SAFI value 8 (subject to IANA) except for the Label
field must be 4 octets. In particular, the following usage rules for
SAFI value 4 also applies to the SAFI value for big labels:
The label(s) specified for a particular route (and associated with
its address prefix) must be assigned by the LSR which is identified
by the value of the Next Hop attribute of the route.
Li & Han Expires January 02, 2014 [Page 6]
Internet-Draft Carrying Big Labels in BGP-4 July 2013
When a BGP speaker redistributes a route, the label(s) assigned to
that route must not be changed (except by omission), unless the
speaker changes the value of the Next Hop attribute of the route.
A BGP speaker can withdraw a previously advertised route (as well as
the binding between this route and a label) by either (a) advertising
a new route (and a label) with the same NLRI as the previously
advertised route, or (b) listing the NLRI of the previously
advertised route in the Withdrawn Routes field of an Update message.
The label information carried (as part of NLRI) in the Withdrawn
Routes field should be set to 0x800000. (Of course, terminating the
BGP session also withdraws all the previously advertised routes.)
6. Capability Anouncement
A BGP speaker that uses MP-BGP [RFC2858] to carry label mapping
information should use the Capabilities Optional Parameter, as
defined in [RFC2842], to inform its peers about this capability. The
MP_EXT Capability Code, as defined in [RFC2858], is used to advertise
the (AFI, SAFI) pairs available on a particular connection.
A BGP speaker should not advertise this capability to another BGP
speaker unless there is a Label Switched Path (LSP) between the two
speakers.
7. IANA Considerations
The requirements on IANA are specified in other related documents
[I-D.draft-renwei-mpls-big-label] and [I-D.draft-renwei-mpls-bgp-big-
label], which request a reserved label to represent Big Label
Indicator and BGP capabilities for big labels.
8. Security Considerations
This draft does not add any additional security implications to the
BGP/MPLS IP VPNs. All existing authentication and security
mechanisms for BGP and MPLS still apply.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999.
Li & Han Expires January 02, 2014 [Page 7]
Internet-Draft Carrying Big Labels in BGP-4 July 2013
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 2842, May 2000.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
9.2. Informative References
[I-D.mahalingam-dutt-dcops-vxlan]
Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
Framework for Overlaying Virtualized Layer 2 Networks over
Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-03
(work in progress), February 2013.
[I-D.sridharan-virtualization-nvgre]
Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang,
Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P.,
and C. Tumuluri, "NVGRE: Network Virtualization using
Generic Routing Encapsulation", draft-sridharan-
virtualization-nvgre-02 (work in progress), February 2013.
Authors' Addresses
Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: renwei.li@huawei.com
Li & Han Expires January 02, 2014 [Page 8]
Internet-Draft Carrying Big Labels in BGP-4 July 2013
Lin Han
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: lin.han@huawei.com
Li & Han Expires January 02, 2014 [Page 9]
