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

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, carlos@cisco.com

“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) <aretana@cisco.com> 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" <iesg-bounces@ietf.org on behalf ofspencerdawkins.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> 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>
>>> 
>>> Routing Area Directors:
>>>   Alia Atlas <akatlas@gmail.com>
>>>   Alvaro Retana <aretana@cisco.com>
>>>   Deborah Brungard <db3546@att.com>
>>> 
>>> Mailing list:
>>>   Address: 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? 
>>  

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.

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

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

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

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

>> Is there any connection with IPPM?

Yes, there is, as already mentioned above.

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
> Ioam@ietf.org
> https://www.ietf.org/mailman/listinfo/ioam