Re: [Raw] New Version Notification for draft-ietf-raw-oam-support-01.txt

[Fabrice Theoleyre <[e-mail]>]

Dear Pascal,

> Hello All:
> 
> I’d be happy to add text in the raw architecture document (section 4.3) on the high level solution space that we want to consider.
> Right now we say what we observe, all segments (in a mesh) or just the wireless access (that’s supposed to be the lossy part and that pays for the rest of the path anyway).
> 
> We also have a discussion on how we tag the packets (with a HbH with is consistent with 6TiSCH and the current directions at 6MAN, https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/, or SRv6 SRH) to identify the flows. In any fashion, this allows to use the same identification  for the OAM packets and the flow itself.

Yes, definitely, we need to have a flow tagging method, and it would also work for OAM. 

> How we observe is not discussed yet. I’d like to wrote text about data collection packets (bees) that travel the reverse path and gather the latest metrics (e.g. DLEP) at each  hop. Also I’d like to see text on IPPM, and whatever you guys think is best suited. The goal of the architecture is to give a blueprint/skeleton/direction for the solution drafts later.
> 
> Any suggestions?

We can re-use some tools such as rfc6534, rfc6673, etc. 

I guess we need to make a distinction between end-to-end opaque metrics and methods vs. hop-by-hop, fine-grained ones.

By the way, shall we consider both directions, or a single direction is sufficient to monitor a raw (DetNet) flow? 
In other words, do we need something like TWAMP or is OWAMP sufficient?

Cheers,
Fabrice