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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 9 Feb 2017 15:57:00 +0000

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" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>

Routing Area Directors:
  Alia Atlas <[email-masked]<mailto:[email-masked]>>
  Alvaro Retana <[email-masked]<mailto:[email-masked]>>
  Deborah Brungard <[email-masked]<mailto:[email-masked]>>

Mailing list:
  Address: [email-masked]<mailto:[email-masked]>
  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:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 9 Feb 2017 17:18:13 +0000

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, [email-masked]

“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) <[email-masked]> wrote:
> 
> Spencer:
>  
>> On 2/8/17, 2:32 PM, "iesg on behalf of Spencer Dawkins at IETF" <[email-masked] on behalf [email-masked]> wrote:
>>  
>> On Wed, Feb 8, 2017 at 12:32 PM, IETF Secretariat <[email-masked]> wrote:
>>> 
>>> 
>>>   Alvaro Retana <[email-masked]>
>>> 
>>> Routing Area Directors:
>>>   Alia Atlas <[email-masked]>
>>>   Alvaro Retana <[email-masked]>
>>>   Deborah Brungard <[email-masked]>
>>> 
>>> Mailing list:
>>>   Address: [email-masked]

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

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?

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

>> 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-sit…

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

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

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

> _______________________________________________
> Ioam mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ioam

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 9 Feb 2017 18:50:42 +0000

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

Carlos, that is not quit where we are going with passive. We use packet 
marking to batch the packets for loss measurement, and we are planning 
to trigger delay/jitter measurement through marking.

As you know marking is much easier in MPLS that IP.

I think the key distinguisher is really that in-situ is about embedding 
OAM meta-data in user data traffic.

- Stewart

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 9 Feb 2017 19:30:57 +0000

Hi, Stewart,

Many thanks for the comments, please see inline.

> On Feb 9, 2017, at 1:50 PM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> Carlos, that is not quit where we are going with passive. We use packet marking to batch the packets for loss measurement, and we are planning to trigger delay/jitter measurement through marking.
> 

I’ll follow down this tangent for a bit. 

I understand and as you know I’m well aware of the (alternate) packet marking techniques and different methods.

However, the *current* definition is quite unambiguous:

https://tools.ietf.org/html/rfc7799#section-3.6
“
3.6.  Passive Methods

   Passive Methods of Measurement are:

   o  based solely on observations of an undisturbed and unmodified
      packet stream of interest (in other words, the method of
      measurement MUST NOT add, change, or remove packets or fields or
      change field values anywhere along the path).
“

Since both those datapoints are rooted in IPPM, I’d suggest working through the definitions on IPPM and how marking fits (since it is not only on observation points)

Now, bringing this back to the relevance of the In-situ OAM (ioam) charter, my only point is that In-situ OAM is neither passive nor active.

> I think the key distinguisher is really that in-situ is about embedding OAM meta-data in user data traffic.

This is a good point.

I agree.

I believe this is already clear in the charter, all the way from the very first sentence:

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

Do you believe this is not clear in the charter? Do you have specific suggestions or concrete recommendations that can improve the charter text?

Thanks!

—

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 9 Feb 2017 22:38:45 +0000

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" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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?

2) There is an ongoing and seemingly very hard to resolve
discussion [1] on [email-masked]<mailto:[email-masked]> 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]?

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:

Mailing list:
flows. It is based on telemetry information which is embedded within live
data packets. The IOAM WG intends to define data formats and associated

application-defined metadata. In-situ OAM data-records are defined using

Milestones

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 10 Feb 2017 09:32:31 +0000

> Now, bringing this back to the relevance of the In-situ OAM (ioam) charter, my only point is that In-situ OAM is neither passive nor active.

... and the point I make is that packet marking (which I think we have 
established is the only viable way of making accurate loss measurements 
in connectionless networking) is also neither active of passive 
according to these definitions.

> Do you believe this is not clear in the charter? Do you have specific suggestions or concrete recommendations that can improve the charter text?

