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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Stephen,

These are important questions — please find some early thoughts inline.

> On Feb 9, 2017, at 5:38 PM, Alvaro Retana (aretana) <[e-mail]> wrote:
> 
> Stephen:
>  
> Hi!
>  
> I think tricky, but important.  I’m cc’ing the list to get the answers there.
>  
> To your second question.  Yes, there clearly is an expectation on the outcome, if IPv6 is used as an encapsulating protocol.  But that is not the only application.
>  
> Thanks!
>  
> Alvaro.
>  
>> On 2/9/17, 3:15 PM, "iesg on behalf of Stephen Farrell" <[e-mail] on behalf [e-mail]> wrote:
>>  
>>  
>> Hiya,
>>  
>> I have two possibly tricky questions about this:
>>  
>> 1) I'm sure there are good things one can do with such
>> marking, but it is very unclear to me how this proposal
>> doesn't also fall afoul of all the privacy downsides of
>> the SPUD/PLUS proposal. My understanding of those privacy
>> downsides was that any generic/extensible marking scheme
>> (whether of packets or transport connections/flows) could
>> easily be abused in many privacy unfriendly ways. Note
>> that I'm not claiming there is IETF consensus on that
>> but I do claim it was a significant issue for SPUD/PLUS
>> and would like to know why (and hope) it is not an issue
>> here. Can someone help me understand what's different here
>> so we avoid that same kind of mega-debate?
>>  

Note that this proposal concerns itself with OAM information, and not as a generic container for all-things. It is not for application information.

Further, as per its charter, it is also constrained in deployment and not a full Internet scope: “ In-Situ OAM operations are defined for a specific operational domain."

That said, I am not too familiar with the depths of the SPUD/PLUS debate or its outcomes. Can you share some pointers or explain how you see the intersection or concern?

>> 2) There is an ongoing and seemingly very hard to resolve
>> discussion [1] on [e-mail] in which a draft related to
>> this proposal has been quoted [2] as evidence on one side
>> of the argument. I'm not clear that we should go ahead with
>> this charter before we have established IETF consensus
>> one way or another about what we think about [1] (by which
>> I specifically mean the issue of headers being processed
>> away from the endpoints). If I'm right that these are
>> related (and it's possible I'm entirely wrong;-) then I
>> guess depending on the outcome of [1] that'd either mean
>> a short delay for this, or else a need for some major
>> change and that risk would seem to me to justify not
>> forging ahead with this just yet. So the question is:
>> am I right that this proposal assumes one outcome of
>> the discussion about header processing in [1]?
>>  

This proposal does not assume one outcome, nor it places a dependency on one. This proposal aims at a number of encapsulations, one of which is IPv6.

Thanks!

— Carlos.

>> Cheers,
>> S.
>>  
>> PS: I'm fine to ask these two questions in a ballot if that's
>> better. But at the moment that'd likely be a BLOCK ballot
>> so I wanted to check first if I'm off base, as happens now
>> and then:-)
>>  
>>  
>> [1] https://www.ietf.org/mail-archive/web/ietf/current/msg100960.html
>> [2] https://www.ietf.org/mail-archive/web/ietf/current/msg101012.html
>>  
>>  
>> On 08/02/17 18:32, IETF Secretariat 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. 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
>>> Milestones:
>>  
>>  
> _______________________________________________
> Ioam mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ioam