idnits 2.17.1 draft-zeng-idr-bgp-mtu-extension-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3988], [RFC1191], [RFC3107]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 233 has weird spacing: '...bo Wang rain...' == Line 235 has weird spacing: '...ijun Xu xuh...' -- The document date (March 9, 2012) is 4424 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5036' is mentioned on line 117, but not defined == Unused Reference: 'RFC4360' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC4659' is defined on line 281, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Zeng 3 Internet-Draft J. Dong 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 10, 2012 March 9, 2012 7 Maximum Transmission Unit Extended Community for BGP-4 8 draft-zeng-idr-bgp-mtu-extension-02 10 Abstract 12 Proper functioning of path Maximum Transmission Unit (MTU) discovery 13 [RFC1191] requires that IP routers have knowledge of the MTU for each 14 link to which they are connected. As MPLS progresses, [RFC3988] 15 specifies extensions to LDP in support of LDP LSP MTU discovery. For 16 the LSP created using Border Gateway Protocol (BGP) [RFC3107], it 17 does not have the ability to signal the path MTU to the ingress Label 18 Switching Router (LSR). In the absence of this functionality, the 19 MTU for the BGP LSP must be statically configured by network 20 operators or by equivalent off-line mechanisms. 22 This document defines the MTU Extended Community for BGP in support 23 of BGP LSP MTU discovery. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. BGP LSP MTU Discovery . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. MTU Extended Community . . . . . . . . . . . . . . . . . . 4 69 3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.4. Considerations on Route Flapping . . . . . . . . . . . . . 5 71 3.5. BGP LSP and LDP LSP Stitching . . . . . . . . . . . . . . . 5 72 4. Applicability Considerations . . . . . . . . . . . . . . . . . 5 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Proper functioning of [RFC1191] path Maximum Transmission Unit (MTU) 85 discovery requires that IP routers have knowledge of the MTU for each 86 link to which they are connected. As MPLS progresses, [RFC3988] 87 specifies some extensions to LDP in support of LDP LSP MTU discovery. 88 For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it 89 does not have the ability to signal the path MTU to the ingress Label 90 Switching Router (LSR). Without knowledge of the path MTU of the 91 whole BGP LSP, ingress BGP LSRs may transmit packets along that LSP 92 which are either too big or too small, thus these packets may either 93 be silently discarded by LSRs or be transmitted inefficiently. In 94 the absence of MTU discovery functionality, the MTU for each BGP LSP 95 must be statically configured by network operators or by equivalent 96 off-line mechanisms. 98 This document defines the MTU Extended Community for BGP in support 99 of BGP LSP MTU discovery. 101 2. Problem Statement 103 For some inter-AS services and also for network scalability, the LSPs 104 need to be established using Labeled BGP [RFC3107]. Typical 105 scenarios include inter-AS VPN Option C, Carrier's Carrier [RFC4364] 106 and Seamless MPLS [I-D.ietf-mpls-seamless-mpls]. 108 Taking "Inter-AS IP VPN Option C" as an example. An ASBR must 109 maintain labeled IPv4 /32 routes to the PE routers within its AS. 110 And it uses EBGP to distribute these labeled /32 routes to other ASes 111 using mechanism in [RFC3107]. ASBRs in transit ASes will also use 112 BGP to pass along the labeled /32 routes. In the AS of ingress PEs 113 (from data plane perspective), the labeled /32 routes can be 114 distributed to the PE routers using IBGP. The /32 routes may also be 115 redistributed into IGP of the Ingress AS (from data plane 116 perspective). Intra-AS LSPs between the PE nodes and ASBRs can be 117 established using LDP [RFC5036] or RSVP-TE [RFC3209]. 119 For intra-AS LSPs established using LDP or RSVP-TE, Path MTU of the 120 LSP could be discovered using mechanisms defined in [RFC3988] and 121 [RFC3209] respectively. But for the inter-AS LSP which is 122 established using BGP, some mechanism is needed to discover the Path 123 MTU. 125 3. BGP LSP MTU Discovery 126 3.1. Definitions 128 BGP LSP Path MTU: The Path MTU of the LSP from a given BGP LSR to a 129 specific prefix. It is carried as a Extended Community with the BGP 130 labeled IPv4 (or IPv6) route. This size includes the IP header and 131 data (or other payload) and the part of the label stack that is 132 considered payload of this BGP LSP. 134 BGP LSR Link MTU: If the two BGP LSRs are directly adjacent, the BGP 135 LSR Link MTU is the interface MTU; If the two BGP LSRs are not 136 directly adjacent, the BGP LSR Link MTU is the Path MTU of the 137 underlying tunnel. If there are multiple links between the two BGP 138 LSRs, the BGP LSR Link MTU is the minimum of those link MTUs. 140 3.2. MTU Extended Community 142 BGP LSP Path MTU is carried in the MTU extended community for BGP-4. 143 The MTU extended community is an optional transitive attribute. 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | MTU extended community Type | Reserved | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Reserved | MTU Value | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 The MTU extended community type is to be assigned by IANA. The first 153 four octets of the value field should be reserved, and the MTU value 154 is carried in the following two octets of the value field. 156 3.3. Signaling 158 The MTU is advertised hop-by-hop from BGP egress LSR to BGP ingress 159 LSR along an BGP LSP. The steps are as follows: 161 A. If BGP speaker A is the originator of the labeled BGP route, and 162 there is a intra-AS LSP to the prefix, A SHOULD set its BGP LSP Path 163 MTU to the path MTU value it has discovered to this prefix, and 164 advertise the labeled BGP route with the MTU Extended Community to 165 its BGP Peer (its upstream BGP LSR). If the prefix belongs to BGP 166 speaker A, the BGP LSP Path MTU SHOULD be set to 65535. 168 B. BGP speaker B receives the labeled BGP route with BGP LSP Path MTU 169 from its BGP peer. 171 a) B SHOULD compute the BGP LSR Link MTU to the Next Hop of the 172 received message, then sets its BGP LSP Path MTU to the minimum of 173 the received BGP LSP Path MTU and (the BGP LSR Link MTU - 4 octets). 175 b). If B distributes the route with the Next Hop attribute 176 unchanged, it MUST keep the MTU Extended Community unchanged when 177 advertising the message to its upstream BGP LSRs. 179 c). If B would change the Next Hop attribute to itself in the 180 subsequent advertisement, it SHOULD set the MTU Extended Community in 181 the message with its BGP LSP Path MTU obtained through step a). 183 3.4. Considerations on Route Flapping 185 Normally change of BGP path attributes would result in advertising a 186 BGP update for the route. In order to throttle the route updates 187 caused by changes of BGP path MTU , this section specifies rules of 188 route update when BGP LSP Path MTU changes: 190 1. If the BGP LSP Path MTU decreases, a new update SHOULD be 191 advertised immediately; 193 2. If the BGP LSP Path MTU increases, the BGP speaker MAY hold down 194 the update until there are changes of some other BGP attributes. 196 3.5. BGP LSP and LDP LSP Stitching 198 In scenarios where the labeled BGP routes are redistributed into IGP 199 on a border router and an LDP LSP is established and stitched to the 200 BGP LSP, the border router SHOULD use its BGP path MTU as the LDP LSP 201 MTU, and the path MTU discovery of the LDP LSP will be performed 202 according to [RFC3988]. 204 4. Applicability Considerations 206 The BGP MTU Extended Community is applicable to labeled BGP defined 207 in [RFC3107]. The application of BGP MTU Discovery may also be used 208 for other inter-AS/inter-area routing scenarios. Such use cases are 209 for further study. 211 In order to correctly calculate the path MTU for internal BGP routes, 212 an implementation needs to track MTU changes for its underlying 213 transport LSPs egressing to the BGP nexthops. 215 In order to make full use of this MTU signaling mechanism, data plane 216 implementation needs to support route-specific fragmentation based on 217 the discovered Path MTU. 219 5. IANA Considerations 221 IANA is requested to assign a type and sub-type value for BGP MTU 222 extended community. 224 6. Security Considerations 226 This extension to BGP does not change the underlying security issues 227 in [RFC4271]. 229 7. Contributors 231 The following individuals contributed to this document: 233 Haibo Wang rainsword.wang@huawei.com 235 Haijun Xu xuhaijun@huawei.com 237 8. Acknowledgements 239 The authors would like to thank Jeff Haas, Nagendra Kumar, David 240 Freedman and Hannes Gredler for their valuable discussions and 241 suggestions. 243 9. References 245 9.1. Normative References 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 251 BGP-4", RFC 3107, May 2001. 253 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 254 Protocol 4 (BGP-4)", RFC 4271, January 2006. 256 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 257 Communities Attribute", RFC 4360, February 2006. 259 9.2. Informative References 261 [I-D.ietf-mpls-seamless-mpls] 262 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 263 M., and D. Steinberg, "Seamless MPLS Architecture", 264 draft-ietf-mpls-seamless-mpls-00 (work in progress), 265 May 2011. 267 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 268 November 1990. 270 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 271 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 272 Tunnels", RFC 3209, December 2001. 274 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 275 Signalling Extensions for the Label Distribution 276 Protocol", RFC 3988, January 2005. 278 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 279 Networks (VPNs)", RFC 4364, February 2006. 281 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 282 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 283 IPv6 VPN", RFC 4659, September 2006. 285 Authors' Addresses 287 Qing Zeng 288 Huawei Technologies 289 Huawei Building, No.156 Beiqing Rd. 290 Beijing 100095 291 China 293 Email: zengqing@huawei.com 295 Jie Dong 296 Huawei Technologies 297 Huawei Building, No.156 Beiqing Rd. 298 Beijing 100095 299 China 301 Email: jie.dong@huawei.com