Dear all,
Taking this email as an anchor for the longer discussion on the list...
Given that no objections were raised since almost one month, we conclude
that the proposal made by the authors in
draft-ietf-opsawg-oam-characterization-08 resolves this issue. Also,
thanks Andy and Matthew for the help to clarify the intent of RFC 5085
Regards, Joe and Benoit
On 6/6/2025 10:56 AM, [email protected] 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 <[email protected]>
*Envoyé :* vendredi 6 juin 2025 06:37
*À :* [email protected]
*Cc :* Matthew Bocci (Nokia) <[email protected]>; Andrew G.
Malis <[email protected]>; Ops Area WG <[email protected]>; Carlos
Pignataro <[email protected]>
*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 <[email protected]> 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*
1. Corresponding; congruous
4. Possessing congruity; suitable; agreeing; corresponding.
6. Corresponding in character
GIM>> Synchronizing disctionaries is very helpful for a productive
discussion. I looked at the interpretation of "congruent" in the
Cambridge disctionary
<https://dictionary.cambridge.org/dictionary/english/congruent> 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
<https://www.merriam-webster.com/dictionary/congruent> 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 [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