I suppose you could say: It is based on telemetry information which is 
embedded within live data packets and is distinct from packet parking 
methods being developed elsewhere in the IETF.

I have not thought it through, but I am wondering what distinguishes the 
packet types you list (IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve) 
from other packet types, the obvious one being MPLS. Not that I am at 
all keen on trying to get this into the simple fast forwarders we use 
for MPLS. In other words what is the generic class of packets you are 
targetting?

Stewart

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 10 Feb 2017 12:58:05 +0100

Hi all,

as a side notice: marking is define as hybrid measurement in the already cited IPPM RFC 7799:

"Augmentation or modification of the stream of interest, or
      employment of methods that modify the treatment of the stream =>
      Hybrid Type I“

Mirja

> Am 10.02.2017 um 10:32 schrieb Stewart Bryant <[email-masked]>:
> 
> 
> 
> ... and the point I make is that packet marking (which I think we have established is the only viable way of making accurate loss measurements in connectionless networking) is also neither active of passive according to these definitions.
> 
>> 
> I suppose you could say: It is based on telemetry information which is embedded within live data packets and is distinct from packet parking methods being developed elsewhere in the IETF.
> 
> I have not thought it through, but I am wondering what distinguishes the packet types you list (IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve) from other packet types, the obvious one being MPLS. Not that I am at all keen on trying to get this into the simple fast forwarders we use for MPLS. In other words what is the generic class of packets you are targetting?
> 
> Stewart
> 
>> 
>> Thanks!
>> 
>>> - Stewart
>> 
>> —

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 10 Feb 2017 13:10:12 +0100

Hi all,

also one more comment on this point:

> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata) <[email-masked]>:
> 

The charter currently says:

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

which indictates that cooperation with IPPM is not planned.

To me in general the relation between this work and other ongoing work in the IETF is not very clear and IPPM has several documents and milestones that are in scope for this work:

- Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option (this draft is mainly done and silenter the publication process soon to my understanding)

- Submit an Experimental draft on coloring-based hybrid measurement methodologies for loss and delay to the IESG: draft-ietf-ippm-alt-mark-03

I don’t think that the assessment in the charter that IPPM's scope does not include piggybacked information is correct. Looking at draft-brockners-inband-oam-transport-02, I think that any work on IPV6 and IPv6 in this scope should be done in IPPM because that’s were this work is already on-going and where the measurement expertise is.

Mirja

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Fri, 10 Feb 2017 13:38:55 +0000

Hi Mirja,

you raise an interesting point. The IPPM charter states  " Specifying network or lower layer OAM mechanisms is out of scope of the IPPM charter.", whereas the WG has " Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM) Destination Option as Proposed Standard 
draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that we'd likely qualify IPv6 as a transport protocol... 

So far I understood the main focus of the new IOAM WG to be network-layer focused, i.e. piggyback OAM-meta-data onto network-layer protocols - but that does not necessarily need to be always the case as you implicitly highlight by drawing the link to IPPM. One could also do so using e.g. TCP options. I did not read the statement on IPPM in the draft charter as "not cooperating with IPPM" - I read it in a way that methods that do not piggyback information on live traffic are not considered in IOAM. That said, especially when it comes to export and interpretation of in-situ OAM data, there might indeed be common ground between IOAM and IPPM.

How about we add another sentence to the charter that underlines the fact that IOAM would actively seek cooperation with other related efforts? We could add something like: 

"The IOAM WG seeks cooperation with other appropriate standards bodies and forums to promote consistent approaches, as well as definition and interpretation of in-situ OAM data."

This would naturally capture IETF WGs like IPPM - but also efforts like INT in P4, hence we'd even cast the net a little wider.

Thoughts?

Thanks, Frank

-----Original Message-----
From: Ioam [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind (IETF)
Sent: Freitag, 10. Februar 2017 13:10
To: Carlos Pignataro (cpignata) <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>
Cc: [email-masked]; The IAB <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>; [email-masked]
Subject: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)

Hi all,

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

Mirja

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 10 Feb 2017 14:21:00 +0000

Hi, Stewart,

