idnits 2.17.1 draft-ali-spring-sr-pm-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 162 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 133: '...the querier node SHOULD send the UDP R...' RFC 2119 keyword, line 134: '... (URO) (Type=131) defined in [RFC7867]. The responder node SHOULD send the...' RFC 2119 keyword, line 313: '... Reserved fields MUST be set to 0 and ...' RFC 2119 keyword, line 380: '...e Address of a query message SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 23, 2017) is 2309 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: 'RFC7867' is mentioned on line 394, but not defined == Missing Reference: 'RFC2679' is mentioned on line 244, but not defined ** Obsolete undefined reference: RFC 2679 (Obsoleted by RFC 7679) == Missing Reference: 'I-D.draft-ietf-6man-segment-routing-header' is mentioned on line 263, but not defined == Missing Reference: 'I-D.draft-filsfils-spring-srv6-network-programming' is mentioned on line 372, but not defined == Unused Reference: 'RFC7876' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-data' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-transport' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'I-D.brockners-inband-oam-requirements' is defined on line 489, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPRING Working Group Z. Ali 2 Internet Draft C. Filsfils 3 Intended status: Standards Track R. Gandhi 4 Expires: June 22, 2018 N. Kumar 5 F. Iqbal 6 C. Pignataro 7 Cisco Systems, Inc. 8 D. Steinberg 9 Steinberg Consulting 10 S. Salsano 11 Universita di Roma "Tor Vergata" 12 G. Naik 13 Drexel University 14 December 23, 2017 16 Performance Measurement in Segment Routing Networks 17 draft-ali-spring-sr-pm-00.txt 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 22 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering Task Force 25 (IETF), its areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months and may be 29 updated, replaced, or obsoleted by other documents at any time. It is 30 inappropriate to use Internet-Drafts as reference material or to cite them other 31 than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on June 22, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the document authors. 44 All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating 47 to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents carefully, as they 49 describe your rights and restrictions with respect to this document. Code 50 Components extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 RFC 6374 specifies protocol mechanisms to enable the efficient and accurate 57 measurement of packet loss, one-way and two-way delay, as well as related metrics 58 such as delay variation and channel throughput in MPLS networks. This document 59 describes how these mechanisms can be used for performance measurements in Segment 60 Routing with MPLS data plane (SR-MPLS) networks. The document also specifies how 61 similar mechanisms can be used for performance measurement in Segment Routing with 62 IPv6 data plane (SRv6) networks. 64 Table of Contents 66 1. Introduction...................................................2 67 2. Performance Measurement in SR-MPLS Networks....................3 68 2.1. Delay Measurement in SR-MPLS Networks.....................3 69 2.1.1. Delay Measurement Message Format.....................3 70 2.1.2. One Way Delay Measurement............................3 71 2.1.2.1. One-Way Delay Measurement using Synthetic Probes3 72 2.1.3. Two Way Delay Measurement............................3 73 3. Performance Measurement in SRv6 Networks.......................4 74 3.1. Terminology and Reference Topology........................4 75 3.2. Delay Measurement in SRv6 Networks........................5 76 3.2.1. One Way Delay Measurement............................5 77 3.2.2. Two Way Delay Measurement............................6 78 3.2.3. Delay Measurement Message Format.....................6 79 3.2.4. One-Way Delay Measurement using Synthetic Probes.....8 80 3.2.4.1. Example Procedure...............................8 81 3.2.5. In-situ One-Way Segment-by-Segment Delay Measurement.9 82 3.2.5.1. Example Procedure...............................9 83 4. Security Considerations.......................................10 84 5. IANA Considerations...........................................10 85 6. Contributors..................................................10 86 7. References....................................................10 87 7.1. Normative References.....................................10 88 7.2. Informative References...................................11 89 8. Acknowledgments...............................................11 91 1. Introduction 93 Service provider's ability to satisfy Service level agreements (SLAs) depend on 94 the ability to measure and monitor performance metrics for packet loss and one-way 95 and two-way delay, as well as related metrics such as delay variation and channel 96 throughput. The ability to monitor these performance metrics also provides 97 operators with greater visibility into the performance characteristics of their 98 networks, thereby facilitating planning, troubleshooting, and network performance 99 evaluation. [RFC6374] specifies protocol mechanisms to enable the efficient and 100 accurate measurement of these performance metrics in MPLS networks. This document 101 describes how these mechanisms can be used for performance measurements in Segment 102 Routing with the MPLS data plane (SR-MPLS) networks. The document also specifies 103 how similar mechanisms can be used for performance measurement in Segment Routing 104 with the IPv6 data plane (SRv6) networks. 106 2. Performance Measurement in SR-MPLS Networks 108 SR-MPLS relies on MPLS data plane without any changes. Hence, the protocol 109 mechanisms for MPLS networks defined in [RFC6374] are equally applicable to SR- 110 MPLS networks. This version of the document focuses on delay measurement. 111 Measurements for loss and other performance metrics are to be added in the future 112 version of this document. 114 2.1. Delay Measurement in SR-MPLS Networks 116 2.1.1. Delay Measurement Message Format 118 As described in [RFC6374], Section 2.9.1, MPLS DM probe messages flow over the 119 MPLS Generic Associated Channel (G-ACh). Thus, a probe packet for a DM message 120 contains SR-MPLS label stack, with the G-ACh Label (GAL) at the bottom of the 121 stack. The GAL is followed by an Associated Channel Header (ACH) (value 0x000C 122 for delay measurement) [RFC6374], which identifies the message type, and the 123 message body following the ACH. The format of the DM message payload as defined 124 in [RFC6374] is used for SR-MPLS delay measurement. 126 2.1.2. One Way Delay Measurement 128 2.1.2.1. One-Way Delay Measurement using Synthetic Probes 130 The query and response mechanisms defined in [RFC6374] are followed for synthetic 131 delay measurement in SR-MPLS network. 133 For one-way delay measurement, the querier node SHOULD send the UDP Return Object 134 (URO) (Type=131) defined in [RFC7867]. The responder node SHOULD send the 135 response back to the querier node in an UDP message when the URO TLV is present in 136 the PM query message. 138 2.1.3. Two Way Delay Measurement 140 The two-way delay measurement for packet networks is defined in [RFC6374]. The 141 two-way delay measurement in SR-MPLS networks is to be added in the future version 142 of this document. 144 3. Performance Measurement in SRv6 Networks 146 This version of the document focuses on delay measurement. Loss and 147 other performance metric measurements are to be added in the future 148 version of this document. 150 3.1. Terminology and Reference Topology 152 Throughout the document, the following simple topology is used for illustration. 154 +--------------------------| N100 |------------------------+ 155 | | 156 ====== link1====== link3------ link5====== link9------ 157 ||N1||======||N2||======| N3 |======||N4||======| N5 | 158 || ||------|| ||------| |------|| ||------| | 159 ====== link2====== link4------ link6======link10------ 160 | | 161 | ------ | 162 +--------| N6 |--------+ 163 link7 | | link8 164 ------ 166 Reference Topology 168 In the reference topology: 170 Nodes N1, N2, and N4 are SRv6 capable nodes. 172 Nodes N3, N5 and N6 are classic IPv6 nodes. 174 Node 100 is a controller. 176 Node Nk has a classic IPv6 loopback address Bk::/128 178 Node Nk has Ak::/48 for its local SID space from which Local SIDs are explicitly 179 allocated. 181 The IPv6 address of the nth Link between node X and Y at the X side is represented 182 as 99:X:Y::Xn. e.g., the IPv6 address of link6 (the 2nd link) between N3 and N4 at 183 N3 in Figure 1 is 99:3:4:32. Similarly, the IPv6 address of link5 (the 1st link 184 between N3 and N4) at node 3 is 99:3:4::31. 186 Ak::0 is explicitly allocated as the END function at Node k. 188 Ak::Cij is explicitly allocated as the END.X function at node k towards neighbor 189 node i via jth Link between node i and node j. e.g., A2::C31 represents END.X at 190 N2 towards N3 via link3 (the 1st link between N2 and N3). Similarly, A4::C52 191 represents the END.X at N4 towards N5 via link10. 193 SRH is the abbreviation for the Segment Routing Header. 195 SL is the abbreviation for the Segment Left. 197 SID is the abbreviation for the Segment ID. 199 represents a SID list where S1 is the first SID and S3 is the last 200 SID. (S3, S2, S1; SL) represents the same SID list but encoded in the SRH format 201 where the rightmost SID (S1) in the SRH is the first SID and the leftmost SID (S3) 202 in the SRH is the last SID. 204 ECMP is the abbreviation for the Equal Cost Multi-Path. 206 UCMP is the abbreviation for the Unequal Cost Multi-Path. 208 3.2. Delay Measurement in SRv6 Networks 210 3.2.1. One Way Delay Measurement 212 The one-way delay measurement for packet networks is defined in [RFC2679]. It is 213 further exemplified using the following Figure. 215 ------ 216 |N100| 217 | | 218 ------ 219 ^ 220 | Response Option2 221 T1 T2 | 222 +-------+/ Query \+-------+ 223 | | - - - - - - - - - ->| | 224 | N1 |=====================| N4 | 225 | |<- - - - - - - - - - | | 226 +-------+\ Response Option1 /+-------+ 227 T4 T3 229 Delay Measurement Reference Model 231 Nodes N1 and N4 may not be directly connected, as shown in the reference topology 232 in Figure 1. When N1 and N4 are not directly connected, the one-way delay 233 measurement reflects the delay observed by the packet over an arbitrary SRv6 234 segment-list/ policy. In other words, the one-way delay is associated with the 235 forward (N1 to N4) direction of the SRv6 segment-list/ policy. 237 The delay measurement can be performed using Active (using synthetic probe) mode 238 and Passive (using data stream aka in-situ) mode. In both modes, T1 refers to the 239 time the packet is transmitted from N1. Timestamping is done as late as possible 240 at the egress pipeline (in hardware) at node N1. T2 refers to the time the packet 241 is received at N2. Timestamping at the receiver (N2) is done as soon as possible 242 at the ingress pipeline (in hardware). 244 The one-way delay metric can be defined as follow [RFC2679], [RFC6374], 245 One-way delay = T2 - T1. 247 Clock synchronization using methods detailed in [RFC6374] is assumed here. 249 Please note that for the one-way delay computation, the receiver (node N4 in 250 Figure 2) is not required to send a response. The response can be sent to a 251 controller (node N100 in Figure 2). The controller may also request the querier 252 (node N1 in Figure 2) to initiate a measurement (this messaging is not shown in 253 Figure 2 and is beyond the scope of this document). 255 3.2.2. Two Way Delay Measurement 257 The two-way delay measurement for packet networks is defined in [RFC6374]. The 258 two-way delay measurement in SRv6 networks is to be added in the future version of 259 this document. 261 3.2.3. Delay Measurement Message Format 263 [I-D.draft-ietf-6man-segment-routing-header] defines Segment Routing Header (SRH) 264 for SRv6. SRH can contain TLVs, as specified in [I-D.draft-ietf-6man-segment- 265 routing-header]. This document specifies Delay Measurement (DM) TLV of SRH. The 266 DM TLV adapts a message format similar to the message format specified in 267 [RFC6374]. The DM TLV format in SRv6 network is defined as following: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | RESERVED | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |Version| Flags | Control Code | RESERVED | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | QTF | RTF | RPTF | Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Session Identifier | TC | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Timestamp 1 | 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 . . 285 . . 286 . . 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Timestamp 4 | 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 ~ SUB-TLV Block ~ 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 The meanings of the fields are summarized in the following table. 296 Field Meaning 297 --------------------- ----------------------------------------------- 298 Type SRH TLV type (Value TBA) 299 Length Total length of the TLV in bytes 300 Version Protocol version 301 Flags Message control flags 302 Control Code Code identifying the query or response type 303 QTF Querier timestamp format 304 RTF Responder timestamp format 305 RPTF Responder's preferred timestamp format 306 Reserved Reserved for future specification 307 Session Identifier Set arbitrarily by the querier 308 Traffic Traffic Class being measured 309 Class (TC) Field 310 Timestamp 1-4 64-bit timestamp values (as shown in Figure 2) 311 TLV Block Optional block of Type-Length-Value fields 313 Reserved fields MUST be set to 0 and ignored upon receipt. The 314 possible values for the remaining fields are as follows. 316 Version: Currently set to 1 (to identify definition of TC field in [RFC6374]) 318 Flags: As specified in [RFC6374]. The T flag in a DM message is set to 1. 320 Control Code: As specified in [RFC6374]. 322 Message Length: Set to the total length of this message in bytes, including the 323 Version, Flags, Control Code, and Message Length fields as well as the TLV Block, 324 if any. 326 Querier Timestamp Format: The format of the timestamp values written by the 327 querier, as specified in Section 3.4 of [RFC6374]. 329 Responder Timestamp Format: The format of the timestamp values written by the 330 responder, as specified in Section 3.4 of [RFC6374]. 332 Responder's Preferred Timestamp Format: The timestamp format preferred by the 333 responder, as specified in Section 3.4 of [RFC6374]. 335 Session Identifier: Set arbitrarily in a query and copied in the response, if any. 336 This field uniquely identifies a measurement operation (also called a session) 337 that consists of a sequence of messages. All messages in the sequence have the 338 same Session Identifier [RFC6374]. 340 TC: Traffic Class being measured. 342 Timestamp 1-4 (T1-T4): Referring to Figure 2. 343 The mapping of timestamps to the Timestamp 1-4 fields is designed to ensure that 344 transmit timestamps are always written at the same fixed offset in the packet, and 345 likewise for receive timestamps. This property is important for hardware 346 processing. 348 TLV Block: Zero or more TLV fields. This document assumes the use of the DM 349 message TLV defined in [RFC6374]. 351 3.2.4. One-Way Delay Measurement using Synthetic Probes 353 For delay measurement using synthetic probes, a DM TLV in the SRH to record the 354 timestamps and END.OTP SID as described in the pseudocode in [I-D.draft-filsfils- 355 spring-srv6-network-programming] to punt the packet are used. 357 3.2.4.1. Example Procedure 359 To measure one-way delay from node N1 over an SR Policy that goes through a 360 segment-list (A2::C31, A4::C52) to node N4, following procedure is followed: 362 O Node N1 constructs a DM probe packet with (B1::0, A2::C31)(A4::C52, A2::C31, 363 SL=1; NH=NONE, DM TLV). To punt the DM probe packet at node N4, node N1 inserts 364 the END.OTP SID [I-D.draft-filsfils-spring-srv6-network-programming] just before 365 the target SID A4::C52 in the SRH. Thus, the packet as it leaves node N1 looks 366 like (B1::0, A2::C31)(A4::C52, A4::OTP, A2::C31; SL=2; NH=NONE, DM TLV (with T1 367 from N1)). The PM synthetic probe query message does not contain any payload 368 data. 370 O When node N4 receives the packet (B1::0, A4::OTP)(A4::C52, A4::OTP, A2::C31; 371 SL=1; NH=NONE, DM TLV), it processes the END.OTP SID, as described in the 372 pseudocode in [I-D.draft-filsfils-spring-srv6-network-programming]. In doing so, 373 it punts the timestamped packet (with T2 from N4) to the Performance Measurement 374 (PM) process for processing. 376 The PM process on node N4 responds to the DM probe message as following: 378 O The Source Address object (Type=130) and Destination Address object (Type=129) 379 TLVs [RFC6374] indicate the addresses of the sender and the intended recipient of 380 the PM message, respectively. The Source Address of a query message SHOULD be 381 used as the destination unless an out-of-band response mechanism has been 382 configured such as return controller's address is locally configured. 384 O When a Return Address TLV object (Type=1) [RFC6374] is present in which case 385 the Return Address specifies the target address for the response message. 387 O If the querier node N1 requires the response to be sent to the controller 388 (N100), it adds the target controller's IP address in the Return Address TLV 389 object of the DM message. 391 O For one-way delay measurement, the querier node can send the UDP Return Object 392 (URO) (Type=131) defined in [RFC7867]. From the responder node, the response is 393 sent back to the PM querier node using the UDP Return Object (URO) TLV (Type=131) 394 defined in [RFC7867] when the URO TLV is present in the PM query message. The PM 395 process copies the content of the DM TLV into the payload of the PM reply message. 397 3.2.5. In-situ One-Way Segment-by-Segment Delay Measurement 399 For delay measurement for in-situ with data traffic, a DM TLV in the SRH to record 400 timestamps and O-bit as described in [I-D.draft-filsfils-spring-srv6-network- 401 programming] to punt the packet on every SRv6 nodes are used. 403 3.2.5.1. Example Procedure 405 Consider the case where the user wants to measure one-way delay from node N1 over 406 an SR Policy that goes through a segment-list (A2::C31, A4::C52). However, the 407 user desired to get the delay measurement done in-situ with data traffic on a 408 segment-by-segment basis. 410 O To force a punt of the time-stamped copy of the data packet at node N2 and node 411 N4, node N1 sets the O-bit in SRH at locally configured periodic measurement 412 interval. The packet, as it leaves node 1, looks like (B1::0, A2::C31)(A4::C52, 413 A2::C31; SL=1, Flags.O=1, DM TLV (with T1 from N1), NH=data payload type)(data 414 payload). Here, the data payload refers to the actual data traffic going over the 415 policy whose performance is being measured. Node N1 may optionally punt a time- 416 stamped copy of the packet with T1 to the local PM process. 418 O When node N2 receives the packet (B1::0, A2::C31)(A4::C52, A2::C31; SL=1, 419 Flags.O=1, DM TLV, NH=data payload type)(data payload) packet, it processes the O- 420 bit in SRH, as described in the pseudocode in [I-D.draft-filsfils-spring-srv6- 421 network-programming]. A time-stamped copy of the packet gets punted to the PM 422 process for processing. Node N2 continues to apply the A2::C31 SID function on 423 the original packet and forwards it, accordingly. As SRH.Flags.O=1, Node N2 also 424 disables the PSP flavour, i.e., does not remove the SRH. 426 O The PM process at node N2 sends the copy of the time-stamped packet (with DM 427 TLV containing T1 from N1 and T2 from N2) to a locally configured controller or to 428 the querier. Please note that, as mentioned in [I-D.draft-filsfils-spring-srv6- 429 network-programming], if node N2 does not support the O-bit, it simply ignores it 430 and processes the local SID, A2::C31. In this case, the controller will not get 431 the performance data from the segments with the nodes that do not support the O- 432 bit. 434 O When node N4 receives the packet (B1::0, A4::C52)(A4::C52, A2::C31; SL=0, 435 Flags.O=1, DM TLV (containing T1 from N1); NH=data payload type)(data payload), it 436 processes the O-bit in SRH, as described in the pseudocode in [I-D.draft-filsfils- 437 spring-srv6-network-programming]. A time-stamped copy of the packet gets punted 438 to the PM process for processing. 440 O The PM process at node N2 sends the copy of the time-stamped packet (with DM 441 TLV containing T1 from N1 and T2 from N4) to a locally configured controller. 443 The Controller processes the time-stamped packet from each segment and computes 444 the segment-by-segment one-way delay. Support for O-bit is part of node 445 capability advertisement. That enables node N1 and the controller know which 446 segment nodes are capable of sending time-stamped copy of the packet. 448 4. Security Considerations 450 TBA. 452 5. IANA Considerations 454 IANA is requested to allocate a value for the new SRH TLV Type for Delay 455 Measurement. 457 6. Contributors 459 Faisal Iqbal 460 Cisco Systems, Inc. 461 Email: faiqbal@cisco.com 463 Carlos Pignataro 464 Cisco Systems, Inc. 465 Email: cpignata@cisco.com 467 7. References 469 7.1. Normative References 471 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS 472 Networks", DOI 10.17487/RFC6374, RFC 6374, September 2011. 474 [RFC7876] Bryant, S., Sivabalan, S., and Soni, S., "UDP Return Path for Packet 475 Loss and Delay Measurement for MPLS Networks", RFC 7876, July 2016. 477 [I.D-filsfils-spring-srv6-network-programming] SRv6 Network Programming, draft- 478 filsfils-spring-srv6-network-programming, C. Fisfils, work in 479 progress. 481 7.2. Informative References 483 [I-D.brockners-inband-oam-data] Data Formats for In-situ OAM. F. 484 Brockners, work in progress. 486 [I-D.brockners-inband-oam-transport] Encapsulations for In-situ OAM Data, 487 F.Brockners, work in progress. 489 [I-D.brockners-inband-oam-requirements] Requirements for In-situ OAM, 490 F.Brockners, work in progress. 492 8. Acknowledgments 494 To be added. 496 Authors' Addresses 498 Clarence Filsfils 499 Cisco Systems, Inc. 500 Email: cfilsfil@cisco.com 502 Zafar Ali 503 Cisco Systems, Inc. 504 Email: zali@cisco.com 506 Rakesh Gandhi 507 Cisco Systems, Inc. 508 Email: rgandhi@cisco.com 510 Nagendra Kumar 511 Cisco Systems, Inc. 512 Email: naikumar@cisco.com 514 Dirk Steinberg 515 Steinberg Consulting 516 Germany 517 Email: dws@dirksteinberg.de 519 Stefano Salsano 520 Universita di Roma "Tor Vergata" 521 Italy 522 Email: stefano.salsano@uniroma2.it