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

["Adrian Farrel" <[e-mail]>]

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

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