> On Feb 10, 2017, at 4:32 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 

That is correct, it is Hybrid Type I. Sorry if I misunderstood when you said “ Carlos, that is not quit where we are going with passive. We use packet marking […]”. 

But in any case, I do not believe the draft charter claims to do marking (more on this below though).

I wonder, as an aside, if there’s any take-away for draft-ietf-ippm-alt-mark-03’s title “Alternate Marking method for passive performance monitoring”.

> I suppose you could say: It is based on telemetry information which is embedded within live data packets and is distinct from packet parking methods being developed elsewhere in the IETF.

That’s one potential approach. To me, though, “embedded within live data packets” is different from “marking packets”; that said, I do not see how it can hurt.

There is one additional wrinkle though: IOAM is not limited to Performance Management (PM), but more generally includes things like path tracing. So perhaps adding the text above might cause confusions.

> I have not thought it through, but I am wondering what distinguishes the packet types you list (IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve) from other packet types, the obvious one being MPLS.…

Encapsulations?

Thanks!

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 10 Feb 2017 14:30:08 +0000

Hi, Mirja,

This is a good point, please see inline.

> On Feb 10, 2017, at 7:10 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi all,
> 

The IOAM work is not narrowscoped to only PM. Things like path tracing are not PM.

On the other hand, IPPM is only about PM, and in fact its charter starts with:
“The IP Performance Metrics (IPPM) Working Group develops and maintains
standard metrics that can be applied to the quality, performance, and
reliability of Internet data delivery services and applications running
over transport layer protocols (e.g. TCP, UDP) over IP."

> which indictates that cooperation with IPPM is not planned.

I think that this ought to be fixed/refined, and I like the sentence that Frank proposed.

This collaboration is important.

> I don’t think that the assessment in the charter that IPPM's scope does not include piggybacked information is correct. Looking at draft-brockners-inband-oam-transport-02, I think that any work on…

I think that IPPM can leverage IOAM and its IPv6 transport insofaras defining PM methods. But IOAM > PM.

Thanks,

— Carlos.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Feb 2017 14:48:48 -0000

[snip]

> > packet types you list (IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve) from
> > other packet types, the obvious one being MPLS. Not that I am at all keen on
> > trying to get this into the simple fast forwarders we use for MPLS. In other words
> > what is the generic class of packets you are targetting?
> 
> Encapsulations?

I *think* I read this as Carlos saying...

We want to define a layer-independent, encapsulation-independent generic data format for carrying any OAM information in user data packets. We expect this to be useful in the following list of forwarding encapsulations <insert list> but the actual use of and encapsulation of this generic data format will be worked on in coordination with the working groups responsible for those encapsulations.

This, to me, seems similar to the approach taken by the SFC working group. The generic format is agnostic to (ignorant of?) both the encapsulation and the type of data carried.

In a sense, of course, it means that it is possible that the generic data format will be invented, but never used (because no group responsible for a forwarding encapsulation thinks IOAM is appropriate or desirable). Although I suspect that Carlos and frank have ambitions in this area :-)

I would certainly like the charter to be more clear about what is being built (the final paragraph does cover some of this, but the generic nature is not as obvious as it should be).

Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 10 Feb 2017 14:50:44 +0000

Hi, Stephen,

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

> On Feb 9, 2017, at 5:38 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Stephen:
>  
> Hi!
>  
>> On 2/9/17, 3:15 PM, "iesg on behalf of Stephen Farrell" <[email-masked] on behalf [email-masked]> wrote:
>>  
>>  
>> Hiya,
>>  

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?

>> discussion [1] on [email-masked] in which a draft related to

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Feb 2017 14:58:10 -0000

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

Hmmm.
Once you define a channel to carry other stuff along with data packets it will be used for purposes as yet undreamed of.

To give you a hint...

The SFC's NSH can carry metadata along with data packets in order that service functions can coordinate their actions and receive hints from packet classifiers.

A recent question was...
Suppose an application that s sourcing packets wishes to communicate with an application receiving those packets in order to explain how the packets should be treated. Could it use the NSH and put information in the metadata even though there is no service function chain involved and no service functions on the path?

