idnits 2.17.1 draft-xzlnp-bier-ioam-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 : ---------------------------------------------------------------------------- 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 (12 January 2022) is 834 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 (-11) exists of draft-ietf-ippm-ioam-direct-export-07 == 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-11 Summary: 0 errors (**), 0 flaws (~~), 4 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: 16 July 2022 Y. Liu 6 China Mobile 7 N. Nainar 8 C. Pignataro 9 Cisco Systems, Inc. 10 12 January 2022 12 Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM 13 (IOAM) Data 14 draft-xzlnp-bier-ioam-03 16 Abstract 18 In-situ Operations, Administration, and Maintenance (IOAM) records 19 operational and telemetry information in the packet while the packet 20 traverses a path in the network. Bit Index Explicit Replication 21 (BIER) is an architecture that provides optimal multicast forwarding 22 through a "multicast domain", without requiring intermediate routers 23 to maintain any per-flow state or to engage in an explicit tree- 24 building protocol. The BIER header contains a bit-string in which 25 each bit represents exactly one egress router to forward the packet 26 to. This document outlines the requirements to carry IOAM data in 27 BIER header and specifies how IOAM data fields are encapsulated in 28 BIER header. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 16 July 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . 3 68 4. IOAM data fields encapsulation in BIER header . . . . . . . . 4 69 5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Selecting the encapsulation approach . . . . . . . . . . 6 71 5.2. Interaction with the BIER OAM field . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 In-situ Operations, Administration, and Maintenance (IOAM) records 83 operational and telemetry information in the packet while the packet 84 traverses a path in the network. [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 OAM data is added to the data packets rather than 91 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 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 packets. This document attempts to provide a way 143 to record operational and telemetry information in the BIER packets 144 through in-situ OAM. 146 4. IOAM data fields encapsulation in BIER header 148 The BIER header is defined in [RFC8279]. The BIER OAM header that 149 follows BIER header is defined in [I-D.ietf-bier-ping]. IOAM-Data- 150 Fields can either be carried in BIER using a new type of OAM message 151 which follows the BIER OAM header (referred to as option 1), or be 152 carried in BIER using a new next protocol header which immediately 153 follows the BIER header (referred to as option 2). In this document, 154 option 2 is selected and the reason is discussed in Section 5.1. An 155 IOAM header is added containing different IOAM-Data-Fields defined in 156 [I-D.ietf-ippm-ioam-data] and [I-D.ietf-ippm-ioam-direct-export]. 158 In a BIER domain where IOAM is applied, inserting the IOAM header 159 into BIER packets is enabled at the BFIRs, which also serve as IOAM 160 encapsulating nodes by means of configuration, and deleting the IOAM 161 header from BIER packets is enabled at the BFERs, which also serve as 162 IOAM decapsulating nodes by means of configuration. 164 The Encapsulation format for IOAM over BIER is defined as follows: 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 169 | BIFT-id | TC |S| TTL | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 171 |Nibble | Ver | BSL | Entropy | | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B 173 |OAM|Rsv| DSCP |Proto=TBA1 | BFIR-id | I 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 175 | BitString (first 32 bits) ~ R 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 177 ~ ~ | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 179 ~ BitString (last 32 bits) | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 181 | IOAM-Type | IOAM HDR Len | Reserved | Next Proto| | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 183 | | O 184 | | A 185 ~ IOAM Option and Data Space ~ M 186 | | | 187 | | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 189 | | 190 | | 191 | Payload + Padding (L2/L3/...) | 192 | | 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1: IOAM Encapsulation Format within BIER 198 The BIER header and fields are defined in [RFC8296]. Within the BIER 199 header, a 6-bit field as "Proto" (Next Protocol) is used to identify 200 the type of the payload immediately following the BIER header, The 201 "Proto" value is set to TBA1 when the IOAM header is present. 203 The IOAM related fields in BIER are defined as follows: 205 IOAM-Type: An 8-bit field defining the IOAM option type, as 206 defined in Section 8.1 of [I-D.ietf-ippm-ioam-data] and 207 Section 4.1 of [I-D.ietf-ippm-ioam-direct-export]. 209 IOAM HDR Len: An 8-bit unsigned integer. Length of the IOAM 210 header in 4-octet units. 212 Reserved: A 10-bit reserved field MUST be set to zero upon 213 transmission and ignored upon receipt. 215 Next Proto: A 6-bit unsigned integer that identifies the type of 216 payload immediately following this IOAM option. The semantics of 217 this field are identical to the "Proto" field in [RFC8296]. 219 IOAM Option and Data Space: IOAM option header and data is present 220 as specified by the IOAM-Type field, and is defined in Section 5 221 of [I-D.ietf-ippm-ioam-data] and Section 3 of 222 [I-D.ietf-ippm-ioam-direct-export]. 224 Multiple IOAM options MAY be included within a BIER encapsulation. 225 For example, if a BIER encapsulation contains two IOAM options 226 preceding a data payload, the "Next Proto" field of the first IOAM 227 option would be set to the value of TBA1 that indicates a second IOAM 228 option follows, while the "Next Proto" field of the second IOAM 229 option would be set to the value of "BIER Next Protocol" indicating 230 the type of the data payload. Each type of IOAM option MUST occur at 231 most once within a BIER encapsulation. 233 5. Considerations 235 This section summarizes a set of considerations on the overall 236 approach taken for IOAM data encapsulation in BIER, as well as 237 deployment considerations. 239 5.1. Selecting the encapsulation approach 241 Both the options described in Section 4 are supposed to be feasible, 242 nevertheless this document needs to select one as standardized 243 encapsulation for IOAM over BIER. Considering the fact that the 244 encapsulation format option 2 using a new next protocol header is 245 more concise than option 1 using a new type of OAM message, and many 246 other transport protocols, e.g., GRE, use a new next protocol header 247 to encapsulate IOAM data, the encapsulation format option 2 is 248 selected as the standardized one. 250 5.2. Interaction with the BIER OAM field 252 [RFC8296] defines a two-bit field, referred to as OAM. 253 [I-D.ietf-bier-pmmm-oam] describes how to use the two-bit OAM field 254 for alternate marking performance measurement method. This document 255 would not change the semantics of the two-bit OAM field. The BIER 256 IOAM header and the BIER OAM field are orthogonal and they can co- 257 exist in one packet, i.e., a BIER packet with IOAM data can set the 258 OAM field and a BIER packet with OAM field set can carry IOAM data 259 too. 261 6. Security Considerations 263 This document describes the encapsulation of IOAM data fields in 264 BIER. Security considerations of the specific IOAM data fields are 265 described in [I-D.ietf-ippm-ioam-data] and 266 [I-D.ietf-ippm-ioam-direct-export]. 268 IOAM is considered a "per domain" feature, where one or several 269 operators decide on configuring IOAM according to their needs. IOAM 270 is intended for deployment in limited domains [RFC8799]. As such, it 271 assumes that a node involved in IOAM operation has previously 272 verified the integrity of the path. Still, operators need to 273 properly secure the IOAM domain to avoid malicious configuration and 274 use, which could include injecting malicious IOAM packets into the 275 domain. 277 As this document describes new protocol fields within the existing 278 BIER encapsulation, these are similar to the security considerations 279 of [RFC8296]. 281 7. IANA Considerations 283 In the "BIER Next Protocol Identifiers" registry created for 284 [RFC8296], a new Next Protocol Value for IOAM is requested from IANA 285 as follows: 287 +====================+=============+============+===========+ 288 | BIER Next Protocol | Description | Semantics | Reference | 289 | Identifier | | Definition | | 290 +====================+=============+============+===========+ 291 | TBA1 | In-situ OAM | Section 4 | This | 292 | | (IOAM) | | Document | 293 +--------------------+-------------+------------+-----------+ 295 Table 1: New BIER Next Protocol Identifier 297 8. Acknowledgements 299 The authors would like to acknowledge Greg Mirsky for his thorough 300 review and very helpful comments. 302 9. References 304 9.1. Normative References 306 [I-D.ietf-ippm-ioam-data] 307 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 308 for In-situ OAM", Work in Progress, Internet-Draft, draft- 309 ietf-ippm-ioam-data-17, 13 December 2021, 310 . 313 [I-D.ietf-ippm-ioam-direct-export] 314 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 315 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 316 OAM Direct Exporting", Work in Progress, Internet-Draft, 317 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 318 . 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 327 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 328 May 2017, . 330 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 331 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 332 Explicit Replication (BIER)", RFC 8279, 333 DOI 10.17487/RFC8279, November 2017, 334 . 336 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 337 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 338 for Bit Index Explicit Replication (BIER) in MPLS and Non- 339 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 340 2018, . 342 9.2. Informative References 344 [I-D.ietf-bier-ping] 345 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 346 and G. Mirsky, "BIER Ping and Trace", Work in Progress, 347 Internet-Draft, draft-ietf-bier-ping-07, 11 May 2020, 348 . 351 [I-D.ietf-bier-pmmm-oam] 352 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 353 "Performance Measurement (PM) with Marking Method in Bit 354 Index Explicit Replication (BIER) Layer", Work in 355 Progress, Internet-Draft, draft-ietf-bier-pmmm-oam-11, 4 356 October 2021, . 359 [I-D.ietf-bier-use-cases] 360 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 361 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 362 Bestler, "BIER Use Cases", Work in Progress, Internet- 363 Draft, draft-ietf-bier-use-cases-12, 10 September 2020, 364 . 367 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 368 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 369 . 371 Authors' Addresses 373 Xiao Min 374 ZTE Corp. 375 Nanjing 376 China 378 Email: xiao.min2@zte.com.cn 380 Zheng(Sandy) Zhang 381 ZTE Corp. 382 Nanjing 383 China 385 Email: zhang.zheng@zte.com.cn 387 Yisong Liu 388 China Mobile 389 Beijing 390 China 392 Email: liuyisong@chinamobile.com 393 Nagendra Kumar Nainar 394 Cisco Systems, Inc. 395 7200-11 Kit Creek Road 396 Research Triangle Park, NC 27709 397 United States of America 399 Email: naikumar@cisco.com 401 Carlos Pignataro 402 Cisco Systems, Inc. 403 7200-11 Kit Creek Road 404 Research Triangle Park, NC 27709 405 United States of America 407 Email: cpignata@cisco.com