Re: [OPSAWG] [nvo3] YANG models for OAM

Hi Tissa, authors, et. al, I've read documents and would like to clarify scope of these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there would not be connectivity verification. And the performance measureme

Re: [OPSAWG] [nvo3] YANG models for OAM

ier-ethernet/technical-specifications > > > > Regards > > > > Don > > > > *From:* L2vpn [mailto:l2vpn-boun...@ietf.org] *On Behalf Of *Tissa > Senevirathne > *Sent:* Thursday, July 31, 2014 5:53 PM > *To:* Greg Mirsky; Tissa Senevirathne (tsenevir) >

Re: [OPSAWG] [nvo3] YANG models for OAM

are not extensible or not modular > enough. > > Thanks > Tissa > > > On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: > > > Hi Tissa, authors, et. al, > I've read documents and would like to clarify scope of these documents. > OAM is not limited to pin

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear All, I read the latest version of the draft. I appreciate the work authors put into making the document clear and easy to read. Proposed IEs are essential for further developing an out-of-band collection of telemetry information. I strongly support the adoption of this work by the OPSAWG. I ha

Re: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

Hi Thomas, thank you for supporting this work and for your helpful comments. Please find my notes inlined below tagged by GIM>>. Regards, Greg On Wed, Jul 26, 2023 at 2:24 PM wrote: > Dear Alex and Greg, > > > > I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and > have so

Re: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

service between two measurement points, a time interval as the unit of PAM needs to be selected. > > > GIM>> I agree. Check the attached diff. > > > > TG> Perfect thanks! > GIM2>> Great! > > > Best wishes > > Thomas > > > >

[OPSAWG] IOAM, iOAM, and oOAM abbreviations

