Subject: [Ioam] Draft charter for in-situ OAM (IOAM) working group

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 30 Jan 2017 18:25:21 +0000

Following the discussions and general support of in-situ OAM on the OPSAWG mailing list and the guidance from Ops and Routing ADs, we are to propose a dedicated working group to progress normative work on in-situ OAM. Below you'll find a first draft of a working group charter for an in-situ OAM WG that several of us drafted. The scope is intentionally crisp and focused, so that we can built on the past discussions and work as well as make quick progress.

We appreciate your thoughts and comments.

Regards, Frank, Tal, Shwetha, Carlos

IOAM working group charter
In-situ OAM provides real-time telemetry of individual data packets and flows. It is based on telemetry information which is embedded along within data packets. The IOAM WG intends to define data formats and associated procedures for in-situ OAM, including mechanisms for capturing path and path-traversal related information as well as procedures to employ, configure, trigger, and export the embedded telemetry information.

The IOAM WG will define the following in-situ OAM components:

* Data-records for in-situ OAM to cover path-tracing and path verification information (node-ids, ingress/egress interfaces), timestamps, transit-delay, transit jitter, sequence numbers, application-defined metadata. In-situ OAM data-records are defined using an in-situ OAM namespace.
* Procedures to add, update, remove, retrieve and export data-records for in-situ OAM to live traffic and active probing.  In case of live traffic a classifier to select subset of live traffic for addition, update, removal and retrieval of in-situ OAM data-records. In case of active probing procedure to return the in-situ OAM data records to the source of the probe.
*  Scope of in-situ OAM operation. In-Situ OAM operations are defined for a specific operational domain. In-situ OAM data-records are added and removed at domain boundaries and updated by nodes within the in-situ OAM domain. Procedure to deal with various challenges in packet forwarding and error handling such as ECMP processing, path MTU and ICMP message handling when in-situ OAM is enabled in an in-situ OAM domain.
*  Data-records for in-situ OAM are to be defined in a way that makes them independent from the transport protocol used. Data-records for in-situ OAM will need to be embedded into transport protocols such as IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve.
* Procedures and data-records optimized for software dataplane and hardware dataplane implementations of in-situ OAM.
* In-situ OAM to support layering. If several transport protocols (e.g. in case of tunneling) are stacked on top of each other, in-situ OAM data-records could be present in every transport protocol layer.

The IOAM working group intends to work on and publish:
* Definition of the data-type formats used in in-situ OAM and namespaces for in-situ OAM.
* Definition of procedures that in-situ OAM enabled nodes will perform on data traffic that carries in-situ OAM information (e.g., introducing, removing, processing, modifying, and exporting the telemetry information from the associated data packets).
In-situ OAM data records could be embedded into a variety of transports. The transports are expected to be defined in the respective working group(s) in consultation with the IOAM working group documents.

Milestones

April 2018 - submit data format and associated procedures document to IESG.
March 2018 - WGLC for data format and associated procedures document.
April 2017 - working group adoption of data format and associated procedures document.

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 31 Jan 2017 20:48:49 +0100

inline
On 30/01/2017 19:25, Frank Brockners (fbrockne) wrote:
> In-situ OAM provides real-time telemetry of individual data packets and flows. It is based on telemetry information which is 
> embedded along within data packets. The IOAM WG intends to define data formats and associated procedures for in-situ OAM, 
> including mechanisms for capturing path and path-traversal related information as well as procedures to employ, configure, 
> trigger, and export the embedded telemetry information.
>
> * Data-records for in-situ OAM to cover path-tracing and path verification information (node-ids, ingress/egress interfaces), 
> timestamps, transit-delay, transit jitter, sequence numbers, application-defined metadata. In-situ OAM data-records are defined 
> using an in-situ OAM namespace.
>
> * Procedures to add, update, remove, retrieve and export data-records for in-situ OAM to live traffic and active probing.  In case 
> of live traffic a classifier to select subset of live traffic for addition, update, removal and retrieval of in-situ OAM 
> data-records. In case of active probing procedure to return the in-situ OAM data records to the source of the probe.
>
> *  Scope of in-situ OAM operation. In-Situ OAM operations are defined for a specific operational domain. In-situ OAM data-records 
> are added and removed at domain boundaries and updated by nodes within the in-situ OAM domain. Procedure to deal with various 
> challenges in packet forwarding and error handling such as ECMP processing, path MTU and ICMP message handling when in-situ OAM is 
> enabled in an in-situ OAM domain.
>
> *  Data-records for in-situ OAM are to be defined in a way that makes them independent from the transport protocol used. 
> Data-records for in-situ OAM will need to be embedded into transport protocols such as IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, 
> Geneve.
>
Mmmm... why LISP? As far as I can tell, LISP IETF documents are all experimental or informational !!??
Correct me if I am wrong.

