idnits 2.17.1 draft-xzlnp-bier-ioam-01.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 (January 8, 2021) is 1203 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-11 == 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-09 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: July 12, 2021 Y. Liu 6 China Mobile 7 N. Nainar 8 C. Pignataro 9 Cisco Systems, Inc. 10 January 8, 2021 12 Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM 13 (IOAM) Data 14 draft-xzlnp-bier-ioam-01 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 July 12, 2021. 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 different IOAM data fields used to record various telemetry data from 86 the transit nodes. The term "in-situ" refers to the fact that the 87 IOAM data fields are added to the data packets rather than being sent 88 within packets specifically dedicated to OAM. 90 Bit Index Explicit Replication (BIER), as defined in [RFC8279], is an 91 architecture that provides optimal multicast forwarding through a 92 "multicast domain", without requiring intermediate routers to 93 maintain any per-flow state or to engage in an explicit tree-building 94 protocol. The BIER header, as defined in [RFC8296], contains a bit- 95 string in which each bit represents exactly one egress router to 96 forward the packet to. 98 This document outlines the requirements to carry IOAM data in BIER 99 header and specifies how IOAM data fields are encapsulated in BIER 100 header. 102 2. Conventions Used in This Document 104 2.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 2.2. Abbreviations 114 Abbreviations used in this document: 116 BFER: Bit Forwarding Egress Router 118 BFIR: Bit Forwarding Ingress Router 120 BIER: Bit Index Explicit Replication 122 GRE: Generic Routing Encapsulation 124 IOAM: In-situ Operations, Administration, and Maintenance 126 OAM: Operations, Administration, and Maintenance 128 3. Requirements to carry IOAM data in BIER header 130 [I-D.ietf-bier-use-cases] lists many use cases for BIER. Usually 131 there are many multicast flows within one network domain, and some of 132 the multicast flows, such as live video and real-time meeting, are 133 sensitive to packet loss, delay and other factors. The network 134 operator wants to know the real-time statistics for these flows, such 135 as delay, sequence, the ingress/egress interface, and the usage of 136 buffer. 138 So methods are needed for measuring the real-time transportation 139 guarantee of BIER packet. Performance measurement function defined 140 in [I-D.ietf-bier-pmmm-oam] can be used for measuring packet loss and 141 delay. This document attempts to provide a way to collect on-path 142 operational and telemetry information through in-situ OAM. 144 4. IOAM data fields encapsulation in BIER header 146 The BIER header is defined in [RFC8279]. The BIER OAM header that 147 follows BIER header is defined in [I-D.ietf-bier-ping]. IOAM-Data- 148 Fields can either be carried in BIER using a new type of OAM message 149 which follows the BIER OAM header (referred to as option 1), or be 150 carried in BIER using a new next protocol header which immediately 151 follows the BIER header (referred to as option 2). In this document, 152 option 2 is selected and the reason is discussed in Section 5.1. An 153 IOAM header is added containing the different IOAM-Data-Fields 154 defined in [I-D.ietf-ippm-ioam-data]. 156 In an administrative domain where IOAM is used, insertion of the IOAM 157 header in BIER is enabled at the BFIRs, which also serve as IOAM 158 encapsulating nodes by means of configuration, deletion of the IOAM 159 header in BIER is enabled at the BFERs, which also serve as IOAM 160 decapsulating nodes by means of configuration. 162 The Encapsulation format for IOAM over BIER is defined as follows: 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 | BIFT-id | TC |S| TTL | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 169 |Nibble | Ver | BSL | Entropy | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B 171 |OAM|Rsv| DSCP |Proto = TBD| BFIR-id | I 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 173 | BitString (first 32 bits) ~ R 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 175 ~ ~ | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 177 ~ BitString (last 32 bits) | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 179 | IOAM-Type | IOAM HDR Len | Reserved | Next Proto| | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 181 | | O 182 | | A 183 ~ IOAM Option and Data Space ~ M 184 | | | 185 | | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 187 | | 188 | | 189 | Payload + Padding (L2/L3/...) | 190 | | 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1: IOAM Encapsulation Format within BIER 196 The BIER header and fields are defined in [RFC8296]. Within the BIER 197 header, a 6-bit field as "Proto" (Next Protocol) is used to identify 198 the type of the payload immediately following the BIER header, The 199 "Proto" value is set to TBD when the IOAM header is present. 201 The IOAM related fields in BIER are defined as follows: 203 IOAM-Type: 8-bit field defining the IOAM Option Type, as defined 204 in Section 8.1 of [I-D.ietf-ippm-ioam-data]. 206 IOAM HDR Len: 8-bit unsigned integer. Length of the IOAM header 207 in 4-octet units. 209 Reserved: 10-bit reserved field MUST be set to zero upon 210 transmission and ignored upon receipt. 212 Next Proto: 6-bit unsigned integer that identifies the type of 213 payload immediately following this IOAM option. The semantics of 214 this field are identical to the "Proto" field in [RFC8296]. 216 IOAM Option and Data Space: IOAM option header and data is present 217 as specified by the IOAM-Type field, and is defined in Section 5 218 of [I-D.ietf-ippm-ioam-data]. 220 Multiple IOAM-Option-Types MAY be included within the BIER 221 encapsulation. For example, if a BIER encapsulation contains two 222 IOAM-Option-Types preceding a data payload, the Next Proto field of 223 the first IOAM option will contain the value of TBD, while the Next 224 Proto field of the second IOAM option will contain the "BIER Next 225 Protocol" number indicating the type of the data payload. Each IOAM 226 Option-Type MUST occur at most once within the same BIER 227 encapsulation header. 229 5. Considerations 231 This section summarizes a set of considerations on the overall 232 approach taken for IOAM data encapsulation in BIER, as well as 233 deployment considerations. 235 5.1. Discussion of the encapsulation approach 237 Both the options described in section 4 are supposed to be feasible, 238 nevertheless this document needs to select one as standardized 239 encapsulation for IOAM over BIER. Considering the fact that the 240 encapsulation format option 2 using a new next protocol header is 241 more concise than option 1 using a new type of OAM message, and many 242 other transport protocols, e.g. GRE, use a new next protocol header 243 to encapsulate IOAM data, the encapsulation format option 2 is 244 selected as the standardized one. 246 5.2. IOAM and the use of the BIER OAM bits 248 [RFC8296] defines a two-bits long field, referred to as OAM. 249 [I-D.ietf-bier-pmmm-oam] describes how to use the two-bits OAM field 250 for alternate marking performance measurement method, and this 251 document would not change the semantics of the two-bits OAM field. 252 The BIER IOAM header and the BIER two-bits OAM field are orthogonal 253 and can co-exist in the same packet header, i.e. a BIER packet with 254 IOAM data can set the OAM field or not, and a BIER packet with OAM 255 field set can also carry IOAM data or not. 257 6. Security Considerations 259 This document does not raise any additional security issues beyond 260 those of the specifications referred to in the list of normative 261 references. 263 7. IANA Considerations 265 In the "BIER Next Protocol Identifiers" registry defined in 266 [RFC8296], a new Next Protocol Value for IOAM is requested from IANA 267 as follows: 269 +--------------------+---------------+-----------------+------------+ 270 | BIER Next Protocol | Description | Semantics | Reference | 271 | Identifier | | Definition | | 272 +--------------------+---------------+-----------------+------------+ 273 | TBD | In-situ OAM | Section 4 | This | 274 | | (IOAM) | | Document | 275 +--------------------+---------------+-----------------+------------+ 277 Table 1: New BIER Next Protocol Identifier for IOAM 279 8. Acknowledgements 281 The authors would like to acknowledge Greg Mirsky for his thorough 282 review and very helpful comments. 284 9. References 286 9.1. Normative References 288 [I-D.ietf-ippm-ioam-data] 289 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 290 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 291 progress), November 2020. 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 299 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 300 May 2017, . 302 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 303 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 304 Explicit Replication (BIER)", RFC 8279, 305 DOI 10.17487/RFC8279, November 2017, 306 . 308 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 309 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 310 for Bit Index Explicit Replication (BIER) in MPLS and Non- 311 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 312 2018, . 314 9.2. Informative References 316 [I-D.ietf-bier-ping] 317 Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 318 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 319 ping-07 (work in progress), May 2020. 321 [I-D.ietf-bier-pmmm-oam] 322 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 323 "Performance Measurement (PM) with Marking Method in Bit 324 Index Explicit Replication (BIER) Layer", draft-ietf-bier- 325 pmmm-oam-09 (work in progress), December 2020. 327 [I-D.ietf-bier-use-cases] 328 Nainar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 329 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 330 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-12 331 (work in progress), September 2020. 333 Authors' Addresses 335 Xiao Min 336 ZTE Corp. 337 Nanjing 338 China 340 Email: xiao.min2@zte.com.cn 342 Zheng(Sandy) Zhang 343 ZTE Corp. 344 Nanjing 345 China 347 Email: zhang.zheng@zte.com.cn 348 Yisong Liu 349 China Mobile 350 Beijing 351 China 353 Email: liuyisong@chinamobile.com 355 Nagendra Kumar Nainar 356 Cisco Systems, Inc. 357 7200-11 Kit Creek Road 358 Research Triangle Park, NC 27709 359 United States 361 Email: naikumar@cisco.com 363 Carlos Pignataro 364 Cisco Systems, Inc. 365 7200-11 Kit Creek Road 366 Research Triangle Park, NC 27709 367 United States 369 Email: cpignata@cisco.com