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]> 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]> > *Envoyé :* mercredi 4 juin 2025 07:32 > *À :* Carlos Pignataro <[email protected]> > *Cc :* Ops Area WG <[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]> > 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]> 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]> > 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]> 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. > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
