Re: [Ioam] Internal WG Review: In-situ OAM (ioam)

Spencer:

Hi!  I’m cc’ing the list to get feedback from them.

Thanks for your comments!

Alvaro.

On 2/8/17, 2:32 PM, "iesg on behalf of Spencer Dawkins at IETF" <iesg-bounces@ietf.org<mailto:iesg-bounces@ietf.org> on behalf of spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>> wrote:

So, thinking about this some more ...

Most of what follows is questions, so you may be educating me in most of the cases, instead of changing text in the proposed charter.

On Wed, Feb 8, 2017 at 12:32 PM, IETF Secretariat <ietf-secretariat-reply@ietf.org<mailto:ietf-secretariat-reply@ietf.org>> wrote:

A new IETF WG is being considered in the IETF. The draft charter for this
WG is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

In-situ OAM (ioam)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  TBD

Assigned Area Director:
  Alvaro Retana <aretana@cisco.com<mailto:aretana@cisco.com>>

Routing Area Directors:
  Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>>
  Alvaro Retana <aretana@cisco.com<mailto:aretana@cisco.com>>
  Deborah Brungard <db3546@att.com<mailto:db3546@att.com>>

Mailing list:
  Address: ioam@ietf.org<mailto:ioam@ietf.org>
  To subscribe: https://www.ietf.org/mailman/listinfo/ioam
  Archive: https://mailarchive.ietf.org/arch/browse/ioam/

Charter: https://datatracker.ietf.org/doc/charter-ietf-ioam/

In-situ OAM provides real-time telemetry of individual data packets and
flows.

Is it true to say that In-situ OAM provides real-time telemetry of individual data packets and flows, based on information embedded within live data packets?

I'm reading the current text as saying that this can do OAM for an individual packet. I don't even know what that means.

I'm not quite sure I understand what a "live" data packet is. Is the point that this isn't injecting measurement traffic (so, "passive", rather than "active" - or is the text calling that "active probing")? But I'm guessing.

It is based on telemetry information which is embedded within live
data packets.

There's a mention of "active probing" further down. You might want to bring that up here, to help the reader understand the scope of the work.

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.

Is this intended to be an exhaustive list? I'm guessing that "application-defined metadata" is probably open-ended ... but whether that's true or not, is the working group allowed to define in-situ OAM that covers more than these named path attributes?

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.

Is "transport protocol" the best term here?

I'm not objecting to this because we're not talking about TCP :-) - I'm asking because I don't know what this text is telling me about these protocols.

If that's the clearest term for this problem domain, that's fine, but I had to ask.

* 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.

It may be useful to call out TSVWG, because they've been consulting on various tunneling protocols.

Is there any connection with IPPM?

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

Milestones: