From nobody Thu Dec 1 21:08:40 2022 Return-Path: X-Original-To: raw@ietfa.amsl.com Delivered-To: raw@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0974DC1522B4; Thu, 1 Dec 2022 21:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jGJoBfIKBjT; Thu, 1 Dec 2022 21:08:35 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2070b.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eab::70b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C3BC14F6E7; Thu, 1 Dec 2022 21:08:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TdhKEhxTQ8JY3UaXOmoz3ORrLmbZLKWjl6nEKIGABx+sIf0r/uGWsqF2uyUuDSVel++4T2dN2WZchFcK8rdefGAy/CRqaBd/70xgYqLZigWgOdrsYyySFiOVES7tv7NcazlVSOq6sx6fkpPkQ6U3dGgtlE4QfGpa5l4KAwyj9UolNz44OyPSA3/6XSRCT8onAA7YRBdTVmYdj2Lg4PV/4b7guDB0EEaTzRiQCSCnBa4gEDlBXauBvB0mWxS5vgaU2fVJ1c7nESDplAm0udahUrlLLm9AczHMrnO3QIC+R6DknrmHy4xVkrtlSlnBoU26A1gEjI7hCnblBDo1a5LLQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p1aI4zqb165d2t/DD5sf0xd4Xw6JbsQzYd9IKF2nCps=; b=N1eNX/T+kSLLbZpJk3zUb5O3N5J4YzbXT3FiRvxgoHlYREQiHgmSAgS8VmIB38ZVT5Z1RjGUXXklnrUwhtUgTBOFz+p4XEcfn1zkMzcu+bQEIniaSYQhoWeBDYyE/KohYLhrgeabwb/7JxjjAbd9Mvc6cyVTSr+utEMUYX6cwgJR2fKhzJ4LfUd90YncJ5NeZVoyqR59bcmWDDms1beeDIGg0NWQyKEQOPiFkywQtlkZKBnkaYzO00ecqL7QxsD7eoY81NYPiIFBeRfointIzfBpHnPrVe9IP4KFViqnEEaP6EwrBQygkYYhYSefyMRgX4cs1FfNMO9q8mdB/PWCqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p1aI4zqb165d2t/DD5sf0xd4Xw6JbsQzYd9IKF2nCps=; b=vjn/+wjLwDfkN87P54JraVNVYbH6hPbJrrEsNc3k6d+EYQfF6wT+Alw6c5ofIXJQjKdEutg2Q/y404PaLyUsQu8LJh9N4yWQMMTZ99A8hTIBL4mIwCXCtlMblIysfIlqZVO4BlqZEAmAjXMaJm7JCglRoxf52JQa7+z75CfoP3c= Received: from PH7PR14MB5368.namprd14.prod.outlook.com (2603:10b6:510:133::11) by CY8PR14MB5979.namprd14.prod.outlook.com (2603:10b6:930:5d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.8; Fri, 2 Dec 2022 05:08:24 +0000 Received: from PH7PR14MB5368.namprd14.prod.outlook.com ([fe80::6ebe:eafc:c749:ecd1]) by PH7PR14MB5368.namprd14.prod.outlook.com ([fe80::6ebe:eafc:c749:ecd1%9]) with mapi id 15.20.5880.008; Fri, 2 Dec 2022 05:08:23 +0000 From: Don Fedyk To: "Pascal Thubert (pthubert)" , "raw@ietf.org" CC: "raw-chairs@ietf.org" , DetNet Chairs Thread-Topic: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt Thread-Index: AQHZBYx7rIyS1gRKFEur4xvzAIzok65Zq9Rg Date: Fri, 2 Dec 2022 05:08:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=labn.net; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH7PR14MB5368:EE_|CY8PR14MB5979:EE_ x-ms-office365-filtering-correlation-id: c3059219-16cd-4567-8fd4-08dad4233d05 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /QIfJ8VLjMLQ5wABmruPJAwYH6Jbfs+6YrV0X4MxhSK4fEW4GrZOvYahOvIgVbV5LSTdIIOPP7IX7oT6AOGr40/5VC0fGGyb1offblp6LrW/hlMzIpy9l1u4AOGRFnq1zfkZj7k6s8pgk6vEjBODbYpG8uhjlUQxLiqrd9JsVP2nz2O89VOpDHYVEMGWemAB7IQ23MpTpvDPqSAIheZFF/Y1GyhAdMmPS6BNyhSeBi1BKsatVy6JFCWL/OdCrWLvIh4AWAzpyf7UDBg/VOAMGZQJzc9maGdI0bHNUdgrxz5WAvVnAqB68vgbfcREqfhl9gPRCyksXe8Kk4z4EsGh1S1EIQhWHVRbmvlaZ1ouqy/OiJxPvLuxrN82Cj9rt+JZptmUutqB6m/xih4rqwWlMV0NzB8rHUpy+4xicR+C2n/mQEvs4kvMtZLIZ3zKM9pZxTNs70V22vtmARKKZe5ZTuc7tk8tPfqB0dm8Ow/aJFEkbkCba8q4CDJfVM6EuNFngRkWJzjyfrNUliyiSQDMTgQm8oE9pJ47iwkYbHl8ftoz4BJe3Xo/xy95T3MeReODT8YO/oy6dDZD2zxP+KC1sE5NAbX5OdtZ7z0fkp4klruKq7Lzlqb4ZyyXWIrdhLzvgEk6gLeWS9Rg0FI7YzRydDCMJdvP+OE+z3EjQnjHcU8RGJGWlgGIvcvopyOb+NJOwAvoNvtr/wS9VzqH3cjfDFp7kZBfKqQDyBGIwcD5I24= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH7PR14MB5368.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(136003)(396003)(366004)(376002)(346002)(39830400003)(451199015)(5660300002)(122000001)(66899015)(30864003)(38100700002)(8936002)(86362001)(33656002)(2906002)(83380400001)(8676002)(9686003)(186003)(41300700001)(64756008)(52536014)(450100002)(38070700005)(4326008)(7696005)(66476007)(66446008)(110136005)(316002)(76116006)(54906003)(26005)(6506007)(71200400001)(478600001)(55016003)(66556008)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?tTL2igNtAV7q9vASSSOoGf+gtavqEd+uANiIcLP0wkA+3YgzgU6xTj8pV4uE?= =?us-ascii?Q?YEDH4oJM3Niu6mRSa8bB6kSCmXxc7z1Dui8slydXFN294qzrugWN9PkgwpGZ?= =?us-ascii?Q?4uaMdK2adLjTMIStbBS5E1L7pIn1jQLOa/y9ybSD7SstkHo50v42iacmmB4L?= =?us-ascii?Q?cB5/1VU557vlH9CqSqVNniU8PcUVOO3kWu7+5VGzKTAOoIAcUJQHoehPov7l?= =?us-ascii?Q?lKS6m7PrC78fm5km+w+xPfvty3oDCEn1wa2a7E9dC1mT6tP5JcvquX22zv/2?= =?us-ascii?Q?SplXVJwjEDjqSKCMLq1px9FtUNV+PGstWPPSqxFFcGVv4dlrnkEqKQ4zuoHz?= =?us-ascii?Q?dccoD/gdnOVEWh3nuIh0FO0017TNVfqwhz6u5rvEAXNcIJOHSTZmmj9HcweQ?= =?us-ascii?Q?BOf3AQRplJfDXjwdwkqGjmUzEaC5EbhHbsAp0JeMV7OokjTWhuTimgHuWbKB?= =?us-ascii?Q?vmThRM0SZSM+KPqKed8Z1MHNp9MJOYCdzT0YB/QSnYCFUCnilULGyBl+CORf?= =?us-ascii?Q?SKdg4qr87WZ8MFMJWhAf8XRn7x5lm5BUsy/zsxE09MYdO5qX5rZeQENN2tbl?= =?us-ascii?Q?0qw4ZHuVDJcRPP3McBtDXTnOYuQ/ZAmd+7zBEnEl4R70QsZ1RfO6AaXlZ99J?= =?us-ascii?Q?NPSTfqHyVyxsopIHmvd9gBObb3/VotfKlchJlfVHn6DEqVI357jS8H1BKdoT?= =?us-ascii?Q?wiZDiSUJfH/1qe35NVTWcBvdGBQTJdXHLhWsPaSLGVClrblodBPPfx3VKtOp?= =?us-ascii?Q?sQqWhRpc8CEpzVotnOMXQJEciG7jDuPaFTkSzuhd5xVQG9QTVbiFL0JVcMoP?= =?us-ascii?Q?1HfSVk+b4HQtaSbDkmR90HrnwR1z2zc8LJV/T4OJjR927yL4SvofTXTR1upT?= =?us-ascii?Q?C5oZNtjeMW43j/f+sesXlbPJF6SHsTIDflorirxNHqDT4QGf89YsvJ2qnRwu?= =?us-ascii?Q?Pwk7Ys0P0NNMCcPjQyPt+2uBv99vdM+ThHQI59OhSfRli/PkAMN5UplDVTz5?= =?us-ascii?Q?l2MmIvkFEiT4bNlxhlQ5RXGIzAH5QRkXm94u0Pcc8INthVwjZrYL5UqX09f6?= =?us-ascii?Q?CCZdrdCHC6F8n4z5gCbujp3Kbf4RpFzx1mmlwK8c4tDmjGfNL6FctfUpEWWb?= =?us-ascii?Q?PFssbwWs1fPRl7UUK0dyO7YK+pzMw5ohfS0mj3EDnL+DiRxsnAaEW4s4du1e?= =?us-ascii?Q?hUh18guL7H6MmCs/SaWYndf6vGtosGMttMV/bkduPjZrxSug+4xbY5E+DJEa?= =?us-ascii?Q?igF5HimjshEyeCiOskZnJO7uNm9ThPUxTjrubyDTXgu1x8bBXfwF+x6Z5CZA?= =?us-ascii?Q?hd0bsMkxzNNLLkjp5UMzCP6jKOEwG6fZ1yZBNxq5TH48xam0GU5r0fsXv9iL?= =?us-ascii?Q?YmJs3MRMVdvneju8v2GBorOk2y+FjHTFvKTqqqeewwOhNd1fglY93g+04b+d?= =?us-ascii?Q?8EcjaX/kj+ADdADs+TuUV7j0mZKjQ4IFh3CIZ2NIYVRiiN1oZbemZR4P5p1F?= =?us-ascii?Q?sNC8FxIAAvuHnBbr2+neTEMGFROyIMK/HwSXH0f6EZrchOljC1mOXZeoV2y+?= =?us-ascii?Q?GPcMQA4Yk1NgNdADpTmimiiOVJkT12E1yQ20L6jx?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH7PR14MB5368.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3059219-16cd-4567-8fd4-08dad4233d05 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2022 05:08:23.8595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jt9TOqq/pm4DBcc4/4n7PeMCjuMSGu1JxT+hoQ6V5XXZHUusc9WU97ThME5UjOcqG36v9Bb6Y9GeUm3wYXvMCQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR14MB5979 Archived-At: Subject: Re: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt X-BeenThere: raw@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: reliable and available wireless List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2022 05:08:39 -0000 Hi Pascal > > >Hello Don > >Whao, that's a lot! Many thanks. Let's see below: > My goal is just to give the WG the opportunity to come to consensus on the terminology. =20 > > >> Remove "Track" - use "RAW protection" or "Active RAW protection paths" >> Rational: These concepts are >> covered in many IETF drafts but here are a few: >> - TEAS terminology 3272bis and MPLS FRR 4090 terminology As well: >> DetNet 8655 M:n protection None, 1:1, 1+1, detour LSP, local=20 >> protection. Replication, Ordering Elimination PREOF. > >I'm good with "protection" and I agree with the history you >point out. The way we use the Track appears consistent with >that term to me too. My point was "Track" is new to me - not been following Roll =20 perhaps my bad but what I offered to do was define Track=20 without using the term and see if the WG agreed Track was what to call it.=20 I caught my self saying "protection path" then realized when=20 talking with Lou that "Protection" embodies the whole concept. =20 > >I'm not good with "RAW" since though RAW is using the >concept, it did not create it and is not the end of it. I only used the term to mean the RAW flavor of protection. I'm fine dropping that.=20 > >We cannot ignore how much work has taken place at ROLL and >6TiSCH, which contribute to the work on reliable and >available Wireless by providing the route installation and >the forwarding over TSCH, respectively.=20 > >Just look at >https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection. >I cannot easily go and tell ROLL that the term they have >been using forever must now change because of RAW. And This >draft is the only way I'm aware of to build the Tracks in a >centralized fashion - unless we argue that PCEP is a valid >contender in a wireless mesh? Well, it points to RAW as the defining place for Track yes=20 I see.=20 > >I suggest we settle for "Protection Track". Again, not my decision but the WGs. Perhaps=20 - Protection as the superset=20 - Protection Track is then the active set of paths in that protection scheme?=20 - And Protection Tracks are the active set of paths for separate services?=20 Googling images of track I realize that I like "lanes".=20 Protection lanes? Was lanes considered? Lanes are a subset of track.=20 =20 > > >> Remove Network Plane - It is a Data plane or a control plane. =20 >> Rational Network plane is not a common term. >>=20 > >See section "4.4.3. The Network Plane" of RFC 8655 I see it is a composite plane and still _rarely_ referenced in DetNet. =20 I'm familiar with data plane, control plane, management plane and Network. So OK my bad. If the WG thinks it brings clarity then it is an established term. >> Remove OODA. - Rational the OODA loop is one type of feedback loop=20 >> common in cybersecurity. In RAW there are multiple feedback loops. > >It's a very abstract model and that's the only one we have >defined a mapping for. It fits very well the detnet network >plane roles of PCE, PSE, OAM and PAREO, respectively. >Do you have something in mind that does not match that >model? Should we describe it in the architecture? It is the "orient" part I think is being forced.=20 OODA looks to me like a larger system of multiple feedbacks.=20 It is a general system and can be fitted to many situations. There are multiple feedback loops. =20 In control loops you have a system with an operating goal,=20 a measurement function and feedback to maintain the goal.=20 There is no orienting measurement is implicit in the feedback loop design. Since we deal with packets and paths we have discrete steps thresholds and actions. =20 There is also in theory a network manager role that tries to optimize over all service - maximizing network utility however when services are equal priority established services win over not yet established services. When priority is involved higher priority services win. =20 I contend this higher level does not exist and you either=20 have equal services FIFO or priority services or both.=20 Again, a question for WG. Does OODA bring clarity over a simple feedback? > > >>=20 >> Details: >> Reading over the RAW architecture I would remove Track and refer to=20 >> places where Track is used as as RAW protection and active RAW=20 >> protection paths >> - This reuses IETF terminology. >> RFC 9030 defined a Track but it is not common use outside that group. > >It is used in the IETF wireless / IoT groups in INT area and RTG Area. > > >> The WG should then decide if a single term such is Track (or other)=20 >> can be used. My issue with the term Track is it is singular in nature=20 >> and the usage here varies from singular to multiple. > >Agreed > > >> There are two fundamental concepts: >> a protection set and >> the active protection set. > >True. I figured from the discussion with Lou that the >"active protection set" is a TE path, so I changed the >terminology to that in the latest publication. Was that >wrong? Note that as I insisted at the WG meeting in London, >the 2 sets are not of the same nature. The former is a >potential, the latter is an actual. Using "protection set" >for both hides that subtlety under the carpet. I agree.=20 > > >> Currently, the RAW Architecture talks about a Network plane. >> I think it means a data plane. Network plane is not widely used. >>=20 >> I would remove OODA loop. There is not much reference to >> it in the IETF and I think it is more a security feedback loop than a=20 >> run time operational feedback loop. We have feedback loops. I think=20 >> the PAREO loop stays largely as as you have defined it. > >We do not have a PAREO loop. PAREO is the action in OODA. Yes I agree I used the wrong wording for PAREO.=20 > >> RAW (and other networks) have multiple feedback loops. >> Link state with statistics (comprises a topology feedback loop). RAW=20 >> active protection path set and service statistics is another feedback=20 >> loop. > >I'm not aware of feedback loop in the data plane though. The >closest I'm aware of would be FRR/LFA but that's not really >a control loop, more a reflex action to avoid a broken >path.A The feedback loop for QoS is RFC2386. Generally considered not a good idea. This is why I questioned the use=20 of PAREO actions and why I suggest they should be limited. =20 > >> Currently the architecture allows RAW to ask for a path to be computed=20 >> (one or several protection paths). >> Then RAW uses local decisions locally decide if it needs to refine the=20 >> active path out of the set. To maintain stability over all paths,=20 >> path allocations of capacity should be sized to the fullest use of the=20 >> protection path set assigned although locally RAW can decide not to=20 >> use all paths. > >True. Do we need more words in the document on that? I think so to alleviate the instability concerns. > >> I think for path computation RAW should assume it uses all resource=20 >> allocated in "active RAW protection". When less resources are used=20 >> over time >> - then it should relinquish the resources. >> This slow adjustment of the actual usage is another feedback loop. >>=20 >> Here is what I think this looks like. >>=20 >> +--------------+ >> +--------->+ Compute RAW +-----------+ >> | | Protection | | >> | | Paths | | >> | +--------+-----+ | >> | ^ | >> | | Network V >> +------+---------+ | Link +-----+-----+ >> |Request RAW | | State | | >> |Service Path | +-----------+Deploy and | >> | | |Monitor | >> |Traffic Request | +-----------+RAW | >> |[Add or delete | | Service |protection | >> | Resources] | V State | | >> +------+---------+ +-----+-------+ +-----+-----+ >> ^ |RAW actions | ^ >> | |PAREO +---------+ >> | +-----+-------+ Local >> | | Change >> | Service | >> | Change | >> +-------------------+ > >I like this drawing, many thanks. The "Network Link State" >is not really correct though. More like "Network Link >Stats", one letter, very different meaning. Or both if we >consider a permanent stat of 0 to be a link down >information. Yes full link capacity to degraded to zero. I think you have better wording.=20 > >Just like there's async and periodic OAM-based "state" >information on links (passing, not passing, assumed >reliability / PDR) to the PSE, there must be periodic and >async stats to the PCE. When the stats differ to widely from >those used to compute the Track, the PCE may update or >rebuild the protection Track. OTOH, if the stats remain in >an acceptable range, the PCE will rely on the PSE to adapt >and refrain from impacting the Track. > >This is the big difference between what the PSE and the PCE >see. The PSE sees links as usable or not at one instant. The >PCE sees quality stats over long periods. As opposed to >classical IGPs the model in radio networks has to >accommodate link flapping smoothly. E.g., RPL is built for >that, that's why it builds DODAGs as opposed to trees.=20 > >> There are three possibilities: >> - The quality is poor, and more resources need to be >> requested. If a RAW service determines that the service >> is not getting sufficient packets through it should ask >> for a better RAW protection (set of paths) . >>=20 >> -The quality meets it targets and allocation of resources stays=20 >> constant. >>=20 >> - The quality meets it target but the connection is >> consuming excessive bandwidth/capacity. Currently RAW >> makes this determination locally. I think that RAW >> should release resources within >> some bounds. >>=20 >> This scheme should be set up to reduce the chance that RAW services=20 >> will compete by over allocating (blocking) or under allocating=20 >> (congesting). > > >True. Then again as a DetNet Extension, RAW uses provisioned >resources so on paper congesting is not part of the game. On >paper, there should be enough resources for all RAW flows >using all the PCE allocated resources. The game is to save >1) energy and 2) spectrum which can then be used by >non-deterministic flows.=20 > >Arguably, the link rate may vary (with MCF). OAM must >capture that, and the PSE of some flows will have to react >and stop using that link, while for other flows the link >will remain usable. Maybe a sentence or 2 to clarify that is >in order? Yes, Even if you over allocate bandwidth there are cases where a=20 loss will cause congestion. You can argue for queuing that=20 sacrifices other flows before RAW flows but ultimately=20 you may not be satisfying. =20 Some environments/wireless links may be bandwidth starved.=20 > >All the best, > >Pascal And I apologize for not having given input earlier. =20 Cheers Don > >