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

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

Hi, Adrian,


> On Feb 10, 2017, at 9:48 AM, Adrian Farrel <[e-mail]> wrote:
> 
> [snip]
> 
>>> 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?
>> 
>> Encapsulations?
> 
> 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"

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

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.

> Adrian
> 
>