idnits 2.17.1 draft-xzlnp-bier-ioam-00.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 13, 2020) is 1382 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 (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-09 == Outdated reference: A later version (-15) exists of draft-ietf-bier-pmmm-oam-08 == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-11 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 14, 2021 Y. Liu 6 China Mobile 7 N. Nainar 8 C. Pignataro 9 Cisco Systems, Inc. 10 July 13, 2020 12 Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM 13 (IOAM) Data 14 draft-xzlnp-bier-ioam-00 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 14, 2021. 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 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. There are 131 many multicast flows in one network. Some of the flows are sensitive 132 for packet loss, delay and other factors, such as live video, real- 133 time meeting. The network administrator wants to know the real-time 134 statistics for these flows, such as delay, sequence, the I/O 135 interface, and the usage of buffer, and so on. 137 So a method need to be used for measuring the packet real-time 138 transportation guarantee. OAM function defined in 139 [I-D.ietf-bier-pmmm-oam] can be used for packet loss and delay 140 detection. This document attempts to provide a way to achieve on- 141 path telemetry information collection through in-situ OAM. 143 4. IOAM data fields encapsulation in BIER header 145 The BIER header is defined in [RFC8279]. The BIER OAM header that 146 follows BIER header is defined in [I-D.ietf-bier-ping]. IOAM-Data- 147 Fields can either be carried in BIER using a new type of OAM message 148 which follows the BIER OAM header (referred to as option 1), or be 149 carried in BIER using a new next protocol header which immediately 150 follows the BIER header (referred to as option 2). In this document, 151 option 2 is selected and the reason is discussed in Section 5.1. An 152 IOAM header is added containing the different IOAM-Data-Fields 153 defined in [I-D.ietf-ippm-ioam-data]. 155 In an administrative domain where IOAM is used, insertion of the IOAM 156 header in BIER is enabled at the BFIRs, which also serve as IOAM 157 encapsulating nodes by means of configuration, deletion of the IOAM 158 header in BIER is enabled at the BFERs, which also serve as IOAM 159 decapsulating nodes by means of configuration. 161 The Encapsulation format for IOAM over BIER is defined as follows: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 166 | BIFT-id | TC |S| TTL | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 168 |Nibble | Ver | BSL | Entropy | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B 170 |OAM|Rsv| DSCP |Proto = TBD| BFIR-id | I 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 172 | BitString (first 32 bits) ~ R 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 174 ~ ~ | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 176 ~ BitString (last 32 bits) | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 178 | IOAM-Type | IOAM HDR Len | Reserved | Next Proto| | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 180 | | O 181 | | A 182 ~ IOAM Option and Data Space ~ M 183 | | | 184 | | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 186 | | 187 | | 188 | Payload + Padding (L2/L3/...) | 189 | | 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: IOAM Encapsulation Format within BIER 195 The BIER header and fields are defined in [RFC8296]. Within the BIER 196 header, a 6-bit field as "Proto" (Next Protocol) is used to identify 197 the type of the payload immediately following the BIER header, The 198 "Proto" value is set to TBD when the IOAM header is present. 200 The IOAM related fields in BIER are defined as follows: 202 IOAM-Type: 8-bit field defining the IOAM Option Type, as defined 203 in Section 7.2 of [I-D.ietf-ippm-ioam-data]. 205 IOAM HDR Len: 8-bit unsigned integer. Length of the IOAM header 206 in 4-octet units. 208 Reserved: 10-bit reserved field MUST be set to zero upon 209 transmission and ignored upon receipt. 211 Next Proto: 6-bit unsigned integer that identifies the type of 212 payload immediately following this IOAM option. The semantics of 213 this field are identical to the "Proto" field in [RFC8296]. 215 IOAM Option and Data Space: IOAM option header and data is present 216 as specified by the IOAM-Type field, and is defined in Section 4 217 of [I-D.ietf-ippm-ioam-data]. 219 Multiple IOAM-Option-Types MAY be included within the BIER 220 encapsulation. For example, if a BIER encapsulation contains two 221 IOAM-Option-Types preceding a data payload, the Next Proto field of 222 the first IOAM option will contain the value of TBD, while the Next 223 Proto field of the second IOAM option will contain the "BIER Next 224 Protocol" number indicating the type of the data payload. Each IOAM 225 Option-Type MUST occur at most once within the same BIER 226 encapsulation header. 228 5. Considerations 230 This section summarizes a set of considerations on the overall 231 approach taken for IOAM data encapsulation in BIER, as well as 232 deployment considerations. 234 5.1. Discussion of the encapsulation approach 236 Both the options described in section 4 are supposed to be feasible, 237 nevertheless this document needs to select one as standardized 238 encapsulation for IOAM over BIER. Considering the fact that the 239 encapsulation format option 2 using a new next protocol header is 240 more concise than option 1 using a new type of OAM message, and many 241 other transport protocols, e.g. GRE, use a new next protocol header 242 to encapsulate IOAM data, the encapsulation format option 2 is 243 selected as the standardized one. 245 5.2. IOAM and the use of the BIER OAM bits 247 [RFC8296] defines a two-bits long field, referred to as OAM. 248 [I-D.ietf-bier-pmmm-oam] describes how to use the two-bits OAM field 249 for alternate marking performance measurement method. The BIER IOAM 250 header and the BIER two-bits OAM field are orthogonal and can co- 251 exist in the same packet header, i.e. a BIER packet with IOAM data 252 can set the OAM field or not, and a BIER packet with OAM field set 253 can also carry IOAM data or not. 255 6. Security Considerations 257 This document does not raise any additional security issues beyond 258 those of the specifications referred to in the list of normative 259 references. 261 7. IANA Considerations 263 In the "BIER Next Protocol Identifiers" registry defined in 264 [RFC8296], a new Next Protocol Value for IOAM is requested from IANA 265 as follows: 267 +--------------------+---------------+-----------------+------------+ 268 | BIER Next Protocol | Description | Semantics | Reference | 269 | Identifier | | Definition | | 270 +--------------------+---------------+-----------------+------------+ 271 | TBD | In-situ OAM | Section 4 | This | 272 | | (IOAM) | | Document | 273 +--------------------+---------------+-----------------+------------+ 275 Table 1: New BIER Next Protocol Identifier for IOAM 277 8. Acknowledgements 279 The authors would like to acknowledge Greg Mirsky for his thorough 280 review and very helpful comments. 282 9. References 284 9.1. Normative References 286 [I-D.ietf-bier-ping] 287 Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 288 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 289 ping-07 (work in progress), May 2020. 291 [I-D.ietf-ippm-ioam-data] 292 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 293 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 294 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 295 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 296 ietf-ippm-ioam-data-09 (work in progress), March 2020. 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 304 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 305 May 2017, . 307 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 308 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 309 Explicit Replication (BIER)", RFC 8279, 310 DOI 10.17487/RFC8279, November 2017, 311 . 313 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 314 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 315 for Bit Index Explicit Replication (BIER) in MPLS and Non- 316 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 317 2018, . 319 9.2. Informative References 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-08 (work in progress), May 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-11 331 (work in progress), March 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