idnits 2.17.1 draft-wang-idr-bgp-ls-ifit-node-capability-03.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 abstract seems to contain references ([RFC7752]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2020) is 1503 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Routing Working Group Y. Wang 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: September 14, 2020 R. Pang 6 China Unicom 7 March 13, 2020 9 Extensions to BGP-LS for Advertising In-situ Flow Information Telemetry 10 (IFIT) Node Capability 11 draft-wang-idr-bgp-ls-ifit-node-capability-03 13 Abstract 15 This document defines a way for a Border Gateway Protocol Link-State 16 (BGP-LS) speaker to announce In-situ Flow Information Telemetry 17 (IFIT) node capabilities of routers to BGP-LS consumer (e.g. a 18 centralized controller). In this document, IFIT Node Capability TLV 19 is defined as a new Node Attribute TLV that is encoded in the BGP-LS 20 attribute with Node NLRIs [RFC7752]. Such advertisements enable a 21 centralized controller that can leverage this information in 22 determining whether a particular IFIT Option type can be supported in 23 a given network. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 September 14, 2020. 48 Copyright Notice 50 Copyright (c) 2020 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 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. IFIT Domain . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. IFIT Node Capability Information . . . . . . . . . . . . 3 70 3. Advertisement of the IFIT Node Capabilities via BGP-LS . . . 4 71 3.1. IFIT Node Capability TLV . . . . . . . . . . . . . . . . 4 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. TLV Code Point of the new IFIT Node Capability TLV within 74 Node NLRIs . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 7.2. Informative References . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 82 1. Introduction 84 IFIT provides a complete framework architecture and a reflection-loop 85 working solution for on-path flow telemetry 86 [I-D.song-opsawg-ifit-framework]. At present, there are a family of 87 emerging on-path flow telemetry techniques, including In-situ OAM 88 (IOAM) [I-D.ietf-ippm-ioam-data], PBT 89 [I-D.song-ippm-postcard-based-telemetry], IOAM Direct Export (DEX) 90 [I-D.ioamteam-ippm-ioam-direct-export], Enhanced Alternate Marking 91 (EAM) [I-D.zhou-ippm-enhanced-alternate-marking], etc. IFIT is a 92 solution focusing on network domains. The "network domain" consists 93 of a set of network devices or entities within a single 94 administration. One network domain MAY consists of multiple IFIT 95 domain. The family of emerging on-path flow telemetry techniques MAY 96 be selectively or partially implemented in different vendors' devices 97 as an emerging feature for various use cases of application-aware 98 network operations. Within the IFIT domain, one or more IFIT-options 99 are added into packet at the IFIT-enabled head node that is referred 100 to as the IFIT encapsulating node. Then IFIT data fields MAY be 101 updated by IFIT transit nodes that the packet traverses. Finally, 102 the data fields are removed at a device that is referred to as the 103 IFIT decapsulating node. Hence, a centralized controller need to 104 know if routers are able to support the IFIT capabilities. BGP-LS 105 defines a way to advertise topology and associated attributes and 106 capabilities of the nodes in that topology to a centralized 107 controller [RFC7752]. Therefore, this document defines extensions to 108 BGP-LS to advertise the IFIT node capabilities to a centralized 109 controller that can learn the IFIT node capability to determine 110 whether a particular IFIT Option type can be supported in a given 111 network. 113 1.1. Terminology 115 BGP-LS: Advertisement of Link-State and TE Information using Border 116 Gateway Protocol 118 2. Concepts 120 2.1. IFIT Domain 122 IFIT is expected to be deployed in a specific domain referred as the 123 IFIT domain. An IFIT domain MAY cross multiple network domains. One 124 network domain MAY consists of multiple IFIT domain. Within the IFIT 125 domain, the IFIT data fields of flow information head MAY be updated 126 by network nodes that the packet traverses. 128 2.2. IFIT Node Capability Information 130 Each IFIT node is configured with a node-id which uniquely identifies 131 a node within the associated IFIT domain. To accommodate the 132 different use cases or requirements of in-situ flow information 133 telemetry, IFIT data fields updated by network nodes fall into 134 different categories which are referred as different IFIT option 135 types, including IOAM Trace Option-Types [I-D.ietf-ippm-ioam-data], 136 IOAM Edge-to-Edge (E2E) Option-Type [I-D.ietf-ippm-ioam-data], IOAM 137 DEX Option-Type [I-D.ioamteam-ippm-ioam-direct-export] and Enhanced 138 Alternate Marking (EAM) Option-Type 139 [I-D.zhou-ippm-enhanced-alternate-marking]. So IFIT Option Types 140 SHOULD be carried in IFIT node capability advertisment. 142 3. Advertisement of the IFIT Node Capabilities via BGP-LS 144 This document describes extensions enabling BGP-LS speakers to 145 announce the IFIT node capabilities of routers in a network to a BGP- 146 LS consumer (e.g. a centralized controller). The centralized 147 controller can leverage this information in enabling IFIT 148 applications in network domains based on IFIT node capabilities and 149 OAM use cases. 151 3.1. IFIT Node Capability TLV 153 IFIT Node-Capability TLV is defined as a new Node Attribute TLV that 154 is encoded in the BGP-LS attribute with Node NLRIs [RFC7752]. The 155 IFIT Node Capability TLV is defined as a TLV triplet, i.e. a two- 156 octet Type field, a two-octet Length field, and four-octet Value 157 field. The Type field indicates the type of items in the Value 158 field. The Length field indicates the length of the Value field in 159 octets. The Value field indicates the IFIT Node Capability, which is 160 a 4-octet IFIT Option Type-enabled Flag bitmask. 162 The IFIT Node Capability TLV has the following format: 164 0 1 2 3 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 | Type | Length | 168 +---------------------------------------------------------------+ 169 | IFIT Option Type-enabled Flag | 170 +---------------------------------------------------------------+ 172 Fig. 1 IFIT Node Capability TLV Format 174 Type: To be assigned by IANA 176 Length: A 2-octet field that indicates the length of the value. 178 IFIT Option Type-enabled Flag: A 4-octet field, which is defined as 179 following: 181 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 182 +---------------------------------------------------------------+ 183 |p|i|d|e|m| Reserved | 184 +---------------------------------------------------------------+ 186 Where: 188 p-Flag: IOAM Pre-allocated Trace Option Type-enabled flag. If bit p 189 is set (1), the router is capable of IOAM Pre-allocated Trace 190 [I-D.ietf-ippm-ioam-data]. 192 i-Flag: IOAM Incremental Trace Option Type-enabled flag. If bit i is 193 set (1), the router is capable of IOAM Incremental Tracing 194 [I-D.ietf-ippm-ioam-data]. 196 d-Flag: IOAM DEX Option Type-enabled flag. If bit d is set (1), the 197 router is capable of IOAM DEX [I-D.ioamteam-ippm-ioam-direct-export]. 199 e-Flag: IOAM E2E Option Type-enabled flag. If bit e is set (1), the 200 router is capable of IOAM E2E processing [I-D.ietf-ippm-ioam-data]. 202 m-Flag: Enhanced Alternative Marking enabled flag. If bit m is set 203 (1), then the router is capable of processing Enhanced Alternative 204 Marking packets [I-D.zhou-ippm-enhanced-alternate-marking]. 206 Reserved: Must be set to zero upon transmission and ignored upon 207 receipt. 209 An IFIT node SHALL be capable of more than one IFIT option types. So 210 in this case, IFIT Option Type-enabled Flag bitmap SHOULD has more 211 than one bit being set. 213 4. IANA Considerations 215 4.1. TLV Code Point of the new IFIT Node Capability TLV within Node 216 NLRIs 218 This document makes the following registrations for a Node Attribute 219 TLV code point for the IFIT Node Capability TLV included with Node 220 NLRIs. 222 +------------+----------------------+ 223 | Code Point | Description | 224 +------------+----------------------+ 225 | TBD | IFIT Node Capability | 226 +------------+----------------------+ 228 5. Security Considerations 230 This document introduces new Node Attribute TLVs for the existing 231 Node NLRIs. It does not introduce any new security risks to BGP-LS. 233 6. Acknowledgements 235 7. References 237 7.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, 241 DOI 10.17487/RFC2119, March 1997, 242 . 244 [RFC7752] "North-Bound Distribution of Link-State and Traffic 245 Engineering (TE) Information Using BGP", 246 . 248 7.2. Informative References 250 [I-D.ietf-ippm-ioam-data] 251 "Data Fields for In-situ OAM". 253 [I-D.ioamteam-ippm-ioam-direct-export] 254 "In-situ OAM Direct Exporting", 255 . 258 [I-D.song-ippm-postcard-based-telemetry] 259 "Postcard-based On-Path Flow Data Telemetry", 260 . 263 [I-D.song-opsawg-ifit-framework] 264 "In-situ Flow Information Telemetry Framework", 265 . 268 [I-D.zhou-ippm-enhanced-alternate-marking] 269 "Enhanced Alternate Marking Method", 270 . 273 Authors' Addresses 274 Yali Wang 275 Huawei 276 156 Beiqing Rd., Haidian District 277 Beijing 278 China 280 Email: wangyali11@huawei.com 282 Tianran Zhou 283 Huawei 284 156 Beiqing Rd., Haidian District 285 Beijing 286 China 288 Email: zhoutianran@huawei.com 290 Ran Pang 291 China Unicom 292 9 Shouti South Rd., Haidian District 293 Beijing 294 China 296 Email: pangran@chinaunicom.cn