Dear All, Loa and I have discussed these abbreviations to help us find a solution that avoids the confusion we found when we came across them. Firstly, what they stand for: - IOAM - In-situ OAM (RFC 9197 ) - iOAM - in-band OAM (RAW architecture

Re: [OPSAWG] [Detnet] [ippm] IOAM, iOAM, and oOAM abbreviations

; information being piggybacked on top of user traffic. This is why the IPPM > WG concluded to use “In-situ OAM” – or “IOAM” for short, which is what is > used in RFC9197 and all related documents. > > > > Frank > > > > > > > > *From:*ippm *On Behalf Of *Greg Mirsky

Re: [OPSAWG] [Detnet] [ippm] IOAM, iOAM, and oOAM abbreviations

23 at 12:41 PM Florian Kauer wrote: > Hi Greg, > thanks a lot for the explanation, find my comments under FK>> > > On 13.12.23 21:14, Greg Mirsky wrote: > > Hi Florian, > > thank you for your questions. I added my notes below under the GIM>> tag. > > > &

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

- Hi Carlos and Adrian, thank you for starting this work. I believe that having a common dictionary helps in having more productive discussions. I took the liberty of inviting all the WGs which you invited to review the document and added DetNet WG. Please feel free to trim the distribution lis

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

tle discussion. If we end up with “everything is > OK and nothing needs to change” that will be OK with us. If we discover > that some work is using terms too generally, while others already have > perfect definitions, that will lead to something similar to this document > to brin

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

Regards, Greg On Tue, Jan 16, 2024 at 2:41 PM Carlos Pignataro wrote: > Dear Greg, > > Thank you for your interest in our draft, and the associated extensive > comments! All welcome! > > *CMP: Please find some additional follow-ups.* > > On Sat, Jan 13, 2024 at 7:52 PM Greg Mir

Re: [OPSAWG] Fwd: [mpls] New Liaison Statement, "LS on the consent of draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr) Requirements and Reference Model for optimized traceroute of joint Internet Pro

but possibly > someone that know could forward. > > And I think it would be a good idea to call on Scott to coordinate a > response. > > /Loa > > > > > id="lineBreakAtBeginningOfSignature">Sent from my > iPhoneBegin forwarded > > message: dir

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

Dear All, I've read the latest version of the draft, Please find my notes and questions below: - All SDOs that standardize methods and/or protocols in the field of OAM recognize that, in the FCAPS network management model, OAM is addressing the 'F' and 'P', i.e., Fault Management and Perf

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

e WG or context? > > Please find some follow-ups inline below: > > On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky > wrote: > >> Dear All, >> I've read the latest version of the draft, Please find my notes and >> questions below: >> >>- All SDOs

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

Hi Michael, thank you for the update. I'm glad that you found the definition in RFC 9551 working for ANIMA's Autonomic Control Plane as well. I will read RFC 8994 to educate myself about it. Regards, Greg On Mon, Apr 15, 2024 at 5:54 PM Michael Richardson wrote: > > Gr

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

really mean when… > > There is no “band” > > [image: image] > > C > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > > On Apr 15, 2024, at 09:03, Greg Mirsky wrote: > >  > Hi Carlos, > I have to repeat that the definitions of terms &qu

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

Hi Michael, I don't think that every term must and can be self-explanatory. We develop our dictionary through the development of explicitly defined terms. That is what we use Terminology section in our drafts for. And, AFAICS, it is normal to expect that anyone interested in the field, in the parti

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

call for adoption, not a Last Call. > GIM>> I think that we have different perspective and expectations of the process. That's is okay. I believe that WG Chairs and the Responcible AD will find the way forward to further advance the development of Internet and technologies that enable its

[OPSAWG] Notes on draft-gfz-opsawg-ipfix-alt-mark

Dear, Authors et al., thank you for your continued work on the Alternate Marking method. In my opinion, draft-gfz-opsawg-ipfix-alt-mark provides an essential IEs making the use of IPFIX operationally viable option for the Alternate Marking method. While I've read the document, it seems that its cur

[OPSAWG]Re: 🔔 WG Adoption Call for draft-gfz-opsawg-ipfix-alt-mark-01

Hi, Henk et al., I read the draft and found it well-written. I believe that it addresses the real issue and provides a viable solution. I support its adoption by the OPSAWG. Regards, Greg On Wed, Jun 26, 2024 at 2:58 AM Henk Birkholz wrote: > Dear OPSAWG members, > > this email starts a call fo

[OPSAWG]Re: I-D Action: draft-ietf-opsawg-ipfix-on-path-telemetry-08.txt

Dear Authors, thank you for updating the draft; I've read it. I hope that adding IPPM WG to discussion of new performance metrics is reasonable. I appreciate your consideration of my notes and questions below: - If I understand correctly, the delay measurement using on-path telemetry is achi

[OPSAWG]Re: IETF 120 opsawg minutes posted

Hi Joe, thank you for bringing minutes to the review. I noticed a minor issue with reflection of my comment to A YANG Data Model for Network Diagnosis by Scheduling Sequences of OAM Tests. I noted that RFC 8913 that defines the TWAMP YANG model, does not

[OPSAWG]Re: IETF 120 opsawg minutes posted

It's perfect! Thank you! Regards, Greg On Thu, Aug 1, 2024 at 1:50 PM Joe Clarke (jclarke) wrote: > Thanks, Greg. I updated your comments in HedgeDoc and reimported the > minutes. > > > > Joe > > > > *From: *Greg Mirsky > *Date: *Thursday, August 1, 202

Re: [OPSAWG] Call for operator's input on use case that requires Network Management Automation.

Dear All, I would propose that IETF send liaison to MEF LSO Committee, and probably other SDOs, notifying them of the discussion and inviting to share their comments. Regards, On Thu, Mar 28, 2019, 11:24 Qin Wu wrote: > Hi, folks: > > I would like to draw you attention to IETF YANG automation F

Re: [OPSAWG] Questions regarding the draft-wu-model-driven-management-virtualization

e inline. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky [mailto:gregimir...@gmail.com] > *Envoyé :* mardi 9 avril 2019 15:33 > *À :* draft-wu-model-driven-management-virtualizat...@ietf.org; RTGWG > *Objet :* Questions regarding the > draft-wu-m

[OPSAWG] I,Scope of FIT Capability: a node or a link?

Dear All, I've read these two drafts with interest. In light of the discussion on the LSR WG list, I've been thinking about the scenarios where IFIT is being used. draft-song-opsawg-ifit-framework defines the overall IFIT architecture that, as I understand it, applicable to different methods of col

[OPSAWG] WGLC: Comments on draft-opsawg-ntf

Dear Authors, thank you for your work on this document. I believe that it is important to analyze and explain what is network telemetry, how it relates to the established tools that support network operations, administration, and maintenance (OAM). Traditionally, OAM tools support two components o

Re: [OPSAWG] WGLC: Comments on draft-opsawg-ntf

with OAM, and in fact, > OAM is an important part of network telemetry. We will take your insight > and reword the corresponding paragraphs for clarification. Please see > inline for more response. > > > > Best regards, > > Haoyu > > > > *From:* OPSAWG *On Behal

Re: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

Dear All, I've read the draft and support its adoption by the OPSAWG. The proposed approach to service assurance is powerful and extensible. I have several questions for the authors and appreciate their consideration: - Is the architecture intended to quantify service degradation? - A health

Re: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07

Dear All, I've read the draft and support its adoption by the OPSAWG. Regards, Greg > > > -Original Message- > From: OPSAWG on behalf of Henk Birkholz < > henk.birkh...@sit.fraunhofer.de> > Date: Tuesday, 27 April 2021 at 20:02 > To: opsawg > Subject: [OPSAWG] 🔔 WG Adoption Call for >

[OPSAWG] A question about relationship between draft-song-opsawg-ifit-framework and draft-wang-idr-bgp-ifit-capabilities

Dear OPSAWG and IDR WGs, I've been following the discussion of draft-song-opsawg-ifit-framework in the OPSAWG. The on-path telemetry is a very important element of the OAM toolset. The IFIT framework discussion is helping to bette

[OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

Dear Authors, thank you for your work on this document. I've read the draft and have a question, and a suggestion. Section 7.6.4 describes how BFD is controlled in vpn-common. I've noticed that you use references to R

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

r BFD for multipoint networks? - What behavior of a BFD system is controlled by the holdtime? Can you point to the text in RFC 5880 that defines the expected behavior? Regards, Greg On Sat, Aug 28, 2021 at 5:07 AM tom petch wrote: > From: Rtg-bfd on behalf of Greg Mirsky < >

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

eliver the requested service. > > > > With that rationale in mind, you can understand why we don’t import device > models but point to the authoritative RFCs for aspects that we think make > sense to be tweaked at the network-level. > > > > Thanks. > > > >

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

Cheers, > Med > > > -Message d'origine- > > De : Jeffrey Haas [mailto:jh...@pfrc.org] > > Envoyé : mercredi 1 septembre 2021 14:38 > > À : BOUCADAIR Mohamed INNOV/NET > > Cc : Greg Mirsky ; draft-ietf-opsawg-l3sm- > > l...@ietf.org; opsawg ; rtg-bfd

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

implemented in the module. You can track > them at: > > > https://github.com/IETF-OPSAWG-WG/lxnm/commit/9b97016743a355f2b7737288dfaedebcdc47c9b8 > > > > Also, made the companion changes to the I-D: > https://tinyurl.com/l3nm-latest > > > > Cheers, > >

[OPSAWG] A question on the use of "direction" in draft-ietf-opsawg-yang-vpn-service-pm

Dear Authors, thank you for your work on this model. I read the document and have one question and a single suggestion for your consideration: - I find the description of the "direction" somewhat confusing. Can you give an example when the "direction" is set to "two-way". In that case, how

Re: [OPSAWG] A question on the use of "direction" in draft-ietf-opsawg-yang-vpn-service-pm

Hi Bo, thank you for carefully considering my notes. Please find my follow-up notes in-lined below under the GIM>> tag. Regards, Greg On Thu, Nov 4, 2021 at 5:14 AM Wubo (lana) wrote: > Hi Greg, > > > > Thanks for the comments. Please see inline. > > > > T

Re: [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01

Hi Adrian, the Authors, and All, thank you Adrian for reviewing the draft and inviting further discussion. I've commented on this work earlier suggesting considering the performance metrics listed in the STAMP YANG data model. I appreciate that the Authors have found them helpful and included them

Re: [OPSAWG] [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt

Hi Thomas, et al., what do you think of the new SPRING WG draft that introduces two methods of the compressed SRv6 SID list encoding in the SRH ? Regards, Greg On Sat, Feb 12, 2022 at 12:10 AM wrote: > Dear Yao, >

[OPSAWG] A question on the definitions of SDP and SAP

Hi Adrian, I've read the draft-ietf-teas-ietf-network-slices (many thanks for all your work on it!) and I've got a question. It appears to me that the definition of a Service Demarcation Point section 2.1) as the point of where

Re: [OPSAWG] A question on the definitions of SDP and SAP

esenting it in management > > and configuration systems. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky > *Envoyé :* lundi 21 mars 2022 12:17 > *À :* Adrian Farrel ; TEAS WG ; > opsawg ; BOUCADAIR Mohamed INNOV/NET < > mohamed.boucad

Re: [OPSAWG] A question on the definitions of SDP and SAP

e VPN network access identifier in > > *Section 7.6 of [RFC9182]*. An example to illustrate the use of > > this attribute during service creation is provided in *Appendix D*. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky > *Envoyé :

Re: [OPSAWG] [ippm] Heads up on draft-ietf-opsawg-yang-vpn-service-pm

Hi Adrian, thank you for bringing this work to my attention. I've read and shared my comments earlier. The authors responded promptly and we've worked together to address my comments. After reading the current version I have a question about the importance of identifying the particular active measu

Re: [OPSAWG] [ippm] Heads up on draft-ietf-opsawg-yang-vpn-service-pm

of PM measurement protocol. > > Please be aware this model is a network model and does not specifies the > details of STAMP. > > Please check whether rev-08 addresses your concerns: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-08 >

[OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM"

quick response! This is very useful! Please see inline > as “CMP2:" > > On Nov 11, 2024, at 11:39 AM, Greg Mirsky wrote: > > Dear Carlos, > please find my notes below tagged GIM>>. > > Regards, > Greg > > On Mon, Nov 11, 2024 at 11:07 AM Carlos Pignataro

[OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM"

band is the monitored flow. Hence, "being in-band" means traversing the same set of nodes and links and receiving the same forwarding treatment as the monitored flow. > > On Oct 27, 2024, at 12:26 AM, Greg Mirsky wrote: > > Dear All, > I read the draft. Although I fin

[OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM"

2024 at 9:25 AM Joe Clarke (jclarke) wrote: > This starts a two week WG LC > https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/. > The authors have been polled and there is no known IPR on this work that > has been disclosed at this time. > > > > Plea

[OPSAWG]Fwd: WG LAST CALL: Guidelines for Charactering "OAM"

n with the on-path telemetry document. Thanks to Greg Mirsky who agreed to shepherd this draft. The WG LC will run until November 4. Thanks. Joe ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe s

[OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM"

losed at this time. > > > > Please post comments and thoughts on this document’s readiness to the > list. We ultimately want to run publication of this in conjunction with > the on-path telemetry document. Thanks to Greg Mirsk

[OPSAWG]Fwd: WG LAST CALL: Guidelines for Charactering "OAM"

ime. Please post comments and thoughts on this document’s readiness to the list. We ultimately want to run publication of this in conjunction with the on-path telemetry document. Thanks to Greg Mirsky who agreed to shepherd this draft. The WG LC will run until November 4. Thanks. Joe _

[OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM"

t; Diff compared to version 04 (which you previously reviewed): > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-oam-characterization-04&url2=draft-ietf-opsawg-oam-characterization-06&difftype=--html > > Please let us know what you think. > > Thanks, > Tal

[OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM"

mproving the draft. > Please see my responses to the latest comments that you have sent to > the authors off-list when you kindly reviewed an intermediate version > of the draft. > > > On Tue, May 13, 2025 at 8:38 PM Greg Mirsky wrote: > > > > Hi Tal, > > > > T

[OPSAWG]Re: Path-Congruent/In-Flow (was RE: Re: RFC 5085/PALS/PWE3 ...")

data packets in that flow are applied (statistically) to OAM packets (matter of determining required number of test packets in the test session). > > > In order to make progress here, can I suggest that: > > > >- @Adrian/Tal/Carlos propose a definition of what they put behi

[OPSAWG]Re: RFC 5085/PALS/PWE3 (RE: Re: WG LAST CALL: Guidelines for Charactering "OAM"

C 9772: * In-flow OAM is an active or hybrid OAM method, as defined in [RFC7799], that traverses the same set of links and interfaces and receives the same Quality of Service treatment as the monitored object. Hybrid OAM natively is in-flow OAM. Ensuring the active OAM metho

[OPSAWG]Re: RFC 5085/PALS/PWE3 (RE: Re: WG LAST CALL: Guidelines for Charactering "OAM"

physical path through the network, and thus should be left up to the > operator. > > Cheers, > Andy > > > On Wed, Jun 4, 2025 at 9:44 PM Greg Mirsky wrote: > >> Hi Andy, >> >> Thank you for your thoughtful analysis of not only RFC 5085 but the >> d

[OPSAWG]Re: RFC 5085/PALS/PWE3 (RE: Re: WG LAST CALL: Guidelines for Charactering "OAM"

us, the term "in-band" in [RFC5085] refers to using the same > > path as the user data. This term is also used in Section 2 of > > [RFC6669] with the same meaning, and the word "congruent" is > > mentioned as synonymous. > > > > Do you

[OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM"

Hi Carlos, please find my notes below tagged GIM2>>. Regards, Greg On Tue, Jun 3, 2025 at 1:21 AM Carlos Pignataro wrote: > Greg: > > While I’ll defer to Tal for a detailed response, I’ve provided three key > points inline. > See “CMP:” below > > On Jun 1, 2025, at

[OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM"

ample > is CCMs, which are sent at the highest possible priority by default > (see RFC 7369 for example). > > Cheers, > Tal. > > On Wed, Jun 4, 2025 at 8:31 AM Greg Mirsky wrote: > > > > Hi Carlos, > > please find my notes below tagged GIM2>>. > >

[OPSAWG]Re: RFC 5085/PALS/PWE3 (RE: Re: WG LAST CALL: Guidelines for Charactering "OAM"

> > > > > > *From: *mohamed.boucad...@orange.com > *Date: *Wednesday, 4 June 2025 at 09:48 > *To: *Andrew G. Malis , Stewart Bryant < > stewart.bry...@gmail.com>, Matthew Bocci (Nokia) > *Cc: *Ops Area WG , Carlos Pignataro , > Greg Mirsky > *Subject: *RFC

[OPSAWG]Re: RFC 5085/PALS/PWE3 (RE: Re: WG LAST CALL: Guidelines for Charactering "OAM"

ion 2 of >> >> [RFC6669] with the same meaning, and the word "congruent" is >> >> mentioned as synonymous. >> >> >> >> Do you see any disconnect between this text and RFC5085? >> >> >> >> FWIW, draft-ietf-opsawg

[OPSAWG]Re: RFC 5085/PALS/PWE3 (RE: Re: WG LAST CALL: Guidelines for Charactering "OAM"

d over the path B, what could be the value of PM obtained using the active OAM measurement method even if both data nd OAM packets has the same CoS marking? > > > Best regards > > > > Matthew > > > > *From: *Greg Mirsky > *Date: *Friday, 6 June 2025 at 01:56 >

[OPSAWG]Re: [IANA #1422930] expert review for draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics)

gt; > Sent: Tuesday, July 15, 2025 12:01 AM > > > Cc: gregimir...@gmail.com; Scharf, Michael > > esslingen.de>; opsawg@ietf.org > > > Subject: [IANA #1422930] expert review for draft-ietf-opsawg-ipfix- > > > on-path- > > > telemetry (pe

[OPSAWG]Re: [IANA #1422930] expert review for draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics)

nd "Passive", as far as I read the text of RFC 7799. But Greg has > > > > probably more context regarding that discussion. > > > > > > > > Best regards > > > > > > > > Michael > > > > > > > > > > &