Hi, Andy, Thank you for this!
Benoit (as shepherd), This was my conclusion as well, as author of 5085: > RFC 5085 doesn't make any reference to QoS treatment as a part of path > congruence […] > the text in the draft to be an accurate quote, except that I wouldn't refer > to only section 6. I And this is what I also asked Greg some emails ago, twice; > then I would ask Greg to write an alternative example of in-band OAM in prior > IETF work that includes QoS treatment to ensure path congruence to include in > the draft Thanks! Carlos. > On Jun 4, 2025, at 7:48 AM, Andrew G. Malis <[email protected]> wrote: > > Hi Med, Carlos, Greg, et al! > > RFC 5085 doesn't make any reference to QoS treatment as a part of path > congruence. It only relies on label equivalence for MPLS PWs and the L2TPv3 > session for IP PWs to provide in-band VCCV. > > Greg does have a point that QoS/traffic class packet forwarding treatment can > have an effect on in-band QoS, and I see that is discussed in the > characterization draft, but it wasn't included in 5085 as written. > > So I find the text in the draft to be an accurate quote, except that I > wouldn't refer to only section 6. I would either refer to the RFC as a whole, > or if you do want section references, I would include sections 3 and 5.1.1 in > addition to section 6. > > However, Greg's comment may not be just about the accuracy of the quote, but > not including QoS treatment to ensure path congruence as a part of the > definition of in-band OAM. > > So if my interpretation of Greg's comment is correct, then I would ask Greg > to write an alternative example of in-band OAM in prior IETF work that > includes QoS treatment to ensure path congruence to include in the draft. > > Cheers, > Andy > > > On Wed, Jun 4, 2025 at 4:48 AM <[email protected] > <mailto:[email protected]>> wrote: >> Hi Andy/Stewart/Matthew, >> >> >> >> I hope you are doing well. >> >> >> >> I’m soliciting your feedback on this text which is included in >> draft-ietf-opsawg-oam-characterization: >> >> >> >> An example of "Path-Congruent OAM" is the Virtual Circuit >> >> Connectivity Verification (VCCV), described is Section 6 of >> >> [RFC5085] as "The VCCV message travels in-band with the Session >> >> and follows the exact same path as the user data for the session". >> >> Thus, 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 see any disconnect between this text and RFC5085? >> >> >> >> FWIW, draft-ietf-opsawg-oam-characterization defines “Path-Congruent OAM” as >> follows: >> >> >> >> The OAM information follows the exact same path as the observed >> >> data traffic. This was sometimes referred to as "in-band". >> >> >> >> Thank you. >> >> >> >> Cheers, >> >> Med >> >> >> >> PS: Please see below for more context. >> >> >> >> De : Greg Mirsky <[email protected] <mailto:[email protected]>> >> Envoyé : mercredi 4 juin 2025 07:32 >> À : Carlos Pignataro <[email protected] <mailto:[email protected]>> >> Cc : Ops Area WG <[email protected] <mailto:[email protected]>> >> Objet : [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 <[email protected] >> <mailto:[email protected]>> 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 7:49 PM, Greg Mirsky <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> Hi Tal, >> >> thank you for explaining updates. Please find my follow-up notes below >> tagged GIM>>. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Thu, May 29, 2025 at 5:59 PM Tal Mizrahi <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Greg, >> >> Thanks again for reviewing the draft. Your comments for the previous >> versions have helped in improving 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 <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > Hi Tal, >> > >> > Thank you for your work on addressing my comments. I reviewed the working >> > version of the draft and have some comments and questions, which are below. >> > Section 2: >> > >> > It is noted that "A frequently encountered case is the use of "in-band" to >> > mean either in-packet or on-path." If that is the case, and there are many >> > IETF documents that use these interpretations of "in-band," it seems like >> > it would be easy to provide several references in support of that >> > assumption. >> >> [TM] Following your comment we have focused the following two paragraphs. >> The following paragraph demonstrates the use of the term "in-band" in >> the context of path-congruent OAM: >> >> Connectivity Verification (VCCV), described is Section 6 of >> [RFC5085] as "The VCCV message travels in-band with the Session >> and follows the exact same path as the user data for the session". >> Thus, 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. >> >> GIM>> I don't think that your interpretation of "in-band" in RFC 5085 is >> accurate. The VCCV message not only traverses the same path as a data packet >> because the same labels are applied along the path, but it also receives the >> same forwarding treatment by the network because the same Traffic Class is >> used for the VCCV message as for the data packet. Thus, it is in-band with >> the monitored data flow, and topological equivalence is only one element, >> while it must be complemented by the QoS equivalence. >> >> >> >> CMP: As an author of RFC 5085, I can confirm that you are completely wrong >> on this. >> >> GIM2>> That is your personal opinion, not the opinion of other authors, and >> even less the opinion of PWE3 (later PALS) WG. As the PALS WG is winding >> down, the MPLS WG may be the community to provide a more authoritative >> interpretation of RFC 5085. >> >> >> >> CMP: That said, you do not need to be an author to know this, you can >> actually **read** the RFC, where it says: >> >> CMP: "in-band (i.e., following the same data-plane faith as PW data).” >> >> CMP: “ travels in-band with the Session and follows the exact same path as >> the user data for the session" >> >> CMP: Let’s not make up ‘interpretations’. >> >> >> >> >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
