Re: [Detnet] OAM terms

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

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


> -----Original Message-----
> From: detnet <[e-mail]> On Behalf Of Balázs Varga A
> Sent: mercredi 7 juillet 2021 16:59
> To: Pascal Thubert (pthubert) <[e-mail]>;
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; Janos Farkas
> <[e-mail]>; [e-mail]
> Subject: Re: [Detnet] OAM terms
> 
> 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) <[e-mail]>
> Sent: Wednesday, July 7, 2021 3:33 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Balázs Varga A <[e-mail]>; Janos
> Farkas <[e-mail]>
> Subject: RE: Re:[Detnet] OAM terms
> 
> Hello Greg:
> 
> Many thanks!
> 
> 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:
> > 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
> 
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet