idnits 2.17.1 draft-hu-lsr-igp-path-mtu-00.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (19 October 2021) is 919 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Hu 3 Internet-Draft S. Peng 4 Intended status: Informational X. Xi 5 Expires: 22 April 2022 Huawei 6 19 October 2021 8 IGP Extensions for Path MTU 9 draft-hu-lsr-igp-path-mtu-00 11 Abstract 13 Segment routing (SR) leverages the source routing mechanism. It 14 allows for a flexible definition of end-to-end paths within IGP 15 topologies by encoding paths as sequences of topological sub-paths 16 which are called segments. These segments are advertised by the 17 link-state routing protocols (IS-IS and OSPF). Unlike the MPLS, SR 18 does not have the specific path construction signaling so that it 19 cannot support the Path MTU. This draft provides the necessary IS-IS 20 and OSPF extensions about the Path MTU that need to be used on SR. 21 Here, the term "OSPF" means both OSPFv2 and OSPFv3. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in BCP 14 [RFC2119] 28 [RFC8174] when, and only when, they appear in all capitals, as shown 29 here. 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 https://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 22 April 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. IGP Extension . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. IS-IS Extension . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. OSPF Extension . . . . . . . . . . . . . . . . . . . . . 5 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Segment routing (SR) leverages the source routing mechanism. SR 78 allows for a flexible definition of end-to-end paths within IGP 79 topologies by encoding paths as sequences of topological sub-paths 80 which are called segments. These segments are advertised by the 81 link-state routing protocols (IS-IS and OSPF). The SR architecture 82 as well as the routing policy is proposed in [RFC8402] and 83 [I-D.ietf-spring-segment-routing-policy]. Two types of segments are 84 defined, Prefix segments and Adjacency segments. Prefix segments 85 represent an ECMP-aware shortest path to a prefix (or a node), as per 86 the state of the IGP topology. Adjacency segments represent a hop 87 over a specific adjacency between two nodes in the IGP. A prefix 88 segment is typically a multi-hop path while an adjacency segment, in 89 most of the cases, is a one-hop path. SR can compute the paths from 90 end to end and without requiring any LDP or RSVP-TE signaling. SR 91 supports per-flow explicit routing while just maintaining per-flow 92 state only at the source node. 94 SR architecture supports the distributed scenario and the centralized 95 scenario. In the distributed scenario, the segments are allocated 96 and signaled by IGP or BGP and a node needs to compute the source- 97 routed policy. Some necessary IS-IS and OSPF extensions for SR are 98 proposed in [RFC8665] [RFC8666] [RFC8667]. In a centralized 99 scenario, the SR controller decides which nodes need to steer which 100 packets on which source-routed policies. However, in both 101 conditions, the MTU is not included in the SR policy. As the SR may 102 push more MPLS labels or SRv6 SIDs in the packet header, the packets 103 are more likely to be larger than the minimum MTU in the path 104 compared to the traditional MPLS forwarding process. Unfortunately, 105 with the current mechanisms in SR, the path MTU information cannot be 106 obtained in advance. Therefore it cannot be ensured that the packet 107 size is less than the path MTU which is the minimum link MTU of all 108 the links in a path between a source node and a destination node. 109 The definition of the path MTU is discussed in [RFC1191] [RFC8201]. 111 This draft describes the necessary IS-IS and OSPF extensions for 112 obtaining the path MTU to be used on SR. New sub-TLVs are introduced 113 for both the IS-IS and OSPF protocols. With the IGP flooding process 114 in the distributed scenario or the BGP transmission to the 115 controller, the ingress node or the controller is able to compute the 116 path MTU for the SR policy. 118 2. Terminology 120 Router: A node that forwards IP packets not explicitly addressed to 121 itself. 123 Interface: A node's attachment to a link. 125 Segment: An instruction a node executes on the incoming packet. For 126 example, forward packet according to shortest path to destination or 127 a specific interface, etc.. 129 SR Policy: An ordered list of segments. 131 MTU: Maximum Transmission Unit, the size in bytes of the largest IP 132 packet, including the IP header and payload, that can be transmitted 133 on a link or path. Note that this could more properly be called the 134 IP MTU, to be consistent with how other standards organizations use 135 the acronym MTU. 137 Link MTU: The maximum transmission unit, i.e., maximum IP packet size 138 in bytes, that can be conveyed in one piece over a link. Be aware 139 that this definition is different from the definition used by other 140 standards organizations. 142 For IETF documents, link MTU is uniformly defined as the IP MTU over 143 the link. This includes the IP header, but excludes link layer 144 headers and other framing that is not part of IP or the IP payload. 146 Be aware that other standards organizations generally define link MTU 147 to include the link layer headers. 149 For the MPLS data plane, this size includes the IP header and data 150 (or other payload) and the label stack but does not include any 151 lower-layer headers. A link may be an interface (such as Ethernet or 152 Packet-over- SONET), a tunnel (such as GRE or IPsec), or an LSP. 154 Path: The set of links traversed by a packet between a source node 155 and a destination node 157 Path MTU: The minimum link MTU of all the links in a path between a 158 source node and a destination node. 160 3. IGP Extension 162 This document describes IS-IS and OSPF extensions to flood the router 163 interface MTU to each node within an IGP domain. Then the controller 164 or the original node collects all the link MTUs from the routers. So 165 the original node can compute the minimum link MTU of all the links 166 in the path. The source node can limit the packet size less than the 167 path MTU. 169 3.1. IS-IS Extension 171 A new sub-TLV called link MTU sub-TLV is defined for TLVs 22, 23, 25, 172 141, 222, 223 in the Router Information LSP to carry the MTU of the 173 interface associated with the link . Each sub-TLV is encoded as shown 174 in Figure 1. 176 Type: MTU, 1 byte, TBD. 178 Length: # of octets in the value field, 1 byte. 180 Value: The value is the MTU size of a link, 2 bytes. 182 0 1 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type = MTU | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | MTU-Value | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1: Figure 1: Link MTU Sub-TLV for the IS-IS extension 192 The use and meaning of these fields are as follows: 194 Type - A single octet encoding the sub-TLV type. Here the type is 1 195 octet. 197 Length - A single octet encoding the total length of the value field 198 of the sub-TLV in octets. 200 MTU-Value - Two octets encoding the MTU size of the sub-TLV. This 201 field identifies the size of the router interfaces. 203 This sub-TLV is optional. 205 This document defines a link MTU sub-TLV for IS-IS extension. The 206 codepoints need to be determined by the IANA. 208 3.2. OSPF Extension 210 A new sub-TLV called link MTU sub-TLV is defined in the corresponding 211 LSA as specified for OSPFv2 and OSPFv3 to carry the MTU of the 212 interface associated with the link. Each sub-TLV is encoded as shown 213 in Figure 2. 215 Type: MTU, 2 bytes, TBD. 217 Length: # of octets in the value field, 2 bytes. 219 Value: The value is the MTU size of a link, 2 bytes. 221 0 1 222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type = MTU | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | MTU-Value | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 2: Figure 2: Link MTU Sub-TLV for the OSPF extension 233 The use and meaning of these fields are as follows: 235 Type - Two octets encoding the TLV type. Here the type is 2 octets. 237 For OSPFv2, the link MTU is advertised as an optional sub-TLV of the 238 OSPFv2 Extended Link TLV in the OSPFv2 Extended Link Opaque LSA as 239 defined in [RFC7684] and the codepoints need to be determined by the 240 IANA. 242 For OSPFv3, the link MTU is advertised as an optional sub-TLV of the 243 Router-Link TLV in the OSPFv3 E-Router-LSA as defined in [RFC8362] 244 and the codepoints need to be determined by the IANA. 246 Length - Two octets encoding the total length of the value field of 247 the sub-TLV in octets. 249 MTU-Value - Two octets encoding the MTU size of the TLV. This field 250 identifies the size of the router interfaces. 252 If the link MTU sub-TLV is advertised for multiple times for the same 253 link in different OSPFv2 Extended Link Opaque LSAs or OSPFv3 E- 254 Router-LSAs originated by the same OSPF router, the link MTU sub-TLV 255 in the OSPFv2 Extended Link Opaque LSA with the smallest Opaque ID or 256 in the OSPFv3 E-Router-LSA with the smallest Link State ID MUST be 257 used by receiving OSPF routers. 259 4. Acknowledgements 261 TBD. 263 5. IANA Considerations 265 This document requests that IANA allocates a new sub-TLV type as 266 defined in Section 3.1 from the "Sub-TLVs for TLVs 22, 23, 25, 141, 267 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 268 Bundle Member Attributes, inter-AS reachability information, MT-ISN, 269 and MT IS Neighbor Attribute TLVs)" registry as specified. 271 Value Description Reference 272 ---------------------- ---------------------------- -------------- 273 TBD IS-IS Link MTU This document 275 Figure 3: Figure 3: IS-IS Link MTU 277 This document requests that IANA allocates a new sub-TLV type as 278 defined in Section 3.2 from the "OSPFv2 Extended Link TLV Sub-TLVs" 279 registry. 281 Value Description Reference 282 ---------------------- ---------------------------- -------------- 283 TBD OSPFv2 Link MTU This document 284 Figure 4: Figure 4: OSPFv2 Link MTU 286 This document requests that IANA allocates a new sub-TLV type as 287 defined in Section 3.2 from the "OSPFv3 Extended LSA Sub-TLVs" 288 registry. 290 Value Description Reference 291 ---------------------- ---------------------------- -------------- 292 TBD OPSFv3 Link MTU This document 294 Figure 5: Figure 5: OSPFv3 Link MTU 296 6. Security Considerations 298 These extensions to IS-IS and OSPF do not add any new security issues 299 to the existing IGP. 301 7. References 303 [I-D.ietf-spring-segment-routing-policy] 304 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 305 P. Mattes, "Segment Routing Policy Architecture", Work in 306 Progress, Internet-Draft, draft-ietf-spring-segment- 307 routing-policy-13, 28 May 2021, 308 . 311 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 312 DOI 10.17487/RFC1191, November 1990, 313 . 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 321 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 322 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 323 2015, . 325 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 326 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 327 May 2017, . 329 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 330 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 331 DOI 10.17487/RFC8201, July 2017, 332 . 334 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 335 F. Baker, "OSPFv3 Link State Advertisement (LSA) 336 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 337 2018, . 339 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 340 Decraene, B., Litkowski, S., and R. Shakir, "Segment 341 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 342 July 2018, . 344 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 345 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 346 Extensions for Segment Routing", RFC 8665, 347 DOI 10.17487/RFC8665, December 2019, 348 . 350 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 351 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 352 December 2019, . 354 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 355 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 356 Extensions for Segment Routing", RFC 8667, 357 DOI 10.17487/RFC8667, December 2019, 358 . 360 Authors' Addresses 362 Zhibo Hu 363 Huawei 364 Huawei Bld., No.156 Beiqing Rd. 365 Beijing 366 100095 367 China 369 Email: huzhibo@huawei.com 370 Shuping Peng 371 Huawei 372 Huawei Bld., No. 156 Beiqing Rd. 373 Beijing 374 100095 375 China 377 Email: pengshuping@huawei.com 379 Xing Xi 380 Huawei 381 Huawei Bld., No. 156 Beiqing Rd. 382 Beijing 383 100095 384 China 386 Email: xixing1@huawei.com