Subject: Re: [Raw] [Detnet] OAM terms

From: <[email-masked]>
Date: Wed, 7 Jul 2021 04:50:21 +0800 (CST)

Hi Pascal,
thank you for driving this important discussion. I wholeheartedly agree that consistency in terminology is fundamental for the successful development of technology as that helps us to communicate, avoiding unnecessary arguments and misunderstandings.
Please find my notes in-lined below under the tag GIM>>.

Kind regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [email-masked]
www.zte.com.cn
------------------Original Mail------------------
Sender: PascalThubert(pthubert)
To: DetNet WG;[email-masked];
CC: Fabrice Theoleyre;Black, David;gregory mirsky10211915;Balázs Varga A;Janos Farkas;
Date: 2021/07/06 07:03
Subject: [Detnet] OAM terms
_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

Dear all
There’s a need in the DetNet OAM framework and in the RAW architecture/framework to agree on definitions that can be used on both sides to mean the same thing. At the DetNet OAM  call today, we agreed to work on that issue before cut off and publish aligned documents.
As a starting point, please find below the current text in the RAW document, largely based on a mix of RFC 6291 ans Greg’s sentences in the previous thread on this subject; you’ll  note the 2 original terms for reverse OAM and Limited OAM that need more refining.
Fire at will!
Pascal
AOM:
GIM>> This seems as a typo. s/AOM/OAM?
OAM stands for Operations, Administration, and Maintenance, and
covers the processes, activities, tools, and standards involved
with operating, administering, managing and maintaining any
system.  This document uses the terms Operations, Administration,
and Maintenance, in conformance with the IETF 'Guidelines for the
Use of the "OAM" Acronym in the IETF' [RFC6291] and the system
observed by the RAW OAM is the Track.
Active OAM:  Active OAM uses specially constructed test packets
crafted to observe a particular Track, subTrack, or Segment of a
Track.
GIM>> Perhaps adding a reference to RFC 7799 Active and Passive Metrics and Methods (with Hybrid Types in-Between)? RFC 7799 provides clear definitions for Active, Passive, and Hybrid OAM methods, particularly when classifying Performance Monitoring OAM protocols.
In-Band OAM:  An active OAM packet is considered in-band in the
monitored Track when it traverses the same set of links and
interfaces receiving the same QoS and PAREO treatment as the data
flows that are injected in the Track.
Out-of-Band OAM:  An active OAM packet is out-of-band if its datapath
is topologically the same as of that of the Track, subTrack or
Segment being observed, but the QoS or PAREO treatment is
different (e.g., lower CoS).
GIM>> I agree that that is a good example of out-of-band active OAM. Also, an out-of-band OAM may be using a diverse path, e.g., management network. Below is the text from the updated version of draft-ietf-detnet-oam-framework:
   Out-of-band OAM is an active OAM whose path through the DetNet domain is not topologically identical to the
   path of the monitored DetNet flow, or its test packets receive different QoS and/or PREOF treatment, or both.