NSH is NFC Service Header. Is that then a protocol ??

Geneve is a tunnelling protocol/mechanism.

So are other tunneling protocols excluded?

Would it be better to use generic "tunneling protocols" ??

Bert
> * In-situ OAM to support layering. If several transport protocols (e.g. in case of tunneling) are stacked on top of each other, 
> in-situ OAM data-records could be present in every transport protocol layer.
>
> * Definition of procedures that in-situ OAM enabled nodes will perform on data traffic that carries in-situ OAM information (e.g., 
> introducing, removing, processing, modifying, and exporting the telemetry information from the associated data packets).
>
> In-situ OAM data records could be embedded into a variety of transports. The transports are expected to be defined in the 
> respective working group(s) in consultation with the IOAM working group documents.
>
> Milestones
>
> _______________________________________________
> Ioam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ioam

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Jan 2017 16:48:05 -0500

On Tue, Jan 31, 2017 at 2:48 PM, Bert Wijnen (IETF) <[email-masked]>
wrote:

>> In-situ OAM provides real-time telemetry of individual data packets and
>> flows. It is based on telemetry information which is embedded along within
>> data packets. The IOAM WG intends to define data formats and associated
>> procedures for in-situ OAM, including mechanisms for capturing path and
>> path-traversal related information as well as procedures to employ,
>> configure, trigger, and export the embedded telemetry information.
>>
>> * Data-records for in-situ OAM to cover path-tracing and path
>> verification information (node-ids, ingress/egress interfaces), timestamps,
>> transit-delay, transit jitter, sequence numbers, application-defined
>> metadata. In-situ OAM data-records are defined using an in-situ OAM
>> namespace.
>>
>> * Procedures to add, update, remove, retrieve and export data-records for
>> in-situ OAM to live traffic and active probing.  In case of live traffic a
>> classifier to select subset of live traffic for addition, update, removal
>> and retrieval of in-situ OAM data-records. In case of active probing
>> procedure to return the in-situ OAM data records to the source of the probe.
>>
>> *  Scope of in-situ OAM operation. In-Situ OAM operations are defined for
>> a specific operational domain. In-situ OAM data-records are added and
>> removed at domain boundaries and updated by nodes within the in-situ OAM
>> domain. Procedure to deal with various challenges in packet forwarding and
>> error handling such as ECMP processing, path MTU and ICMP message handling
>> when in-situ OAM is enabled in an in-situ OAM domain.
>>
>> *  Data-records for in-situ OAM are to be defined in a way that makes
>> them independent from the transport protocol used. Data-records for in-situ
>> OAM will need to be embedded into transport protocols such as IPv4, IPv6,
>> VXLAN-GPE, LISP, NSH, SRv6, Geneve.
>>

LISP is chartered to produce standards track documents now.

> NSH is NFC Service Header. Is that then a protocol ??

No - it's coming from SFC and is "transport-agnostic" so it can run inside
anything from UDP to MPLS to Ethernet.  The details of which transports are
likely hasn't really been discussed.

> Geneve is a tunnelling protocol/mechanism.

Both Geneve and VXLAN-GPE, as currently described in NVO3, are unlikely to
progress to be published
as standards track documents.  NVO3 currently has a design team that is
coming up with a merged solution
that is intended to progress.  Obviously, a charter needs to consider
carefully what work is intended as standards track.

> Would it be better to use generic "tunneling protocols" ??

It's likely and possible that there may be differences - both in terms of
what data-records might be carried and in terms of how the packets are
carried.  I don't think an open charter that supports any tunneling
protocol is likely to be beneficial for focus.

Regards,
Alia

> Bert
>
>>
>> * Procedures and data-records optimized for software dataplane and
>> hardware dataplane implementations of in-situ OAM.
>>
>> * In-situ OAM to support layering. If several transport protocols (e.g.
>> in case of tunneling) are stacked on top of each other, in-situ OAM
>> data-records could be present in every transport protocol layer.
>>
>> * Definition of procedures that in-situ OAM enabled nodes will perform on
>> data traffic that carries in-situ OAM information (e.g., introducing,
>> removing, processing, modifying, and exporting the telemetry information
>> from the associated data packets).
>>
>> In-situ OAM data records could be embedded into a variety of transports.
>> The transports are expected to be defined in the respective working
>> group(s) in consultation with the IOAM working group documents.
>>
>> Milestones
>>