Network Working Group Q. Zeng Internet-Draft J. Dong Intended status: Standards Track Huawei Technologies Expires: May 3, 2012 October 31, 2011 Maximum Transmission Unit Extended Community for BGP-4 draft-zeng-idr-bgp-mtu-extension-01 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 May 3, 2012. Copyright Notice Zeng & Dong Expires May 3, 2012 [Page 1] Internet-Draft MTU Extended Community for BGP-4 October 2011 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 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 May 3, 2012 [Page 2] Internet-Draft MTU Extended Community for BGP-4 October 2011 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 May 3, 2012 [Page 3] Internet-Draft MTU Extended Community for BGP-4 October 2011 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 May 3, 2012 [Page 4] Internet-Draft MTU Extended Community for BGP-4 October 2011 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. 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]. Zeng & Dong Expires May 3, 2012 [Page 5] Internet-Draft MTU Extended Community for BGP-4 October 2011 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 and David Freedman 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, 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 Zeng & Dong Expires May 3, 2012 [Page 6] Internet-Draft MTU Extended Community for BGP-4 October 2011 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 May 3, 2012 [Page 7]