[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>
- [Detnet] AD review of draft-ietf-raw-architecture… Ketan Talaulikar
- [Detnet] Re: AD review of draft-ietf-raw-architec… Pascal Thubert
- [Detnet] Re: AD review of draft-ietf-raw-architec… Ketan Talaulikar
- [Detnet] Re: AD review of draft-ietf-raw-architec… Pascal Thubert