So, if you open a channel, it will be used.
Will it also provide a covert channel? Who can say?

Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 10 Feb 2017 15:05:43 +0000

Hi, Adrian,

> On Feb 10, 2017, at 9:48 AM, Adrian Farrel <[email-masked]> wrote:
> 
> [snip]
> 
> I *think* I read this as Carlos saying…

Sorry, I actually meant to actually keep expanding on this point beyond that single word, but got distracted and hit Send.

These are encapsulations where we believe IOAM is a useful natural fit and we have heard the problem that IOAM addresses exists and there’s a desire to solve it. But that said, there’s no particular underlying pattern, nor perhaps an easy name to group those. 

The relevant text says:

“Data-records for
in-situ OAM will need to be embedded into transport protocols such as
IPv4, IPv6, VXLAN-GPE, LISP, NSH, SRv6, Geneve.”

Where the key is “such as"

> I would certainly like the charter to be more clear about what is being built (the final paragraph does cover some of this, but the generic nature is not as obvious as it should be).

I do not disagree that a tightening of the charter text in this regard is useful.

One approach is to list explicitly some encaps that the group would look at first, and then follow with more examples.

Another approach is to say “the group will decide which encaps to work on”.

Do you have thoughts or preferences, or another (better) approach?

Thanks!

Carlos.

---

From: Fioccola Giuseppe <[email-masked]>
Date: Fri, 10 Feb 2017 15:17:06 +0000

Hi Carlos, Stewart, All
just an addition on this point.
Marking method could be considered both hybrid and passive depending on the application.
I agree upon Hybrid Type I PM definition in some cases.
But in other cases it could be also defined as Passive PM: for instance a true example of passive application is in draft-ietf-bier-pmmm-oam-01, where marking method should not modify the actual data packet processing behavior, by using a dedicated OAM field in BIER Header.

Giuseppe

-----Messaggio originale-----
Da: Ioam [mailto:[email-masked]] Per conto di Carlos Pignataro (cpignata)
Inviato: venerdì 10 febbraio 2017 15:21
A: Stewart Bryant
Cc: [email-masked]; Alvaro Retana (aretana); The IAB; Spencer Dawkins at IETF; [email-masked]
Oggetto: Re: [Ioam] Internal WG Review: In-situ OAM (ioam)

Hi, Stewart,

Encapsulations?

Thanks!

— Carlos.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 10 Feb 2017 15:19:56 +0000

> On Feb 10, 2017, at 9:58 AM, Adrian Farrel <[email-masked]> wrote:
> 

I understand that — which is true pretty much for any new protocol field.

I was curious to see if there were more specifics on the PLUS discussion beyond this that particularly apply to IOAM.

> Suppose an application that s sourcing packets wishes to communicate with an application receiving those packets in order to explain how the packets should be treated. Could it use the NSH and put…

Right. This example depicts a use beyond the original goal. Could any IP option be used to carry other data? 

In the NSH example, the question is about using an SFC metadata channel as an inter-SF signaling (configuration?) channel, and application-to-application communication channel. I have thoughts about this, starting from the fact that if there is no SFP there is no data, and if there’s no data there’s no metadata, and the metadata field carries, well, metadata. But posing the question does not render the NSH as not useful for carrying SFP contextual data.

For IOAM, the data to be carried is well specified OAM data. 

> Will it also provide a covert channel? Who can say?

A protocol specification would need to address these security and privacy considerations. Which part of this ought to be codified in the charter?

Thanks!

— Carlos.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 10 Feb 2017 16:11:44 +0100

Hi Frank, hi all,

please see in-line.

> Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne) <[email-masked]>:
> 
> Hi Mirja,
> 
> draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that we'd likely qualify IPv6 as a transport protocol… 

If you also cite the sentence before this, this might become clearer:

"The IP Performance Metrics (IPPM) Working Group develops and maintains
standard metrics that can be applied to the quality, performance, and
reliability of Internet data delivery services and applications running
over transport layer protocols (e.g. TCP, UDP) over IP. Specifying network
or lower layer OAM mechanisms is out of scope of the IPPM charter.“

