idnits 2.17.1 draft-wang-lsr-hbh-process-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 : ---------------------------------------------------------------------------- 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 (October 29, 2020) is 1273 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Link State Routing Working Group Y. Wang 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Z. Hu 5 Expires: May 2, 2021 Huawei 6 October 29, 2020 8 IGP Extensions for Advertising Hop-by-Hop Options Header Processing 9 Action 10 draft-wang-lsr-hbh-process-00 12 Abstract 14 This document extends Node and Link attribute TLVs to Interior 15 Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header 16 processing action and supported services (e.g. IOAM Trace Option and 17 Alternate Marking) at node and link granularity. Such advertisements 18 allow entities (e.g., centralized controllers) to determine whether 19 the Hop-by-Hop Options header and specific services can be supported 20 in a given network. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 2, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Hop-by-Hop Options Header Processing Action . . . . . . . . . 4 65 4. Signaling Processing Action Using IS-IS . . . . . . . . . . . 5 66 4.1. IS-IS Node Processing-Action Sub-TLV . . . . . . . . . . 5 67 4.2. IS-IS Link Processing-Action Sub-TLV . . . . . . . . . . 6 68 5. Signaling Processing Action Using OSPF . . . . . . . . . . . 6 69 5.1. OSPF Node Processing-Action TLV . . . . . . . . . . . . . 7 70 5.2. OSPFv2 Link Processing-Action sub-TLV . . . . . . . . . . 7 71 5.3. OSPFv3 Link Processing-Action Sub-TLV . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 9.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 [RFC8200] specifies IPv6 extension headers, including Hop-by-Hop 83 Options header, Destination Options header, Routing header, etc. An 84 IPv6 packet may carry zero, one, or more extension headers that must 85 be processed strictly in the order they appear in the packet. Except 86 for the Hop-by-Hop Options header, other extension headers are not 87 processed, inserted, or deleted by any transit node along a packet's 88 delivery path, until the packet arrives at the Destination node. 90 As specified in [RFC8200], although the Hop-by-Hop Options header is 91 not inserted or deleted by any transit node along a packet's delivery 92 path, it is only examined and processed by nodes along a packet's 93 delivery path if they are explicitly configured to process. Besides, 94 nodes may be configured to ignore the Hop-by-Hop Options header, drop 95 packets containing a Hop-by-Hop Options header, or assign packets 96 containing a Hop-by-Hop Options header to a slow processing path. In 97 the results, devices of different vendors can be configured to 98 process the Hop-by-Hop Options header in different ways. 100 Until now, the Hop-by-Hop Options header has been widely used. In- 101 situ Operations, Administration, and Maintenance (IOAM) data fields 102 are encapsulated in two types of extension headers in IPv6 packets, 103 either Hop-by-Hop Options header or Destination Options header, 104 depending on IOAM usage [I-D.ietf-ippm-ioam-ipv6-options]. For 105 example, IOAM-tracing options are represented as an IPv6 options in 106 Hop-by-Hop extension header. Similarly, the Alternate Marking 107 technique can be carried by the Hop-by-Hop Options header and the 108 Destination Options header [I-D.ietf-6man-ipv6-alt-mark]. If nodes 109 are not explicitly configured to process the Hop-by-Hop Option 110 header, they should ignore them. In this case, the performance 111 measurement does not account for all links and nodes along a path. 112 Therefore, such advertisement can be useful for entities (e.g., the 113 centralized controller) to determine whether a specific service can 114 be implemented in IPv6 netowrk by encoding in the Hop-by-Hop Options 115 header. 117 BGP-LS defines a way to advertise topology and associated attributes 118 and capabilities of the nodes in that topology to a centralized 119 controller [RFC7752]. Typically, BGP-LS is configured on a small 120 number of nodes that do not necessarily act as head-ends. In order 121 for BGP-LS to signal the processing action of the Hop-by-Hop Options 122 header for all the devices in the network, the processing action 123 SHOULD be advertised by every IGP router in the network. 125 This document defines a mechanism to signal the configured processing 126 action of the Hop-by-Hop Options header and supported services at 127 node and/or link granularity using IS-IS, OSPFv2 and OSPFv3. 129 2. Terminology 131 Following are abbreviations used in this document: 133 o IGP: Interior Gateway Protocols 135 o IS-IS: Intermediate System to Intermediate System 137 o OSPF: Open Shortest Path First 139 o BGP-LS: Border Gateway Protocol - Link State 140 o NLRI: Network Layer Reachability Information 142 3. Hop-by-Hop Options Header Processing Action 144 This document defines the information of processing action formed of 145 a tuple of a 1-octet Extension Header Options identifier and 8-bit 146 Processing Action Flag. 148 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 149 +---------------+-------------------------------+---------------+ 150 | Action Flag | Services Flag | Max EH Len | 151 +---------------+-------------------------------+---------------+ 153 Fig. 1 Processing Action Format 155 Where: 157 o Action Flag: A 8-bit field. The highest-order 3-bit indicates the 158 processing action, i.e., 000 - drop packets; 001 - dispatch to 159 control plane; 010 - forward, skip to Next Header; 011 - forward, 160 ignoring all extension Options header; 100 - examine and process. 162 o Max EH Len: A one octet field. The maximum length of the 163 Extension Header in 8-octet units can be examined and processed at 164 node or link granularity. The definition is same as the Next 165 Header Length in [RFC8200]. 167 o Services Flag: A 16-bit bitmap. The format is defined as follows. 169 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 170 +-------------------------------+ 171 |O|A| Reserved | 172 +-------------------------------+ 174 Fig. 2 Services Flag Format 176 where fields are defined as the following: 178 o O (IOAM Trace Option) is a one-bit flag. The O flag is set to 1 179 if the IOAM Trace Option is supported at node or link granularity. 181 o A (Alternate Marking) is a one-bit flag. The A flag is set to 1 182 if the Alternate Marking method is supported at node or link 183 granularity. 185 o R - reserved bits for future use. These flags MUST be zeroed on 186 transimit and ignored on receipt. 188 In this document, the processing action at link granularity is 189 defined as the supported the Hop-by-Hop Options header processing 190 action of the interface associated with the link. When all 191 interfaces associated with links support the same processing action, 192 the processing action at node granularity SHOULD represent the Link 193 processing action. Both of Node and Link processing action 194 information are formed of a tuple of a 1-octet Extension Header 195 Options identifier and 8-bit Processing Action Flag. 197 When both of Node and Link processing action are advertised, the Link 198 processing action information MUST take precedence over the Node 199 processing action. Besides, when a Link processing action is not 200 signaled, then the Node processing action SHOULD be considered to be 201 the processing action for this link. 203 4. Signaling Processing Action Using IS-IS 205 The IS-IS Extensions for advertising Router Information TLV named IS- 206 IS Router CAPABILITY TLV [RFC7981], which allows a router to announce 207 its capabilities within an IS-IS level or the entire routing domain. 209 4.1. IS-IS Node Processing-Action Sub-TLV 211 According to the format of IS-IS Router CAPABILITY TLV [RFC7981], the 212 Node Processing-Action sub-TLV within the body of the IS-IS router 213 CAPABILITY TLV is composed of three fields, a one-octet Type field, a 214 one-octet Length field, and a 4-octet Value field. The following 215 format is used: 217 0 1 2 3 218 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 219 +---------------+---------------+ 220 | Type | Length | 221 +---------------+---------------+-------------------------------+ 222 | Node-Processing-Action | 223 +---------------------------------------------------------------+ 225 Fig. 3 IS-IS Node Processing-Action Sub-TLV Format 227 Where: 229 o Type: To be assigned by IANA 231 o Length: A one-octet field that indicates the length of the value 232 portion in octets. 234 o Node-Processing-Action: A 4-octet field, which is same as defined 235 in Section 3. 237 4.2. IS-IS Link Processing-Action Sub-TLV 239 The Link Processing-Action sub-TLV is defined for TLVs 22, 23, 25, 240 141, 222, and 223 to carry the Processing-Action information of the 241 interface associated with the link. The Link Processing-Action sub- 242 TLV is formed of three fields, a one-octet Type field, a one-octet 243 Length field, and a 4-octet Value field. The following format is 244 used: 246 0 1 2 3 247 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 248 +---------------+---------------+ 249 | Type | Length | 250 +---------------+---------------+-------------------------------+ 251 | Link-Processing-Action | 252 +---------------------------------------------------------------+ 254 Fig. 4 IS-IS Link Processing-Action Sub-TLV Format 256 Where: 258 o Type: To be assigned by IANA 260 o Length: A one-octet field that indicates the length of the value 261 portion in octets. 263 o Link-Processing-Action: A 4-octet field, which is same as defined 264 in Section 3. 266 5. Signaling Processing Action Using OSPF 268 Given that OSPF uses the options field in LSAs and hello packets to 269 advertise optional router capabilities [RFC7770], this document 270 defines a new Node Processing-Action TLV within the body of the OSPF 271 RI Opaque LSA [RFC7770] to carry the Processing Action of the router 272 originating the RI LSA. 274 This document defines the Link Processing-Action sub-TLV to carry the 275 Processing-Action information of the interface associated with the 276 link. For OSPFv2, the link-level Processing-Action information is 277 advertised as a sub-TLV of the OSPFv2 Extended Link TLV as defined in 278 [RFC7684]. For OSPFv3, the link-level Processing-Action information 279 is advertised a sub-TLV of the E-Router-LSA TLV as defined in 280 [RFC8362]. 282 5.1. OSPF Node Processing-Action TLV 284 The Node Processing-Action TLV is composed of three fields, a 2-octet 285 Type field, a 2-octet Length field, and a 4-octet Value field. The 286 following format is used: 288 0 1 2 3 289 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 290 +-------------------------------+-------------------------------+ 291 | Type | Length | 292 +---------------------------------------------------------------+ 293 | Node-Processing-Action | 294 +---------------------------------------------------------------+ 296 Fig. 5 OSPF Node Processing-Action TLV 298 Where: 300 o Type: To be assigned by IANA 302 o Length: A 2-octet field that indicates the length of the value 303 field. 305 o Node-Processing-Action: A 4-octet field, which is as defined in 306 Section 3. 308 5.2. OSPFv2 Link Processing-Action sub-TLV 310 The Link Processing-Action sub-TLV encoded in the OSPFv2 Extended 311 Link TLV as defined in [RFC7684], which is constructed of three 312 fields, a 2-octet Type field, a 2-octet Length field, and a 4-octet 313 Value field. The following format is used: 315 0 1 2 3 316 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 317 +-------------------------------+-------------------------------+ 318 | Type | Length | 319 +---------------------------------------------------------------+ 320 | Link-Processing-Action | 321 +---------------------------------------------------------------+ 323 Fig. 6 OSPFv2 Link Processing-Action sub-TLV 325 Where: 327 o Type: To be assigned by IANA 328 o Length: A 2-octet field that indicates the length of the value 329 field. 331 o Link-Processing-Action: A 4-octet field, which is as defined in 332 Section 3. 334 5.3. OSPFv3 Link Processing-Action Sub-TLV 336 The Link Processing-Action sub-TLV encoded in the OSPFv3 E-Router-LSA 337 TLV as defined in [RFC8362], which is constructed of three fields, a 338 2-octet Type field, a 2-octet Length field, and a 4-octet Value 339 field. The following format is used: 341 0 1 2 3 342 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 343 +-------------------------------+-------------------------------+ 344 | Type | Length | 345 +---------------------------------------------------------------+ 346 | Link-Processing-Action | 347 +---------------------------------------------------------------+ 349 Fig. 7 OSPFv3 Link Processing-Action sub-TLV 351 Where: 353 o Type: To be assigned by IANA 355 o Length: A 2-octet field that indicates the length of the value 356 field. 358 o Link-Processing-Action: A 4-octet field, which is as defined in 359 Section 3. 361 6. IANA Considerations 363 IANA is requested to allocate values for the following new TLV and 364 sub-TLVs. 366 +------+--------------------------------------+ 367 | Type | Description | 368 +------+--------------------------------------+ 369 | TBA | IS-IS Node Processing-Action Sub-TLV | 370 | TBA | IS-IS Link Processing-Action Sub-TLV | 371 +------+--------------------------------------+ 373 +------+---------------------------------------+ 374 | Type | Description | 375 +------+---------------------------------------+ 376 | TBA | OSPF Node Processing-Action TLV | 377 | TBA | OSPFv2 Link Processing-Action sub-TLV | 378 | TBA | OSPFv3 Link Processing-Action sub-TLV | 379 +------+---------------------------------------+ 381 7. Security Considerations 383 This document introduces new IGP Node and Link Attribute TLVs and 384 sub-TLVs for dvertising processing actions of the Hop-by-Hop Options 385 header at node and/or link granularity. It does not introduce any 386 new security risks to IS-IS, OSPFv2 and OSPFv3. 388 8. Acknowledgements 390 TBD 392 9. References 394 9.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, 398 DOI 10.17487/RFC2119, March 1997, 399 . 401 [RFC7684] "OSPFv2 Prefix/Link Attribute Advertisement", 402 . 404 [RFC7752] "North-Bound Distribution of Link-State and Traffic 405 Engineering (TE) Information Using BGP", 406 . 408 [RFC7770] "Extensions to OSPF for Advertising Optional Router 409 Capabilities", . 411 [RFC7981] "IS-IS Extensions for Advertising Router Information", 412 . 414 [RFC8200] "Internet Protocol, Version 6 (IPv6) Specification", 415 . 417 [RFC8362] "OSPFv3 Link State Advertisement (LSA) Extensibility", 418 . 420 9.2. Informative References 422 [I-D.ietf-6man-ipv6-alt-mark] 423 "IPv6 Application of the Alternate Marking Method", 424 . 427 [I-D.ietf-ippm-ioam-ipv6-options] 428 "In-situ OAM IPv6 Options", 429 . 432 Authors' Addresses 434 Yali Wang 435 Huawei 436 156 Beiqing Rd., Haidian District 437 Beijing 438 China 440 Email: wangyali11@huawei.com 442 Tianran Zhou 443 Huawei 444 156 Beiqing Rd., Haidian District 445 Beijing 446 China 448 Email: zhoutianran@huawei.com 450 Zhibo Hu 451 Huawei 452 156 Beiqing Rd., Haidian District 453 Beijing 454 China 456 Email: huzhibo@huawei.com