Limited OAM:  An active OAM packet is a Limited OAM packet when it is
observes the RAW operation over a node, a segment, or a subTrack
of the Track, though not from Ingress to Egress.  It is injected
in the datapath and extracted from the datapath around the
particular function or subnetwork (e.g., around a relay providing
a service layer replication point) that is being tested.
GIM>> Can a node, a subTrack, and a segment be considered as examples of the same construct? In the course of describing OAM in MPLS-TP, a Sub-Path Maintenance Element was introduced in Section 3.13 of RFC 5921 (https://datatracker.ietf.org/doc/html/rfc5921#section-3.13). An SPME is needed in the MPLS data plane because an active OAM packet cannot be injected into an LSP by an LSR (only LER can inject a test packet). An SPME is a hierarchical LSP that tunnels a section of the transport LSP and creates MEPs at the section's end-points. Can we re-use any of MPLS-TP OAM terminology (even though no one likes to be reminded of MPLS-TP)?

Reverse OAM:  A Reverse OAM packet is an Out-of-Band OAM packet that
traverses the Track from West to East and North-South in one of
either direction, to capture and report OAM measurements upstream.
GIM>> As this is one method of collecting telemetry information, could it be described without giving it a distinct name?

---

From: "Wangyali(Yali,Data Communication Standards and Patents Dept)" <[email-masked]>
Date: Wed, 7 Jul 2021 07:42:44 +0000

Hi Greg and Pascal,
Glad to join in this discussion. Please find my questions and notes inline Yali>>.
Thanks,
Yali

-----Original Message-----
From: RAW [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 7, 2021 4:50 AM
To: pthubert=[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Raw] [Detnet] OAM terms

Hi Pascal,

Kind regards,
Greg Mirsky
------------------Original Mail------------------
Sender: PascalThubert(pthubert)
To: DetNet WG;[email-masked];
CC: Fabrice Theoleyre;Black, David;gregory mirsky10211915;Balázs Varga A;Janos Farkas;
Date: 2021/07/06 07:03
Subject: [Detnet] OAM terms

Dear all
There’s a need in the DetNet OAM framework and in the RAW architecture/framework to agree on definitions that can be used on both sides to mean the same thing. At the DetNet OAM  call today, we agreed to work on that issue before cut off and publish aligned documents.
As a starting point, please find below the current text in the RAW document, largely based on a mix of RFC 6291 ans Greg’s sentences in the previous thread on this subject; you’ll  note the 2 original terms for reverse OAM and Limited OAM that need more refining.
Fire at will!
Pascal
AOM:
GIM>> This seems as a typo. s/AOM/OAM?
OAM stands for Operations, Administration, and Maintenance, and covers the processes, activities, tools, and standards involved with operating, administering, managing and maintaining any system.  This document uses the terms Operations, Administration, and Maintenance, in conformance with the IETF 'Guidelines for the Use of the "OAM" Acronym in the IETF' [RFC6291] and the system observed by the RAW OAM is the Track.
Yali>> As described in this sentence that '' the system observed by the RAW OAM is the Track'' and based on my understand after reading the draft-pthubert-raw-architecture-08 and draft-ietf-raw-oam-support-02, the Track is categorized as  a simple Track and a complex Track, which stands for a multi-hop path or multi-hop N-ECMP. So my question is that do we only consider the Track (i.e. path) monitored in the RAW OAM domain? Or do we also consider the RAW flow? If the RAW flow for measuring its performance metrics, I suggest to fill up a RAW flow in this sentence " the system observed by the RAW OAM is the Track and a RAW flow".

Active OAM:  Active OAM uses specially constructed test packets crafted to observe a particular Track, subTrack, or Segment of a Track.
GIM>> Perhaps adding a reference to RFC 7799 Active and Passive Metrics and Methods (with Hybrid Types in-Between)? RFC 7799 provides clear definitions for Active, Passive, and Hybrid OAM methods, particularly when classifying Performance Monitoring OAM protocols.

In-Band OAM:  An active OAM packet is considered in-band in the monitored Track when it traverses the same set of links and interfaces receiving the same QoS and PAREO treatment as the data flows that are injected in the Track.
Out-of-Band OAM:  An active OAM packet is out-of-band if its datapath is topologically the same as of that of the Track, subTrack or Segment being observed, but the QoS or PAREO treatment is different (e.g., lower CoS).
GIM>> I agree that that is a good example of out-of-band active OAM. Also, an out-of-band OAM may be using a diverse path, e.g., management network. Below is the text from the updated version of draft-ietf-detnet-oam-framework:
   Out-of-band OAM is an active OAM whose path through the DetNet domain is not topologically identical to the
   path of the monitored DetNet flow, or its test packets receive different QoS and/or PREOF treatment, or both.
Yali>> Do we also consider "in-situ" OAM?

Limited OAM:  An active OAM packet is a Limited OAM packet when it is observes the RAW operation over a node, a segment, or a subTrack of the Track, though not from Ingress to Egress.  It is injected in the datapath and extracted from the datapath around the particular function or subnetwork (e.g., around a relay providing a service layer replication point) that is being tested.
GIM>> Can a node, a subTrack, and a segment be considered as examples of the same construct? In the course of describing OAM in MPLS-TP, a Sub-Path Maintenance Element was introduced in Section 3.13 of RFC 5921 (https://datatracker.ietf.org/doc/html/rfc5921#section-3.13). An SPME is needed in the MPLS data plane because an active OAM packet cannot be injected into an LSP by an LSR (only LER can inject a test packet). An SPME is a hierarchical LSP that tunnels a section of the transport LSP and creates MEPs at the section's end-points. Can we re-use any of MPLS-TP OAM terminology (even though no one likes to be reminded of MPLS-TP)?

Reverse OAM:  A Reverse OAM packet is an Out-of-Band OAM packet that traverses the Track from West to East and North-South in one of either direction, to capture and report OAM measurements upstream.
GIM>> As this is one method of collecting telemetry information, could 
GIM>> it be described without giving it a distinct name?
Yali>> Does "Reverse OAM'' mean a packet generated by egress node and copy measurements metrics from Forward OAM packet, then transmitted by egress node to ingress node? If it is, my consider is that the "Reverse OAM" packet may not traverse the same Track with the "Forward OAM" packet traverses along. Besides, what's the North-South Track?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Jul 2021 13:33:27 +0000

Hello Greg:

Many thanks!

> GIM>> This seems as a typo. s/AOM/OAM?

Yes typo sorry

> OAM stands for Operations, Administration, and Maintenance, and covers the
> processes, activities, tools, and standards involved with operating,
> administering, managing and maintaining any system.  This document uses
> the terms Operations, Administration, and Maintenance, in conformance with
> the IETF 'Guidelines for the Use of the "OAM" Acronym in the IETF'
> [RFC6291] and the system observed by the RAW OAM is the Track.
> Active OAM:  Active OAM uses specially constructed test packets crafted to
> observe a particular Track, subTrack, or Segment of a Track.

> GIM>> Perhaps adding a reference to RFC 7799 Active and Passive Metrics
> and Methods (with Hybrid Types in-Between)? RFC 7799 provides clear
> definitions for Active, Passive, and Hybrid OAM methods, particularly when
> classifying Performance Monitoring OAM protocols.

Added in supplemental text

> In-Band OAM:  An active OAM packet is considered in-band in the monitored
> Track when it traverses the same set of links and interfaces receiving the
> same QoS and PAREO treatment as the data flows that are injected in the
> Track.
> Out-of-Band OAM:  An active OAM packet is out-of-band if its datapath is
> topologically the same as of that of the Track, subTrack or Segment being
> observed, but the QoS or PAREO treatment is different (e.g., lower CoS).

> GIM>> I agree that that is a good example of out-of-band active OAM. Also,
> an out-of-band OAM may be using a diverse path, e.g., management network.
> Below is the text from the updated version of draft-ietf-detnet-oam-
> framework:
>    path of the monitored DetNet flow, or its test packets receive
> different QoS and/or PREOF treatment, or both.

I adapted that new text to RAW 

> observes the RAW operation over a node, a segment, or a subTrack of the
> Track, though not from Ingress to Egress.  It is injected in the datapath
> and extracted from the datapath around the particular function or
> subnetwork (e.g., around a relay providing a service layer replication
> point) that is being tested.

> GIM>> Can a node, a subTrack, and a segment be considered as examples of
> the same construct? In the course of describing OAM in MPLS-TP, a Sub-Path
> Maintenance Element was introduced in Section 3.13 of RFC 5921
> (https://datatracker.ietf.org/doc/html/rfc5921#section-3.13). An SPME is
> needed in the MPLS data plane because an active OAM packet cannot be
> injected into an LSP by an LSR (only LER can inject a test packet). An
> SPME is a hierarchical LSP that tunnels a section of the transport LSP and
> creates MEPs at the section's end-points. Can we re-use any of MPLS-TP OAM
> terminology (even though no one likes to be reminded of MPLS-TP)?

A Track is a networking graph where the edges are Segments and the vertices are (service layer) detnet relays, where a Segment is a sequence of Links connected by (forwarding layer) detnet transit nodes.
I believe these are all different concepts. 

That terminology seems useful beyond RAW though, because the term path is really anything and everything, see the definition of path in RFC 9049 vs. the detnet expectations. As you know there's hardly anything better than an approximate terminology to be completely misunderstood.

On the bright side, the logic of defining a sub-Track is consistent with that of defining a sub-path.

> traverses the Track from West to East and North-South in one of either
> direction, to capture and report OAM measurements upstream.

The term is used in the main text. It appears useful. But are you saying that it is misleading?

Many thanks!

Pascal

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 7 Jul 2021 14:58:50 +0000

Hi Pascal, All,

thanks for the initiatives and the great suggestions. I think before 
editing/fine-tuning the definitions we may need a common understanding,
what minimum terminology is necessary.

We may want to characterize an OAM session with just two characteristics:
(I.) what path OAM packets are using during forwarding and 
(II.) what resources OAM packets are using during forwarding.

General comments:
1, The terms MEP/MIP are well anchored with OAM. It would be great to
use them.
2, Discussion on the position of the originator entity of an OAM session.
This entity is a MEP. In my view this is an essential part of OAM discussion.
I fully support Greg's comment in this email-thread regarding the 
"Sub-Path Maintenance Element".
3, I have found terms "Track/SubTrack/Segment of a Track" confusing.
No such terms are defined for DetNet. If needed they have to be 
specified as well, but in my view they all refer to an OAM session 
between two MEPs (i.e., the originator MEP and the targeted MEP).

More in particular:
4, I am OK with the following terms after some massage:
- OAM: I am fine with the definition
- Active OAM: I would prefer a definition based on MEPs
- In-Band/Out-of-Band OAM: I would prefer a definition based on MEPs (and not Track)

5, I am not sure we need these definitions:
- Limited OAM: depends on the result of the originator-MEP placement discussion
whether such a term is needed (see item 3). This is also an OAM session, but the MEPs 
of the OAM session are not at the source/destination of the flow, but somewhere 
along the path.
- Reverse OAM: this seems to be a response OAM packet of a MEP/MIP sent 
to the originator of the OAM packet. So why not simple call it OAM-Response.
Furthermore, why is it highlighted, that it is an "out-of-band OAM packet"?
E.g., DetNet flows are unidirectional, therefore it cannot be in-band.

Have I missed something?

6, Some other terms may worth for consideration to cover all possible characteristics
(i) how OAM packets are forwarded and (ii) what resources they are using:
- In-path OAM/Out-path OAM: this is a characteristic how OAM packets reach their 
destination. "In-path" means using the same path as the related data flow. Note,
that an in-path OAM session can be in-band (usig the same resources as the dataflow) 
or out-of-band (not using the dataflow resources).
"Out-path" means that any path to destination can be used. Out-path OAM is always
"out-of-band" as well.

Thanks
Bala'zs

-----Original Message-----
From: Pascal Thubert (pthubert) <[email-masked]> 
Sent: Wednesday, July 7, 2021 3:33 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Balázs Varga A <[email-masked]>; Janos Farkas <[email-masked]>
Subject: RE: Re:[Detnet] OAM terms

Hello Greg:

Many thanks!

Yes typo sorry

> OAM stands for Operations, Administration, and Maintenance, and covers 
> the processes, activities, tools, and standards involved with 
> operating, administering, managing and maintaining any system.  This 
> document uses the terms Operations, Administration, and Maintenance, 
> in conformance with the IETF 'Guidelines for the Use of the "OAM" Acronym in the IETF'
> crafted to observe a particular Track, subTrack, or Segment of a Track.

> GIM>> Perhaps adding a reference to RFC 7799 Active and Passive 
> GIM>> Metrics
> definitions for Active, Passive, and Hybrid OAM methods, particularly 
> when classifying Performance Monitoring OAM protocols.

> monitored Track when it traverses the same set of links and interfaces 
> receiving the same QoS and PAREO treatment as the data flows that are 
> injected in the Track.
> is topologically the same as of that of the Track, subTrack or Segment 
> being observed, but the QoS or PAREO treatment is different (e.g., lower CoS).

> GIM>> I agree that that is a good example of out-of-band active OAM. 
> GIM>> Also,
>    Out-of-band OAM is an active OAM whose path through the DetNet 
> domain is not topologically identical to the

> observes the RAW operation over a node, a segment, or a subTrack of 
> the Track, though not from Ingress to Egress.  It is injected in the 
> datapath and extracted from the datapath around the particular 
> function or subnetwork (e.g., around a relay providing a service layer 
> replication

> GIM>> Can a node, a subTrack, and a segment be considered as examples 
> GIM>> of
> the same construct? In the course of describing OAM in MPLS-TP, a 
> Sub-Path Maintenance Element was introduced in Section 3.13 of RFC 
> 5921 (https://datatracker.ietf.org/doc/html/rfc5921#section-3.13). An 
> SPME is needed in the MPLS data plane because an active OAM packet 
> cannot be injected into an LSP by an LSR (only LER can inject a test 
> packet). An SPME is a hierarchical LSP that tunnels a section of the 
> transport LSP and creates MEPs at the section's end-points. Can we 
> re-use any of MPLS-TP OAM terminology (even though no one likes to be reminded of MPLS-TP)?

Many thanks!

Pascal

---

From: <[email-masked]>
Date: Thu, 8 Jul 2021 08:34:45 +0800 (CST)

Hi Pascal,
thank you for your kind consideration of my notes and the detailed answers to questions. I've been thinking about the Reverse OAM. As I understand the use case, please correct me if it is wrong, the goal of a Reverse OAM is not a measurement of any performance metric or making a snapshot of resource utilization, e.g., buffer utilization on ingress/egress interface. As I understand it, the Reverse OAM is to collect compounded, i.e., calculated over a period of time, based on a sequence of singleton metrics, information from nodes traversed by the monitored flow. In other words, the Reverse OAM is tasked with collecting the telemetry information. If that is the case, we may look into extending the HTS to be used in it. Based on my assumption and understanding, I'm updating the HTS draft to make it possible for an arbitrary node to transmit the HTS Follow-up packet with characteristic information of the monitored data flow. As a result, an egress node can transmit such packet di
 recting it towards the ingress of the flow with the engineered path that crosses nodes of interest. What do you think?

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: PascalThubert(pthubert)
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];
Date: 2021/07/07 06:34
Subject: RE: Re:[Detnet] OAM terms
Hello Greg:
Many thanks!
Yes typo sorry

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jul 2021 16:24:01 +0000

Perfect Greg! 

That's exactly how I see it. I already tried to express it in the raw architecture draft (soon to be draft ietf 00). Please look for the discussion on HTS in the OAM section.

Keep safe

Pascal

> From: [email-masked] <[email-masked]>
> Sent: jeudi 8 juillet 2021 2:35
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Re:[Detnet] OAM terms
> 
> Hi Pascal,
> thank you for your kind consideration of my notes and the detailed answers
> to questions. I've been thinking about the Reverse OAM. As I understand
> the use case, please correct me if it is wrong, the goal of a Reverse OAM
> is not a measurement of any performance metric or making a snapshot of
> resource utilization, e.g., buffer utilization on ingress/egress
> interface. As I understand it, the Reverse OAM is to collect compounded,
> i.e., calculated over a period of time, based on a sequence of singleton
> metrics, information from nodes traversed by the monitored flow. In other
> words, the Reverse OAM is tasked with collecting the telemetry
> information. If that is the case, we may look into extending the HTS to be
> used in it. Based on my assumption and understanding, I'm updating the HTS
> draft to make it possible for an arbitrary node to transmit the HTS
> Follow-up packet with characteristic information of the monitored data
> flow. As a result, an egress node can transmit such packet di  recting it
> towards the ingress of the flow with the engineered path that crosses
> nodes of interest. What do you think?
> 
> Regards,
> Greg Mirsky
> 预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline
> Product R&D Institute/Wireline Product Operation Division
> CC:
> [email-masked];[email-masked];[email-masked];[email-masked];bal
> [email-masked];[email-masked];
> Date: 2021/07/07 06:34
> I committed https://raw.githubusercontent.com/raw-wg/raw-
> architecture/main/raw-architecture.txt?token=ABYHN4L5D5UAWDLRS6YK2XTA4WWSE
> for the discussion below, if you can please recheck that we are aligned so
> I can publish; more below:
> > AOM:
> A Track is a networking graph where the edges are Segments and the
> vertices are (service layer) detnet relays, where a Segment is a sequence
> of Links connected by (forwarding layer) detnet transit nodes.
> That terminology seems useful beyond RAW though, because the term path is
> really anything and everything, see the definition of path in RFC 9049 vs.
> the detnet expectations. As you know there's hardly anything better than
> an approximate terminology to be completely misunderstood.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jul 2021 16:33:28 +0000

Hello Balazs

The raw architecture and the detnet OWM drafts have a consistent definition at this very moment. 
I'm open to change e.g. to introduce MEP and stuff, but we need a common agreement with Greg and the DetNet team. 

I agree that the terms Track subTrack and segments are defined in RAW but have been missing so far in DetNet. They inherit from the art of wireless and IoT, see for instance RFC 9030 and https://tools.ietf.org/html/draft-ietf-roll-dao-projection. I believe that DetNet would get a crisper terminology if inheriting those terms too. 

The RAW definitions are as follows, from the RAW architecture:

   Track:  A networking graph that can be used as a "path" to transport
      RAW packets with equivalent treatment; as opposed to the usual
      understanding of a path (see for instance the definition of "path"
      in section 1.1 of [RFC9049]), a Track may fork and rejoin to
      enable the PAREO operations.

      In DetNet [RFC8655] terms, a Track has the following properties:

      *  A Track has one Ingress and one Egress nodes, which operate as
         DetNet Edge nodes.

      *  A Track is reversible, meaning that packets can be routed
         against the flow of data packets, e.g., to carry OAM
         measurements or control messages back to the Ingress.

      *  The vertices of the Track are DetNet Relay nodes that operate
         at the DetNet Service sublayer and provide the PAREO functions.

      *  The topological edges of the graph are serial sequences of
         DetNet Transit nodes that operate at the DetNet Forwarding
         sublayer.

   SubTrack:  A Track within a Track.  The RAW PSE selects a subTrack on
      a per-packet or a per-collection of packets basis to provide the
      desired reliability for the transported flows.

   Segment:  A serial path formed by a topological edge of a Track.
      East-West Segments are oriented from Ingress (East) to Egress
      (West).  North/South Segments can be bidirectional; to avoid
      loops, measures must be taken to ensure that a given packet flows
      either Northwards or Southwards along a bidirectional Segment, but
      never bounces back.

Keep safe;

Pascal

> From: detnet <[email-masked]> On Behalf Of Balázs Varga A
> Sent: mercredi 7 juillet 2021 16:59
> To: Pascal Thubert (pthubert) <[email-masked]>;
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; Janos Farkas
> <[email-masked]>; [email-masked]
> Subject: Re: [Detnet] OAM terms
> 
> Hi Pascal, All,
> 
> 1, The terms MEP/MIP are well anchored with OAM. It would be great to use
> them.
> I fully support Greg's comment in this email-thread regarding the "Sub-
> Path Maintenance Element".
> No such terms are defined for DetNet. If needed they have to be specified
> as well, but in my view they all refer to an OAM session between two MEPs
> (i.e., the originator MEP and the targeted MEP).
> 
> More in particular:
> - Limited OAM: depends on the result of the originator-MEP placement
> discussion whether such a term is needed (see item 3). This is also an OAM
> session, but the MEPs of the OAM session are not at the source/destination
> of the flow, but somewhere along the path.
> - Reverse OAM: this seems to be a response OAM packet of a MEP/MIP sent to
> the originator of the OAM packet. So why not simple call it OAM-Response.
> - In-path OAM/Out-path OAM: this is a characteristic how OAM packets reach
> their destination. "In-path" means using the same path as the related data
> flow. Note, that an in-path OAM session can be in-band (usig the same
> resources as the dataflow) or out-of-band (not using the dataflow
> resources).
> "Out-path" means that any path to destination can be used. Out-path OAM is
> always "out-of-band" as well.
> 
> Thanks
> Bala'zs
> 
> 
> [email-masked]; Balázs Varga A <[email-masked]>; Janos
> Farkas <[email-masked]>
> I committed https://protect2.fireeye.com/v1/url?k=3f207e70-60bb4775-
> 3f203eeb-86959e472243-7f691555596d8b47&q=1&e=8befdca4-5db8-4c69-8706-
> 08551b827e2e&u=https%3A%2F%2Fraw.githubusercontent.com%2Fraw-wg%2Fraw-
> architecture%2Fmain%2Fraw-
> architecture.txt%3Ftoken%3DABYHN4L5D5UAWDLRS6YK2XTA4WWSE for the
> discussion below, if you can please recheck that we are aligned so I can
> publish; more below:
> 
> > AOM: