idnits 2.17.1 draft-wang-idr-bgpls-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 13, 2020) is 1375 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 Inter-Domain Routing Working Group Y. Wang 3 Internet-Draft T. Zhou 4 Intended status: Standards Track M. Liu 5 Expires: January 14, 2021 Huawei 6 R. Pang 7 China Unicom 8 H. Chen 9 China Telecom 10 July 13, 2020 12 BGP-LS Extensions for In-situ Flow Information Telemetry (IFIT) 13 Capability Advertisement 14 draft-wang-idr-bgpls-extensions-ifit-00 16 Abstract 18 This document extends Node and Link Attribute TLVs to Border Gateway 19 Protocol-Link State (BGP-LS) 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 entities (e.g. 25 Path Computation Element (PCE)) to gather each router's IFIT 26 capability for achieving the computation of end-to-end Traffic 27 Engineering (TE) paths that be able to fulfill the visibility of on- 28 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 14, 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 BGP-LS . . . . . . . . . . . 5 74 4.1. Node IFIT TLV . . . . . . . . . . . . . . . . . . . . . . 5 75 4.2. Link IFIT TLV . . . . . . . . . . . . . . . . . . . . . . 6 76 5. Application . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 9.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Introduction 87 IFIT provides a high-level framework and a reflection-loop solution 88 for on-path telemetry [I-D.song-opsawg-ifit-framework]. At present, 89 there is a family of emerging on-path telemetry techniques, including 90 In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data], IOAM Direct Export 91 (DEX) [I-D.ietf-ippm-ioam-direct-export], Enhanced Alternate Marking 92 (EAM) [I-D.ietf-6man-ipv6-alt-mark], etc. 94 IFIT is a solution focusing on network domains. The "network domain" 95 consists of a set of network devices or entities within a single 96 Autonomous System (AS). The part of the network which employs IFIT 97 is referred to as the IFIT domain. One network domain may consist of 98 multiple IFIT domains. An IFIT domain may cross multiple network 99 domains. The family of emerging on-path telemetry techniques may be 100 partially enabled in different vendors' devices as an emerging 101 feature for various use cases of application-aware network 102 operations. So that in order to dynamically enable IFIT 103 functionality in a network domain, it is necessary to advertise the 104 information of IFIT option types supported in each device. 106 An ingress router cannot insert IFIT-Data-Fields for packets going 107 into a path unless an egress router has indicated via signaling that 108 it has the capability to process IFIT-Data-Fields. In addition, such 109 advertisements would be useful for entities (e.g. Path Computation 110 Element (PCE)) to gather each router's IFIT capability for achieving 111 the computation of end-to-end TE paths that be able to fulfill the 112 visibility of on-path OAM data. 114 [RFC7752] describes a mechanism by which link-state and TE 115 information can be collected from the network outside one Interior 116 Gateway Protocols (IGP) area or Autonomous System (AS). This 117 document extends Node and Link Attribute TLVs to BGP-LS to advertise 118 supported IFIT capabilities at node and/or link granularity. 120 2. Terminology 122 Following are abbreviations used in this document: 124 o BGP-LS: Border Gateway Protocol - Link State 126 o IFIT: In-situ Flow Information Telemetry 128 o TE: Traffic Engineering 130 o IOAM: In-situ OAM 132 o PBT: Postcard-Based Telemetry 134 o DEX: IOAM Direct Export 136 o EAM: Enhanced Alternate Marking 138 o IGP: Interior Gateway Protocols 140 o AS: Autonomous System 142 o E2E: Edge-to-Edge 143 o NLRI: Network Layer Reachability Information 145 3. IFIT Capability 147 Each IFIT-capable node is configured with a node-id which uniquely 148 identifies a node within the associated IFIT domain. To accommodate 149 the different use cases or requirements of in-situ flow information 150 telemetry, IFIT data fields updated by network nodes fall into 151 different categories which are referred as different IFIT option 152 types, including IOAM Trace Option-Types [I-D.ietf-ippm-ioam-data], 153 IOAM Edge-to-Edge (E2E) Option-Type [I-D.ietf-ippm-ioam-data], IOAM 154 DEX Option-Type [I-D.ietf-ippm-ioam-direct-export] and EAM Option- 155 Type [I-D.ietf-6man-ipv6-alt-mark]. A subset or all the IFIT-Option- 156 Types and their corresponding IFIT-Data-Fields can be associated to 157 an IFIT-Namespace. Namespace identifiers allow a device which is 158 IFIT-capable to determine whether IFIT-Option-Types need to be 159 processed. So that IFIT-Option-Types and Namespace-IDs SHOULD be 160 included in IFIT capability information. 162 This document defines the IFIT Capability information formed of one 163 or more pairs of a 2-octet Namespace-ID and 16-bit Option-Type Flag. 165 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 166 +---------------------------------------------------------------+ 167 | Namespace-ID_1 | Option-Type Flag_1 | 168 +---------------------------------------------------------------+ 169 | Namespace-ID_2 | Option-Type Flag_2 | 170 +---------------------------------------------------------------+ 171 | ... | ... | 172 +---------------------------------------------------------------+ 174 Fig. 1 IFIT Capability Format 176 Where: 178 o Namespace-ID: A 2-octet identifier, which must be present and 179 populated in all IFIT-Option-Types. The definition is the same as 180 described in [I-D.ietf-ippm-ioam-data]. 182 o Option-Type Flag: A 16-bit bitmap, which is defined as: 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 185 +-------------------------------+ 186 |p|i|d|e|m| Reserved | 187 +-------------------------------+ 189 Where: 191 o p-Flag: IOAM Pre-allocated Trace Option Type flag. When set, this 192 indicates that the router is capable of IOAM Pre-allocated Trace 193 [I-D.ietf-ippm-ioam-data]. 195 o i-Flag: IOAM Incremental Trace Option Type flag. When set, this 196 indicates that the router is capable of IOAM Incremental Tracing 197 [I-D.ietf-ippm-ioam-data]. 199 o d-Flag: IOAM DEX Option Type flag. When set, this indicates that 200 the router is capable of IOAM DEX 201 [I-D.ietf-ippm-ioam-direct-export]. 203 o e-Flag: IOAM E2E Option Type flag. When set, this indicates that 204 the router is capable of IOAM E2E processing 205 [I-D.ietf-ippm-ioam-data]. 207 o m-Flag: EAM flag. When set, this indicates that the router is 208 capable of processing Enhanced Alternative Marking packets 209 [I-D.ietf-6man-ipv6-alt-mark]. 211 o Reserved: Must be set to zero upon transmission and ignored upon 212 receipt. 214 An IFIT node MAY be capable of more than one IFIT option types. In 215 this case, Option-Type Flag can has more than one bit being set. 217 In this document, Link IFIT Capability is defined as the supported 218 IFIT-Option-Types of the interface associated with the link. When 219 all interfaces associated with links support the same IFIT-Option- 220 Type, the Node IFIT Capability SHOULD represent the Link IFIT 221 Capability. Both of Node and Link IFIT Capability information are 222 formed of one or more pairs of Namespace-ID and Option-Type Flag. 224 When both of Node and Link IFIT Capability are advertised, the Link 225 IFIT Capability information MUST take precedence over the Node IFIT 226 Capability. Besides, when a Link IFIT Capability is not signaled, 227 then the Node IFIT Capability SHOULD be considered to be the IFIT 228 Capability for this link. 230 4. Signaling IFIT Capability Using BGP-LS 232 4.1. Node IFIT TLV 234 The Node IFIT TLV is an optional extension to Node Attribute TLVs 235 that may be encoded in the BGP-LS Attribute associated with a Node 236 NLRI [RFC7752]. The following format is used: 238 0 1 2 3 239 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 240 +-------------------------------+-------------------------------+ 241 | Type | Length | 242 +---------------------------------------------------------------+ 243 | Node-IFIT-Capability | 244 ~ ~ 245 +---------------------------------------------------------------+ 247 Fig. 7 BGP-LS Node IFIT TLV 249 Where: 251 o Type: To be assigned by IANA 253 o Length: A 2-octet field that indicates the length of the value. 255 o Node-IFIT-Capability: A multiple of 4-octet field, which is as 256 defined in Section 3. 258 4.2. Link IFIT TLV 260 The Link IFIT TLV is an optional extension to Link Attribute TLVs 261 that may be encoded in the BGP-LS Attribute associated with a Link 262 NLRI [RFC7752]. The following format is used: 264 0 1 2 3 265 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 266 +-------------------------------+-------------------------------+ 267 | Type | Length | 268 +---------------------------------------------------------------+ 269 | Link-IFIT-Capability | 270 ~ ~ 271 +---------------------------------------------------------------+ 273 Fig. 8 BGP-LS Link IFIT TLV 275 Where: 277 o Type: To be assigned by IANA 279 o Length: A 2-octet field that indicates the length of the value. 281 o Link-IFIT-Capability: A multiple of 4-octet field, which is as 282 defined in Section 3. 284 5. Application 286 As any packet with IFIT-Data-Fields must not leak out from the IFIT 287 domain, the IFIT decapsulating node must be able to capture packets 288 with IFIT-specific header and metadata and recover their format 289 before forwarding them out of the IFIT domain. Thus, an ingress 290 router cannot insert IFIT-Data-Fields for packets going into a path 291 unless an egress router has indicated via signaling that it has the 292 capability to process IFIT-Data-Fields. In this case, such 293 advertisements are helpful for avoiding the leak of IFIT-specific 294 header and metadata. 296 In addition, such advertisements would be useful for entities (e.g. 297 Path Computation Element (PCE)) to gather each router's IFIT 298 capability for achieving the computation of end-to-end TE paths that 299 be able to fulfill the visibility of on-path OAM data. For example, 300 for achieving the computation of low-latency SR-TE path, latency is 301 expected to be collected at every node that a packet traverses to 302 ensure performance visibility into the entire path. IOAM Trace 303 Option-Types is a desired option to have a hop-by-hop latency 304 measurement. If not all nodes on this path are IOAM Trace Option- 305 Type capable, an incomplete measurement can have negative impacts on 306 SR-TE path computation and adjustment for low-latency assurance. 308 6. IANA Considerations 310 IANA is requested to allocate values for the following TLV Type from 311 the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 312 Attribute TLVs" registry. 314 +------------+-------------+---------------+ 315 | Code Point | Description | Reference | 316 +------------+-------------+---------------+ 317 | TBA1 | Node IFIT | This document | 318 | TBA2 | Link IFIT | This document | 319 +------------+-------------+---------------+ 321 7. Security Considerations 323 This document introduces new BGP-LS Node and Link Attribute TLVs for 324 the IFIT Capability advertisements at node and/or link granularity. 325 It does not introduce any new security risks to BGP-LS. 327 8. Acknowledgements 329 The authors would like to thank Acee Lindem, Christian Hopps, Robert 330 Raszuk, Les Ginsberg, Jeff Tantsura, Rakesh Gandhi and Greg Mirsky 331 for the comments and advices. 333 9. References 335 9.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, 339 DOI 10.17487/RFC2119, March 1997, 340 . 342 [RFC7752] "North-Bound Distribution of Link-State and Traffic 343 Engineering (TE) Information Using BGP", 344 . 346 9.2. Informative References 348 [I-D.ietf-6man-ipv6-alt-mark] 349 "IPv6 Application of the Alternate Marking Method", 350 . 353 [I-D.ietf-ippm-ioam-data] 354 "Data Fields for In-situ OAM". 356 [I-D.ietf-ippm-ioam-direct-export] 357 "In-situ OAM Direct Exporting", 358 . 361 [I-D.song-opsawg-ifit-framework] 362 "In-situ Flow Information Telemetry Framework", 363 . 366 Authors' Addresses 368 Yali Wang 369 Huawei 370 156 Beiqing Rd., Haidian District 371 Beijing 372 China 374 Email: wangyali11@huawei.com 375 Tianran Zhou 376 Huawei 377 156 Beiqing Rd., Haidian District 378 Beijing 379 China 381 Email: zhoutianran@huawei.com 383 Min Liu 384 Huawei 385 156 Beiqing Rd., Haidian District 386 Beijing 387 China 389 Email: lucy.liumin@huawei.com 391 Ran Pang 392 China Unicom 393 9 Shouti South Rd., Haidian District 394 Beijing 395 China 397 Email: pangran@chinaunicom.cn 399 Huanan Chen 400 China Telecom 401 109 West Zhongshan Ave. 402 Guangzhou, Guangdong 403 China 405 Email: chenhuan6@chinatelecom.cn