Subject: [Ioam] Updated Draft Charter

From: Tal Mizrahi <[email-masked]>
Date: Tue, 7 Feb 2017 16:17:15 +0000

Hi,

An updated draft charter can be found below. The draft has been updated based on the comments received on the mailing list in the last few days.
Many thanks to Shwetha and Frank for ironing out the text.

Comments will be welcome.

Cheers,
Tal.

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 within live 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. It should be possible to control the information that gets recorded in data-records.
* 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.
* Management and control of role of nodes for in-situ OAM operation, dynamic control of in-situ OAM data collected in the data records, data export optimization.

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).
* Configuration and operational data models for controlling in-situ OAM data and operations.
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) like NVO3, SFC, 6man, MPLS etc in consultation with the IOAM working group documents. IOAM WG exclusively focuses on mechanisms which piggyback OAM-related metadata onto en-route traffic for OAM purposes. Other ongoing OAM-related efforts in working groups(s) such as MPLS and IPPM that do not piggyback information onto the live user data traffic are out of scope of the IOAM WG.

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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 8 Feb 2017 10:07:03 -0500

Doesn't there need to be some discussion in the charter of the 
constraints within which this work is to be done?  As written, this 
would sem to allow any and all mechanisms, withour\t regard to issues 
such as MTU, complexity of expanding or contracting packets, exposure of 
information across administrative boundaries, or any of the other real 
world constraints which will affect the utility and deployability of 
this work.

Yours,
Joel

On 2/7/17 11:17 AM, Tal Mizrahi wrote:
> Hi,
>
>
>
> An updated draft charter can be found below. The draft has been updated
> based on the comments received on the mailing list in the last few days.
>
> In-situ OAM provides real-time telemetry of individual data packets and
> flows. It is based on telemetry information which is embedded within
> live 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. It should be possible to control the
> information that gets recorded in data-records.
>
> * 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.
>
> * Management and control of role of nodes for in-situ OAM operation,
> dynamic control of in-situ OAM data collected in the data records, data
> export optimization.
>
>
>
> * 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) like NVO3, SFC, 6man, MPLS etc in consultation with the IOAM
> working group documents. IOAM WG exclusively focuses on mechanisms which
> piggyback OAM-related metadata onto en-route traffic for OAM purposes.
> Other ongoing OAM-related efforts in working groups(s) such as MPLS and
> IPPM that do not piggyback information onto the live user data traffic
> are out of scope of the IOAM WG.
>
>
>
> Milestones
>
>
>
> _______________________________________________
> Ioam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ioam
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 8 Feb 2017 15:31:59 +0000

Hi, Joel,

This is a good point. Most of those considerations are under the 'Scope of in-situ OAM operation’ heading already, as operational considerations.

I would not mind being a tad more prescriptive; perhaps we can add that “Specifically, the procedures list and evaluate considerations and constrains imposed due to MTU and packet sizes, as well as domain boundary implications.”

Or are you thinking about codifying more specifics in the charter itself? I think adding such a sentence would close any potential wedge in the charter, but otherwise can you share more specifics?

Thanks!

—
Carlos Pignataro, [email-masked]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

> On Feb 8, 2017, at 10:07 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Doesn't there need to be some discussion in the charter of the constraints within which this work is to be done?  As written, this would sem to allow any and all mechanisms, withour\t regard to issues such as MTU, complexity of expanding or contracting packets, exposure of information across administrative boundaries, or any of the other real world constraints which will affect the utility and deployability of this work.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 8 Feb 2017 10:41:33 -0500

My concern with the existing sentence is that it reads mor elike "we 
will find a way around these issues" rather than "these are real world 
constraints and we have to recognize them."
Thus, I like your proposed text better as it recognize constraints and 
implications, not just problems to be worked around.

I think it would be helpful to note these constraints and implications 
in the section before the list of things to be defined, as that would 
make it clear that this relates to all of the deliverables.

Yours,
Joel

On 2/8/17 10:31 AM, Carlos Pignataro (cpignata) wrote:
> Hi, Joel,
>
> This is a good point. Most of those considerations are under the
> 'Scope of in-situ OAM operation’ heading already, as operational
> considerations.
>
> I would not mind being a tad more prescriptive; perhaps we can add
> that “Specifically, the procedures list and evaluate considerations
> and constrains imposed due to MTU and packet sizes, as well as domain
> boundary implications.”
>
> Or are you thinking about codifying more specifics in the charter
> itself? I think adding such a sentence would close any potential
> wedge in the charter, but otherwise can you share more specifics?
>
> Thanks!
>
> — Carlos Pignataro, [email-masked]
>
>> would sem to allow any and all mechanisms, withour\t regard to
>> issues such as MTU, complexity of expanding or contracting packets,
>> exposure of information across administrative boundaries, or any of
>> the other real world constraints which will affect the utility and
>> deployability of this work.
>>
>> Yours, Joel
>>
>>> An updated draft charter can be found below. The draft has been
>>> updated based on the comments received on the mailing list in the
>>> last few days.
>>>
>>> In-situ OAM provides real-time telemetry of individual data
>>> packets and flows. It is based on telemetry information which is
>>> embedded within live 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.
>>>
>>>
>>>
>>> application-defined metadata. In-situ OAM data-records are
>>> defined using an in-situ OAM namespace. It should be possible to
>>> control the information that gets recorded in data-records.
>>>
>>> * 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.
>>>
>>> * Management and control of role of nodes for in-situ OAM
>>> operation, dynamic control of in-situ OAM data collected in the
>>> data records, data export optimization.
>>>
>>>
>>>
>>> * 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) like NVO3, SFC, 6man, MPLS etc in
>>> consultation with the IOAM working group documents. IOAM WG
>>> exclusively focuses on mechanisms which piggyback OAM-related
>>> metadata onto en-route traffic for OAM purposes. Other ongoing
>>> OAM-related efforts in working groups(s) such as MPLS and IPPM
>>> that do not piggyback information onto the live user data
>>> traffic are out of scope of the IOAM WG.
>>>
>>>
>>>
>>> Milestones
>>>
>>>
>>>
>>> _______________________________________________ Ioam mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/ioam
>>>
>>
>> _______________________________________________ Ioam mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/ioam
>