[Detnet] AD review of draft-ietf-raw-architecture-24

Ketan Talaulikar <ketant.ietf@gmail.com> Thu, 05 June 2025 11:59 UTC

Return-Path: <ketant.ietf@gmail.com>
X-Original-To: detnet@mail2.ietf.org
Delivered-To: detnet@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 2A1B8314057E; Thu, 5 Jun 2025 04:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjwzuemyYO-U; Thu, 5 Jun 2025 04:59:11 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 19FE23140577; Thu, 5 Jun 2025 04:59:11 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-22d95f0dda4so11441885ad.2; Thu, 05 Jun 2025 04:59:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749124749; x=1749729549; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hXvRut7MMYZtYC5ybu3/X6wB1ICol9pUjcjzLKlAzBs=; b=ljnj2pcRUbzmwwsjbwJD14FAyCl4QheyKA6jP7wMRzX/WPUaIl8NE+hvvLR2VEdFt8 XSat13dDL6ObL8c6UKqvRLRNgHTwGY4YyTdi+Gk3Jx7iVvGlUVdRmi6uoSiSgII/Stgm l+i45p2E55K4C7YnaQVzECIIJJdB+EFntJni1QBEk3jdBk4IHSMfIs7MyaVjiJHc7bTC MGYZlpmAkJND7q+fTSwaroB/gd2PN0AIQIrldvEhzvdncq/KIPzMUrWlW/eaPDH+/1e1 fQ2uBeCeTpR+dsEqdJ1oShuXbq+8SC5arDbgDtmFUJuOmoM611Hg2DANHvICwf0Jdpd9 OGSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749124749; x=1749729549; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hXvRut7MMYZtYC5ybu3/X6wB1ICol9pUjcjzLKlAzBs=; b=Foy4b7njvs+bN4AtkTxphcV9PAWna0COtQX9bNhlJgdVg2EpyAZDxSaO1h9eZavaIW jA++MYk9FnQfwcFofkVsJteEJhuJv7WsWvHflaH8rk34huuaKLDV1jXwVmGLFBjryNCF B0QUNb3WX1KPVlqr3pKOeusbUmVBhk6O9i2otVcIyk4kjbdj9hT23ik44t1M6SMC3zsS ZQa9DC9g8xTV58ZeCHUMVuvQJ9+E2kiWazMsGZj5b2Mr2/IMN3ZMdWr9+GKjtqLMjtDm CncIq2DgLRK0NCAVSuiuyNMmvTzxW9q9kIdd1eDl8u92JJlMcP6/EQ82rtONeamWokxh u0vQ==
X-Gm-Message-State: AOJu0Yz5C4ecF5T5R6bzcx6C6eD4KVAMXYWjNlvuleL2aIYgmyXGYbiA qhxxEDcEEH5x0+6tyavxMLs1mZvtVjx7LW9U5fxBwx6smae001IiX22mSQmTxAqt7N9OITIEPer /J717R9Lu3kczETeLH7wL3RlUPjcFgv7YkuQ4
X-Gm-Gg: ASbGncv4N3ZZc7+Ftz/om/fD+1nDRlMNVO6Sq4rVRjjbclP3slSS7vg8yhum32tvL0p F7fJIVAL0NB27VuGAzni0aUazI/KpBr7ASRta8DYYUhJiG3izi4llDsdD2tluyJCpO4o5QOP8y+ gYYL/CQrn9t9MPnEx0SRPcNo8lwuU4NkYu04nBkkXHxRPP/sRk+SiEjV1ziQe1QYV8O44AFhBAa ZM8
X-Google-Smtp-Source: AGHT+IG4hT94PfIMa6Dx5ZZ7cgDZsikiZzLspYZuPHUAP8q4Ad4+AgHL2SNHIi09OX8yRmcYDhDMvUgYpfpFbUkvA1o=
X-Received: by 2002:a17:902:d58d:b0:234:a139:1218 with SMTP id d9443c01a7336-235e12380afmr89301195ad.25.1749124749258; Thu, 05 Jun 2025 04:59:09 -0700 (PDT)
MIME-Version: 1.0
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Thu, 05 Jun 2025 17:28:57 +0530
X-Gm-Features: AX0GCFsYv3SxOzVKM_R4p22Uofm90ulP8ttkcv8i_nZMNqHjpWW8eOuzev93fWI
Message-ID: <CAH6gdPwDS=bYUgQ+_zvgws27=Z6eaOXzE1ezML7tJE8_RU9icw@mail.gmail.com>
To: draft-ietf-raw-architecture@ietf.org
Content-Type: multipart/alternative; boundary="00000000000058f3a50636d1d7c2"
Message-ID-Hash: UTO4GFBUCFDT3XUTBWWLCZV2ETCXLZZY
X-Message-ID-Hash: UTO4GFBUCFDT3XUTBWWLCZV2ETCXLZZY
X-MailFrom: ketant.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-detnet.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: detnet@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Detnet] AD review of draft-ietf-raw-architecture-24
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/akAA3bL-E0rHroT-UYviFe7Ft1g>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Owner: <mailto:detnet-owner@ietf.org>
List-Post: <mailto:detnet@ietf.org>
List-Subscribe: <mailto:detnet-join@ietf.org>
List-Unsubscribe: <mailto:detnet-leave@ietf.org>

Hello Authors/WG,

Thanks for your work on this document. I find that the document provides a
very good background and conveys the high-level architectural blocks for
RAW.

My comments/suggestions/questions are provided below inline in the idnits
output of v24 of the document. Please check for the tag <EoRv24> at the end
of the email and if you don't find it then likely the email has been
truncated; you should then look at the WG mailer archive for the full
version.

Thanks,
Ketan.

Detail review follows:

2 RAW                                                      P. Thubert, Ed.

<minor> Should it now be changed to detnet?

3 Internet-Draft                                       Without Affiliation
4 Updates: 8655 (if approved)                             28 February 2025

<major> I do not believe the "updates" usage is appropriate here since it
is
not fixing an issue or changing something in RFC8655 for base DetNet but
is instead extending it for RAW. Please correct me if I am wrong. "Extends"
is not the same as the RFC Updates tag.

174   DetNet layers may vary.  Furthermore, the different RAW technologies
175   are equipped with different reliability features, e.g., short range
176   broadcast, MUMIMO, PHY rate and other Modulation Coding Scheme
177   adaptation, (H)ARQ, constructive interference and overhearing.  The

<nit> please expand the acronyms and provide references

180   DetNet.  That is, the LL API makes cross-layer optimization possible
181   for the reliability functions of different layers depending on the
182   actual exposure provided via the LL API by the given RAW technology.
183   DLEP [DLEP] is an example protocol that can be used to implement the

<nit> please expand DLEP on first use

186   This document presents the RAW problem and associated terminology in

<minor> Would it be more appropriate to say - RAW problem statement ?

215   In an quantic analogy, a recovery graph is to a path what an atomic
216   orbital is to a planetary orbit, in that the electron has a
217   probability of presence within a known shape as opposed to a
218   deterministic trajectory.

<minor> I found that analogy complex and hard to understand. I think an
effective analogy is something that a layperson is able to understand. Is
there
a better analogy?

220   The concept of recovery graph is agnostic to the underlaying

<nit> perhaps underlying?

221   technology and applies but is not limited to any full or partial
222   wireless mesh.  RAW specifies strict and loose recovery graphs

<minor> Is there a reference for the technology being referred to as
wireless
mesh here?

273 2.1.6.  ISM

<minor> duplicate of section 2.1.2

528 2.3.5.  Segment

530   A strict sequence of DetNet Transit nodes between 2 DetNet Relay
531   nodes; a Segment of a recovery graph is composed topologically of two
532   vertices of the recovery graph and one edge of the recovery graph
533   between those vertices.

<minor> Segment ... this term is overloaded in many contexts. I don't
remember
this term being capitalized in DetNet Arch. I hope we can avoid
capitalizing it
in RAW i.e., it is OK to use just as an English word. If there is really no
option, then please see if it can be qualified e.g., RAW Segment?

614 2.6.1.  Active OAM

616   See [RFC7799].  In the context of RAW, Active OAM is used to observe
617   a particular recovery graph, DetNet Path, or Segment of a recovery
618   graph regardless of whether it is used for traffic at that time.

<question> I believe this is synthetic traffic/probe? Is there a Passive
OAM?

636 2.6.4.  Limited OAM

