idnits 2.17.1 draft-liu-lsr-isis-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 ([RFC7981]), 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 09, 2020) is 1501 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) No issues found here. 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 M. Liu 3 Internet-Draft Y. Wang 4 Intended status: Standards Track Huawei 5 Expires: September 10, 2020 R. Pang 6 China Unicom 7 March 09, 2020 9 IS-IS Extensions for Advertising In-situ Flow Information Telemetry 10 (IFIT) Node Capability 11 draft-liu-lsr-isis-ifit-node-capability-03 13 Abstract 15 This document defines a way for an Intermediate System to 16 Intermediate System (IS-IS) routers to advertise IFIT (In-situ Flow 17 Information Telemetry) capabilities. This document extends a new 18 optional sub-TLV in the IS-IS Router CAPABILITY TLV [RFC7981], which 19 allows a router to announce its IFIT node capabilities within an IS- 20 IS level or the entire routing domain. Such advertisements enable 21 IFIT applications in the network domain. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 10, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. IFIT Domain . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. IFIT Node Capability Information . . . . . . . . . . . . 3 66 2. Advertisement of the IFIT Node Capabilities in ISIS . . . . . 3 67 2.1. IFIT Node Capability Sub-TLV . . . . . . . . . . . . . . 3 68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Sub-TLVs for the IS-IS Router CAPABILITY TLV (242) . . . 5 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 6.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 IFIT provides a complete framework architecture and a reflection-loop 80 working solution for on-path flow telemetry 81 [I-D.song-opsawg-ifit-framework]. At present, there are a family of 82 emerging on-path flow telemetry techniques, including In-situ OAM 83 (IOAM) [I-D.ietf-ippm-ioam-data], PBT 84 [I-D.song-ippm-postcard-based-telemetry] , IOAM Direct Export (DEX) 85 [I-D.ioamteam-ippm-ioam-direct-export] , Enhanced Alternate Marking 86 (EAM) [I-D.zhou-ippm-enhanced-alternate-marking], etc. IFIT is a 87 solution focusing on network domains. The "network domain" consists 88 of a set of network devices or entities within a single 89 administration. For example, a network domain can be one or more IGP 90 routing domains. The family of emerging on-path flow telemetry 91 techniques may be selectively or partially implemented in different 92 vendors' devices as an emerging feature for various use cases of 93 application-aware network operations. Hence, in order to enable IFIT 94 applications in an operational network domain, IFIT node capabilities 95 SHOULD be advertised by every Intermediate System to Intermediate 96 System (IS-IS) router in the network domain. 98 1.1. IFIT Domain 100 IFIT is expected to be deployed in a specific domain referred as the 101 IFIT domain. An IFIT domain may cross multiple network domains. One 102 network domain may consists of multiple IFIT domain. Within the IFIT 103 domain, the IFIT data fields of flow information head MAY be updated 104 by network nodes that the packet traverses. 106 1.2. IFIT Node Capability Information 108 Each IFIT node is configured with a node-id which uniquely identifies 109 a node within the associated IFIT domain. To accommodate the 110 different use cases or requirements of in-situ flow information 111 telemetry, IFIT data fields updated by network nodes fall into 112 different categories which are referred as different IFIT option 113 types, including IOAM Trace Option-Types [I-D.ietf-ippm-ioam-data], 114 IOAM Edge-to-Edge (E2E) Option-Type [I-D.ietf-ippm-ioam-data], IOAM 115 DEX Option-Type [I-D.ioamteam-ippm-ioam-direct-export] and Enhanced 116 Alternate Marking (EAM) Option-Type 117 [I-D.zhou-ippm-enhanced-alternate-marking]. So IFIT Option Types 118 SHOULD be carried in IFIT node capability advertisment. 120 2. Advertisement of the IFIT Node Capabilities in ISIS 122 The IS-IS Extensions for Advertising Router Information TLV named IS- 123 IS Router CAPABILITY TLV [RFC7981], which allows a router to announce 124 its capabilities within an IS-IS level or the entire routing domain, 125 has been chosen for IFIT node capabilities advertisement. IS-IS 126 Router CAPABILITY TLV is formed of multiple sub-TLVs [RFC5305]. 128 2.1. IFIT Node Capability Sub-TLV 130 According to the format of IS-IS Router CAPABILITY TLV [RFC7981], the 131 IFIT Node Capability sub-TLV is composed of three fields, a one-octet 132 Type field, a one-octet Length field, and zero or more octets of 133 Value. The Type field indicates the type of items in the Value 134 field. The Length field indicates the length of the Value field in 135 octets. The Value field indicates the IFIT Node Capability, which is 136 a 2-octet IFIT Option Type-enabled Flag. 138 The IFIT Node-capability Sub-TLV has the following format: 140 0 1 2 3 141 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 142 +---------------+---------------+-------------------------------+ 143 | Type | Length |IFIT Option Type-enabled Flag | 144 +---------------+---------------+-------------------------------+ 146 Fig. 1 IFIT Node Capability Sub-TLV Format 148 Type: To be assigned by IANA 150 Length: A 8-bit field that indicates the length of the value portion 151 in octets. 153 IFIT Option Type-enabled Flag: A 2-octet field that is defined as 154 following: 156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 157 +-------------------------------+ 158 |p|i|d|e|m| Reserved | 159 +-------------------------------+ 161 Where: 163 p-Flag: iOAM Pre-allocated Trace Option Type-enabled flag. If p bit 164 is set (1), the router is capable of iOAM Pre-allocated Trace 165 [I-D.ietf-ippm-ioam-data]. 167 i-Flag: iOAM Incremental Trace Option Type-enabled flag. If i bit is 168 set (1), the router is capable of iOAM Incremental Tracing 169 [I-D.ietf-ippm-ioam-data]. 171 d-Flag: iOAM DEX Option Type-enabled flag. If d bit is set (1), the 172 router is capable of iOAM DEX [I-D.ioamteam-ippm-ioam-direct-export]. 174 e-Flag: iOAM E2E Option Type-enabled flag. If e bit is set (1), the 175 router is capable of iOAM E2E processing [I-D.ietf-ippm-ioam-data]. 177 m-Flag: Enhanced Alternative Marking enabled flag. If m bit is set 178 (1), then the router is capable of processing Enhanced Alternative 179 Marking packets [I-D.zhou-ippm-enhanced-alternate-marking]. 181 Reserved: Must be set to zero upon transmission and ignored upon 182 receipt. 184 An IFIT node SHALL be capable of more than one IFIT option types. So 185 for this case, IFIT Option Type-enabled Flag bitmap SHOULD has more 186 than one bit being set. 188 3. IANA Considerations 190 Note to RFC Editor: this section may be removed on publication as an 191 RFC. 193 3.1. Sub-TLVs for the IS-IS Router CAPABILITY TLV (242) 195 This document makes the following registrations for a Sub-TLV type of 196 the new Sub-TLV proposed in Section 3 of this document from the "Sub- 197 TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)" registry. 199 +------+----------------------+ 200 | Type | Description | 201 +------+----------------------+ 202 | TBD | IFIT Node Capability | 203 +------+----------------------+ 205 4. Security Considerations 207 This document introduces new sub-TLVs for the existing IS-IS Router 208 capability TLV. It does not introduce any new security risks to 209 ISIS. 211 5. Acknowledgements 213 6. References 215 6.1. Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, 219 DOI 10.17487/RFC2119, March 1997, 220 . 222 [RFC5305] "IS-IS Extensions for Traffic Engineering", 223 . 225 [RFC7981] "IS-IS Extensions for Advertising Router Information", 226 . 228 6.2. Informative References 230 [I-D.ietf-ippm-ioam-data] 231 "Data Fields for In-situ OAM". 233 [I-D.ioamteam-ippm-ioam-direct-export] 234 "In-situ OAM Direct Exporting", 235 . 238 [I-D.song-ippm-postcard-based-telemetry] 239 "Postcard-based On-Path Flow Data Telemetry", 240 . 243 [I-D.song-opsawg-ifit-framework] 244 "In-situ Flow Information Telemetry Framework", 245 . 248 [I-D.zhou-ippm-enhanced-alternate-marking] 249 "Enhanced Alternate Marking Method", 250 . 253 Authors' Addresses 255 Min Liu 256 Huawei 257 156 Beiqing Rd., Haidian District 258 Beijing 259 China 261 Email: lucy.liumin@huawei.com 263 Yali Wang 264 Huawei 265 156 Beiqing Rd., Haidian District 266 Beijing 267 China 269 Email: wangyali11@huawei.com 270 Ran Pang 271 China Unicom 272 9 Shouti South Rd., Haidian District 273 Beijing 274 China 276 Email: pangran@chinaunicom.cn