idnits 2.17.1 draft-li-spring-light-weight-srv6-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.brockners-inband-oam-requirements]), 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 (December 19, 2018) is 1947 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) == Missing Reference: 'SL' is mentioned on line 427, but not defined -- Looks like a reference, but probably isn't: '0' on line 430 == Unused Reference: 'RFC6374' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC8321' is defined on line 511, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-06 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-15 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-00 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-06) exists of draft-ali-spring-ioam-srv6-00 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-04 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track S. Previdi 5 Expires: June 22, 2019 Huawei 6 Z. Li 7 China Mobile 8 December 19, 2018 10 A Light Weight IOAM for SRv6 Network Programming 11 draft-li-spring-light-weight-srv6-ioam-00 13 Abstract 15 In-situ OAM(IOAM) records OAM information within the packet while the 16 packet traverses a particular network domain. A discussion of the 17 motivation and requirements for in-situ OAM can be found in 18 [I-D.brockners-inband-oam-requirements]. 20 This document defines a light weight IOAM method for SRv6 network 21 programming. In this method, IOAM information is carried in the data 22 packet by the SIDs in the SRH. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 22, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 3. SRv6 Light Weight IOAM . . . . . . . . . . . . . . . . . . . 4 62 3.1. The FLAG Field of SID . . . . . . . . . . . . . . . . . . 4 63 4. Capabilities and SID Format Advertisement . . . . . . . . . . 5 64 5. SIDs Distribution . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 6 67 6.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 6 68 6.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 7 69 6.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 7 70 6.3.1. Egress Node . . . . . . . . . . . . . . . . . . . . . 7 71 6.4. Instructions for FLAG . . . . . . . . . . . . . . . . . . 8 72 7. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Timestamp Recording Procedures . . . . . . . . . . . . . 10 74 8. Backward Compatibility Considerations . . . . . . . . . . . . 10 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 78 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 13.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 Segment routing (SR) [RFC8402] is a source routing paradigm that 87 explicitly indicates the forwarding path for packets at the source 88 node by inserting an ordered list of instructions, called segments. 89 A segment can represent a topological or service-based instruction. 91 When segment routing is deployed on IPv6 dataplane, called SRv6 92 [I-D.ietf-6man-segment-routing-header], a segment is a 128 bit value, 93 and it can be an IPv6 address of a local interface but it does not 94 have to. As defined in 95 [I-D.filsfils-spring-srv6-network-programming], a segment has the 96 format of LOC: FUNCT. The most significant L bits is LOC that is 97 routable and leads packets to the SID originating node. The least 98 significant 128-L bits is the value of FUNCT that defines the local 99 actions associated to the SID. L is the length of LOC and it is 100 flexible. For supporting SR, a new type of routing header, called 101 Segment Routing Header (SRH), which contains a list of SIDs and other 102 needed information , has been defined in 103 [I-D.ietf-6man-segment-routing-header]. 105 In-situ OAM(IOAM) records OAM information within the packet while the 106 packet traverses a particular network domain. A discussion of the 107 motivation and requirements for in-situ OAM can be found in 108 [I-D.brockners-inband-oam-requirements]. [I-D.ali-spring-ioam-srv6] 109 defines an IOAM mechanism for SRv6. 111 However, recording IOAM data in SRH TLVs will bring bigger overhead, 112 which will reduce transport efficiency. In addition, the length of 113 the header will increase in the incremental trace option 114 [I-D.ietf-ippm-ioam-data], which may bring MTU problem and increase 115 the difficulty of packet processing. 117 This document introduces a light weight IOAM method for SRv6 network 118 programming. In this method, the OAM information is in the segment 119 list of the SRH once the segment is processed. 121 In most cases, an SRv6 segment will not be reused again after it has 122 been processed for updating the IPv6 destination address (as part of 123 the SRH procedures described in 124 [I-D.ietf-6man-segment-routing-header]. However, these processed 125 SIDs will still be carried in the SRH to the destination of the 126 packet (or penultimate node if PSP is enabled). Therefore, these 127 processed SIDs (i.e.: the 128 bit space they occupy) can be reused 128 for other purposes such as carrying performance measurement 129 information or IOAM [I-D.ietf-ippm-ioam-data] information. 131 Using the SID in order to carry OAM information allows not to 132 increase the size of the packet header and, of course, will cause the 133 loss of the original SID value. 135 2. Terminology 137 This memo makes use of the terms defined in [RFC8402], 138 [I-D.ietf-ippm-ioam-data] and 139 [I-D.filsfils-spring-srv6-network-programming]. 141 2.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 3. SRv6 Light Weight IOAM 151 This document defines a light weight IOAM model for SRv6 network 152 programming. 154 In SRv6, a SID will not be used again after it has been processed 155 according to SRH procedures described in 156 [I-D.ietf-6man-segment-routing-header]. Therefore, the 128 bits of 157 the used SID are reused in order to store metadata such as IOAM data. 159 In this document, we assume that the rewritable length of a SID is 64 160 bits at least, since IOAM data need to meet the accuracy requirement 161 as defined at [I-D.ietf-ippm-ioam-data]. The rewritable part 162 consists of the last 64 bits of the SID, which MAY be the FUNCT part. 164 In order to determine to which node the IOAM data is related, the LOC 165 that identifies the node must remain, especially when the type of 166 IOAM data is not node ID [I-D.ietf-ippm-ioam-data]. For getting rid 167 of the limitation of keeping LOC part of the SID, a Path Segment 168 [I-D.li-spring-srv6-path-segment] is included in the SID list. 170 In order to indicate the type of IOAM data, the document defines a 171 new field of the SID called the FLAG. With the FLAG field, the 172 format of the SID is LOC:FLAG:FUNCT. The new FLAG field is used in 173 order to indicate additional operations, such as IOAM operations. 174 The IOM data stored in the SID is structured in the following format: 175 . The procedure will be described in section 5. 177 3.1. The FLAG Field of SID 179 In order to indicate the type of IOAM data, this document defines a 180 new field of the SID, called FLAG. 182 This document does not limit the offset and length of the FLAG field, 183 and it can be configured by the operator. For instance, a FLAG field 184 can be a 8 bits value between the LOC and the FUNCT fields. The 185 offset can be the 48th bit. In other words, 0-47 bit is the LOC, 186 48-55 bit is the FLAG, and 56-127 bit is the FUNCT. The value of the 187 FLAG field indicates the IOAM processing and IOAM data type, and may 188 have the following values: 190 o 0: Non IOAM 192 o 1: Timestamp(32-bit seconds and 32-bit subseconds) 194 o 2: Packet counter 196 o 3: Queue depth 198 o 4: Ingress_if_id and egress_if_id (short format) 200 o 5: Hop_Lim and node_id 202 o 6: Namespace specific data 204 o 7: Buffer occupancy 206 o 8: Checksum Complement 208 o 9-255: Reserved 210 The IOAM data reuses the format defined in [I-D.ietf-ippm-ioam-data]. 211 A packet counter is a 64-bit value that records the total number of 212 packets in a flow, path or SR policy received by the node. It can be 213 used for use cases like packet loss measurement. 215 4. Capabilities and SID Format Advertisement 217 In order to support light weight IOAM, nodes SHOULD advertise the 218 IOAM capability to other nodes within an SR domain via, e.g., IGP 219 extensions. The definition, advertisement and processing of such 220 capability advertisement is out of scope of this document, and will 221 be described in a separate document. 223 The format of the SID SHOULD also be advertised to the other nodes in 224 the SR domain so that each node having to insert IOAM data, know 225 which format of the SID it has to use (i.e.: the size of the LOC, 226 FLAG and FUNC fields). The description of the advertisement of the 227 SID format is out of scope of this document, and will be described in 228 another document. 230 5. SIDs Distribution 232 It has to be noted that the FLAG field does not introduce any new 233 type of SID in the SR architecture. 235 A node can distribute all variants of SIDs with different FLAG 236 values. For example, Node A instantiates an End SID 237 [I-D.filsfils-spring-srv6-network-programming] as 238 A::0::100(LOC:FLAG:FUNCT), and it supports adding IOAM data of 239 timestamp and queue depth. Then, node A can distribute the SIDs 240 A::0::100, A::1::100, and A::3::100 in order to support respectively 241 non-IOAM End SID, End SID with timestamp recording, and End SID with 242 Queue depth recording. An Ingress node B can use these three 243 variants of SIDs according to the SR policy in order to achieve IOAM 244 with the specific node data. 246 Alternatively, a node can distribute only a default variant of SID in 247 order to reduce the SID distribution flooding traffic. The other 248 variants can be generated and used by the ingress node according to 249 the capabilities information of the SID endpoint node A. The details 250 will be discussed in another document. 252 6. Packet Processing 254 [I-D.ietf-6man-segment-routing-header] describes SRv6 packet 255 processing at the SR source, Transit and SR segment endpoint nodes. 256 This section describes the SRv6 packet processing with the new FLAG 257 field in the SID. 259 6.1. Source SR Node 261 This document assumes that, in an operator network, the packet 262 received at the ingress node is encapsulated into an outer IPv6+SRH 263 header. Therefore, the term "ingress" and "source" are to be 264 intended as the same node. 266 A source node steers a packet into an SR Policy that consists of a 267 segment list. When deploying IOAM, the source node SHOULD insert the 268 associated SID variant into the segment list as illustrated in 269 section 5. The variants of the SID can be learned from SIDs 270 distribution or generated according to node's capabilities. 272 After the first SID (SID-List[n-1], last entry in the SID list)is 273 updated to the IPv6 DA, the source node SHOULD rewrite the SID with 274 IOAM data according to the value of FLAG field and then send it to 275 the next hop. 277 6.1.1. Reduced SRH 279 Reduced SRH cannot support light weight IOAM since there is no space 280 for carrying IOAM data of the source node. 282 6.2. Transit Node 284 As specified in [RFC8200], the only node allowed to inspect the 285 Routing Extension Header (and therefore the SRH), is the node 286 corresponding to the DA of the packet. Any other transit node MUST 287 NOT inspect the underneath routing header and MUST forward the packet 288 toward the DA according to its IPv6 routing table. Thus, there is no 289 modification of packet processing on transit nodes. 291 6.3. SR Segment Endpoint Node 293 As per [I-D.ietf-6man-segment-routing-header], when an SRv6-capable 294 node receives an IPv6 packet, it performs a longest-prefix-match 295 lookup on the packets destination address. When this lookup returns 296 A FIB entry that represents a locally instantiated SRv6 SID, then the 297 node should process the SRH and related SIDs. 299 As per [I-D.filsfils-spring-srv6-network-programming], if the IPv6 DA 300 is a local SID instantiated by the node, then it should be looked up 301 in "My local SID table " in order to execute the instruction bound to 302 it. The "My Local SID Table" matches on a per longest-prefix-match 303 basis. 305 In order to process FLAG field, there are two options: 307 o All variants of the SID should be generated by the endpoint node 308 and stored in the "My Local SID Table" so that the variants of the 309 SID in IPv6 DA can match the entry by longest-prefix-match basis. 310 The node looks up the variant SID and executes the associated 311 instruction. IOAM data will be rewritten into the SID after the 312 SID has been copied into the DA of the packet. In this way, all 313 variants will be instantiated in the SID table. 315 o The endpoint node only distributes a default variant SID (FLAG 316 value is 0) and stores it in the "My Local SID Table". Before 317 looking up the SID, the value of the FLAG part is obtained and 318 then make it as all zero. The node looks up the default variant 319 SID to get the instruction. The FLAG related instruction that 320 sets IOAM data into the SID is executed after the DA of the packet 321 is updated with the SID (as per SRH processing - 322 [I-D.filsfils-spring-srv6-network-programming]). 324 6.3.1. Egress Node 326 In this document it is assumed that the egress node is the final 327 destination of the encapsulated packet. Therefore, the egress node 328 removes the outer IPv6 and SRH header. 330 As the last SRV6 endpoint node in the SID list, the egress node 331 cannot write any IOAM data into the SID since the segment list is 332 completed and there is no more SID to use. Therefore, the egress 333 node should record the related IOAM data and punt the data with a 334 copied packet to the CPU for further IOAM processing. 336 6.4. Instructions for FLAG 338 In order to achieve lightweight IOAM, processing of the FLAG field is 339 required and illustrated by the pseudo code here below: 341 1.If FLAG == n: 342 2. Get the IOAM-data D1 of type n. 343 3. If SL=1 and DA is End.S or if SL=0: ;;Ref1 344 4. Punt a copied packet with D1 to CPU for further processing;;Ref2 345 5. Else: 346 6. Insert following code after the instruction of updating DA: 347 7. Update SRH[SL][64:] with D1 ;;Ref3 349 o Ref1: If SL is 0 or SL is 1 and the DA is an End.S 350 [I-D.filsfils-spring-srv6-network-programming], it means that the 351 current node is the egress node. The node will punt a copied 352 packet with the D1 to the CPU for further processing. 354 o Ref2: At the egress node, in order not to affect the packet 355 forwarding, a copy of the data packet should be punted instead of 356 the data packet itself. However, this document does not limit 357 implementations to punt the entire packet or only headers of the 358 packet. 360 o Ref3: If the node is not the egress node the node only inserts 361 "updates the SID with D1" after the instruction of "update DA with 362 SRH[SL]". The last 64 bits of SID SRH[SL] is rewritten with D1 363 after updating SID SRH[SL] to IPv6 DA. If there is no Path 364 Segment in the segment list, the locator part needs to remain for 365 identifying a SID. The related IOAM data at the ingress node 366 should be written into the SID before sending the data packet. 368 The pseudo code below illustrates the example where the FLAG is set 369 to 1, indicating that the IOAM data is a timestamp: 371 1.If FLAG == 1: 372 2. Get the receiving timestamp T1. 373 3. If SL=1 and DA is End.S or if SL=0: 374 4. Punt a copy of the packet with T1 to CPU for further processing 375 5. Else: 376 6. Insert following code after the instruction of updating DA: 377 7. Update SRH[SL][64:] with T1 379 7. Illustrations 381 For easy understanding, the following simple topology is used for 382 illustration. 384 CE-A ---- N1-----N2-----N3---- CE-B 386 Reference Topology 388 In the reference topology: 390 o Nodes N1, N2, and N3 are all SRv6 capable nodes. 392 o Node N1 and N3 are configured with a tenant 10, each connected to 393 CE-A and CE-B respectively. 395 o Node Nk has Ak::/48 for its local SID space from which Local SIDs 396 are explicitly allocated. 398 o A2::1::1 is an End [I-D.filsfils-spring-srv6-network-programming] 399 function with timestamp recording allocated by N2 401 o A3::1::D10 is an End.DT4 402 [I-D.filsfils-spring-srv6-network-programming] function with 403 timestamp recording bound to tenant IPv4 table 10 allocated by N3. 405 o Bk::/48 is the loopback address of node K for IGP. 407 It is assumed that the measured flow from CE-A to CE-B will travel 408 along the path . 410 When the ingress node N1 receives an IPv4 packet with SA:CE-A, and 411 DA:CE-B, the ingress node N1 will encapsulate the packet into an IPv6 412 header followed by an SRH with the SID list , 413 so that the packet header is now (B1, A2::1::1) (A3::1::D10, 414 A2::1::1, SL=2)(CE-A, CE-B). The DA of the IPv6 header is then 415 updated with the first segment. 417 7.1. Timestamp Recording Procedures 419 After updating the DA with A2::1::1, the ingress node N1 updates the 420 SID A2::1::1 in the segment list with current timestamp. Then it 421 forwards the packet to N2 according to its RIB/FIB. Assuming that 422 the timestamp value is T1, then the updated packet header becomes 423 (B1, A2::1::1) (A3::D10, A2::1::T1, SL=1) (CE-A, CE-B). 425 When N2 receives the packet with DA A2::1::1 which is an End SID with 426 timestamp recording originated by N2, N2 will insert "Update 427 SRH[SL][64:] with the current timestamp" after instruction of "update 428 DA with SRH[SL]", and then process this End SID. 430 After updating IPv6 DA with SRH[0] A3::1::D10, the current timestamp 431 will be recorded at the last 64 bits of End SID A3::1::D10. Assuming 432 that the timestamp value is T2, the updated packet header becomes 433 (B1, A3::1::D10) (A3::1::T2, A2::1::T1, SL=0) (CE-A, CE-B). 434 According to the updated DA A3::1::D10, the packet will be forwarded 435 to N3. 437 When the egress node N3 receives the packet with header (B1, 438 A3::1::D10) (A3::1::T2, A2::1::T1, SL=0) (CE-A, CE-B), N3 should 439 timestamp the copied packet and punt it to CPU for further 440 processing. Then, N3 decapsulates the outer header and forwards the 441 inner packet to CE-B based on the routes in tenant-10 IPv4 table. 443 IOAM data processing can be implemented by a node or a remote 444 controller. In this solution, only one receiving timestamp or 445 sending timestamp can be recorded in the SID at each endpoint node. 446 Therefore, it is RECOMMENDED that the ingress node records the 447 sending timestamp while the other nodes record the receiving 448 timestamp. 450 8. Backward Compatibility Considerations 452 TBA 454 9. IANA Considerations 456 TBA 458 10. Security Considerations 460 TBA 462 11. Contributors 464 TBA 466 12. Acknowledgements 468 Many thanks to Stefano's professional comments. 470 13. References 472 13.1. Normative References 474 [I-D.filsfils-spring-srv6-network-programming] 475 Filsfils, C., Camarillo, P., Leddy, J., 476 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 477 Network Programming", draft-filsfils-spring-srv6-network- 478 programming-06 (work in progress), October 2018. 480 [I-D.ietf-6man-segment-routing-header] 481 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 482 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 483 (SRH)", draft-ietf-6man-segment-routing-header-15 (work in 484 progress), October 2018. 486 [I-D.li-spring-srv6-path-segment] 487 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 488 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 489 draft-li-spring-srv6-path-segment-00 (work in progress), 490 October 2018. 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, 494 DOI 10.17487/RFC2119, March 1997, 495 . 497 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 498 Measurement for MPLS Networks", RFC 6374, 499 DOI 10.17487/RFC6374, September 2011, 500 . 502 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 503 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 504 May 2017, . 506 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 507 (IPv6) Specification", STD 86, RFC 8200, 508 DOI 10.17487/RFC8200, July 2017, 509 . 511 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 512 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 513 "Alternate-Marking Method for Passive and Hybrid 514 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 515 January 2018, . 517 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 518 Decraene, B., Litkowski, S., and R. Shakir, "Segment 519 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 520 July 2018, . 522 13.2. Informative References 524 [I-D.ali-spring-ioam-srv6] 525 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Kumar, 526 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 527 "Segment Routing Header encapsulation for In-situ OAM 528 Data", draft-ali-spring-ioam-srv6-00 (work in progress), 529 October 2018. 531 [I-D.brockners-inband-oam-requirements] 532 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 533 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 534 T., Lapukhov, P., and r. remy@barefootnetworks.com, 535 "Requirements for In-situ OAM", draft-brockners-inband- 536 oam-requirements-03 (work in progress), March 2017. 538 [I-D.ietf-ippm-ioam-data] 539 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 540 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 541 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 542 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 543 data-04 (work in progress), October 2018. 545 Authors' Addresses 547 Cheng Li 548 Huawei 550 Email: chengli13@huawei.com 552 Mach(Guoyi) Chen 553 Huawei 555 Email: mach.chen@huawei.com 556 Stefano Previdi 557 Huawei 558 Italy 560 Email: stefano@previdi.net 562 Zhenqiang Li 563 China Mobile 564 32 Xuanwumen West Ave 565 Beijing, Xicheng District 566 China 568 Email: lizhenqiang@chinamobile.com