idnits 2.17.1 draft-li-idr-sr-policy-path-mtu-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 03, 2019) is 1635 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-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-01 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-03 == Outdated reference: A later version (-05) exists of draft-zhu-idr-bgp-ls-path-mtu-01 Summary: 0 errors (**), 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 6, 2020 China Telecom 6 A. Sawaf 7 Saudi Telecom Company 8 Z. Li 9 Huawei Technologies 10 November 03, 2019 12 Segment Routing Path MTU in BGP 13 draft-li-idr-sr-policy-path-mtu-03 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 6, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 3 63 3. SR Policy for Path MTU . . . . . . . . . . . . . . . . . . . 3 64 3.1. SR Path MTU Sub-TLV . . . . . . . . . . . . . . . . . . . 4 65 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Segment routing (SR) [RFC8402] is a source routing paradigm that 78 explicitly indicates the forwarding path for packets at the ingress 79 node. The ingress node steers packets into a specific path according 80 to the Segment Routing Policy ( SR Policy) as defined in 81 [I-D.ietf-spring-segment-routing-policy]. In order to distribute SR 82 policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] 83 specifies a mechanism by using BGP. 85 The maximum transmission unit (MTU) is the largest size packet or 86 frame, in bytes, that can be sent in a network. An MTU that is too 87 large might cause retransmissions. Too small an MTU might cause the 88 router to send and handle relatively more header overhead and 89 acknowledgments. 91 When an LSP is created across a set of links with different MTU 92 sizes, the ingress router needs to know what the smallest MTU is on 93 the LSP path. If this MTU is larger than the MTU of one of the 94 intermediate links, traffic might be dropped, because MPLS packets 95 cannot be fragmented. Also, the ingress router may not be aware of 96 this type of traffic loss, because the control plane for the LSP 97 would still function normally. [RFC3209] specify the mechanism of 98 MTU signaling in RSVP. Likewise, SRv6 pakcets will be dropped if the 99 packet size is larger than path MTU, since IPv6 packet can not be 100 fragmented on transmission [RFC8200] . 102 The host may discover the PMTU by Path MTU Discovery (PMTUD) 103 [RFC8201] or other mechanisms. But the ingress still needs to 104 examine the packet size for dropping too large packets to avoid 105 malicious traffic or error traffic. Also, the packet size may 106 exceeds the PMTU because of the new encapsulation of SR-MPLS or SRv6 107 packet at the ingress. 109 In order to check whether the Packet size exceeds the PMTU or not, 110 the ingress node needs to know the Path MTU associated to the 111 forwarding path. However, the path maximum transmission unit (MTU) 112 information for SR path is not available since the SR does not 113 require signaling. 115 This document defines extensions to BGP to distribute path MTU 116 information within SR policies. The Link MTU information can be 117 obtained via BGP-LS [I-D.zhu-idr-bgp-ls-path-mtu] or some other 118 means. With the Link MTU, the controller can compute the PMTU and 119 convey the information via the BGP SR policy. 121 2. Terminology 123 This memo makes use of the terms defined in [RFC8402] and [RFC3209]. 125 2.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. SR Policy for Path MTU 135 As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR 136 policy encoding structure is as follows: 138 SR Policy SAFI NLRI: 139 Attributes: 140 Tunnel Encaps Attribute (23) 141 Tunnel Type: SR Policy 142 Binding SID 143 Preference 144 Priority 145 Policy Name 146 Explicit NULL Label Policy (ENLP) 147 Segment List 148 Weight 149 Segment 150 Segment 151 ... 152 ... 154 As introduced in Section 1, each SR path has it's path MTU. SR 155 policy with SR path MTU information is expressed as below: 157 SR Policy SAFI NLRI: 158 Attributes: 159 Tunnel Encaps Attribute (23) 160 Tunnel Type: SR Policy 161 Binding SID 162 Preference 163 Priority 164 Policy Name 165 Explicit NULL Label Policy (ENLP) 166 Segment List 167 Weight 168 Path MTU 169 Segment 170 Segment 171 ... 172 ... 174 3.1. SR Path MTU Sub-TLV 176 An SR Path MTU sub-TLV is an Optional sub-TLV. When it appears, it 177 must appear only once at most within a Segment List sub-TLV. If 178 multiple Path MTU sub-TLVs appear within a Segment List sub-TLV, the 179 first one will be processed, and the rest will be ignored. An SR 180 Path MTU sub-TLV is associated with an SR path specified by a segment 181 list sub-TLV or path segment as defined in 182 [I-D.ietf-spring-mpls-path-segment] and 183 [I-D.li-spring-srv6-path-segment]. It has the following format: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | RESERVED | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Path MTU | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1. Path MTU sub-TLV 194 Where: 196 Type: to be assigned by IANA. 198 Length: the total length of the value field not including Type and 199 Length fields. 201 Reserved: 16 bits reserved and MUST be set to 0 on transmission and 202 MUST be ignored on receipt. 204 Path MTU: 4 bytes value of path MTU in octets. The value can be 205 calculated by a central controller or other devices based on the 206 information that learned via IGP of BGP-LS or other means. 208 Whenever the path MTU of a physical or logical interface is changed, 209 a new SR policy with new path MTU information should be updated 210 accordingly by BGP. 212 4. Operations 214 The document does not bring new operation beyong the description of 215 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 216 existing operations defined in 217 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 218 directly. 220 Typically but not limit to, the SR policies carrying path MTU 221 infomation are configured by a controller. 223 After configuration, the SR policies carrying path MTU infomation 224 will be advertised by BGP update messages. The operation of 225 advertisement is the same as defined in 226 [I-D.ietf-idr-segment-routing-te-policy], as well as the receiption. 228 The consumer of the SR policies is not the BGP process. The 229 operation of sending information to consumers is out of scope of this 230 document. 232 5. IANA Considerations 234 This document defines a new Sub-TLV in registries "SR Policy List 235 Sub- TLVs" [I-D.ietf-idr-segment-routing-te-policy]: 237 Value Description Reference 238 --------------------------------------------------------------------- 239 TBA Path MTU sub-TLV This document 241 6. Security Considerations 243 TBA 245 7. Contributors 247 Jun Qiu 249 Huawei Technologies 251 China 253 Email: qiujun8@huawei.com 255 8. Acknowledgements 257 TBA 259 9. References 261 9.1. Normative References 263 [I-D.ietf-idr-segment-routing-te-policy] 264 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain, 265 D., and S. Lin, "Advertising Segment Routing Policies in 266 BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in 267 progress), July 2019. 269 [I-D.ietf-spring-segment-routing-policy] 270 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 271 P. Mattes, "Segment Routing Policy Architecture", draft- 272 ietf-spring-segment-routing-policy-03 (work in progress), 273 May 2019. 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 281 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 282 May 2017, . 284 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 285 Decraene, B., Litkowski, S., and R. Shakir, "Segment 286 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 287 July 2018, . 289 9.2. Informative References 291 [I-D.ietf-spring-mpls-path-segment] 292 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 293 "Path Segment in MPLS Based Segment Routing Network", 294 draft-ietf-spring-mpls-path-segment-01 (work in progress), 295 September 2019. 297 [I-D.li-spring-srv6-path-segment] 298 Li, C., Cheng, W., Chen, M., Dhody, D., Li, Z., Dong, J., 299 and R. Gandhi, "Path Segment for SRv6 (Segment Routing in 300 IPv6)", draft-li-spring-srv6-path-segment-03 (work in 301 progress), August 2019. 303 [I-D.zhu-idr-bgp-ls-path-mtu] 304 Zhu, Y., Hu, Z., Yan, G., and J. Yao, "BGP-LS Extensions 305 for Advertising Path MTU", draft-zhu-idr-bgp-ls-path- 306 mtu-01 (work in progress), July 2019. 308 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 309 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 310 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 311 . 313 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 314 (IPv6) Specification", STD 86, RFC 8200, 315 DOI 10.17487/RFC8200, July 2017, 316 . 318 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 319 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 320 DOI 10.17487/RFC8201, July 2017, 321 . 323 Authors' Addresses 325 Cheng Li 326 Huawei Technologies 327 Huawei Campus, No. 156 Beiqing Rd. 328 Beijing 100095 329 China 331 Email: chengli13@huawei.com 333 YongQing Zhu 334 China Telecom 335 109, West Zhongshan Road, Tianhe District. 336 Guangzhou 337 China 339 Email: zhuyq.gd@chinatelecom.cn 341 Ahmed El Sawaf 342 Saudi Telecom Company 343 Riyadh 344 Saudi Arabia 346 Email: aelsawaf.c@stc.com.sa 348 Zhenbin Li 349 Huawei Technologies 350 Huawei Campus, No. 156 Beiqing Rd. 351 Beijing 100095 352 China 354 Email: lizhenbin@huawei.com