[OPSAWG]Re: Path-Congruent/In-Flow (was RE: Re: RFC 5085/PALS/PWE3 ...")

[Adrian Farrel <[e-mail]>]

Ah, yes.
Q: When is a network not a network?
A: When it's a network.

Perhaps s/within a network/within a layer network/

A

-----Original Message-----
From: tom petch <[e-mail]> 
Sent: 11 June 2025 12:26
To: Tal Mizrahi <[e-mail]>; [e-mail]; Ops Area WG <[e-mail]>
Subject: [OPSAWG]Re: Path-Congruent/In-Flow (was RE: Re: RFC 5085/PALS/PWE3 ...")

From: Tal Mizrahi <[e-mail]>
Sent: 10 June 2025 07:15

Hi Med, All,

> @Adrian/Tal/Carlos propose a definition of what they put behind “congruent”

We propose adding the following text to the draft in order to clarify
the term congruent:

          In this document, the term "path-congruent packets"
describes packets that follow the exact same path (i.e., traverse the
same nodes and links) within a network. Note that this definition does
not describe how the packets are treated in queues within the nodes on
the path. A further concept, "equal-forwarding-treatment" describes
how path-congruent packets receive the same forwarding treatment
(e.g., Quality of Service (QoS)).

If this makes sense, we will go ahead and include this clarification
in the next version of the document.

<tp>
I still see an ambiguity there which may or may not be wanted.  Most networks are nested, one network within another such as IPv4 being carried over IPv6 or - perhaps more common here - MPLS within IPv4.

So how far down the stack does the congruence have to go?  Is it just at the outer IP layer or should it encompass all the layers that the IETF deals with?  (non-IETF networks at still  lower layers can look after themselves!)

Tom Petch
 
Thanks,
The authors.



On Fri, Jun 6, 2025 at 12:57 PM <[e-mail]> wrote:
>
> Hi all,
>
>
>
> (changing the subject to ease tracking the discussion)
>
>
>
> At least from where I sit, I think that that the inputs from Andy/ Matthew kindly helped to clarify the assumptions on the QoS treatment.
>
>
>
> Now, focusing on this part of the discussion where Greg suggests:
>
>
>
>    *  In-flow OAM is an active or hybrid OAM method, as defined in
>
>       [RFC7799], that traverses the same set of links and interfaces and
>
>       receives the same Quality of Service treatment as the monitored
>
>       object.
>
>
>
> Which is inspired by RFC9772:
>
>
>
>    *  In-band OAM is an active or hybrid OAM method, as defined in
>
>       [RFC7799], that traverses the same set of links and interfaces and
>
>       receives the same Quality of Service treatment as the monitored
>
>       object.  In this context, the monitored object refers to either
>
>       the entire Geneve tunnel or a specific tenant flow within a given
>
>       Geneve tunnel.
>
>
>
> I have some clarification questions for Greg:
>
>
>
> is this a proposal for replacement to the following terms or are these new terms?
>
>
>
>
>
> CURRENT:
>
>       Path-Congruent OAM:
>
>          The OAM information follows the exact same path as the observed
>
>          data traffic.  This was sometimes referred to as "in-band".
>
>
>
>       Non-Path-Congruent OAM:
>
>          The OAM information does not follow the exact same path as the
>
>          observed data traffic.  This can also be called Path-
>
>          Incongruent OAM, and was sometimes referred to as "out-of-
>
>          band".
>
>
>
> If so, taking into account the feedback received in the discussion with with Andy, why the assumption on QoS is part of the definition?
> Being part of a flow (as suggested by in-flow) does not guarantee that the same path will be followed, for reasons that you know (multipathing, load-balancing, etc.).
>
>
>
> In order to make progress here, can I suggest that:
>
>
>
> @Adrian/Tal/Carlos propose a definition of what they put behind “congruent”
> @All: discuss the definition and converge
> See if we need a better term to capture that definition
>
> Thank you.
>
>
>
> Cheers
>
> Med
>
>
>
> De : Greg Mirsky <[e-mail]>
> Envoyé : vendredi 6 juin 2025 06:37
> À : [e-mail]
> Cc : Matthew Bocci (Nokia) <[e-mail]>; Andrew G. Malis <[e-mail]>; Ops Area WG <[e-mail]>; Carlos Pignataro <[e-mail]>
> Objet : [OPSAWG]Re: RFC 5085/PALS/PWE3 (RE: Re: WG LAST CALL: Guidelines for Charactering "OAM"
>
>
>
>
>
> Hi Adrian,
>
> Thank you for your detailed and thoughtful response. Please find my notes below tagged GIM2>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Jun 5, 2025 at 7:24 PM Adrian Farrel <[e-mail]> wrote:
>
> Geometry may possibly be a rather specialist use of an English language term. The usage here is not colloquial.
>
>
>
> Picking an online dictionary at random…
>
> (The American Heritage® Dictionary of the English Language, 5th Edition)
>
> adjective
>
> Corresponding; congruous
>
> Possessing congruity; suitable; agreeing; corresponding.
>
> Corresponding in character
>
> GIM>> Synchronizing disctionaries is very helpful for a productive discussion. I looked at the interpretation of "congruent" in the Cambridge disctionary One of the examples seems very relevant to our discussion:
>
> Congruent segments geometry
>
>
>
> Congruent segments are segments (= parts of a line) that are the same length.
>
>
>
> The Merriam-Webster dictionary gives the following very generic interpretation:
>
> congruent
>
> adjective
>
> con·gru·ent kən-ˈgrü-ənt  ˈkäŋ-grə-wənt
>
> : having the same size and shape : capable of being placed over another figure and exactly matching
>
> My understanding of how "congruent" is used in IETF documents differs significantly from the interpretation outside the IETF. If that is the case, how is defining the IETF-specific interpretation of "congruent" more and more advantageous, a better way to use consistent and intuitive terminology compared to describing the IETF-specific interpretation of "in-band"?
>
>
>
> Further, as indicated in the draft, this term is used (and defined) in RFC 6669.
>
> GIM>> Unless I am missing it, in RFC 6669 congruent is defined through "in-band":
>
>       OAM packets and the user traffic are congruent (i.e., OAM packets
>
>       are transmitted in-band) ...
>
> The concept of “congruent routes” is found in RFC 2362, and congruent topologies in RFC 2796 and RFC 4257/8.
>
> There are many other RFCs that talk about congruent topologies, and I don’t think any of them means, “Of the same shape or connectivity so that one could be mapped to the other through an isomorphic transposition.”
>
> GIM>> If we compare number of RFCs that use "congruent" and use "in-band", I think that it will be pretty close outcome.
>
>
>
> Notwithstanding this, if Greg finds this word to be confusing we should assume that other readers of similar education may be similarly confused.
>
> I think the best solution is to include a careful definition of “congruent”.
>
> GIM>> Thank you for your kind consideration, Adrian. I proposed a pair of new terms, "in-flow/out-of-the-flow", defined, with minor update, as in RFC 9772:
>
>    *  In-flow OAM is an active or hybrid OAM method, as defined in
>
>       [RFC7799], that traverses the same set of links and interfaces and
>
>       receives the same Quality of Service treatment as the monitored
>
>       object.
>
> Hybrid OAM natively is in-flow OAM. Ensuring the active OAM method is used as in-flow OAM usually requires special considerations. What are your thoughts?
>
>
>
> Cheers,
>
> Adrian
>
>
>
>
>
> ____________________________________________________________________________________________________________
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

_______________________________________________
OPSAWG mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
_______________________________________________
OPSAWG mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]