638   An active OAM packet is a Limited OAM packet when it observes the RAW
639   operation over a node, a segment, or a DetNet Path of the recovery
640   graph, though not from Ingress to Egress.  It is injected in the data
641   path and extracted from the data path around the particular function
642   or subnetwork (e.g., around a relay providing a Service sub-layer
643   replication point) that is being tested.

<major> Is there an end-to-end OAM? Or does it imply that all
in-band/out-of-band
OAM variants are end-to-end. Please clarify this aspect for all the OAM
terms.

665   either via measurement or communication with the lower layer.  This
666   information may be obtained from inside the device using specialized
667   API (e.g., L2 triggers), via measurement protocols such as BFD
668   [RFC5880] or via a control protocol exchange with the lower layer

<major> BFD is only doing liveness monitoring and is not a measurement
protocol. Did you mean STAMP (RFC9503) or TWAMP (RFC5357) or such?

778   "Overview and Principles of Internet Traffic Engineering" [TE]
779   discusses the importance of measurement for network protection, and
780   provides an abstract method for network survivability with the
781   analysis of a traffic matrix as observed via a network management
782   YANG model, probing techniques, FTP, IGP link state advertisements,
783   and more.

<minor> Please expand FTP and provide a reference

871   Obstacle in Fresnel Zone:  The optimal transmission happens when the
872      Fresnel Zone between the sender and the receiver is free of
873      obstacles.

<minor> Could you provide a reference or a brief description of Fresnel
Zone?

1001      From a DetNet perspective, this may translate taking into accoun

<nit> s/accoun/account

1002      how transmission from on node may intefer with the transmission of

<nit> s/from on node may intefer/from one node may interfere

1003      another node attached to the same wireless sub-layer network.


1023   As opposed to wired networks, the action of installing a path over a
1024   set of wireless links may be very slow relative to the speed at which
1025   the radio conditions vary, and it makes sense in the wireless case to
1026   provide redundant forwarding solutions along a (see Section 2.3) and

<minor> along a ? ... path? graph?

1049   2.  The DetNet Controller Plane establish primay and protection paths

<nit> s/primay/primary


1064   4.  Service protection actions that are actuated or triggered over
1065       the LL API by the PLR to increase the reliability of the end-to-
1066       end transmissions.  The RAW architecture also covers in-situ
1067       signaling, e.g., via OAM, when the decision is acted (like the A

<minor> What is this in-situ mechanism? Any reference?

1076 4.  The RAW Conceptual Model

1078   RAW extendss the conceptual model described in section 4 of the

<nit> s/extendss/extends

1128   In the case of centralized routing operations, the RAW routing CPF

<minor> I guess CPF is Controller Plane Function? Please expand.


1391   The interaction between the network nodes and the routing function is
1392   handled by the orientation function, which builds reports to the
1393   routing function and sends control information in a digested form
1394   back to the RAW node, to be used inside a forwarding control loop for
1395   !  traffic steering.

<nit> please delete the stray !


1427   In the case of wireless, the changes that affect the forwarding
1428   decision can happen frequently and often for short durations, e.g., a
1429   mobile object moves between a transmitter and a receiver, and cancels
1430   the line of sight transmission for a few seconds, or, a radar
1431   measures the depth of a pool using rgz S/Nme (say, ISM) band, and
1432   interferes on a particular channel for a split second.

<minor> Please explain "rgz S/Nme" or provide a reference.

1434   There is thus a desire to separate the long-term computation of the
1435   route and the short-term forwarding decision.  In that model, the
1436   routing operation computes a recovery graph that enables multiple
1437   Non-Equal Cost Multi-Path (N-ECMP) forwarding solutions along so-

<minor> I think N-ECMP stands for network-level ECMP. The term you are
looking
for is perhaps unequal cost multi-path (UCMP).

1438   called protection paths, and leaves it to the Network Plane to make
1439   the per-packet decision of which of these possibilities should be
1440   used.

<major> Is it only and strictly per-packet decision or could it also be
per-flow decision?

1478   Act:  PREOF Dataplane actions are controlled by the PLR over the LL
1479      API to increase the reliability of the end-to-end transmission.
1480      The RAW architecture also covers in-situ signaling when the
1481      decision is Acted by a node that down the recovery graph from the

<nit> s/node that down/node that is down

1550   Conversely, in the case of Radio Access Protection, illustrated in

<minor> Can you provide a reference for Radio Access Protection?

<EoRv24>