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