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

Hi Greg, 

+1 for not using TCP. 

Actually, my questioning was rather on the bidirectionnality of the measurement. Since resources may be reserved in one direction, shall we always consider directionality? Or bidirectionally would be an option, that may be tricky to handle in some situations. Do I interpret wrongly the problem? 

Cheers,
Fabrice

> Le 7 juin 2021 à 22:20, gregory.mirsky@ztetx.com a écrit :
> 
> Hi Fabrice, et al.,
> using TWAMP/OWAMP will require the use of TCP-based control protocol that negotiates a test session between Session-Sender and Session-Reflector/Receiver. Also, should note that TWAMP YANG data model is, in effect, the data model of the TWAMP-Control protocol and thus does not directly controls TWAMP-Test. Hence, STAMP (RFC 8762 and RFC 8972) might be a better option as an active OAM protocol for measuring packet loss and packet delay in the network. STAMP YANG data model (draft-ietf-ippm-stamp-yang) controls the test session and includes a set of performance metrics, e.g., percentiles, that are expected to be calculated and reported by the conforming implementation.
> 
> Regards,
> Greg Mirsky
> Sr. Standardization Expert
> 预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
> E: gregory.mirsky@ztetx.com
> www.zte.com.cn
> ------------------Original Mail------------------
> Sender: FabriceTheoleyre
> To: pthubert=40cisco.com@dmarc.ietf.org;
> CC: raw@ietf.org;
> Date: 2021/06/07 08:06
> Subject: Re: [Raw] New Version Notification for draft-ietf-raw-oam-support-01.txt
> 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
> 
> 
> 
> --
> RAW mailing list
> RAW@ietf.org
> https://www.ietf.org/mailman/listinfo/raw