idnits 2.17.1 draft-brockners-inband-oam-transport-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 (July 18, 2016) is 2839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.hildebrand-spud-prototype' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'P4' is defined on line 581, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-01 == Outdated reference: A later version (-13) exists of draft-ietf-ippm-6man-pdm-option-03 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Brockners 3 Internet-Draft S. Bhandari 4 Intended status: Informational C. Pignataro 5 Expires: January 19, 2017 Cisco 6 H. Gredler 7 RtBrick Inc. 8 J. Leddy 9 Comcast 10 S. Youell 11 JMPC 12 July 18, 2016 14 Encapsulations for In-band OAM Data 15 draft-brockners-inband-oam-transport-01 17 Abstract 19 In-band operation, administration and maintenance (OAM) records 20 operational and telemetry information in the packet while the packet 21 traverses a path between two points in the network. In-band OAM is 22 to complement current out-of-band OAM mechanisms based on ICMP or 23 other types of probe packets. This document outlines how in-band OAM 24 data records can be transported in protocols such as NSH, Segment 25 Routing, VXLAN-GPE, native IPv6 (via extension header), and IPv4. 26 Transport options are currently investigated as part of an 27 implementation study. This document is intended to only serve 28 informational purposes. 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 http://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 January 19, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. In-Band OAM Metadata Transport in IPv6 . . . . . . . . . . . 4 67 3.1. In-band OAM in IPv6 Hop by Hop Extension Header . . . . . 4 68 3.1.1. In-band OAM Hop by Hop Options . . . . . . . . . . . 4 69 3.1.2. Procedure at the Ingress Edge to Insert the In-band 70 OAM Header . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.3. Procedure at Intermediate Nodes . . . . . . . . . . . 7 72 3.1.4. Procedure at the Egress Edge to Remove the In-band 73 OAM Header . . . . . . . . . . . . . . . . . . . . . 7 74 4. In-band OAM Metadata Transport in VXLAN-GPE . . . . . . . . . 7 75 5. In-band OAM Metadata Transport in NSH . . . . . . . . . . . . 9 76 6. In-band OAM Metadata Transport in Segment Routing . . . . . . 11 77 6.1. In-band OAM in SR with IPv6 Transport . . . . . . . . . . 11 78 6.2. In-band OAM in SR with MPLS Transport . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 11.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 This document discusses transport mechanisms for "in-band" operation, 91 administration, and maintenance (OAM) data records. In-band OAM 92 records OAM information within the packet while the packet traverses 93 a particular network domain. The term "in-band" refers to the fact 94 that the OAM data is added to the data packets rather than is being 95 sent within packets specifically dedicated to OAM. A discussion of 96 the motivation and requirements for in-band OAM can be found in 97 [draft-brockners-inband-oam-requirements]. Data types and data 98 formats for in-band OAM are defined in 99 [draft-brockners-inband-oam-data]. 101 This document outlines transport encapsulations for the in-band OAM 102 data defined in [draft-brockners-inband-oam-data]. This document is 103 to serve informational purposes only. As part of an in-band OAM 104 implementation study different protocol encapsulations for in-band 105 OAM data are being explored. Once data formats and encapsulation 106 approaches are settled, protocol specific specifications for in-band 107 OAM data transport will address the standardization aspect. 109 The data for in-band OAM defined in [draft-brockners-inband-oam-data] 110 can be carried in a variety of protocols based on the deployment 111 needs. This document discusses transport of in-band OAM data for the 112 following protocols: 114 o IPv6 116 o VXLAN-GPE 118 o NSH 120 o Segment Routing (IPv6 and MPLS) 122 This list is non-exhaustive, as it is possible to carry the in-band 123 OAM data in several other protocols and transports. 125 A feasibility study of in-band OAM is currently underway as part of 126 the FD.io project [FD.io]. The in-band OAM implementation study 127 should be considered as a "tool box" to showcase how "in-band" OAM 128 can complement probe-packet based OAM mechanisms for different 129 deployments and packet transport formats. For details, see the open 130 source code in the FD.io [FD.io]. 132 2. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 Abbreviations used in this document: 140 MTU: Maximum Transmit Unit 142 OAM: Operations, Administration, and Maintenance 143 SR: Segment Routing 145 SID: Segment Identifier 147 NSH: Network Service Header 149 POT: Proof of Transit 151 SFC: Service Function Chain 153 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol 154 Extension 156 3. In-Band OAM Metadata Transport in IPv6 158 This mechanisms of in-band OAM in IPv6 complement others proposed to 159 enhance diagnostics of IPv6 networks, such as the IPv6 Performance 160 and Diagnostic Metrics Destination Option described in 161 [I-D.ietf-ippm-6man-pdm-option]. The IP Performance and Diagnostic 162 Metrics Destination Option is destination focused and specific to 163 IPv6, whereas in-band OAM is performed between end-points of the 164 network or a network domain where it is enabled and used. 166 A historical note: The idea of IPv6 route recording was originally 167 introduced by [draft-kitamura-ipv6-record-route] back in year 2000. 168 With IPv6 now being generally deployed and new concepts such as 169 Segment Routing [I-D.ietf-spring-segment-routing] being introduced, 170 it is imperative to further mature the operations, administration, 171 and maintenance mechanisms available to IPv6 networks. 173 The in-band OAM options translate into options for an IPv6 extension 174 header. The extension header would be inserted by either a host 175 source of the packet, or by a transit/domain-edge node. 177 3.1. In-band OAM in IPv6 Hop by Hop Extension Header 179 This section defines in-band OAM for IPv6 transport. In-band OAM 180 data is transported as an IPv6 hop-by-hop extension header. 182 3.1.1. In-band OAM Hop by Hop Options 184 Brief recap of the IPv6 hop-by-hop header as well as the options used 185 for carrying in-band OAM data: 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Next Header | Hdr Ext Len | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 190 | | 191 . . 192 . Options . 193 . . 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 198 | Option Type | Opt Data Len | Option Data 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 201 With 2 highest order bits of Option Type indicating the following: 203 00 - skip over this option and continue processing the header. 205 01 - discard the packet. 207 10 - discard the packet and, regardless of whether or not the 208 packet's Destination Address was a multicast address, send an 209 ICMP Parameter Problem, Code 2, message to the packet's 210 Source Address, pointing to the unrecognized Option Type. 212 11 - discard the packet and, only if the packet's Destination 213 Address was not a multicast address, send an ICMP Parameter 214 Problem, Code 2, message to the packet's Source Address, 215 pointing to the unrecognized Option Type. 217 3rd highest bit: 219 0 - Option Data does not change en-route 221 1 - Option Data may change en-route 223 In-band OAM data records are inserted as options in an IPv6 hop-by- 224 hop extension header: 226 1. Tracing Option: The in-band OAM Tracing option defined in 227 [draft-brockners-inband-oam-data] is represented as a IPv6 option 228 in hop by hop extension header by allocating following type: 230 Option Type: 001xxxxxx 8-bit identifier of the type of option. 231 xxxxxx=TBD_IANA_TRACE_OPTION_IPV6. 233 2. Proof of Transit Option: The in-band OAM POT option defined in 234 [draft-brockners-inband-oam-data] is represented as a IPv6 option 235 in hop by hop extension header by allocating following type: 237 Option Type: 001xxxxxx 8-bit identifier of the type of option. 238 xxxxxx=TBD_IANA_POT_OPTION_IPV6. 240 3. Edge to Edge Option: The in-band OAM E2E option defined in 241 [draft-brockners-inband-oam-data] is represented as a IPv6 option 242 in hop by hop extension header by allocating following type: 244 Option Type: 000xxxxxx 8-bit identifier of the type of option. 245 xxxxxx=TBD_IANA_E2E_OPTION_IPV6. 247 3.1.2. Procedure at the Ingress Edge to Insert the In-band OAM Header 249 In an administrative domain where in-band OAM is used, insertion of 250 the in-band OAM header is enabled at the required edge nodes by means 251 of configuration. 253 Such a config SHOULD allow selective enablement of in-band OAM header 254 insertion for a subset of traffic (e.g., one or several "pipes"). 256 Further the ingress edge node should be aware of maximum size of the 257 header that can be inserted. Details on how the maximum size/size of 258 the in-band OAM domain are retrieved are outside the scope of this 259 document. 261 Let n = max number of nodes to be allocated; 262 (Based on PMTU advertised in the domain) 264 Let k = number of node data that can be allocated by this node 265 Let node_data_size = size of each node_data based on in-band OAM type 267 if (packet matches traffic for which in-band OAM is enabled) { 268 Create in-band OAM hbyh ext header with k node data preallocated 269 Increment payload length in IPv6 header : 270 with size of in-band OAM hbyh ext header 271 Populate node data at : 272 (size of in-band OAM hbyh header = 8) + k * node_data_size 273 from the beginning of the header 274 Set segments left to : k - 1 276 } 278 3.1.3. Procedure at Intermediate Nodes 280 If a network node receives a packet with an in-band OAM header and it 281 is enabled to process in-band OAM data it performs the following: 283 k = number of node data that this node can allocate 284 if (in-band OAM ext hbyh header is present) { 285 if (Segments Left > 0)) { 286 populate node data at : 287 node_data_start[Segments Left] 288 Segments Left = Segments Left - 1 289 } 290 } 292 3.1.4. Procedure at the Egress Edge to Remove the In-band OAM Header 294 egress_edge = list of interfaces where in-band OAM hbyh ext 295 header is to be stripped 296 Before forwarding packet out of interfaces in egress_edge list: 297 if (in-band OAM hbyh ext header is present) { 298 remove the in-band OAM hbyh ext header, 299 possibly store the record along with additional 300 fields for analysis and export 301 Decrement Payload Length in IPv6 header 302 by size of in-band OAM ext header 303 } 305 4. In-band OAM Metadata Transport in VXLAN-GPE 307 VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation is somewhat similar 308 to IPv6 extension headers in that a series of headers can be 309 contained in the header as a linked list. The different in-band OAM 310 types are added as options within a new in-band OAM protocol header 311 in VXLAN GPE. 313 In-band OAM header in VXLAN GPE header: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Outer Ethernet Header | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Outer IP Header | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Outer UDP Header | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 324 |R|R|Ver|I|P|R|O| Reserved | NP = i.b.OAM | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE 326 | Virtual Network Identifier (VNI) | Reserved | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 328 | Type =i.b.OAM | i.b.OAM HDR len | Reserved | NP = IP/Eth | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+iOAM 330 | in-band OAM options | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 332 | | 333 | | 334 | Payload + Padding (L2/L3/ESP/...) | 335 | | 336 | | 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 The VXLAN-GPE header and fields are defined in 341 [I-D.ietf-nvo3-vxlan-gpe]. in-band OAM specific fields and header are 342 defined here: 344 Type: 8-bit unsigned integer defining in-band OAM header type 346 in-band OAM HDR len: 8-bit unsigned integer. Length of the in-band 347 OAM HDR in 8-octet units 349 in-band OAM options: Variable-length field, of length such that the 350 complete in-band OAM header is an integer multiple of 8 octets 351 long. Contains one or more TLV-encoded options of the format: 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 354 | Option Type | Opt Data Len | Option Data 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 357 Option Type 8-bit identifier of the type of option. 359 Opt Data Len 8-bit unsigned integer. Length of the Option 360 Data field of this option, in octets. 362 Option Data Variable-length field. Option-Type-specific 363 data. 365 The in-band OAM options defined in [draft-brockners-inband-oam-data] 366 are encoded with an option type allocated in the new in-band OAM IANA 367 registry - in-band OAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In 368 addition the following padding options are defined to be used when 369 necessary to align subsequent options and to pad out the containing 370 header to a multiple of 8 octets in length. 372 Pad1 option (alignment requirement: none) 374 +-+-+-+-+-+-+-+-+ 375 | 0 | 376 +-+-+-+-+-+-+-+-+ 377 NOTE: The format of the Pad1 option is a special case -- it does 378 not have length and value fields. 380 The Pad1 option is used to insert one octet of padding into the 381 Options area of a header. If more than one octet of padding is 382 required, the PadN option, described next, should be used, rather 383 than multiple Pad1 options. 385 PadN option (alignment requirement: none) 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 388 | 1 | Opt Data Len | Option Data 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 390 The PadN option is used to insert two or more octets of padding 391 into the Options area of a header. For N octets of padding, the 392 Opt Data Len field contains the value N-2, and the Option Data 393 consists of N-2 zero-valued octets. 395 5. In-band OAM Metadata Transport in NSH 397 In Service Function Chaining (SFC) [RFC7665], the Network Service 398 Header (NSH) [I-D.ietf-sfc-nsh] already includes path tracing 399 capabilities [I-D.penno-sfc-trace], but currently does not offer a 400 solution to securely prove that packets really traversed the service 401 chain. The "Proof of Transit" capabilities (see 402 [draft-brockners-inband-oam-requirements] and 403 [draft-brockners-proof-of-transit]) of in-band OAM can be leveraged 404 within NSH. Proof of transit in-band OAM data is added as NSH Type 2 405 metadata: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | TLV Class=Cisco (0x0009) |C| Type=POT |F|R|R| Len=4 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 412 | Random | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 414 | Random(contd) | C 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V 416 | Cumulative | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 418 | Cumulative (contd) | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 421 TLV Class: Describes the scope of the "Type" field. In some cases, 422 the TLV Class will identify a specific vendor, in others, the TLV 423 Class will identify specific standards body allocated types. POT 424 is currently defined using the Cisco (0x0009) TLV class. 426 Type: The specific type of information being carried, within the 427 scope of a given TLV Class. Value allocation is the 428 responsibility of the TLV Class owner. Currently a type value of 429 0x94 is used for proof of transit 431 Reserved bits: Two reserved bit are present for future use. The 432 reserved bits MUST be set to 0x0. 434 F: One bit. Indicates which POT-profile is active. 0 means the even 435 POT-profile is active, 1 means the odd POT-profile is active. 437 Length: Length of the variable metadata, in 4-octet words. Here the 438 length is 4. 440 Random: 64-bit Per packet Random number. 442 Cumulative: 64-bit Cumulative that is updated by the Service 443 Functions. 445 6. In-band OAM Metadata Transport in Segment Routing 447 6.1. In-band OAM in SR with IPv6 Transport 449 Similar to NSH, a service chain or path defined using Segment Routing 450 for IPv6 can be verified using the in-band OAM "Proof of Transit" 451 approach. The Segment Routing Header (SRH) for IPv6 offers the 452 ability to transport TLV structured data, similar to what NSH does 453 (see [I-D.ietf-6man-segment-routing-header]). A new "POT TLV" is 454 defined for the SRH which is to carry proof of transit in-band OAM 455 data. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type | Length | RESERVED |F| Flags | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 462 | Random | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P 464 | Random(contd) | O 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T 466 | Cumulative | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 468 | Cumulative (contd) | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 471 Type: To be assigned by IANA. 473 Length: 18. 475 RESERVED: 8 bits. SHOULD be unset on transmission and MUST be 476 ignored on receipt. 478 F: 1 bit. Indicates which POT-profile is active. 0 means the even 479 POT-profile is active, 1 means the odd POT-profile is active. 481 Flags: 8 bits. No flags are defined in this document. 483 Random: 64-bit per packet random number. 485 Cumulative: 64-bit cumulative value that is updated at specific 486 nodes that form the service path to be verified. 488 6.2. In-band OAM in SR with MPLS Transport 490 In-band OAM "Proof of Transit" data can also be carried as part of 491 the MPLS label stack. Details will be addressed in a future version 492 of this document. 494 7. IANA Considerations 496 IANA considerations will be added in a future version of this 497 document. 499 8. Manageability Considerations 501 Manageability considerations will be addressed in a later version of 502 this document.. 504 9. Security Considerations 506 Security considerations will be addressed in a later version of this 507 document. For a discussion of security requirements of in-band OAM, 508 please refer to [draft-brockners-inband-oam-requirements]. 510 10. Acknowledgements 512 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 513 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 514 Nadahalli, Stefano Previdi and Andrew Yourtchenko for the comments 515 and advice. For the IPv6 encapsulation, this document leverages and 516 builds on top of several concepts described in 517 [draft-kitamura-ipv6-record-route]. The authors would like to 518 acknowledge the work done by the author Hiroshi Kitamura and people 519 involved in writing it. 521 11. References 523 11.1. Normative References 525 [draft-brockners-inband-oam-requirements] 526 Brockners, F., Bhandari, S., and S. Dara, "Requirements 527 for in-band OAM", July 2016. 529 11.2. Informative References 531 [draft-brockners-inband-oam-data] 532 Brockners, F., Bhandari, S., Pignataro, C., and H. 533 Gredler, "Data Formats for in-band OAM", July 2016. 535 [draft-brockners-proof-of-transit] 536 Brockners, F., Bhandari, S., and S. Dara, "Proof of 537 transit", July 2016. 539 [draft-kitamura-ipv6-record-route] 540 Kitamura, H., "Record Route for IPv6 (PR6),Hop-by-Hop 541 Option Extension", November 2000. 543 [FD.io] "Fast Data Project: FD.io", . 545 [I-D.hildebrand-spud-prototype] 546 Hildebrand, J. and B. Trammell, "Substrate Protocol for 547 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 548 prototype-03 (work in progress), March 2015. 550 [I-D.ietf-6man-segment-routing-header] 551 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 552 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 553 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 554 segment-routing-header-01 (work in progress), March 2016. 556 [I-D.ietf-ippm-6man-pdm-option] 557 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com, 558 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 559 Option", draft-ietf-ippm-6man-pdm-option-03 (work in 560 progress), June 2016. 562 [I-D.ietf-nvo3-vxlan-gpe] 563 Kreeger, L. and U. Elzur, "Generic Protocol Extension for 564 VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress), 565 April 2016. 567 [I-D.ietf-sfc-nsh] 568 Quinn, P. and U. Elzur, "Network Service Header", draft- 569 ietf-sfc-nsh-05 (work in progress), May 2016. 571 [I-D.ietf-spring-segment-routing] 572 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 573 and R. Shakir, "Segment Routing Architecture", draft-ietf- 574 spring-segment-routing-09 (work in progress), July 2016. 576 [I-D.penno-sfc-trace] 577 Penno, R., Quinn, P., Pignataro, C., and D. Zhou, 578 "Services Function Chaining Traceroute", draft-penno-sfc- 579 trace-03 (work in progress), September 2015. 581 [P4] Kim, , "P4: In-band Network Telemetry (INT)", September 582 2015. 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, 586 DOI 10.17487/RFC2119, March 1997, 587 . 589 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 590 Chaining (SFC) Architecture", RFC 7665, 591 DOI 10.17487/RFC7665, October 2015, 592 . 594 Authors' Addresses 596 Frank Brockners 597 Cisco Systems, Inc. 598 Hansaallee 249, 3rd Floor 599 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 600 Germany 602 Email: fbrockne@cisco.com 604 Shwetha Bhandari 605 Cisco Systems, Inc. 606 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 607 Bangalore, KARNATAKA 560 087 608 India 610 Email: shwethab@cisco.com 612 Carlos Pignataro 613 Cisco Systems, Inc. 614 7200-11 Kit Creek Road 615 Research Triangle Park, NC 27709 616 United States 618 Email: cpignata@cisco.com 620 Hannes Gredler 621 RtBrick Inc. 623 Email: hannes@rtbrick.com 625 John Leddy 626 Comcast 628 Email: John_Leddy@cable.comcast.com 629 Stephen Youell 630 JP Morgan Chase 631 25 Bank Street 632 London E14 5JP 633 United Kingdom 635 Email: stephen.youell@jpmorgan.com