Greg, Just a couple quick follow-ups to wrap things up, labeled “CMP_Again”, trimming the long parts for clarity.
> On Jun 4, 2025, at 1:31 AM, Greg Mirsky <[email protected]> wrote: > >>> 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_Again: I posted actual text from the RFC, right below. CMP_Again: If you want to provide a different “interpretation” than the actual clear text, it is on you to provide pointers. CMP_Again: CMP_Again: For example, If I were to say: CMP_Again: “Well, RFC 5085 actually means that ‘in-band’ means traversing the same paths on Wednesday nights, with packets longer than 120 octets, that contain ascii for a smiley face”, it would be on me to show pointers for that “interpretation” CMP_Again: CMP_Again: I do not see anyone needing clarity here… >> >> 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’. >> […] >>> GIM>> I find historical references not relevant to my questions. >>> Furthermore, AFAICS, [I-D.song-opsawg-ifit-framework], and >>> [I-D.kumar-ippm-ifa], as individual drafts, do not reflect an agreement of >>> any of IETF WGs. Additionally, both individual drafts have been expired for >>> over 6 months. On the other hand, several RFCs published by IETF, e.g., RFC >>> 9772 <https://datatracker.ietf.org/doc/rfc9772/> give clear and useful >>> interpretation of >> >> CMP: This is *exactly* the problem that we are trying to solve with this >> document, and truly an argument for moving forward with this document. >> CMP: You are citing protocol-specific context-specific wg-specific >> definitions. >> CMP: If the goal is to write a lot of RFCs with almost overlapping text, >> sure. >> CMP: If the goal is clarity and removing ambiguity, the per-protocol >> approach does not work. > GIM2>> Before trying to normalize terminology, one needs to understand that > both topological and forwarding equivencies between OAM and the monitored > data flow must be provided to make the results of OAM observation viable. CMP_Again: Eh? CMP_Again: Without a normative reference, this feels a bit abstract… almost, like, handwaving… CMP_Again: What if someone says “one needs to understand the lunar phase at the time of monitoring?” CMP_Again: and a third individual adds “and one needs to understand the spacio-temporal delta between data and OAM” > What is the value of, e.g., performance measurement, if there is only > topological equivalency between data and OAM flows, but respective packets > receive different forwarding treatment from the network? On the other hand, > what would be the operational value of the network detection while the > topological equivalency is not ensured, but only the forwarding equivalency > is? The answer is evident in both cases - no value. That is why I am asking > about the benefit of defining two characteristics, which only complicates the > definition of what is required from an OAM to be a viable operational tool. CMP_Again: Interesting framing, it just does not hold… CMP_Again: “the answer is evident” is a rhetorical shortcut — not having proved anything. The conclusion of “no value” rests on unexplained assumptions and a false premise. CMP_Again: CMP_Again: Let me share text, instead of insubstantial language: rfc9772 says topology and Qos for the tunnel or sub-flow; rfc9780 and rfc9571 say only topology; rfc9551 says topology, qos, and PREOF, but not sub-flows. This is the risk you are introducing. […] >>>> There are many examples of "in-band OAM" and "out-of-band OAM" in >>>> published RFCs. For instance, the term "in-band" appears in both >>>> [RFC5085] and [RFC9551]. While the context in each of these >>>> documents is clear, the term carries different meanings in each case. >>> GIM>> As noted above, I find that the interpretations of "in-band OAM" in >>> RFC 5085, RFC 9551 (and RFC 9772) are, if not identical, then very close, >>> as both require topological and QoS equivalencies between OAM and data >>> packets. >> >> CMP: Clearly you are “reading’ much beyond the words on the RFCs. RFC 5085 >> did not consider QoS. >> CMP: Please search all archives and share one mention of QoS along with 5085. >> CMP: Now, “the very close” is the whole problem. You are inclined in >> defining the same term, in-band, with **very close** but not the same >> definitions per WG... > GIM2>> Asked and answered. If the OPSAWG is looking for the authoritative > opinion on RFC 5085, it would be reasonable to post the question to the MPLS > WG. CMP_Again: There was no question asked here… where is the “asked and answered”? CMP_Again: Please read again: “Please search all archives and share one mention of QoS along with 5085” CMP_Again: Otherwise, the conversation is being artificially derailed and delayed. CMP_Again: I have not seen "OPSAWG looking for the authoritative opinion on RFC 5085”… if you believe a particular interpretation that is not written in the RFC, it really is on you to show the rationale (assuming it is rational) Best, Carlos. >>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
