Tal, Adrian, WG, Capturing from Matthew's second paragraph, this sounds like a great definition to include:
paths are congruent if when one is superimposed on the other, they are the same. Thanks, Carlos. > On Jun 5, 2025, at 5:37 AM, Matthew Bocci (Nokia) > <[email protected]> wrote: > > Hi Greg > > Thanks for the reference to your previous conversation. I was referring to > your statement that the QoS treatment of VCCV must always be the same as the > user data. The use case you describe in that thread is one case that I don’t > think you can generalise, and conflates congestion with loss of > connectivity/reachability, which I am not sure is valid. Also, VCCV has other > functions like checking the FEC/label bindings along the path and at the > endpoints of the PW, which may need to succeed in the presence of congestion. > What I am saying is that ‘must’ is too strong a term, and the QoS treatment > should be left up to the operator depending on the use case. > > “Superimpose” means to lay a thing on something else. I think it is > reasonable to say that paths are congruent if when one is superimposed on the > other, they are the same. Maybe you are thinking of “transpose”? I do agree > with you that we should have better-defined what it means in networking. > > Best regards > Matthew > > > From: Greg Mirsky <[email protected] <mailto:[email protected]>> > Date: Thursday, 5 June 2025 at 01:41 > To: Matthew Bocci (Nokia) <[email protected] > <mailto:[email protected]>> > Cc: [email protected] > <mailto:[email protected]><[email protected] > <mailto:[email protected]>>, Andrew G. Malis <[email protected] > <mailto:[email protected]>>, Stewart Bryant <[email protected] > <mailto:[email protected]>>, Ops Area WG <[email protected] > <mailto:[email protected]>>, Carlos Pignataro <[email protected] > <mailto:[email protected]>> > Subject: Re: RFC 5085/PALS/PWE3 (RE: [OPSAWG]Re: WG LAST CALL: Guidelines for > Charactering "OAM" > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext <http://nok.it/ext> for > additional information. > > > Hi Matthew, > In another email thread related to this draft, Tal and I discussed a similar > scenario > <https://mailarchive.ietf.org/arch/msg/opsawg/isseTIy5uTZYl-K-oVAoV_yf5iE/> > in which proactive defect detection for a multi-CoS flow utilizes a single > OAM session. As in the discussed example of ETH-CC, using VCCV-BFD at higher > CoS might create false positives for the lower CoS sub-flows since there is > no definition of what constitutes a "short bursts of congestion" and when > such bursts must be handled as a loss of connectivity for the particular CoS. > Also, I'm confused by the colloquial use of "congruent", which is not > consistent with the definition of the term: > Geometry > (of figures) identical in form; coinciding exactly when superimposed. > As I understand it, "superimposed" includes transformations such as shift, > flip, and rotate. For example, semi-circles are congruent, but that is not > what is required for an OAM packet. Would you agree? That re-definition of > the fundamental term in geometry is inappropriate, and I consider "in-band" a > clearer term for demonstrating the required topological equivalency between > the path traversed by an OAM packet and the data packet of the monitored flow. > Regards, > Greg > > On Wed, Jun 4, 2025 at 8:49 PM Matthew Bocci (Nokia) <[email protected] > <mailto:[email protected]>> wrote: > Hi Med > > My interpretation and experience of this is that in-band means that the > encapsulation is such that the OAM packets flow on the same tunnel and PW as > the user data of that PW. This means that the paths are congruent from an > MPLS / PWE3 perspective (same P and PE routers). I am not sure that it is > strictly correct to conflate in-band with congruent. If VCCV packets are sent > in-band then they are congruent with the PW user data, but in general the > term congruent does not imply they are in-band. > > RFC6669 was written from an MPLS-TP perspective where bidirectional paths > were intended to be congruent (see RFC5921). I believe that text quoted below > from RFC6669 really meant that the OAM packets are sent in-band to achieve > congruency. > > I don’t think it means the QoS treatment *must* always be the same between > VCCV and user data on a given PW. For example, there are cases such as > VCCV-BFD where you are doing a continuity check that should not be affected > by short bursts of congestion that might affect the user packets (which would > be measured by some other OAM such as PM) but must nonetheless follow the > same PW. > > Best regards > > Matthew > > > From: [email protected] > <mailto:[email protected]><[email protected] > <mailto:[email protected]>> > Date: Wednesday, 4 June 2025 at 09:48 > To: Andrew G. Malis <[email protected] <mailto:[email protected]>>, Stewart > Bryant <[email protected] <mailto:[email protected]>>, Matthew > Bocci (Nokia) <[email protected] <mailto:[email protected]>> > Cc: Ops Area WG <[email protected] <mailto:[email protected]>>, Carlos Pignataro > <[email protected] <mailto:[email protected]>>, Greg Mirsky > <[email protected] <mailto:[email protected]>> > Subject: RFC 5085/PALS/PWE3 (RE: [OPSAWG]Re: WG LAST CALL: Guidelines for > Charactering "OAM" > > 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. > _______________________________________________ > OPSAWG mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
