Subject: RE: Follow-up on Error Performance Measurement presentation at IETF-110

From: "Wangyali(Yali,Data Communication Standards and Patents Dept)" <[email-masked]>
Date: Mon, 17 May 2021 13:07:46 +0000

Hi Greg,

After reading these draft, which are interesting to me, I have following considerations.

1)      Is the Integrated OAM defined as a new protocol? Otherwise this draft is intent to extend the BFD specified in RFC5880?

2)      If it’s a new protocol, why not define a new Integrated OAM message independent to BFD, which supports both proactive connectivity check and performance measurement ? For example, directly defining the LM message, DM message or combined LM/DM message in the IntOAM control message body but not as a TLV. While it’s flexible using TLVs.

3)      For EPM use case, it may be defined as a TLV in IntOAM control message, right?

From my side, this work is interesting. And willing to work together to advance the IntOAM document.

Best,
Yali

From: rtgwg [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, April 8, 2021 7:04 AM
To: IETF IPPM WG <[email-masked]>; RTGWG <[email-masked]>
Subject: Follow-up on Error Performance Measurement presentation at IETF-110

Dear All,
in the course of presenting our work on the Error Performance Measurement<https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/> (slides attached), I didn't mention the work on the Integrated OAM<https://datatracker.ietf.org/doc/draft-mmm-rtgwg-integrated-oam/>. The Integrated OAM work was presented and discussed at the RTGWG session during the IETF-110. We believe that EPM is one of the use cases that highlight the benefits of using the Integrated OAM. We believe that experts from IPPM and RTGWG WGs would be interested to see how the works we've presented are related to each other and help to solve challenges in operating networks.
The authors always welcome your questions, comment, and suggestions.

Regards,
Greg

---

From: <[email-masked]>
Date: Thu, 20 May 2021 10:21:47 +0800 (CST)

Hi Yali,

thank you for your interest in the Integrated OAM, much appreciated.

Please find my notes in-line below tagged GIM>>.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: Wangyali(Yali,DataCommunicationStandardsandPatentsDept)
To: Greg Mirsky;IETF IPPM WG;RTGWG;
Date: 2021/05/17 06:08
Subject: Re: [ippm] Follow-up on Error Performance Measurement presentation at IETF-110

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

Hi Greg,

 

GIM>> You're right, we've started this work as the extension of BFD. After discussing it in the BFD WG, we've decided that a new protocol is more appropriate format. Of course, in the foundation of the Integrated OAM are RFC 5880 and RFC 6374 with the addition of the capability negotiation, fine-grain authentication and more.

GIM>> That is an interesting idea that we are open to discuss and explore.

GIM>> I think that the EPM might use a new TLV to fetch EPM-specific information, e.g., current EPM state (available or unavailable period. As for the qalification of a time unit, i.e., is it Severely Errored unit (the current version uses a second) or else, that can be defined as a combination of Service Level Objectives, e.g., packet loss ratio, packet delay, that the IntOAM protocol already can do.

GIM>> Your most welcome. I am looking forward to working together.

Best,

Yali

 

Dear All,

in the course of presenting our work on the Error Performance Measurement (slides attached), I didn't mention the work on the Integrated OAM. The Integrated OAM work was presented and discussed at the RTGWG session during the IETF-110. We believe that EPM is one of the use cases that highlight the benefits of using the Integrated OAM. We believe that experts from IPPM and RTGWG WGs would be interested to see how the works we've presented are related to each other and help to solve challenges in operating networks.

 

Regards,

Greg