idnits 2.17.1 draft-wang-lsr-igp-extensions-ifit-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 (July 12, 2020) is 1355 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 M. Liu 5 Expires: January 13, 2021 Huawei 6 H. Chen 7 China Telecom 8 R. Pang 9 China Unicom 10 July 12, 2020 12 IGP Extensions for In-situ Flow Information Telemetry (IFIT) Capability 13 Advertisement 14 draft-wang-lsr-igp-extensions-ifit-00 16 Abstract 18 This document extends Node and Link Attribute TLVs to Interior 19 Gateway Protocols (IGP) to advertise supported In-situ Flow 20 Information Telemetry (IFIT) capabilities at node and/or link 21 granularity. An ingress router cannot insert IFIT-Data-Fields for 22 packets going into a path unless an egress router has indicated via 23 signaling that it has the capability to process IFIT-Data-Fields. In 24 addition, such advertisements would be useful for ingress routers to 25 gather each router's IFIT capability for achieving the computation of 26 Traffic Engineering (TE) paths or loose TE paths that be able to 27 fulfill the visibility of on-path OAM data. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 13, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. IFIT Capability . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Signaling IFIT Capability Using IS-IS . . . . . . . . . . . . 6 72 4.1. IS-IS Node IFIT Sub-TLV . . . . . . . . . . . . . . . . . 6 73 4.2. IS-IS Link IFIT Sub-TLV . . . . . . . . . . . . . . . . . 6 74 5. Signaling IFIT Capability Using OSPF . . . . . . . . . . . . 7 75 5.1. OSPF Node IFIT TLV . . . . . . . . . . . . . . . . . . . 7 76 5.2. OSPFv2 Link IFIT sub-TLV . . . . . . . . . . . . . . . . 8 77 5.3. OSPFv3 Link IFIT Sub-TLV . . . . . . . . . . . . . . . . 9 78 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 10.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 IFIT provides a high-level framework and a reflection-loop solution 90 for on-path telemetry [I-D.song-opsawg-ifit-framework]. At present, 91 there is a family of emerging on-path telemetry techniques, including 92 In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data], IOAM Direct Export 93 (DEX) [I-D.ietf-ippm-ioam-direct-export], Enhanced Alternate Marking 94 (EAM) [I-D.ietf-6man-ipv6-alt-mark], etc. 96 IFIT is a solution focusing on network domains. The "network domain" 97 consists of a set of network devices or entities within a single 98 Autonomous System (AS). The part of the network which employs IFIT 99 is referred to as the IFIT domain. One network domain may consist of 100 multiple IFIT domains. An IFIT domain may cross multiple network 101 domains. The family of emerging on-path telemetry techniques may be 102 partially enabled in different vendors' devices as an emerging 103 feature for various use cases of application-aware network 104 operations. So that in order to dynamically enable IFIT 105 functionality in a network domain, it is necessary to advertise the 106 information of IFIT option types supported in each device. 108 An ingress router cannot insert IFIT-Data-Fields for packets going 109 into a path unless an egress router has indicated via signaling that 110 it has the capability to process IFIT-Data-Fields. In addition, such 111 advertisements would be useful for ingress routers to gather each 112 router's IFIT capability for achieving the computation of TE paths or 113 loose TE paths that be able to fulfill the visibility of on-path OAM 114 data. 116 BGP-LS defines a way to advertise topology and associated attributes 117 and capabilities of the nodes in that topology to a centralized 118 controller [RFC7752]. Typically, BGP-LS is configured on a small 119 number of nodes that do not necessarily act as head-ends. In order 120 for BGP-LS to signal IFIT node capabilities for all the devices in 121 the network, IFIT node capabilities SHOULD be advertised by every IGP 122 router in the network. 124 This document defines a mechanism to signal the supported IFIT 125 capabilities at node and/or link granularity using IS-IS, OSPFv2 and 126 OSPFv3. 128 2. Terminology 130 Following are abbreviations used in this document: 132 o BGP-LS: Border Gateway Protocol - Link State 134 o IS-IS: Intermediate System to Intermediate System 136 o OSPF: Open Shortest Path First 138 o IFIT: In-situ Flow Information Telemetry 140 o TE: Traffic Engineering 142 o IOAM: In-situ OAM 143 o PBT: Postcard-Based Telemetry 145 o DEX: IOAM Direct Export 147 o EAM: Enhanced Alternate Marking 149 o IGP: Interior Gateway Protocols 151 o AS: Autonomous System 153 o E2E: Edge-to-Edge 155 o NLRI: Network Layer Reachability Information 157 3. IFIT Capability 159 Each IFIT-capable node is configured with a node-id which uniquely 160 identifies a node within the associated IFIT domain. To accommodate 161 the different use cases or requirements of in-situ flow information 162 telemetry, IFIT data fields updated by network nodes fall into 163 different categories which are referred as different IFIT option 164 types, including IOAM Trace Option-Types [I-D.ietf-ippm-ioam-data], 165 IOAM Edge-to-Edge (E2E) Option-Type [I-D.ietf-ippm-ioam-data], IOAM 166 DEX Option-Type [I-D.ietf-ippm-ioam-direct-export] and EAM Option- 167 Type [I-D.ietf-6man-ipv6-alt-mark]. A subset or all the IFIT-Option- 168 Types and their corresponding IFIT-Data-Fields can be associated to 169 an IFIT-Namespace. Namespace identifiers allow a device which is 170 IFIT-capable to determine whether IFIT-Option-Types need to be 171 processed. So that IFIT-Option-Types and Namespace-IDs SHOULD be 172 included in IFIT capability information. 174 This document defines the IFIT Capability information formed of one 175 or more pairs of a 2-octet Namespace-ID and 16-bit Option-Type Flag. 177 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 178 +---------------------------------------------------------------+ 179 | Namespace-ID_1 | Option-Type enabled Flag_1 | 180 +---------------------------------------------------------------+ 181 | Namespace-ID_2 | Option-Type enabled Flag_2 | 182 +---------------------------------------------------------------+ 183 | ... | ... | 184 +---------------------------------------------------------------+ 186 Fig. 1 IFIT Capability Format 188 Where: 190 o Namespace-ID: A 2-octet identifier, which must be present and 191 populated in all IFIT-Option-Types. The definition is the same as 192 described in [I-D.ietf-ippm-ioam-data]. 194 o Option-Type Flag: A 16-bit bitmap, which is defined as: 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 197 +-------------------------------+ 198 |p|i|d|e|m| Reserved | 199 +-------------------------------+ 201 Where: 203 o p-Flag: IOAM Pre-allocated Trace Option Type flag. When set, this 204 indicates that the router is capable of IOAM Pre-allocated Trace 205 [I-D.ietf-ippm-ioam-data]. 207 o i-Flag: IOAM Incremental Trace Option Type flag. When set, this 208 indicates that the router is capable of IOAM Incremental Tracing 209 [I-D.ietf-ippm-ioam-data]. 211 o d-Flag: IOAM DEX Option Type flag. When set, this indicates that 212 the router is capable of IOAM DEX 213 [I-D.ietf-ippm-ioam-direct-export]. 215 o e-Flag: IOAM E2E Option Type flag. When set, this indicates that 216 the router is capable of IOAM E2E processing 217 [I-D.ietf-ippm-ioam-data]. 219 o m-Flag: EAM flag. When set, this indicates that the router is 220 capable of processing Enhanced Alternative Marking packets 221 [I-D.ietf-6man-ipv6-alt-mark]. 223 o Reserved: Must be set to zero upon transmission and ignored upon 224 receipt. 226 An IFIT node MAY be capable of more than one IFIT option types. In 227 this case, Option-Type Flag can has more than one bit being set. 229 In this document, Link IFIT Capability is defined as the supported 230 IFIT-Option-Types of the interface associated with the link. When 231 all interfaces associated with links support the same IFIT-Option- 232 Type, the Node IFIT Capability SHOULD represent the Link IFIT 233 Capability. Both of Node and Link IFIT Capability information are 234 formed of one or more pairs of Namespace-ID and Option-Type Flag. 236 When both of Node and Link IFIT Capability are advertised, the Link 237 IFIT Capability information MUST take precedence over the Node IFIT 238 Capability. Besides, when a Link IFIT Capability is not signaled, 239 then the Node IFIT Capability SHOULD be considered to be the IFIT 240 Capability for this link. 242 4. Signaling IFIT Capability Using IS-IS 244 The IS-IS Extensions for advertising Router Information TLV named IS- 245 IS Router CAPABILITY TLV [RFC7981], which allows a router to announce 246 its capabilities within an IS-IS level or the entire routing domain. 247 And [RFC5305] describes extensions to IS-IS to support Traffic 248 Engineering. 250 4.1. IS-IS Node IFIT Sub-TLV 252 According to the format of IS-IS Router CAPABILITY TLV [RFC7981], the 253 Node IFIT sub-TLV within the body of the IS-IS router CAPABILITY TLV 254 is composed of three fields, a one-octet Type field, a one-octet 255 Length field, and a multiple of 4-octet Value field. The following 256 format is used: 258 0 1 2 3 259 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 260 +---------------+---------------+ 261 | Type | Length | 262 +---------------+---------------+-------------------------------+ 263 | Node-IFIT-Capability | 264 ~ ~ 265 +---------------------------------------------------------------+ 267 Fig. 2 IS-IS Node IFIT Sub-TLV Format 269 Where: 271 o Type: To be assigned by IANA 273 o Length: A one-octet field that indicates the length of the value 274 portion in octets. 276 o Node-IFIT-Capability: A multiple of 4-octet field, which is same 277 as defined in Section 3. 279 4.2. IS-IS Link IFIT Sub-TLV 281 The Link IFIT sub-TLV is defined to carry the IFIT-Capability 282 information of the interface associated with the link, which is 283 formed of three fields, a one-octet Type field, a one-octet Length 284 field, and a multiple of 4-octet Value field. The following format 285 is used: 287 0 1 2 3 288 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 289 +---------------+---------------+ 290 | Type | Length | 291 +---------------+---------------+-------------------------------+ 292 | Link-IFIT-Capability | 293 ~ ~ 294 +---------------------------------------------------------------+ 296 Fig. 3 IS-IS Link IFIT Sub-TLV Format 298 Where: 300 o Type: To be assigned by IANA 302 o Length: A one-octet field that indicates the length of the value 303 portion in octets. 305 o Link-IFIT-Capability: A multiple of 4-octet field, which is same 306 as defined in Section 3. 308 5. Signaling IFIT Capability Using OSPF 310 Given that OSPF uses the options field in LSAs and hello packets to 311 advertise optional router capabilities [RFC7770], this document 312 defines a new IFIT Node TLV within the body of the OSPF RI Opaque LSA 313 [RFC7770] to carry the IFIT Capabilities of the router originating 314 the RI LSA. 316 This document defines the Link IFIT sub-TLV to carry the IFIT- 317 Capability information of the interface associated with the link. 318 For OSPFv2, the link-level IFIT capability information is advertised 319 as a sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684]. 320 For OSPFv3, the link-level IFIT capability information is advertised 321 a sub-TLV of the E-Router-LSA TLV as defined in [RFC8362]. 323 5.1. OSPF Node IFIT TLV 325 The Node IFIT TLV is composed of three fields, a 2-octet Type field, 326 a 2-octet Length field, and a multiple of 4-octet Value field. The 327 following format is used: 329 0 1 2 3 330 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 331 +-------------------------------+-------------------------------+ 332 | Type | Length | 333 +---------------------------------------------------------------+ 334 | Node-IFIT-Capability | 335 ~ ~ 336 +---------------------------------------------------------------+ 338 Fig. 4 OSPF Node IFIT TLV 340 Where: 342 o Type: To be assigned by IANA 344 o Length: A 2-octet field that indicates the length of the value 345 field. 347 o Node-IFIT-Capability: A multiple of 4-octet field, which is as 348 defined in Section 3. 350 5.2. OSPFv2 Link IFIT sub-TLV 352 The Link IFIT sub-TLV encoded in the OSPFv2 Extended Link TLV is 353 constructed of three fields, a 2-octet Type field, a 2-octet Length 354 field, and a multiple of 4-octet Value field. The following format 355 is used: 357 0 1 2 3 358 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 359 +-------------------------------+-------------------------------+ 360 | Type | Length | 361 +---------------------------------------------------------------+ 362 | Link-IFIT-Capability | 363 ~ ~ 364 +---------------------------------------------------------------+ 366 Fig. 5 OSPFv2 Link IFIT sub-TLV 368 Where: 370 o Type: To be assigned by IANA 372 o Length: A 2-octet field that indicates the length of the value 373 field. 375 o Link-IFIT-Capability: A multiple of 4-octet field, which is as 376 defined in Section 3. 378 5.3. OSPFv3 Link IFIT Sub-TLV 380 The Link IFIT sub-TLV encoded in the OSPFv3 E-Router-LSA TLV is 381 constructed of three fields, a 2-octet Type field, a 2-octet Length 382 field, and a multiple of 4-octet Value field. The following format 383 is used: 385 0 1 2 3 386 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 387 +-------------------------------+-------------------------------+ 388 | Type | Length | 389 +---------------------------------------------------------------+ 390 | Link-IFIT-Capability | 391 ~ ~ 392 +---------------------------------------------------------------+ 394 Fig. 6 OSPFv3 Link IFIT sub-TLV 396 Where: 398 o Type: To be assigned by IANA 400 o Length: A 2-octet field that indicates the length of the value 401 field. 403 o Link-IFIT-Capability: A multiple of 4-octet field, which is as 404 defined in Section 3. 406 6. Application 408 As any packet with IFIT-Data-Fields must not leak out from the IFIT 409 domain, the IFIT decapsulating node must be able to capture packets 410 with IFIT-specific header and metadata and recover their format 411 before forwarding them out of the IFIT domain. Thus, an ingress 412 router cannot insert IFIT-Data-Fields for packets going into a path 413 unless an egress router has indicated via signaling that it has the 414 capability to process IFIT-Data-Fields. In this case, such 415 advertisements are helpful for avoiding the leak of IFIT-specific 416 header and metadata. 418 In addition, such advertisements would be useful for ingress routers 419 to gather each router's IFIT capability for achieving the computation 420 of TE paths or loose TE paths that be able to fulfill the visibility 421 of on-path OAM data. For example, for achieving the computation of 422 low-latency SR-TE path, latency is expected to be collected at every 423 node that a packet traverses to ensure performance visibility into 424 the entire path. IOAM Trace Option-Types is a desired option to have 425 a hop-by-hop latency measurement. If not all nodes on this path are 426 IOAM Trace Option-Type capable, an incomplete measurement can have 427 negative impacts on SR-TE path computation and adjustment for low- 428 latency assurance. 430 7. IANA Considerations 432 IANA is requested to allocate values for the following new TLV and 433 sub-TLVs. 435 +------+-------------------------+ 436 | Type | Description | 437 +------+-------------------------+ 438 | TBD | IS-IS Node IFIT Sub-TLV | 439 | TBD | IS-IS Link IFIT Sub-TLV | 440 +------+-------------------------+ 442 +------+-------------------------------------+ 443 | Type | Description | 444 +------+-------------------------------------+ 445 | TBD | OSPF Node IFIT Capability TLV | 446 | TBD | OSPFv2 Link IFIT Capability sub-TLV | 447 | TBD | OSPFv3 Link IFIT Capability sub-TLV | 448 +------+-------------------------------------+ 450 8. Security Considerations 452 This document introduces new IGP Node and Link Attribute TLVs and 453 sub-TLVs for the IFIT Capability advertisements at node and/or link 454 granularity. It does not introduce any new security risks to IS-IS, 455 OSPFv2 and OSPFv3. 457 9. Acknowledgements 459 The authors would like to thank Acee Lindem, Christian Hopps, Robert 460 Raszuk, Les Ginsberg, Jeff Tantsura, Rakesh Gandhi and Greg Mirsky 461 for the comments and advices. 463 10. References 465 10.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, 469 DOI 10.17487/RFC2119, March 1997, 470 . 472 [RFC5305] "IS-IS Extensions for Traffic Engineering", 473 . 475 [RFC7684] "OSPFv2 Prefix/Link Attribute Advertisement", 476 . 478 [RFC7752] "North-Bound Distribution of Link-State and Traffic 479 Engineering (TE) Information Using BGP", 480 . 482 [RFC7770] "Extensions to OSPF for Advertising Optional Router 483 Capabilities", . 485 [RFC7981] "IS-IS Extensions for Advertising Router Information", 486 . 488 [RFC8362] "OSPFv3 Link State Advertisement (LSA) Extensibility", 489 . 491 10.2. Informative References 493 [I-D.ietf-6man-ipv6-alt-mark] 494 "IPv6 Application of the Alternate Marking Method", 495 . 498 [I-D.ietf-ippm-ioam-data] 499 "Data Fields for In-situ OAM". 501 [I-D.ietf-ippm-ioam-direct-export] 502 "In-situ OAM Direct Exporting", 503 . 506 [I-D.song-opsawg-ifit-framework] 507 "In-situ Flow Information Telemetry Framework", 508 . 511 Authors' Addresses 513 Yali Wang 514 Huawei 515 156 Beiqing Rd., Haidian District 516 Beijing 517 China 519 Email: wangyali11@huawei.com 521 Tianran Zhou 522 Huawei 523 156 Beiqing Rd., Haidian District 524 Beijing 525 China 527 Email: zhoutianran@huawei.com 529 Min Liu 530 Huawei 531 156 Beiqing Rd., Haidian District 532 Beijing 533 China 535 Email: lucy.liumin@huawei.com 537 Huanan Chen 538 China Telecom 539 109 West Zhongshan Ave. 540 Guangzhou, Guangdong 541 China 543 Email: chenhuan6@chinatelecom.cn 545 Ran Pang 546 China Unicom 547 9 Shouti South Rd., Haidian District 548 Beijing 549 China 551 Email: pangran@chinaunicom.cn