Network Working Group F. Brockners Internet-Draft S. Bhandari Intended status: Informational C. Pignataro Expires: May 3, 2017 Cisco H. Gredler RtBrick Inc. J. Leddy Comcast S. Youell JMPC T. Mizrahi Marvell D. Mozes Mellanox Technologies Ltd. P. Lapukhov Facebook R. Chang Barefoot Networks October 30, 2016 Encapsulations for In-situ OAM Data draft-brockners-inband-oam-transport-02 Abstract In-situ Operations, Administration, and Maintenance (OAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. In-situ OAM is to complement current out-of-band OAM mechanisms based on ICMP or other types of probe packets. This document outlines how in-situ OAM data records can be transported in protocols such as NSH, Segment Routing, VXLAN-GPE, native IPv6 (via extension headers), and IPv4. Transport options are currently investigated as part of an implementation study. This document is intended to only serve informational purposes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Brockners, et al. Expires May 3, 2017 [Page 1] Internet-Draft In-situ OAM Data Transport October 2016 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. In-Situ OAM Metadata Transport in IPv6 . . . . . . . . . . . 4 3.1. In-situ OAM in IPv6 Hop by Hop Extension Header . . . . . 5 3.1.1. In-situ OAM Hop by Hop Options . . . . . . . . . . . 5 3.1.2. Procedure at the Ingress Edge to Insert the In-situ OAM Header . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Procedure at Transit Nodes . . . . . . . . . . . . . 8 3.1.4. Procedure at the Egress Edge to Remove the In-situ OAM Header . . . . . . . . . . . . . . . . . . . . . 8 4. In-situ OAM Metadata Transport in IPv4 . . . . . . . . . . . 9 5. In-situ OAM Metadata Transport in VXLAN-GPE . . . . . . . . . 9 6. In-situ OAM Metadata Transport in NSH . . . . . . . . . . . . 11 7. In-situ OAM Metadata Transport in Segment Routing . . . . . . 13 7.1. In-situ OAM in SR with IPv6 Transport . . . . . . . . . . 13 7.2. In-situ OAM in SR with MPLS Transport . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Manageability Considerations . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Brockners, et al. Expires May 3, 2017 [Page 2] Internet-Draft In-situ OAM Data Transport October 2016 1. Introduction This document discusses transport mechanisms for "in-situ" Operations, Administration, and Maintenance (OAM) data records. In- situ OAM records OAM information within the packet while the packet traverses a particular network domain. The term "in-situ" refers to the fact that the OAM data is added to the data packets rather than is being sent within packets specifically dedicated to OAM. A discussion of the motivation and requirements for in-situ OAM can be found in [I-D.brockners-inband-oam-requirements]. Data types and data formats for in-situ OAM are defined in [I-D.brockners-inband-oam-data]. This document outlines transport encapsulations for the in-situ OAM data defined in [I-D.brockners-inband-oam-data]. This document is to serve informational purposes only. As part of an in-situ OAM implementation study different protocol encapsulations for in-situ OAM data are being explored. Once data formats and encapsulation approaches are settled, protocol specific specifications for in-situ OAM data transport will address the standardization aspect. The data for in-situ OAM defined in [I-D.brockners-inband-oam-data] can be carried in a variety of protocols based on the deployment needs. This document discusses transport of in-situ OAM data for the following protocols: o IPv6 o IPv4 o VXLAN-GPE o NSH o Segment Routing (IPv6 and MPLS) This list is non-exhaustive, as it is possible to carry the in-situ OAM data in several other protocols and transports. A feasibility study of in-situ OAM is currently underway as part of the FD.io project [FD.io]. The in-situ OAM implementation study should be considered as a "tool box" to showcase how "in-situ" OAM can complement probe-packet based OAM mechanisms for different deployments and packet transport formats. For details, see the open source code in the FD.io [FD.io]. Brockners, et al. Expires May 3, 2017 [Page 3] Internet-Draft In-situ OAM Data Transport October 2016 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Abbreviations used in this document: MTU: Maximum Transmit Unit NSH: Network Service Header OAM: Operations, Administration, and Maintenance POT: Proof of Transit SFC: Service Function Chain SID: Segment Identifier SR: Segment Routing VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol Extension 3. In-Situ OAM Metadata Transport in IPv6 This mechanisms of in-situ OAM in IPv6 complement others proposed to enhance diagnostics of IPv6 networks, such as the IPv6 Performance and Diagnostic Metrics Destination Option described in [I-D.ietf-ippm-6man-pdm-option]. The IP Performance and Diagnostic Metrics Destination Option is destination focused and specific to IPv6, whereas in-situ OAM is performed between end-points of the network or a network domain where it is enabled and used. A historical note: The idea of IPv6 route recording was originally introduced by [I-D.kitamura-ipv6-record-route] back in year 2000. With IPv6 now being generally deployed and new concepts such as Segment Routing [I-D.ietf-spring-segment-routing] being introduced, it is imperative to further mature the Operations, Administration, and Maintenance mechanisms available to IPv6 networks. The in-situ OAM options translate into options for an IPv6 extension header. The extension header would be inserted by either a host source of the packet, or by a transit/domain-edge node. If the addition of the in-situ OAM Hop-by-Hop Option header would lead to the packet exceeding the MTU of the domain an error should be reported. The methods and procedures of how the error is reported Brockners, et al. Expires May 3, 2017 [Page 4] Internet-Draft In-situ OAM Data Transport October 2016 are outside the scope of this document. Likewise if an ICMPv6 forwarding error occurs between encapsulating and decapsulating nodes, the node generating the ICMPv6 error should strip the in-situ OAM Hop-by-Hop Option header before sending the ICMPv6 message to the source. 3.1. In-situ OAM in IPv6 Hop by Hop Extension Header This section defines in-situ OAM for IPv6 transport. In-situ OAM data is transported as an IPv6 hop-by-hop extension header. 3.1.1. In-situ OAM Hop by Hop Options Brief recap of the IPv6 hop-by-hop header as well as the options used for carrying in-situ OAM data: Brockners, et al. Expires May 3, 2017 [Page 5] Internet-Draft In-situ OAM Data Transport October 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - With 2 highest order bits of Option Type indicating the following: 00 - skip over this option and continue processing the header. 01 - discard the packet. 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 3rd highest bit: 0 - Option Data does not change en-route 1 - Option Data may change en-route In-situ OAM data records are inserted as options in an IPv6 hop-by- hop extension header: 1. Tracing Option: The in-situ OAM Tracing option defined in [I-D.brockners-inband-oam-data] is represented as a IPv6 option in hop by hop extension header by allocating following type: Option Type: 001xxxxxx 8-bit identifier of the type of option. xxxxxx=TBD_IANA_TRACE_OPTION_IPV6. Brockners, et al. Expires May 3, 2017 [Page 6] Internet-Draft In-situ OAM Data Transport October 2016 2. Proof of Transit Option: The in-situ OAM POT option defined in [I-D.brockners-inband-oam-data] is represented as a IPv6 option in hop by hop extension header by allocating following type: Option Type: 001xxxxxx 8-bit identifier of the type of option. xxxxxx=TBD_IANA_POT_OPTION_IPV6. 3. Edge to Edge Option: The in-situ OAM E2E option defined in [I-D.brockners-inband-oam-data] is represented as a IPv6 option in hop by hop extension header by allocating following type: Option Type: 000xxxxxx 8-bit identifier of the type of option. xxxxxx=TBD_IANA_E2E_OPTION_IPV6. 3.1.2. Procedure at the Ingress Edge to Insert the In-situ OAM Header In an administrative domain where in-situ OAM is used, insertion of the in-situ OAM header is enabled at the required edge nodes (i.e. at the encapsulating/decapsulating nodes) by means of configuration. Such a configuration SHOULD allow selective enablement of in-situ OAM header insertion for a subset of traffic (e.g., one or several "pipes"). Further the ingress edge node should be aware of maximum size of the header that can be inserted. Details on how the maximum size/size of the in-situ OAM domain are retrieved are outside the scope of this document. Brockners, et al. Expires May 3, 2017 [Page 7] Internet-Draft In-situ OAM Data Transport October 2016 Let n = max number of nodes updating in-situ OAM data; (calculated based on the packet size and the minimal MTU on all links within the OAM domain) Let k = number of node data records that can be allocated by this node. Let node_data_size = size of each node_data based on in-situ OAM type. if (packet matches traffic for which in-situ OAM is enabled) { Create in-situ OAM hbyh ext-header with k node data records preallocated. Increment payload length in IPv6 header: with size of in-situ OAM hbyh ext-header Populate node data at: (size of in-situ OAM hbyh ext-header = 8) + k * node_data_size from the beginning of the header Set Elements-left to: k - 1 Update "Next Header" field in main IPv6 header and set "Next Header" field of OAM hbyh extension header appropriately. } 3.1.3. Procedure at Transit Nodes If a network node receives a packet with an in-situ OAM header and it is enabled to process in-situ OAM data it performs the following: k = number of node data that this node can allocate if (in-situ OAM ext hbyh ext-header is present) { if (Elements-left > 0)) { populate node data at : node_data_start[Elements-left] Elements-left = Elements-left - 1 } } 3.1.4. Procedure at the Egress Edge to Remove the In-situ OAM Header Brockners, et al. Expires May 3, 2017 [Page 8] Internet-Draft In-situ OAM Data Transport October 2016 egress_edge = list of interfaces where in-situ OAM hbyh ext header is to be stripped Before forwarding packet out of interfaces in egress_edge list: if (in-situ OAM hbyh ext-header is present) { remove the in-situ OAM hbyh ext-header, possibly store the record along with additional fields for analysis and export Decrement Payload Length in IPv6 header by size of in-situ OAM ext header Update "Next Header" field in main IPv6 header and set "Next Header" field of OAM hbyh extension header appropriately. } 4. In-situ OAM Metadata Transport in IPv4 Transport of in-situ OAM data in IPv4 will be detailed in a future version of this document. 5. In-situ OAM Metadata Transport in VXLAN-GPE VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation is somewhat similar to IPv6 extension headers in that a series of headers can be contained in the header as a linked list. The different in-situ OAM types are added as options within a new in-situ OAM protocol header in VXLAN GPE. In an administrative domain where in-situ OAM is used, insertion of the in-situ OAM protocol header in VXLAN GPE is enabled at the VXLAN GPE tunnel endpoint which also serve as in-situ OAM encapsulating/decapsulating nodes by means of configuration. Brockners, et al. Expires May 3, 2017 [Page 9] Internet-Draft In-situ OAM Data Transport October 2016 In-situ OAM header in VXLAN GPE header: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Ethernet Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer IP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer UDP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R|R|Ver|I|P|R|O| Reserved | NP = i.s.OAM | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE | Virtual Network Identifier (VNI) | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type =i.s.OAM | i.s.OAM HDR len | Reserved | NP = IP/Eth | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+iOAM | in-situ OAM options | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | | | Payload + Padding (L2/L3/ESP/...) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VXLAN-GPE header and fields are defined in [I-D.ietf-nvo3-vxlan-gpe]. in-situ OAM specific fields and header are defined here: Type: 8-bit unsigned integer defining in-situ OAM header type in-situ OAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR in 8-octet units in-situ OAM options: Variable-length field, of length such that the complete in-situ OAM header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options of the format: Brockners, et al. Expires May 3, 2017 [Page 10] Internet-Draft In-situ OAM Data Transport October 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Option Type 8-bit identifier of the type of option. Opt Data Len 8-bit unsigned integer. Length of the Option Data field of this option, in octets. Option Data Variable-length field. Option-Type-specific data. The in-situ OAM options defined in [I-D.brockners-inband-oam-data] are encoded with an option type allocated in the new in-situ OAM IANA registry - in-situ OAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In addition the following padding options are defined to be used when necessary to align subsequent options and to pad out the containing header to a multiple of 8 octets in length. Pad1 option (alignment requirement: none) +-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+ NOTE: The format of the Pad1 option is a special case -- it does not have length and value fields. The Pad1 option is used to insert one octet of padding into the Options area of a header. If more than one octet of padding is required, the PadN option, described next, should be used, rather than multiple Pad1 options. PadN option (alignment requirement: none) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - The PadN option is used to insert two or more octets of padding into the Options area of a header. For N octets of padding, the Opt Data Len field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. 6. In-situ OAM Metadata Transport in NSH In Service Function Chaining (SFC) [RFC7665], the Network Service Header (NSH) [I-D.ietf-sfc-nsh] already includes path tracing capabilities [I-D.penno-sfc-trace], but currently does not offer a solution to securely prove that packets really traversed the service Brockners, et al. Expires May 3, 2017 [Page 11] Internet-Draft In-situ OAM Data Transport October 2016 chain. The "Proof of Transit" capabilities (see [I-D.brockners-inband-oam-requirements] and [I-D.brockners-proof-of-transit]) of in-situ OAM can be leveraged within NSH. In an administrative domain where in-situ OAM is used, insertion of the in-situ OAM data into the NSH header is enabled at the required nodes (i.e. at the in-situ OAM encapsulating/ decapsulating nodes) by means of configuration. Proof of transit in-situ OAM data is added as NSH Type 2 metadata: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class=Cisco (0x0009) |C| Type=POT |R| Len=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | Random | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P | Random(contd.) | O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T | Cumulative | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Cumulative (contd.) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ TLV Class: Describes the scope of the "Type" field. In some cases, the TLV Class will identify a specific vendor, in others, the TLV Class will identify specific standards body allocated types. POT is currently defined using the Cisco (0x0009) TLV class. Type: The specific type of information being carried, within the scope of a given TLV Class. Value allocation is the responsibility of the TLV Class owner. Currently a type value of 0x94 is used for proof of transit Reserved bits: Two reserved bit are present for future use. The reserved bits MUST be set to 0x0. F: One bit. Indicates which POT-profile is active. 0 means the even POT-profile is active, 1 means the odd POT-profile is active. Length: Length of the variable metadata, in 4-octet words. Here the length is 4. Random: 64-bit Per-packet Random number. Cumulative: 64-bit Cumulative that is updated by the Service Functions. Brockners, et al. Expires May 3, 2017 [Page 12] Internet-Draft In-situ OAM Data Transport October 2016 7. In-situ OAM Metadata Transport in Segment Routing 7.1. In-situ OAM in SR with IPv6 Transport Similar to NSH, a service chain or path defined using Segment Routing for IPv6 can be verified using the in-situ OAM "Proof of Transit" approach. The Segment Routing Header (SRH) for IPv6 offers the ability to transport TLV structured data, similar to what NSH does (see [I-D.ietf-6man-segment-routing-header]). In an domain where in- situ OAM is used, insertion of the in-situ OAM data is enabled at the required edge nodes (i.e. at the in-situ OAM encapsulating/ decapsulating nodes) by means of configuration. A new "POT TLV" is defined for the SRH which is to carry proof of transit in situ OAM data. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | RESERVED |F| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ | Random | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P | Random(contd.) | O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T | Cumulative | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Cumulative (contd.) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ Type: To be assigned by IANA. Length: 18. RESERVED: 8 bits. SHOULD be unset on transmission and MUST be ignored on receipt. F: 1 bit. Indicates which POT-profile is active. 0 means the even POT-profile is active, 1 means the odd POT-profile is active. Flags: 8 bits. No flags are defined in this document. Random: 64-bit per-packet random number. Cumulative: 64-bit cumulative value that is updated at specific nodes that form the service path to be verified. Brockners, et al. Expires May 3, 2017 [Page 13] Internet-Draft In-situ OAM Data Transport October 2016 7.2. In-situ OAM in SR with MPLS Transport In-situ OAM "Proof of Transit" data can also be carried as part of the MPLS label stack. Details will be addressed in a future version of this document. 8. IANA Considerations IANA considerations will be added in a future version of this document. 9. Manageability Considerations Manageability considerations will be addressed in a later version of this document.. 10. Security Considerations Security considerations will be addressed in a later version of this document. For a discussion of security requirements of in-situ OAM, please refer to [I-D.brockners-inband-oam-requirements]. 11. Acknowledgements The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker, and Andrew Yourtchenko for the comments and advice. For the IPv6 encapsulation, this document leverages and builds on top of several concepts described in [I-D.kitamura-ipv6-record-route]. The authors would like to acknowledge the work done by the author Hiroshi Kitamura and people involved in writing it. 12. References 12.1. Normative References [I-D.brockners-inband-oam-requirements] Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Gredler, H., Leddy, J., and S. Youell, "Requirements for In-band OAM", draft-brockners-inband-oam-requirements-01 (work in progress), July 2016. 12.2. Informative References [FD.io] "Fast Data Project: FD.io", . Brockners, et al. Expires May 3, 2017 [Page 14] Internet-Draft In-situ OAM Data Transport October 2016 [I-D.brockners-inband-oam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., and S. Youell, "Data Formats for In-band OAM", draft-brockners-inband-oam-data-01 (work in progress), July 2016. [I-D.brockners-proof-of-transit] Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Leddy, J., and S. Youell, "Proof of Transit", draft- brockners-proof-of-transit-01 (work in progress), July 2016. [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- segment-routing-header-02 (work in progress), September 2016. [I-D.ietf-ippm-6man-pdm-option] Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", draft-ietf-ippm-6man-pdm-option-06 (work in progress), September 2016. [I-D.ietf-nvo3-vxlan-gpe] Kreeger, L. and U. Elzur, "Generic Protocol Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress), April 2016. [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-10 (work in progress), September 2016. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-09 (work in progress), July 2016. [I-D.kitamura-ipv6-record-route] Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop Option Extension", draft-kitamura-ipv6-record-route-00 (work in progress), November 2000. [I-D.penno-sfc-trace] Penno, R., Quinn, P., Pignataro, C., and D. Zhou, "Services Function Chaining Traceroute", draft-penno-sfc- trace-03 (work in progress), September 2015. Brockners, et al. Expires May 3, 2017 [Page 15] Internet-Draft In-situ OAM Data Transport October 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/ RFC7665, October 2015, . Authors' Addresses Frank Brockners Cisco Systems, Inc. Hansaallee 249, 3rd Floor DUESSELDORF, NORDRHEIN-WESTFALEN 40549 Germany Email: fbrockne@cisco.com Shwetha Bhandari Cisco Systems, Inc. Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Email: shwethab@cisco.com Carlos Pignataro Cisco Systems, Inc. 7200-11 Kit Creek Road Research Triangle Park, NC 27709 United States Email: cpignata@cisco.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com Brockners, et al. Expires May 3, 2017 [Page 16] Internet-Draft In-situ OAM Data Transport October 2016 John Leddy Comcast Email: John_Leddy@cable.comcast.com Stephen Youell JP Morgan Chase 25 Bank Street London E14 5JP United Kingdom Email: stephen.youell@jpmorgan.com Tal Mizrahi Marvell 6 Hamada St. Yokneam 20692 Israel Email: talmi@marvell.com David Mozes Mellanox Technologies Ltd. Email: davidm@mellanox.com Petr Lapukhov Facebook 1 Hacker Way Menlo Park, CA 94025 US Email: petr@fb.com Remy Chang Barefoot Networks 2185 Park Boulevard Palo Alto, CA 94306 US Brockners, et al. Expires May 3, 2017 [Page 17]