Greg: Thank you for sharing your belief.
Unless you can reference supporting material related RFC 5085 to substantiate this belief, I would suggest starting a new thread, as this topic diverges from the scope of draft-ietf-opsawg-oam-characterization. > GIM>> I believe that both, QoS treatment and OAM packets traversing the same, > i.e., identical, path are critical to obtaining the most operationally useful > measurement results. However, examples have already been shared showing that this is not universally the case. You’ve also been asked multiple times to provide references supporting your views. Best, Carlos. > On Jun 7, 2025, at 12:38 AM, Greg Mirsky <[email protected]> wrote: > > Hi Matthew, > thank you for sharing your thoughts and helping me see the issue from a > different point. Please find my notes below tagged GIM2>>. > > Regards, > Greg > > On Fri, Jun 6, 2025 at 7:15 PM Matthew Bocci (Nokia) <[email protected] > <mailto:[email protected]>> wrote: >> Hi Greg >> >> >> >> “In-flow” might be confused with “in-situ”. >> > GIM>> That similarity is non-technical, historical, and , IMO, unfortunate. >> Even if you send OAM PM to follow the exact same data path, they may not be >> treated in the same way as user data depending on the QoS mechanisms acting >> on a given queue, whether they have the same mix of drop precedence, etc. >> > GIM>> I agree, that coule be the case, e.g., in the ECMP environment. But if > that is the case, then we cannot claim the topological equivalence, right? > And then it is not "in-band" and some black magic (or use the explicit source > of entropy) must be used to ensure that OAM is "in-band" with the monitored > flow. >> >> >> I think it would be better not to make assumptions about the QoS and >> congestion control algorithms in use, and that just sending a packet of one >> protocol along the same data path as another protocol guarantees the same >> QoS treatment. Instead, maybe you could make a statement that PM relies on >> OAM packets being treated in the same way as user data packets, without >> getting into the data path details. >> > GIM>> I believe that both, QoS treatment and OAM packets traversing the same, > i.e., identical, path are critical to obtaining the most operationally useful > measurement results. Consider ECMP environment that includes path A and B > between the same pair of nodes. If data flow is on path A, and OAM packets > are consistently routed 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 <[email protected] <mailto:[email protected]>> >> Date: Friday, 6 June 2025 at 01:56 >> 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, >> >> thank you for clarifying how my earlier notes came across. I agree with you >> that for some OAM functions, e.g., as you pointed out, FEC/label binding, >> QoS equivalence between the QoS treatments received by an OAM packet and the >> monitored data flow is not required. For some OAM functions, even the >> topological equivalence between paths traversed by OAM packets and monitored >> data packets may not be required, for example, direct loss measurement. >> These would be examples of out-of-bound OAM. However, for some OAM >> functions, such as performance measurement using the active OAM method, >> having equivalence between both topological and QoS aspects makes the >> results of the observation more operationally useful. Regarding the use of >> "in-band" in RFC 5085, it is possible that the requirements for performance >> measurement using active OAM were outside the scope. (I couldn't find them >> being discussed in RFC 5085 or any later specification on the applicability >> of active measurement methods in PWs before draft-gandhi-mpls-stamp-pw >> <https://datatracker.ietf.org/doc/draft-gandhi-mpls-stamp-pw/>.) >> >> >> >> Earlier, I proposed to use "in-flow/out-of-flow" to characterize the >> relationship between OAM packets and data flow. WDYT? >> >> >> >> Regards, >> >> Greg >> >> >> >> >> >> On Thu, Jun 5, 2025 at 6:37 PM Matthew Bocci (Nokia) >> <[email protected] <mailto:[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] > To unsubscribe send an email to [email protected]
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