It’s focused on performance measurements of data delivery services and application, not metric sthat are specific to network operation e.g. up-time of a router (as an example that just came to my mind).

So to me the scope and the goals of IPPM and IOAM are overlapping currently as for me "real-time telemetry of individual data packets and flows“ is exactly what IPPM is doing.

> So far I understood the main focus of the new IOAM WG to be network-layer focused, i.e. piggyback OAM-meta-data onto network-layer protocols - but that does not necessarily need to be always the ca…

My point is not that there needs to be cooperation. My point is that we already have a working group that is mostly charter to do what you want to do.

Mirja

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 10 Feb 2017 10:59:36 -0600

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)" <[email-masked]>
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.

—

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

>> On 2/8/17, 2:32 PM, "iesg on behalf of Spencer Dawkins at IETF" <
[email-masked] on behalf [email-masked]> wrote:
>> 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.
>> 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).

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

>> 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 :-)

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

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

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.

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

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.

---

From: Ram Krishnan <[email-masked]>
Date: Fri, 10 Feb 2017 09:09:22 -0800

Very good discussion.

Another aspect to note is that we see value for in-situ OAM for monitoring
network functions (especially virtual) besides network interconnects. This
is captured in Section 3 in the draft (
https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1
).

I believe IPPM charter addresses only network monitoring.

Thanks,
Ramki

On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> > you raise an interesting point. The IPPM charter states  " Specifying
> network or lower layer OAM mechanisms is out of scope of the IPPM
> charter.", whereas the WG has " Submit a draft on the IPv6 Performance and
> Diagnostic Metrics (PDM) Destination Option as Proposed Standard
> > draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that we'd
> likely qualify IPv6 as a transport protocol…
>
> It’s focused on performance measurements of data delivery services and
> application, not metric sthat are specific to network operation e.g.
> up-time of a router (as an example that just came to my mind).
>
> So to me the scope and the goals of IPPM and IOAM are overlapping
> currently as for me "real-time telemetry of individual data packets and
> flows“ is exactly what IPPM is doing.
>
> >
> > So far I understood the main focus of the new IOAM WG to be
> network-layer focused, i.e. piggyback OAM-meta-data onto network-layer
> protocols - but that does not necessarily need to be always the case as you
> implicitly highlight by drawing the link to IPPM. One could also do so
> using e.g. TCP options. I did not read the statement on IPPM in the draft
> charter as "not cooperating with IPPM" - I read it in a way that methods
> that do not piggyback information on live traffic are not considered in
> IOAM. That said, especially when it comes to export and interpretation of
> in-situ OAM data, there might indeed be common ground between IOAM and IPPM.
>
> My point is not that there needs to be cooperation. My point is that we
> already have a working group that is mostly charter to do what you want to
> do.
>
> Mirja
>
>
> >
> > How about we add another sentence to the charter that underlines the
> fact that IOAM would actively seek cooperation with other related efforts?
> We could add something like:
> >
> > "The IOAM WG seeks cooperation with other appropriate standards bodies
> and forums to promote consistent approaches, as well as definition and
> interpretation of in-situ OAM data."
> >
> > This would naturally capture IETF WGs like IPPM - but also efforts like
> INT in P4, hence we'd even cast the net a little wider.
> >
> > Thoughts?
> >
> > Thanks, Frank
> >
> > Cc: [email-masked]; The IAB <[email-masked]>; Spencer Dawkins at IETF <
> [email-masked]>; [email-masked]
> IPPM that do not piggyback information onto the live user data traffic are
> out of scope of the IOAM WG.“
> >
> > To me in general the relation between this work and other ongoing work
> in the IETF is not very clear and IPPM has several documents and milestones
> that are in scope for this work:
> >
> > - Submit a draft on the IPv6 Performance and Diagnostic Metrics (PDM)
> Destination Option as Proposed Standard: draft-ietf-ippm-6man-pdm-option
> (this draft is mainly done and silenter the publication process soon to my
> understanding)
> >
> > - Submit an Experimental draft on coloring-based hybrid measurement
> methodologies for loss and delay to the IESG: draft-ietf-ippm-alt-mark-03
> >
> > I don’t think that the assessment in the charter that IPPM's scope does
> not include piggybacked information is correct. Looking at
> draft-brockners-inband-oam-transport-02, I think that any work on IPV6
> and IPv6 in this scope should be done in IPPM because that’s were this work
> is already on-going and where the measurement expertise is.
> >
> > Mirja
> >
> >
> >
> >

