Internet DRAFT - draft-zeng-idr-bgp-mtu-extension
draft-zeng-idr-bgp-mtu-extension
Network Working Group Q. Zeng
Internet-Draft J. Dong
Intended status: Standards Track Huawei Technologies
Expires: September 10, 2012 March 9, 2012
Maximum Transmission Unit Extended Community for BGP-4
draft-zeng-idr-bgp-mtu-extension-02
Abstract
Proper functioning of path Maximum Transmission Unit (MTU) discovery
[RFC1191] requires that IP routers have knowledge of the MTU for each
link to which they are connected. As MPLS progresses, [RFC3988]
specifies extensions to LDP in support of LDP LSP MTU discovery. For
the LSP created using Border Gateway Protocol (BGP) [RFC3107], it
does not have the ability to signal the path MTU to the ingress Label
Switching Router (LSR). In the absence of this functionality, the
MTU for the BGP LSP must be statically configured by network
operators or by equivalent off-line mechanisms.
This document defines the MTU Extended Community for BGP in support
of BGP LSP MTU discovery.
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 RFC 2119 [RFC2119].
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 September 10, 2012.
Copyright Notice
Zeng & Dong Expires September 10, 2012 [Page 1]
Internet-Draft MTU Extended Community for BGP-4 March 2012
Copyright (c) 2012 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
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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
3. BGP LSP MTU Discovery . . . . . . . . . . . . . . . . . . . . . 3
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. MTU Extended Community . . . . . . . . . . . . . . . . . . 4
3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Considerations on Route Flapping . . . . . . . . . . . . . 5
3.5. BGP LSP and LDP LSP Stitching . . . . . . . . . . . . . . . 5
4. Applicability Considerations . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Zeng & Dong Expires September 10, 2012 [Page 2]
Internet-Draft MTU Extended Community for BGP-4 March 2012
1. Introduction
Proper functioning of [RFC1191] path Maximum Transmission Unit (MTU)
discovery requires that IP routers have knowledge of the MTU for each
link to which they are connected. As MPLS progresses, [RFC3988]
specifies some extensions to LDP in support of LDP LSP MTU discovery.
For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it
does not have the ability to signal the path MTU to the ingress Label
Switching Router (LSR). Without knowledge of the path MTU of the
whole BGP LSP, ingress BGP LSRs may transmit packets along that LSP
which are either too big or too small, thus these packets may either
be silently discarded by LSRs or be transmitted inefficiently. In
the absence of MTU discovery functionality, the MTU for each BGP LSP
must be statically configured by network operators or by equivalent
off-line mechanisms.
This document defines the MTU Extended Community for BGP in support
of BGP LSP MTU discovery.
2. Problem Statement
For some inter-AS services and also for network scalability, the LSPs
need to be established using Labeled BGP [RFC3107]. Typical
scenarios include inter-AS VPN Option C, Carrier's Carrier [RFC4364]
and Seamless MPLS [I-D.ietf-mpls-seamless-mpls].
Taking "Inter-AS IP VPN Option C" as an example. An ASBR must
maintain labeled IPv4 /32 routes to the PE routers within its AS.
And it uses EBGP to distribute these labeled /32 routes to other ASes
using mechanism in [RFC3107]. ASBRs in transit ASes will also use
BGP to pass along the labeled /32 routes. In the AS of ingress PEs
(from data plane perspective), the labeled /32 routes can be
distributed to the PE routers using IBGP. The /32 routes may also be
redistributed into IGP of the Ingress AS (from data plane
perspective). Intra-AS LSPs between the PE nodes and ASBRs can be
established using LDP [RFC5036] or RSVP-TE [RFC3209].
For intra-AS LSPs established using LDP or RSVP-TE, Path MTU of the
LSP could be discovered using mechanisms defined in [RFC3988] and
[RFC3209] respectively. But for the inter-AS LSP which is
established using BGP, some mechanism is needed to discover the Path
MTU.
3. BGP LSP MTU Discovery
Zeng & Dong Expires September 10, 2012 [Page 3]
Internet-Draft MTU Extended Community for BGP-4 March 2012
3.1. Definitions
BGP LSP Path MTU: The Path MTU of the LSP from a given BGP LSR to a
specific prefix. It is carried as a Extended Community with the BGP
labeled IPv4 (or IPv6) route. This size includes the IP header and
data (or other payload) and the part of the label stack that is
considered payload of this BGP LSP.
BGP LSR Link MTU: If the two BGP LSRs are directly adjacent, the BGP
LSR Link MTU is the interface MTU; If the two BGP LSRs are not
directly adjacent, the BGP LSR Link MTU is the Path MTU of the
underlying tunnel. If there are multiple links between the two BGP
LSRs, the BGP LSR Link MTU is the minimum of those link MTUs.
3.2. MTU Extended Community
BGP LSP Path MTU is carried in the MTU extended community for BGP-4.
The MTU extended community is an optional transitive attribute.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU extended community Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MTU Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MTU extended community type is to be assigned by IANA. The first
four octets of the value field should be reserved, and the MTU value
is carried in the following two octets of the value field.
3.3. Signaling
The MTU is advertised hop-by-hop from BGP egress LSR to BGP ingress
LSR along an BGP LSP. The steps are as follows:
A. If BGP speaker A is the originator of the labeled BGP route, and
there is a intra-AS LSP to the prefix, A SHOULD set its BGP LSP Path
MTU to the path MTU value it has discovered to this prefix, and
advertise the labeled BGP route with the MTU Extended Community to
its BGP Peer (its upstream BGP LSR). If the prefix belongs to BGP
speaker A, the BGP LSP Path MTU SHOULD be set to 65535.
B. BGP speaker B receives the labeled BGP route with BGP LSP Path MTU
from its BGP peer.
a) B SHOULD compute the BGP LSR Link MTU to the Next Hop of the
received message, then sets its BGP LSP Path MTU to the minimum of
the received BGP LSP Path MTU and (the BGP LSR Link MTU - 4 octets).
Zeng & Dong Expires September 10, 2012 [Page 4]
Internet-Draft MTU Extended Community for BGP-4 March 2012
b). If B distributes the route with the Next Hop attribute
unchanged, it MUST keep the MTU Extended Community unchanged when
advertising the message to its upstream BGP LSRs.
c). If B would change the Next Hop attribute to itself in the
subsequent advertisement, it SHOULD set the MTU Extended Community in
the message with its BGP LSP Path MTU obtained through step a).
3.4. Considerations on Route Flapping
Normally change of BGP path attributes would result in advertising a
BGP update for the route. In order to throttle the route updates
caused by changes of BGP path MTU , this section specifies rules of
route update when BGP LSP Path MTU changes:
1. If the BGP LSP Path MTU decreases, a new update SHOULD be
advertised immediately;
2. If the BGP LSP Path MTU increases, the BGP speaker MAY hold down
the update until there are changes of some other BGP attributes.
3.5. BGP LSP and LDP LSP Stitching
In scenarios where the labeled BGP routes are redistributed into IGP
on a border router and an LDP LSP is established and stitched to the
BGP LSP, the border router SHOULD use its BGP path MTU as the LDP LSP
MTU, and the path MTU discovery of the LDP LSP will be performed
according to [RFC3988].
4. Applicability Considerations
The BGP MTU Extended Community is applicable to labeled BGP defined
in [RFC3107]. The application of BGP MTU Discovery may also be used
for other inter-AS/inter-area routing scenarios. Such use cases are
for further study.
In order to correctly calculate the path MTU for internal BGP routes,
an implementation needs to track MTU changes for its underlying
transport LSPs egressing to the BGP nexthops.
In order to make full use of this MTU signaling mechanism, data plane
implementation needs to support route-specific fragmentation based on
the discovered Path MTU.
Zeng & Dong Expires September 10, 2012 [Page 5]
Internet-Draft MTU Extended Community for BGP-4 March 2012
5. IANA Considerations
IANA is requested to assign a type and sub-type value for BGP MTU
extended community.
6. Security Considerations
This extension to BGP does not change the underlying security issues
in [RFC4271].
7. Contributors
The following individuals contributed to this document:
Haibo Wang rainsword.wang@huawei.com
Haijun Xu xuhaijun@huawei.com
8. Acknowledgements
The authors would like to thank Jeff Haas, Nagendra Kumar, David
Freedman and Hannes Gredler for their valuable discussions and
suggestions.
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.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
9.2. Informative References
[I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
Zeng & Dong Expires September 10, 2012 [Page 6]
Internet-Draft MTU Extended Community for BGP-4 March 2012
M., and D. Steinberg, "Seamless MPLS Architecture",
draft-ietf-mpls-seamless-mpls-00 (work in progress),
May 2011.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit
Signalling Extensions for the Label Distribution
Protocol", RFC 3988, January 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006.
Authors' Addresses
Qing Zeng
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing 100095
China
Email: zengqing@huawei.com
Jie Dong
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Zeng & Dong Expires September 10, 2012 [Page 7]
