idnits 2.17.1 draft-ietf-idr-sr-policy-path-mtu-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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2020) is 1271 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) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-06 == Outdated reference: A later version (-05) exists of draft-zhu-idr-bgp-ls-path-mtu-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing Working Group C. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track Y. Zhu 5 Expires: May 5, 2021 China Telecom 6 A. Sawaf 7 Saudi Telecom Company 8 Z. Li 9 Huawei Technologies 10 November 1, 2020 12 Segment Routing Path MTU in BGP 13 draft-ietf-idr-sr-policy-path-mtu-02 15 Abstract 17 Segment Routing is a source routing paradigm that explicitly 18 indicates the forwarding path for packets at the ingress node. An SR 19 policy is a set of candidate SR paths consisting of one or more 20 segment lists with necessary path attributes. However, the path 21 maximum transmission unit (MTU) information for SR path is not 22 available in the SR policy since the SR does not require signaling. 23 This document defines extensions to BGP to distribute path MTU 24 information within SR policies. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 5, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 63 3. SR Policy for Path MTU . . . . . . . . . . . . . . . . . . . 5 64 3.1. Path MTU Sub-TLV . . . . . . . . . . . . . . . . . . . . 6 65 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 10.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Segment routing (SR) [RFC8402] is a source routing paradigm that 80 explicitly indicates the forwarding path for packets at the ingress 81 node. The ingress node steers packets into a specific path according 82 to the Segment Routing Policy ( SR Policy) as defined in 83 [I-D.ietf-spring-segment-routing-policy]. In order to distribute SR 84 policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] 85 specifies a mechanism by using BGP. 87 The maximum transmission unit (MTU) is the largest size packet or 88 frame, in bytes, that can be sent in a network. An MTU that is too 89 large might cause retransmissions. Too small an MTU might cause the 90 router to send and handle relatively more header overhead and 91 acknowledgments. 93 When an LSP is created across a set of links with different MTU 94 sizes, the ingress router needs to know what the smallest MTU is on 95 the LSP path. If this MTU is larger than the MTU of one of the 96 intermediate links, traffic might be dropped, because MPLS packets 97 cannot be fragmented. Also, the ingress router may not be aware of 98 this type of traffic loss, because the control plane for the LSP 99 would still function normally. [RFC3209] specify the mechanism of 100 MTU signaling in RSVP. Likewise, SRv6 pakcets will be dropped if the 101 packet size is larger than path MTU, since IPv6 packet can not be 102 fragmented on transmission [RFC8200] . 104 The host may discover the PMTU by Path MTU Discovery (PMTUD) 105 [RFC8201] or other mechanisms. But the ingress still needs to 106 examine the packet size for dropping too large packets to avoid 107 malicious traffic or error traffic. Also, the packet size may 108 exceeds the PMTU because of the new encapsulation of SR-MPLS or SRv6 109 packet at the ingress. 111 In order to check whether the Packet size exceeds the PMTU or not, 112 the ingress node needs to know the Path MTU associated to the 113 forwarding path. However, the path maximum transmission unit (MTU) 114 information for SR path is not available since the SR does not 115 require signaling. 117 This document defines extensions to BGP to distribute path MTU 118 information within SR policies. The Link MTU information can be 119 obtained via BGP-LS [I-D.zhu-idr-bgp-ls-path-mtu] or some other 120 means. With the Link MTU, the controller can compute the PMTU and 121 convey the information via the BGP SR policy. 123 2. Terminology 125 This memo makes use of the terms defined in [RFC8402] and [RFC3209]. 127 MTU: Maximum Transmission Unit, the size in bytes of the largest IP 128 packet, including the IP header and payload, that can be 129 transmitted on a link or path. Note that this could more properly 130 be called the IP MTU, to be consistent with how other standards 131 organizations use the acronym MTU. 133 Link MTU: The Maximum Transmission Unit, i.e., maximum IP packet 134 size in bytes, that can be conveyed in one piece over a link. Be 135 aware that this definition is different from the definition used 136 by other standards organizations. 138 For IETF documents, link MTU is uniformly defined as the IP MTU 139 over the link. This includes the IP header, but excludes link 140 layer headers and other framing that is not part of IP or the IP 141 payload. 143 Be aware that other standards organizations generally define link 144 MTU to include the link layer headers. 146 For the MPLS data plane, this size includes the IP header and data (or 147 other payload) and the label stack but does not include any lower-layer 148 headers. A link may be an interface (such as Ethernet or Packet-over- 149 SONET), a tunnel (such as GRE or IPsec), or an LSP. 151 Path: The set of links traversed by a packet between a source node 152 and a destination node. 154 Path MTU, or PMTU: The minimum link MTU of all the links in a path 155 between a source node and a destination node. 157 For the MPLS data plane, it is the MTU of an LSP from a given LSR to 158 the egress(es), over each valid (forwarding) path. This size includes 159 the IP header and data (or other payload) and any part of the label 160 stack that was received by the ingress LSR before it placed the packet 161 into the LSP (this part of the label stack is considered part of the 162 payload for this LSP). The size does not include any lower-level 163 headers. 165 Note that: The PMTU value may be modified by subtracting some overhead 166 introduced by protection mechanism, like TI-LFA. Therefore, the value 167 of PMTU dilivered to the ingress node MAY be smaller than the minimum 168 link MTU of all the links in a path between a source node and a 169 destination node. 171 2.1. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 3. SR Policy for Path MTU 181 As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR 182 policy encoding structure is as follows: 184 SR Policy SAFI NLRI: 185 Attributes: 186 Tunnel Encaps Attribute (23) 187 Tunnel Type: SR Policy 188 Binding SID 189 Preference 190 Priority 191 Policy Name 192 Explicit NULL Label Policy (ENLP) 193 Segment List 194 Weight 195 Segment 196 Segment 197 ... 198 ... 200 As introduced in Section 1, each SR path has it's path MTU. SR 201 policy with SR path MTU information is expressed as below: 203 SR Policy SAFI NLRI: 204 Attributes: 205 Tunnel Encaps Attribute (23) 206 Tunnel Type: SR Policy 207 Binding SID 208 Preference 209 Priority 210 Policy Name 211 Explicit NULL Label Policy (ENLP) 212 Segment List 213 Weight 214 Path MTU 215 Segment 216 Segment 217 ... 218 ... 220 3.1. Path MTU Sub-TLV 222 A Path MTU sub-TLV is an Optional sub-TLV. When it appears, it must 223 appear only once at most within a Segment List sub-TLV. If multiple 224 Path MTU sub-TLVs appear within a Segment List sub-TLV, the NLRI MUST 225 be treated as a malformed NLRI. 227 As per [I-D.ietf-idr-segment-routing-te-policy], when the error 228 determined allows for the router to skip the malformed NLRI(s) and 229 continue processing of the rest of the update message, then it MUST 230 handle such malformed NLRIs as 'Treat-as-withdraw'. This document 231 does not define new error handling rules for Path MTU sub-TLV, and 232 the error handling rules defined in 233 [I-D.ietf-idr-segment-routing-te-policy] apply to this document. 235 A Path MTU sub-TLV is associated with an SR path specified by a 236 segment list sub-TLV or a path segment 237 [I-D.ietf-spring-mpls-path-segment] 238 [I-D.li-spring-srv6-path-segment]. The Path MTU sub-TLV has the 239 following format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | RESERVED | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Path MTU | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 1. Path MTU sub-TLV 250 Where: 252 Type: to be assigned by IANA. 254 Length: the total length of the value field not including Type and 255 Length fields. 257 Reserved: 16 bits reserved and MUST be set to 0 on transmission and 258 MUST be ignored on receipt. 260 Path MTU: 4 bytes value of path MTU in octets. The value can be 261 calculated by a central controller or other devices based on the 262 information that learned via IGP of BGP-LS or other means. 264 Whenever the path MTU of a physical or logical interface is changed, 265 a new SR policy with new path MTU information should be updated 266 accordingly by BGP. 268 4. Operations 270 The document does not bring new operation beyond the description of 271 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 272 existing operations defined in 273 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 274 directly. 276 Typically but not limit to, the SR policies carrying path MTU 277 infomation are configured by a controller. 279 After configuration, the SR policies carrying path MTU infomation 280 will be advertised by BGP update messages. The operation of 281 advertisement is the same as defined in 282 [I-D.ietf-idr-segment-routing-te-policy], as well as the receiption. 284 The consumer of the SR policies is not the BGP process. The 285 operation of sending information to consumers is out of scope of this 286 document. 288 5. Implementation Status 290 [Note to the RFC Editor - remove this section before publication, as 291 well as remove the reference to [RFC7942]. 293 This section records the status of known implementations of the 294 protocol defined by this specification at the time of posting of this 295 Internet-Draft, and is based on a proposal described in [RFC7942]. 296 The description of implementations in this section is intended to 297 assist the IETF in its decision processes in progressing drafts to 298 RFCs. Please note that the listing of any individual implementation 299 here does not imply endorsement by the IETF. Furthermore, no effort 300 has been spent to verify the information presented here that was 301 supplied by IETF contributors. This is not intended as, and must not 302 be construed to be, a catalog of available implementations or their 303 features. Readers are advised to note that other implementations may 304 exist. 306 According to [RFC7942], "this will allow reviewers and working groups 307 to assign due consideration to documents that have the benefit of 308 running code, which may serve as evidence of valuable experimentation 309 and feedback that have made the implemented protocols more mature. 310 It is up to the individual working groups to use this information as 311 they see fit". 313 5.1. Huawei's Commercial Delivery 315 The feature has been implemented on Huawei VRP8. 317 o Organization: Huawei 319 o Implementation: Huawei's Commercial Delivery implementation based 320 on VRP8. 322 o Description: The implementation has been done. 324 o Maturity Level: Product 326 o Contact: guokeqiang@huawei.com 328 6. IANA Considerations 330 This document defines a new Sub-TLV in registries "SR Policy List 331 Sub- TLVs" [I-D.ietf-idr-segment-routing-te-policy]: 333 Value Description Reference 334 --------------------------------------------------------------------- 335 TBA Path MTU sub-TLV This document 337 7. Security Considerations 339 TBA 341 8. Contributors 343 Jun Qiu 345 Huawei Technologies 347 China 349 Email: qiujun8@huawei.com 351 9. Acknowledgements 353 Authors would like to thank Ketan Talaulikar, Aijun Wang, Weiqiang 354 Cheng, Huanan Chen, Chongfeng Xie, Stefano Previdi, Taishan Tang, 355 Keqiang Guo, Chen Zhang, Susan Hares, Weiguo Hao, Gong Xia, Bing 356 Yang, Linda Dunbar, Shunwan Zhuang, Huaimo Chen, Mach Chen, Jingring 357 Xie, Zhibo Hu, Jimmy Dong and Jianwei Mao for their proprefessional 358 comments and help. 360 10. References 362 10.1. Normative References 364 [I-D.ietf-idr-segment-routing-te-policy] 365 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 366 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 367 Routing Policies in BGP", draft-ietf-idr-segment-routing- 368 te-policy-09 (work in progress), May 2020. 370 [I-D.ietf-spring-segment-routing-policy] 371 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 372 P. Mattes, "Segment Routing Policy Architecture", draft- 373 ietf-spring-segment-routing-policy-08 (work in progress), 374 July 2020. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 382 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 383 May 2017, . 385 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 386 Decraene, B., Litkowski, S., and R. Shakir, "Segment 387 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 388 July 2018, . 390 10.2. Informative References 392 [I-D.ietf-spring-mpls-path-segment] 393 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 394 "Path Segment in MPLS Based Segment Routing Network", 395 draft-ietf-spring-mpls-path-segment-03 (work in progress), 396 September 2020. 398 [I-D.li-spring-srv6-path-segment] 399 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 400 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 401 li-spring-srv6-path-segment-06 (work in progress), 402 September 2020. 404 [I-D.zhu-idr-bgp-ls-path-mtu] 405 Zhu, Y., Hu, Z., Peng, S., and R. Mwehair, "BGP-LS 406 Extensions for Advertising Path MTU", draft-zhu-idr-bgp- 407 ls-path-mtu-04 (work in progress), August 2020. 409 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 410 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 411 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 412 . 414 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 415 Code: The Implementation Status Section", BCP 205, 416 RFC 7942, DOI 10.17487/RFC7942, July 2016, 417 . 419 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 420 (IPv6) Specification", STD 86, RFC 8200, 421 DOI 10.17487/RFC8200, July 2017, 422 . 424 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 425 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 426 DOI 10.17487/RFC8201, July 2017, 427 . 429 Authors' Addresses 431 Cheng Li 432 Huawei Technologies 433 Huawei Campus, No. 156 Beiqing Rd. 434 Beijing 100095 435 China 437 Email: chengli13@huawei.com 438 YongQing Zhu 439 China Telecom 440 109, West Zhongshan Road, Tianhe District. 441 Guangzhou 442 China 444 Email: zhuyq8@chinatelecom.cn 446 Ahmed El Sawaf 447 Saudi Telecom Company 448 Riyadh 449 Saudi Arabia 451 Email: aelsawaf.c@stc.com.sa 453 Zhenbin Li 454 Huawei Technologies 455 Huawei Campus, No. 156 Beiqing Rd. 456 Beijing 100095 457 China 459 Email: lizhenbin@huawei.com