Re: [Raw] [Detnet] OAM terms

["Pascal Thubert (pthubert)" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: jeudi 8 juillet 2021 2:35
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> 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
> Sr. Standardization Expert
> 预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline
> Product R&D Institute/Wireline Product Operation Division
> E: [e-mail]
> www.zte.com.cn
> ------------------Original Mail------------------
> Sender: PascalThubert(pthubert)
> To: gregory mirsky10211915;
> CC:
> [e-mail];[e-mail];[e-mail];[e-mail];bal
> [e-mail];[e-mail];
> Date: 2021/07/07 06:34
> Subject: RE: Re:[Detnet] OAM terms
> Hello Greg:
> Many thanks!
> 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:
> > 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
> > GIM>> 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.
> > GIM>> 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.
> I adapted that new text to RAW
> >
> > 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
> > 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)?
> 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.
> >
> > 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?
> The term is used in the main text. It appears useful. But are you saying
> that it is misleading?
> Many thanks!
> Pascal