[Detnet] Re: Mohamed Boucadair's No Objection on draft-ietf-raw-architecture-27: (with COMMENT)

[Pascal Thubert <[e-mail]>]

Hello Med :)

Many thanks for your review!

I placed proposed changes in guthub as
https://github.com/raw-wg/raw-architecture/commit/b91d50c2128f5bf560f1b3dd90c8fae87249a058

Please see below for the details:


> ----------------------------------------------------------------------
>
> Hi Pascal,
>
> Thank you for the effort put into this document. I find it well-written,
> interesting, and useful.
>
> Thanks to Giuseppe Fioccola for the OPSDIR review and Pascal for engaging
> and
> agreeing changes. I like the new OAM text you proposed.
>

Well, there was more discussion in the thread you contributed to. Greg
pointed that the DetNet terminology is agreed upon and consistent within
the DetNet world at least, so the word of caution about not using some
terms therein may be unnecessary within that context.
I'm trying to reach a consensus in-between. The current proposed text in
GitHub is:

"
  RAW reuses terminology defined for Operations, Administration, and
   Maintenance (OAM) protocols in Section 1.1 of the "Framework of OAM
   for DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods
   (with Hybrid Types In-Between)" [RFC7799].  "Guidelines for
   Characterizing OAM" [I-D.ietf-opsawg-oam-characterization] provides
   additional semantics of the terms Active, Passive, Hybrid, and In-
   Packet OAM that are consistent with [RFC7799].  It also warns about
   potential inconsistencies in the way the terms "in-band" and "out-of-
   band" are used across the IETF; the DetNet reference for those terms
   is [DetNet-OAM].

"
Is that acceptable?


> Please find below some very minor comments:
>
> # Gymnastic :-)
>
> CURRENT:
>    RAW extends the DetNet services by providing elements that are
>    specialized for transporting IP flows over deterministic radio
>    technologies such as listed in [RAW-TECHNOS].  Conceptually, RAW is
>    agnostic to the lower layer, though the capability to control latency
>    is assumed to assure the DetNet services that RAW extends.
>
> There is a tension between the two sentences (and even some inconsistency
> given
> W part of RAW at the first place :-)), but I think this reflects the
> spirit of
> RAW. Thanks for having included this section early in the document.
>
> # PANRG Path Properties
>
> CURRENT:
>    Section 2 of [I-D.irtf-panrg-path-properties] points to a longer,
>    more modern definition of path, which begins as follows:
>
>    |  A sequence of adjacent path elements over which a packet can be
>    |  transmitted, starting and ending with a node.  A path is
>    |  unidirectional.  Paths are time-dependent, i.e., the sequence of
>    |  path elements over which packets are sent from one node to another
>    |  may change.  A path is defined between two nodes.
>
> ## Please note that draft was published as RFC 9473.
>

Thanks for shepherding it :)


>
> ## The text you quoted does not appear as such in the final version. Please
> update it
>
> NEW:
>       A sequence of adjacent path elements over which a packet can
>       be transmitted, starting and ending with a node.
>
>       Paths are unidirectional and time-dependent, i.e., there can be a
>       variety of paths from one node to another, and the path over which
>       packets are transmitted may change.  A path definition can be
>       strict (i.e., the exact sequence of path elements remains the
>       same) or loose (i.e., the start and end node remain the same, but
>       the path elements between them may vary over time).
>
>       The representation of a path and its properties may depend on the
>       entity considering the path.  On the one hand, the representation
>       may differ due to entities having partial visibility of path
>       elements comprising a path or their visibility changing over time.
>
> # Do we really need these terms;
>
> CURRENT:
> 3.5.2.  Service Level Objective
>
>    A service level objective (SLO) is one term in the SLA, for which
>    specific network setting and operations are implemented.  For
>    instance, a dynamic tuning of the packet redundancy addresses an SLO
>    of consecutive losses in a row by augmenting the chances of delivery
>    of a packet that follows a loss.
>
> 3.5.3.  Service Level Indicator
>
>    A service level indicator (SLI) measures the compliance of an SLO to
>    the terms of the contract.  It can be for instance, the statistics of
>    individual losses and losses in a row as time series.
>
> These are not called in the main text.
>

The architecture is also a base reference for the work to come; e.g., the
RAW framework that uses the term.
More than that, this illustrates that a sentence using SLO was missing.
I reworked the last sentence of the introduction, moving the paragraph on
Lower Layer API deeper in the spec.
The proposed new text reads as:
"
   The intent of RAW is to meet Service Level Objectives (SLO) in terms
   of packet delivery ratio (PDR), maximum contiguous losses or latency
   boundaries for DetNet flows over mixes of wired and wireless
   networks, including wireless access and meshes (see Section 2 for
   more on the RAW problem).  This document introduces and/or leverages
   terminology (see Section 3), principles (see Section 4), and concepts
   such as protection path and recovery graph, to put together a
   conceptual model for RAW (see Section 5), and, based on that model,
   elaborate on an in-network optimization control loop (see Section 6).
"



>
> # YANG Model: Be consistent with the reco in RFC8407bis for the terminology
> usage
>
> Please change all such occurrences in the draft to “YANG data model”.
>
>
done


> # SLA vs SLO
>
> Section 6 says:
>
>    The overall OODA Loop optimizes the use of redundancy to achieve the
>    required reliability and availability Service Level Agreement (SLA)
>    while minimizing the use of constrained resources such as spectrum
>    and battery.
>
> But reliability and availability are SLOs as these can be part of traffic
> performance parameters enclosed in an SLA. Refer, for example, to RFC9544.
>

Changed to SLO. Also added text in a new terminology subsection, I agree it
would be a useful pointer for the subsequent work:
"
3.5.4.  Precision Availability Metrics

   Precision Availability Metrics (PAMs) [RFC9544] aim at capturing
   service levels for a flow, specifically the degree to which the flow
   complies with the SLOs that are in effect.
"


>
> # Check the classification of many references currently marked as normative
>
> For example, I don’t think the following one is normative:
>
> CURRENT:
>
>    Nevertheless, deterministic capabilities are required in a number of
>    wireless use cases as well [RAW-USE-CASES].
>
>    ..
>
>    [RAW-USE-CASES]
>               Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F.
>               Theoleyre, "RAW Use-Cases", Work in Progress, Internet-
>               Draft, draft-ietf-raw-use-cases-11, 17 April 2023,
>               <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
>               cases-11>.
>
> Likewise, I don’t think RFC4655 is normative as well given that the only
> citation is as follows:
>
> CURRENT:
>    [I-D.ietf-detnet-controller-plane-framework], and may use a Path
>    computation Element (PCE) [RFC4655]
>
> Idem for [INT-ARCHI], [RAW-TECHNOS], etc.
>
> Please do a full check of your entries and move at least the ones cited
> above
> to be under Informative. Thanks.
>

I moved them and others. But left  [RAW-TECHNOS]. Reason being, I was
explained that for an "informational" I-D, which is not "normative" anyway,
we could leverage the "normative" section for the "important reading". For
RAW, I'd argue that understanding the lower layers is important reading.

Again, many thanks for your review, and please let me know if more is
desirable.

-- 
Pascal