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

[Spencer Dawkins at IETF <[e-mail]>]

I've read through this thread to the bottom as of the time I'm sending this
note, but just to wrap up my own questions ...

On Feb 9, 2017 11:18, "Carlos Pignataro (cpignata)" <[e-mail]>
wrote:

Thanks, Alvaro.

Hi, Spencer,

Please find some follow-ups inline. Look forward to understanding if they
clarify, or what specific suggestions can make the charter text better.

—
Carlos Pignataro, [e-mail]

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

> On Feb 9, 2017, at 10:57 AM, Alvaro Retana (aretana) <[e-mail]>
wrote:
>
> 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" <
[e-mail] on behalf [e-mail]> 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 <
[e-mail]> 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 <[e-mail]>
>>>
>>> Routing Area Directors:
>>>   Alia Atlas <[e-mail]>
>>>   Alvaro Retana <[e-mail]>
>>>   Deborah Brungard <[e-mail]>
>>>
>>> Mailing list:
>>>   Address: [e-mail]
>>>   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?
>>

In-situ OAM records telemetry information by embedding it into actual data
packets (as opposed to synthetic probes). In that context, I’d say it is
true — however, see below.


The clearest term I've seen pop up in this thread is "user data packets".
I'd suggest that you consider adopting that term.


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

Perhaps “live” is the distractor here. I do wonder if “actual” might make
it clearer.

The challenge is that In-situ OAM is neither “active” not “passive”
measurement.
Passive means ‘solely by observation and without modification to the
packet’ (https://tools.ietf.org/html/draft-ietf-ippm-active-
passive-06#section-3.6).
Active means ‘generating (accompanying / synthetic) packet streams’ (
https://tools.ietf.org/html/draft-ietf-ippm-active-passive-06#section-3.4).

Thus, In-situ OAM is its own class.

Based on this, do you have another recommendation? Does “actual” instead of
“active” make it better?

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

See above.


I'm still confused from the charter text as to whether this effort includes
injected traffic. I'm happy to wait until you folks spin a revision to see
whether I've gotten any smarter :-)


>>> 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?
>>

This is a comprehensive but probably not fully exhaustive list. We could
clarify this.


You might find that helpful. We have a similar list in the QUIC charter,
and people find it tempting to use that list as a filter for what's in
scope for QUIC, so being clear about whether other path attributes are in
scope would likely be helpful for IOAM.


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

Thanks for asking. As you surmised, this is not “transport” in the context
of transport-layer protocols as TCP. In fact, these protocols do not
operate at the same layer (or at a defined model layer).

Perhaps “encapsulation protocols” is best?


I'm not sure whether "encapsulation protocols" is surviving discussion
later in the thread, but I think it's an improvement. Thanks for suggesting
it.


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

I am not sure there is a strong connection to TSVWG — but on the other
hand, it might not hurt to call it out.


I was actually thinking about other reasons to include TSVWG, but just to
cover one question - I'm assuming that adding IOAM attributes to a user
data packet will increase the MTU size. If that's true, that point alone
would make TSVWG awareness worth calling out.

>> Is there any connection with IPPM?

Yes, there is, as already mentioned above.


I see that this linkage is under discussion further down, so I'll comment
there if I have something to contribute.

Thanks for the speedy response!

Spencer

Thanks!

— Carlos.

>>
>>> 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:
> _______________________________________________
> Ioam mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ioam