-- 
Thanks,
Ramki

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 10 Feb 2017 11:19:33 -0600

Hi, Ram,

On Feb 10, 2017 11:09, "Ram Krishnan" <[email-masked]> wrote:

Very good discussion.

Another aspect to note is that we see value for in-situ OAM for monitoring
network functions (especially virtual) besides network interconnects. This
is captured in Section 3 in the draft (https://datatracker.ietf.org/
doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1).

The responsible AD for IPPM happens to agree :-)

Is the expertise required for path monitoring the same as the expertise
required for network element monitoring?

Thanks,

Spencer

Thanks,
Ramki

-- 
Thanks,
Ramki

---

From: Ram Krishnan <[email-masked]>
Date: Fri, 10 Feb 2017 09:37:35 -0800

Hi Spencer,

There is some expertise overlap, but there are several distinct skills
needed especially in the context of virtual network functions since it
needs a deep understanding of server/NIC architectures.

Thanks,
Ramki

On Fri, Feb 10, 2017 at 9:19 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

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

-- 
Thanks,
Ramki

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 Feb 2017 14:34:19 -0500

I would be very careful about using this proposal as a justification for 
an iOAM working group.
it is SFC specific.
And there are some interesting challenges in the details.

Yours,
Joel

On 2/10/17 12:09 PM, Ram Krishnan wrote:
> Very good discussion.
>
> Another aspect to note is that we see value for in-situ OAM for
> monitoring network functions (especially virtual) besides network
> interconnects. This is captured in Section 3 in the draft
> (https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1).
>
> On Fri, Feb 10, 2017 at 7:11 AM, Mirja Kuehlewind (IETF)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Frank, hi all,
>
>     please see in-line.
>
>     > Am 10.02.2017 um 14:38 schrieb Frank Brockners (fbrockne)
>     <[email-masked] <mailto:[email-masked]>>:
>     >
>     > Hi Mirja,
>     >
>     > you raise an interesting point. The IPPM charter states  "
>     Specifying network or lower layer OAM mechanisms is out of scope of
>     the IPPM charter.", whereas the WG has " Submit a draft on the IPv6
>     Performance and Diagnostic Metrics (PDM) Destination Option as
>     Proposed Standard
>     > draft-ietf-ippm-6man-pdm-option" as a milestone. I'd assume that
>     we'd likely qualify IPv6 as a transport protocol…
>
>     It’s focused on performance measurements of data delivery services
>     and application, not metric sthat are specific to network operation
>     e.g. up-time of a router (as an example that just came to my mind).
>
>     currently as for me "real-time telemetry of individual data packets
>     and flows“ is exactly what IPPM is doing.
>
>     >
>     network-layer focused, i.e. piggyback OAM-meta-data onto
>     network-layer protocols - but that does not necessarily need to be
>     always the case as you implicitly highlight by drawing the link to
>     IPPM. One could also do so using e.g. TCP options. I did not read
>     the statement on IPPM in the draft charter as "not cooperating with
>     IPPM" - I read it in a way that methods that do not piggyback
>     information on live traffic are not considered in IOAM. That said,
>     especially when it comes to export and interpretation of in-situ OAM
>     data, there might indeed be common ground between IOAM and IPPM.
>
>     My point is not that there needs to be cooperation. My point is that
>     we already have a working group that is mostly charter to do what
>     you want to do.
>
>     Mirja
>
>
>     >
>     > How about we add another sentence to the charter that underlines
>     the fact that IOAM would actively seek cooperation with other
>     related efforts? We could add something like:
>     >
>     > "The IOAM WG seeks cooperation with other appropriate standards
>     bodies and forums to promote consistent approaches, as well as
>     definition and interpretation of in-situ OAM data."
>     >
>     > This would naturally capture IETF WGs like IPPM - but also efforts
>     like INT in P4, hence we'd even cast the net a little wider.
>     >
>     > Thoughts?
>     >
>     > Thanks, Frank
>     >
>     > From: Ioam [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Mirja Kuehlewind (IETF)
>     > To: Carlos Pignataro (cpignata) <[email-masked]
>     <mailto:[email-masked]>>; Alvaro Retana (aretana)
>     <[email-masked] <mailto:[email-masked]>>
>     > Cc: [email-masked] <mailto:[email-masked]>; The IAB <[email-masked]
>     <mailto:[email-masked]>>; Spencer Dawkins at IETF
>     <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     >> Am 09.02.2017 um 18:18 schrieb Carlos Pignataro (cpignata)
>     <[email-masked] <mailto:[email-masked]>>:
>     >>
>     > "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.“
>     >
>     > To me in general the relation between this work and other ongoing
>     work in the IETF is not very clear and IPPM has several documents
>     and milestones that are in scope for this work:
>     >
>     > - Submit a draft on the IPv6 Performance and Diagnostic Metrics
>     (PDM) Destination Option as Proposed Standard:
>     draft-ietf-ippm-6man-pdm-option (this draft is mainly done and
>     silenter the publication process soon to my understanding)
>     >
>     > - Submit an Experimental draft on coloring-based hybrid
>     measurement methodologies for loss and delay to the IESG:
>     draft-ietf-ippm-alt-mark-03
>     >
>     > I don’t think that the assessment in the charter that IPPM's scope
>     does not include piggybacked information is correct. Looking at
>     draft-brockners-inband-oam-transport-02, I think that any work on
>     IPV6 and IPv6 in this scope should be done in IPPM because that’s
>     were this work is already on-going and where the measurement
>     expertise is.
>     >
>     > Mirja
>     >
>     >
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ioam>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ioam>
>
>
>
>
> --
> Thanks,
> Ramki
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Feb 2017 20:32:42 -0000

Well, indeed.
 
This is why I was scratching away at whether this is a proposal for a generic
OAM encapsulation.

AFAICS the devil is in the detail of the encapsulation/forwarding/switching
mechanism and a lot of the information that has to be encoded will be different.
So, will this proposal lead to more than a set of TLVs that would be filled out
for different use cases?

It *might* be that it would be more useful to identify the target us cases (i..,
those that people want to build and deploy now) and work on those.

Adrian

> From: Ioam [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 10 February 2017 19:34
> To: Ram Krishnan; Mirja Kuehlewind (IETF)
> Cc: Carlos Pignataro (cpignata); Frank Brockners (fbrockne); The IAB;
> [email-masked]; [email-masked]; Alvaro Retana (aretana); Spencer Dawkins at IETF

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 10 Feb 2017 22:11:58 +0000

Spencer,

A couple of quick follow-ups:

> On Feb 10, 2017, at 11:59 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> 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.
> 

Indeed.

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

Thank you!

Carlos.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 10 Feb 2017 21:02:28 +0100

Hi Ram,

to me the current charter seem to not include monitoring of network functions. Also your draft is currently not listed as related on the BoF page. I had a very brief look at this now and I don’t think that Data-plane probe for in-band telemetry collection (draft-lapukhov-dataplane-probe) and Network Service Header KPI Stamping (draft-browne-sfc-nsh-kpi-stamp), which are both listed as use cases, can or should be treated the same. As Joel notes below SFC is a specific use case and probably requires very different expertise. I don’t think throwing everything the same working group is the right approach here.

Mirja

> Am 10.02.2017 um 20:47 schrieb Adrian Farrel <[email-masked]>:
> 
> Well, indeed.
> 
>>>    we'd likely qualify IPv6 as a transport protocol.
>>> 
>>>    or lower layer OAM mechanisms is out of scope of the IPPM charter."
>>> 
>>>    It's focused on performance measurements of data delivery services
>>>    and flows" is exactly what IPPM is doing.
>>> 
>>>> 
>>>    data traffic are out of scope of the IOAM WG."
>>>> 
>>>> I don't think that the assessment in the charter that IPPM's scope
>>>    IPV6 and IPv6 in this scope should be done in IPPM because that's

---

From: Ram Krishnan <[email-masked]>
Date: Fri, 10 Feb 2017 12:12:04 -0800

Hi Mirja,

Fair points. Still wondering how my draft missed the BoF page - I will get
it added through the BoF coordinators.

Thanks,
Ramki

On Fri, Feb 10, 2017 at 12:02 PM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> Hi Ram,
>
> to me the current charter seem to not include monitoring of network
> functions. Also your draft is currently not listed as related on the BoF
> page. I had a very brief look at this now and I don’t think that Data-plane
> probe for in-band telemetry collection (draft-lapukhov-dataplane-probe)
> and Network Service Header KPI Stamping (draft-browne-sfc-nsh-kpi-stamp),
> which are both listed as use cases, can or should be treated the same. As
> Joel notes below SFC is a specific use case and probably requires very
> different expertise. I don’t think throwing everything the same working
> group is the right approach here.
>
> Mirja
>
>

-- 
Thanks,
Ramki

---

From: Joe Clarke <[email-masked]>
Date: Sat, 11 Feb 2017 05:46:57 -0500

> Do you believe this is not clear in the charter? Do you have specific suggestions or concrete recommendations that can improve the charter text?

I'm not sure this is clear (i.e., "live data").  Intuitively, I know
what IOAM is trying to do, but the expression live data or even user
data may not be ultimately clear as to the scope.  For example, would
IOAM headers be excluded from packets that did not have any data payload?

Yeah, this is a bikeshed, but would text such as "packets within
existing network flows" be better or clearer?

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Feb 2017 09:45:24 +0000

> I was curious to see if there were more specifics on the PLUS discussion beyond this that particularly apply to IOAM.

Adrian is correct here, but short of a breakthrough in cryptography that 
allows the use of  homomorphic encryption at speed with small payloads, 
we sit on the horns of a dilemma between enhancing the legitimate 
observability of a network for management purposes and enhancing the 
observability for nefarious purposes. Perhaps the answer is to require 
all phys to include encryption?

Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Feb 2017 09:57:19 -0000

My concern was about use of the in-situ OAM container for non-OAM purposes. Such as, to allow an application to coordinate the use of the payload data.

Pending a conversation about whether that would be smart or stupid, I think that any in-situ OAM mechanism needs to be carefully ringed around with words that say what uses are unacceptable, and probably also words that carefully define where in-situ OAM bytes are and are not allowed to be added.

I think we probably have (albeit implicit?) that in-situ OAM bytes are not allowed to enter the domain. We should probably also have that they can only be added/modified by "OAM applications" and not "data sources". However, thin end of wedge? Will an application (perhaps a VoIP application) not consider it legitimate to add in-situ OAM to get feedback on the behavior of the network for its voice calls? And if so, that opens the gates for any application to use in-situ OAM, and *that* opens the possibility of two end-point applications using the in-situ OAM mechanism to talk about *anything*.

Adrian

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: 14 February 2017 09:45
> To: Carlos Pignataro (cpignata); Adrian Farrel
> Cc: Alvaro Retana (aretana); [email-masked]; The IESG; The IAB; Stephen Farrell
> >> Once you define a channel to carry other stuff along with data packets it will
> be used for purposes as yet undreamed of.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Feb 2017 12:21:44 +0000

I don't think it matters what we say, if people want to use it for other 
purposes they will pay money to their vendor of choice or to the open 
source community and it will happen. We can try locking down the 
code-points I suppose.

What we really need is a simple method of adding this information under 
cryptographic cover. That way at least only authorised parties can look 
at it.

Stewart