idnits 2.17.1 draft-xzlnp-bier-ioam-02.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 11, 2021) is 1018 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) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-12 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-03 == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-15) exists of draft-ietf-bier-pmmm-oam-10 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Working Group X. Min 3 Internet-Draft Z. Zhang 4 Intended status: Standards Track ZTE Corp. 5 Expires: January 12, 2022 Y. Liu 6 China Mobile 7 N. Nainar 8 C. Pignataro 9 Cisco Systems, Inc. 10 July 11, 2021 12 Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM 13 (IOAM) Data 14 draft-xzlnp-bier-ioam-02 16 Abstract 18 In-situ Operations, Administration, and Maintenance (IOAM) collects 19 operational and telemetry information while the packet traverses a 20 particular network domain. Bit Index Explicit Replication (BIER) is 21 an architecture that provides optimal multicast forwarding through a 22 "multicast domain", without requiring intermediate routers to 23 maintain any per-flow state or to engage in an explicit tree-building 24 protocol. The BIER header contains a bit-string in which each bit 25 represents exactly one egress router to forward the packet to. This 26 document outlines the requirements to carry IOAM data in BIER header 27 and specifies how IOAM data fields are encapsulated in BIER header. 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 January 12, 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Requirements to carry IOAM data in BIER header . . . . . . . 3 68 4. IOAM data fields encapsulation in BIER header . . . . . . . . 4 69 5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Discussion of the encapsulation approach . . . . . . . . 6 71 5.2. IOAM and the use of the BIER OAM bits . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 9.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 In-situ Operations, Administration, and Maintenance (IOAM) collects 83 operational and telemetry information while the packet traverses a 84 particular network domain. [I-D.ietf-ippm-ioam-data] defines 85 multiple IOAM options with different IOAM data fields used to record 86 various telemetry data from the transit nodes. 87 [I-D.ietf-ippm-ioam-direct-export] defines IOAM Direct Export option 88 with IOAM data fields, which indicate telemetry data to be collected 89 without being embedded in data packets. The term "in-situ" refers to 90 the fact that the IOAM data fields are added to the data packets 91 rather than being sent within packets specifically dedicated to OAM. 93 Bit Index Explicit Replication (BIER), as defined in [RFC8279], is an 94 architecture that provides optimal multicast forwarding through a 95 "multicast domain", without requiring intermediate routers to 96 maintain any per-flow state or to engage in an explicit tree-building 97 protocol. The BIER header, as defined in [RFC8296], contains a bit- 98 string in which each bit represents exactly one egress router to 99 forward the packet to. 101 This document outlines the requirements to carry IOAM data in BIER 102 header and specifies how IOAM data fields are encapsulated in BIER 103 header. 105 2. Conventions Used in This Document 107 2.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 2.2. Abbreviations 117 Abbreviations used in this document: 119 BFER: Bit Forwarding Egress Router 121 BFIR: Bit Forwarding Ingress Router 123 BIER: Bit Index Explicit Replication 125 GRE: Generic Routing Encapsulation 127 IOAM: In-situ Operations, Administration, and Maintenance 129 OAM: Operations, Administration, and Maintenance 131 3. Requirements to carry IOAM data in BIER header 133 [I-D.ietf-bier-use-cases] lists many use cases for BIER. Usually 134 there are many multicast flows within one network domain, and some of 135 the multicast flows, such as live video and real-time meeting, are 136 sensitive to packet loss, delay and other factors. The network 137 operator wants to know the real-time statistics for these flows, such 138 as delay, sequence, the ingress/egress interface, and the usage of 139 buffer. 141 So methods are needed for measuring the real-time transportation 142 guarantee of BIER packet. Performance measurement function defined 143 in [I-D.ietf-bier-pmmm-oam] can be used for measuring packet loss and 144 delay. This document attempts to provide a way to collect on-path 145 operational and telemetry information through in-situ OAM. 147 4. IOAM data fields encapsulation in BIER header 149 The BIER header is defined in [RFC8279]. The BIER OAM header that 150 follows BIER header is defined in [I-D.ietf-bier-ping]. IOAM-Data- 151 Fields can either be carried in BIER using a new type of OAM message 152 which follows the BIER OAM header (referred to as option 1), or be 153 carried in BIER using a new next protocol header which immediately 154 follows the BIER header (referred to as option 2). In this document, 155 option 2 is selected and the reason is discussed in Section 5.1. An 156 IOAM header is added containing the different IOAM-Data-Fields 157 defined in [I-D.ietf-ippm-ioam-data] and 158 [I-D.ietf-ippm-ioam-direct-export]. 160 In an administrative domain where IOAM is used, insertion of the IOAM 161 header in BIER is enabled at the BFIRs, which also serve as IOAM 162 encapsulating nodes by means of configuration, deletion of the IOAM 163 header in BIER is enabled at the BFERs, which also serve as IOAM 164 decapsulating nodes by means of configuration. 166 The Encapsulation format for IOAM over BIER is defined as follows: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 171 | BIFT-id | TC |S| TTL | | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 173 |Nibble | Ver | BSL | Entropy | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B 175 |OAM|Rsv| DSCP |Proto = TBD| BFIR-id | I 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 177 | BitString (first 32 bits) ~ R 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 179 ~ ~ | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 181 ~ BitString (last 32 bits) | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 183 | IOAM-Type | IOAM HDR Len | Reserved | Next Proto| | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 185 | | O 186 | | A 187 ~ IOAM Option and Data Space ~ M 188 | | | 189 | | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 191 | | 192 | | 193 | Payload + Padding (L2/L3/...) | 194 | | 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: IOAM Encapsulation Format within BIER 200 The BIER header and fields are defined in [RFC8296]. Within the BIER 201 header, a 6-bit field as "Proto" (Next Protocol) is used to identify 202 the type of the payload immediately following the BIER header, The 203 "Proto" value is set to TBD when the IOAM header is present. 205 The IOAM related fields in BIER are defined as follows: 207 IOAM-Type: 8-bit field defining the IOAM Option Type, as defined 208 in Section 8.1 of [I-D.ietf-ippm-ioam-data] and Section 4.1 of 209 [I-D.ietf-ippm-ioam-direct-export]. 211 IOAM HDR Len: 8-bit unsigned integer. Length of the IOAM header 212 in 4-octet units. 214 Reserved: 10-bit reserved field MUST be set to zero upon 215 transmission and ignored upon receipt. 217 Next Proto: 6-bit unsigned integer that identifies the type of 218 payload immediately following this IOAM option. The semantics of 219 this field are identical to the "Proto" field in [RFC8296]. 221 IOAM Option and Data Space: IOAM option header and data is present 222 as specified by the IOAM-Type field, and is defined in Section 5 223 of [I-D.ietf-ippm-ioam-data] and Section 3 of 224 [I-D.ietf-ippm-ioam-direct-export]. 226 Multiple IOAM-Option-Types MAY be included within the BIER 227 encapsulation. For example, if a BIER encapsulation contains two 228 IOAM-Option-Types preceding a data payload, the Next Proto field of 229 the first IOAM option will contain the value of TBD, while the Next 230 Proto field of the second IOAM option will contain the "BIER Next 231 Protocol" number indicating the type of the data payload. Each IOAM 232 Option-Type MUST occur at most once within the same BIER 233 encapsulation header. 235 5. Considerations 237 This section summarizes a set of considerations on the overall 238 approach taken for IOAM data encapsulation in BIER, as well as 239 deployment considerations. 241 5.1. Discussion of the encapsulation approach 243 Both the options described in section 4 are supposed to be feasible, 244 nevertheless this document needs to select one as standardized 245 encapsulation for IOAM over BIER. Considering the fact that the 246 encapsulation format option 2 using a new next protocol header is 247 more concise than option 1 using a new type of OAM message, and many 248 other transport protocols, e.g. GRE, use a new next protocol header 249 to encapsulate IOAM data, the encapsulation format option 2 is 250 selected as the standardized one. 252 5.2. IOAM and the use of the BIER OAM bits 254 [RFC8296] defines a two-bit field, referred to as OAM. 255 [I-D.ietf-bier-pmmm-oam] describes how to use the two-bits OAM field 256 for alternate marking performance measurement method, and this 257 document would not change the semantics of the two-bits OAM field. 258 The BIER IOAM header and the BIER two-bits OAM field are orthogonal 259 and can co-exist in the same packet header, i.e. a BIER packet with 260 IOAM data can set the OAM field or not, and a BIER packet with OAM 261 field set can also carry IOAM data or not. 263 6. Security Considerations 265 This document does not raise any additional security issues beyond 266 those of the specifications referred to in the list of normative 267 references. 269 7. IANA Considerations 271 In the "BIER Next Protocol Identifiers" registry defined in 272 [RFC8296], a new Next Protocol Value for IOAM is requested from IANA 273 as follows: 275 +--------------------+---------------+-----------------+------------+ 276 | BIER Next Protocol | Description | Semantics | Reference | 277 | Identifier | | Definition | | 278 +--------------------+---------------+-----------------+------------+ 279 | TBD | In-situ OAM | Section 4 | This | 280 | | (IOAM) | | Document | 281 +--------------------+---------------+-----------------+------------+ 283 Table 1: New BIER Next Protocol Identifier for IOAM 285 8. Acknowledgements 287 The authors would like to acknowledge Greg Mirsky for his thorough 288 review and very helpful comments. 290 9. References 292 9.1. Normative References 294 [I-D.ietf-ippm-ioam-data] 295 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 296 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 297 progress), February 2021. 299 [I-D.ietf-ippm-ioam-direct-export] 300 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 301 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 302 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 303 export-03 (work in progress), February 2021. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 311 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 312 May 2017, . 314 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 315 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 316 Explicit Replication (BIER)", RFC 8279, 317 DOI 10.17487/RFC8279, November 2017, 318 . 320 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 321 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 322 for Bit Index Explicit Replication (BIER) in MPLS and Non- 323 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 324 2018, . 326 9.2. Informative References 328 [I-D.ietf-bier-ping] 329 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 330 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 331 ping-07 (work in progress), May 2020. 333 [I-D.ietf-bier-pmmm-oam] 334 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 335 "Performance Measurement (PM) with Marking Method in Bit 336 Index Explicit Replication (BIER) Layer", draft-ietf-bier- 337 pmmm-oam-10 (work in progress), March 2021. 339 [I-D.ietf-bier-use-cases] 340 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 341 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 342 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-12 343 (work in progress), September 2020. 345 Authors' Addresses 347 Xiao Min 348 ZTE Corp. 349 Nanjing 350 China 352 Email: xiao.min2@zte.com.cn 353 Zheng(Sandy) Zhang 354 ZTE Corp. 355 Nanjing 356 China 358 Email: zhang.zheng@zte.com.cn 360 Yisong Liu 361 China Mobile 362 Beijing 363 China 365 Email: liuyisong@chinamobile.com 367 Nagendra Kumar Nainar 368 Cisco Systems, Inc. 369 7200-11 Kit Creek Road 370 Research Triangle Park, NC 27709 371 United States of America 373 Email: naikumar@cisco.com 375 Carlos Pignataro 376 Cisco Systems, Inc. 377 7200-11 Kit Creek Road 378 Research Triangle Park, NC 27709 379 United States of America 381 Email: cpignata@cisco.com