Re: [spring] new draft on segment routing approach to TSN

Balázs Varga A <balazs.a.varga@ericsson.com> Tue, 09 March 2021 09:17 UTC

Return-Path: <balazs.a.varga@ericsson.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32463A1843; Tue, 9 Mar 2021 01:17:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.247
X-Spam-Level:
X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABHlE3tPaNXU; Tue, 9 Mar 2021 01:17:43 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2046.outbound.protection.outlook.com [40.107.20.46]) (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 6A4D73A1842; Tue, 9 Mar 2021 01:17:31 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KKkG3Vm4GGtEqeeMuYTq4NXGws8QurRMD35gQHk2dE+bDt70Zso6iHG18tLzt5dsT/MfJESajnrwVMIrE+mljpLwinrVKHWisjWbx69oSjJ4EduvtMSanQDCMBLJCMgAilOt1WgRTqXQHqEI4v2g7+aqwEWv2j5oWpNGXHHS+2Nxa8LYgBBiTEtlsVctiEqse+FdlZRyOrSMNvUHflR1SMOqcqiUL1JjVsLvbD0Mvt/6AAyome1EvIO3N/Erz8xS8Enu0+D7dVRGo4M3KIwSX46/vgFCztpM7mAE1NDqtse2TR2QJYnUTFMGBlhW5yChT3TQx+sAr0WKxJd1eCTsXg==
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-SenderADCheck; bh=xe2IxXA5oMSO/jpxdnXG7nP3KKIJ7WNFHdye5J6PdsU=; b=OhhF/1/k2IFvauRIGfhQAxu0g3pc7AEqBPe7WJ3M4OVX3EunwpCHWZkhLbbzQSjNIavXgg2hcJvcntRqq+wixLdVR3qOwd2mOq+WLNHfsrEBbDQAZzwyzJn8YIqwq06ZvtLVv0ApIUJ8CgCkpnj7GSWH3BRgJjm/eWyo6VcN6QzNZrEku2RUXPvmRkpylq4beuZ+vQ/iYtzxlC3rebVrKlqLatTjY+fhL+sz6Xrqvc4JlMnUW9P5R1T10nsfCpF/JuGWh70nCekaaUx87bw74CjQvJhfoARPzNvKZiri7PyC/Umy6HO9tZBSKxFWnWL1/T7fyae5z8Z0dMMR1SLo/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xe2IxXA5oMSO/jpxdnXG7nP3KKIJ7WNFHdye5J6PdsU=; b=HMXf6osxXcpbbhrdZre3YJ4vvSSR/cc0gayvk5cFwHm+tU2CbvH6AnpZHRLuXqC9PuJetKFDR0CISQ/HlGBbYoyGpDmVbyJNxSfNx6MOJH+Xn08rTgagrTfIEcbeVaDgHXc7R/spPVJ2bNN0uQ74trYfuBMX9nBFDEgdWF42Hdo=
Received: from HE1PR0702MB3609.eurprd07.prod.outlook.com (2603:10a6:7:83::33) by HE1PR0701MB2409.eurprd07.prod.outlook.com (2603:10a6:3:6e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.11; Tue, 9 Mar 2021 09:17:26 +0000
Received: from HE1PR0702MB3609.eurprd07.prod.outlook.com ([fe80::b1b9:13ce:fac6:586b]) by HE1PR0702MB3609.eurprd07.prod.outlook.com ([fe80::b1b9:13ce:fac6:586b%4]) with mapi id 15.20.3933.025; Tue, 9 Mar 2021 09:17:26 +0000
From: Balázs Varga A <balazs.a.varga@ericsson.com>
To: "Liubingyang (Bryan)" <liubingyang@huawei.com>, Yaakov Stein <yaakov_s@rad.com>, Haoyu Song <haoyu.song@futurewei.com>, detnet <detnet@ietf.org>, spring <spring@ietf.org>, pce <pce@ietf.org>
Thread-Topic: new draft on segment routing approach to TSN
Thread-Index: AdcJ5AjgmuXpLt94R1Stsoh/vUDwUAIGpPHgAEKRNTAALm7rkAAGaIpAAA9T+5AAAZ19cAAB5aG+ACccnpA=
Date: Tue, 09 Mar 2021 09:17:25 +0000
Message-ID: <HE1PR0702MB36092FA11B951E91CA57898CAC929@HE1PR0702MB3609.eurprd07.prod.outlook.com>
References: <AM0PR03MB35228092287B38B95D7056F7E5809@AM0PR03MB3522.eurprd03.prod.outlook.com> <DM6PR13MB2762033C6ACECC4A816830AC9A969@DM6PR13MB2762.namprd13.prod.outlook.com> <AM0PR03MB3522BD9D4D0A3134FE16B49FE5949@AM0PR03MB3522.eurprd03.prod.outlook.com> <DM6PR13MB27624F07A612BDCF98A8C92F9A939@DM6PR13MB2762.namprd13.prod.outlook.com> <AM0PR03MB35223AD654033E1DE5963A21E5939@AM0PR03MB3522.eurprd03.prod.outlook.com> <9b01579697ba42cf90b0bd5861730fc3@huawei.com>, <AM0PR03MB35220E7B943E9BD4EB64624AE5939@AM0PR03MB3522.eurprd03.prod.outlook.com> F09AC6CE-AECC-4EC0-B0FA-34EB7844EDE2
In-Reply-To: F09AC6CE-AECC-4EC0-B0FA-34EB7844EDE2
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [185.29.82.144]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3d905715-edfb-4aee-3899-08d8e2dc27d7
x-ms-traffictypediagnostic: HE1PR0701MB2409:
x-microsoft-antispam-prvs: <HE1PR0701MB2409459B1A02028269D28BAEAC929@HE1PR0701MB2409.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4303;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: fppyL0mzVlPHCNi7dP+0ftIGhJ7KwVLOw+u9H1HWv2/amy2g9Xs75A0TRDKMRlP+vWS3jaGdJlaRmCsdCTodlRgjNkKHF3yuNRn9x8qMKlCz3ASQThiyFoN93mPxXd68wFQAdmzm+Hi8psVc0l/SJe4sZzbjQqAStIIoQGMJVR87Vjx4Unmh9LZD2th5P9zeiy/MfTmKg1NvJ5b9HLNtE4cY11CaateUfbsLPs5pgJ0BsBs0yNC/4kecHcDUnDv9Qg/B71I7ew0g2dUfEYsWuz4LaPnNwOWtx2zvuOnUituWVKjnPna3P9jua0XZI0LmDh/Svd3DannC04LwIpWRrYluRKLNTa9Qj5rinyQJ4NzmLmhzXxPWhm6xfn89v0nF/kGYGPC9yXdSwyQ3RN0DhYR200+phRdLS5OHDVDE6KKWB+zCreR5SgdWyKTiB+Ep3N5E8TxENW3Lio/onIoSDvyxnQJanS54noT0GgkW32ryiZynb/B8HEzthT8xy/BYSHXEpPpjbsOUDM8Zap9kahf4USgcjqGlcpTUn24ZwzNxiQYNY9Fzh4zp5/0aYLv7nCa/+TBgLg0yEmiizVh/JxWExUnjyCYVWvFNXdTuGH0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3609.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(396003)(39850400004)(66476007)(66946007)(76116006)(86362001)(83380400001)(66446008)(55016002)(508600001)(966005)(66574015)(52536014)(110136005)(71200400001)(8936002)(9686003)(7696005)(26005)(186003)(53546011)(166002)(6506007)(64756008)(8676002)(2906002)(5660300002)(66556008)(9326002)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: uUv2A7D5REaT/6/cVlN7TepTMzldO4afgkvorPNfLloLG+ZLU3algrQ7rmHM6qLR9NhaJ/9eEYIH2BELL8KX8rkeEv751qBEcladsTapm+LtpSn2OM71LSD9fH9mCpqMEKftqkiLL1XoNOxmMZvVMVrLbfozgwRuQCeQ1Igc7cGIF/31mfqpH7eCTolYQLvu47pB48ohfA4TOsCwEkZ3cxVZ3eBLh2v1rtRRFuAH2Xfytju6fQcsRM9xl9A/F2ofqpkhG4kpyPx3bKpLIcMQnUJt8KHLcaIzB68fvMPsJVZy7Nwmves4+GEfNwCAOHleO5DmXamdkSle26D+mjNVeZAvF1s6l+zxvHb2wNN7/HcdSfWvgmdN4ypetb3KVAJvtTgDAygUpsYXHjeXsTrHOcglNuMyAoSv/4X+bkdEE7MEw0lG3ofW0ZK1C9tqpQvxfGrf471iUMpsd14YUAhSqot2TREzIfLXAjkhP20j/mpU39PqehSWsukPLnqtZ+hG94eD+zAZvmLjwNxKRcoi4CA9NFTeJIva4ofy5b6DZ05UAhlJdVopqQz/dloQ2B++Vfzho6TGksHbAzIPD5ddYnuUqKn+ShBe2OcCoy/2antwVLAfNNx/sDeLhH90lXsnM5SHgJ5Xuu1Ux7SQbJQqqBLPvIeuxFdLtVp+UJ8dgDvlJK0y7L8GM+k+ZqdYhS0mq6Ga5bylbEwex0O7dgxvx3jBj+oVZoxut7DfW+oq0LA=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB36092FA11B951E91CA57898CAC929HE1PR0702MB3609_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3609.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d905715-edfb-4aee-3899-08d8e2dc27d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2021 09:17:26.0074 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GpRQ7vxXI0l0QLcWDxE1ToT7lM35AOh/ttuoXTff7YF+e+W+RCGSM4a3i1smgY7Iole5NvbKKUdnmgAdvvU7CVVLCETTatfEQyhUtLecHRs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2409
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/FPEM419dAuk0SeRAiT_RGOsNLI4>
Subject: Re: [spring] new draft on segment routing approach to TSN
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2021 09:17:46 -0000

Hi Bryan,

Sure, but there is no free lunch. :--))
You have added the problem of calculation of the budget.
Knowing your exact egress time in advance is not an easy task.
There will be an inaccuracy in budget calculations.

Cheers
Bala'zs


From: detnet <detnet-bounces@ietf.org> On Behalf Of Liubingyang (Bryan)
Sent: Monday, March 8, 2021 3:31 PM
To: Yaakov Stein <yaakov_s@rad.com>; Haoyu Song <haoyu.song@futurewei.com>; detnet <detnet@ietf.org>; spring <spring@ietf.org>; pce <pce@ietf.org>
Subject: Re: [Detnet] new draft on segment routing approach to TSN

Some advantages.
If you use budget instead of deadline, you don't need accurate time sync.
If you use budget, the time budget encoded in packet require fewer bits than using absolute time.


The tightness is related to whether and how many flows can be admitted. It is related to network resource utilization and revenue.


If e2e deadline is 1ms, then time sync with 1ms accuracy will not work well. Using budget helps resolve this problem.

Just my two cents.

Bryan


From:Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>
To:Liubingyang (Bryan) <liubingyang@huawei.com<mailto:liubingyang@huawei.com>>;Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>;detnet <detnet@ietf.org<mailto:detnet@ietf.org>>;spring <spring@ietf.org<mailto:spring@ietf.org>>;pce <pce@ietf.org<mailto:pce@ietf.org>>
Date:2021-03-08 21:38:20
Subject:RE: new draft on segment routing approach to TSN

Bryan

The local deadlines are specified in absolute time - not deltas.
So there is no need to add the time saved - it is already there!

As I previously replied, the accuracy of the time sync depends on the tightness of the budget.
It has nothing to do with the encoding.

Y(J)S

From: Liubingyang (Bryan) <liubingyang@huawei.com<mailto:liubingyang@huawei.com>>
Sent: 08/03/2021 14:55
To: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>; Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>; detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: new draft on segment routing approach to TSN

Hi Yaakov,

Great work. One suggestion.
If we divide the end-to-end delay budget to per-hop budgets, and carry them in SR header, we can mimic using the end-to-end absolute deadline. One thing we need to do is, when the actual time used in a hop is less than the budget of this hop, you can add the remaining budget to the budget of next hop. In this case, you can save a lot of bits used for time, and you don't have to rely on accurate time sync.

Bryan (Bingyang Liu)

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: Monday, March 8, 2021 1:37 PM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>; detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Detnet] new draft on segment routing approach to TSN

Haoyu

I think we are in agreement.

I do not see the need for explicitly handling the case of a packet missing a LOCAL deadline,
since the following switches will already handle this case optimally (and may still meet the overall budget).

Counting packets that miss their delay budget is indeed important,
and a counter could be configured in the egress router for this.
We'll need to define this when we get to the protocol specification.

It would be advantageous to put a threshold on the failure rate
and feed this back to the path/stack optimizer.

Y(J)S

From: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Sent: 08/03/2021 04:41
To: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>; detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: new draft on segment routing approach to TSN

Hi Yaakov,

Some feedback inline.

Best regards,
Haoyu

From: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>
Sent: Saturday, March 6, 2021 8:36 PM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>; detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: new draft on segment routing approach to TSN

Haoyu,

I'll address your points:

> The use of clock time as deadline requires network synchronization
That is a basic assumption of TSN networks (IMO the defining assumption).
However, the sync needn't be highly accurate - it depends on the tightness of the delay budgets.
>> Yes, I understand it. What I mean is that the method mentioned in the draft seems to be also applicable to other types of networks. For example, we can envision some time-critical traffic in DCN or WAN. If a protocol would be developed, can it also serve the other networks? If so, it would be better.


> accurate measurement of per-link propagation time
Yes, I am assuming that once an for all someone does a TDR or at least OWAMP/TWAMP/Y.1731-1wD delay measurement of the links, and these are stored in some database.
Once again, the required accuracy depends on the delay budgets.

> which can somehow limit the application scope of this work
If the delay budget only above the physically minimal delay by say less than 100 microseconds,
I agree that the previous two issues MUST be carried out. But in such cases there is no alternative.
If the delay budget is much higher than that, then one could use an RSVP-like mechanism,
sending a packet (or several packets) from source to destination collecting a stack of timestamps,
and then using that stack for the following packets.

> Mechanism should be provisioned to track where the timing requirement is violated and by how much
I'll leave the OAM for later. However there are already many high accuracy performance measurement techniques and protocols for this.
>> For this I mean something recorded in the same packet with the deadlines. If it misses the deadline, the receiver may need to know where it's violated. Other independent methods are possible, but it's better to consider if it can be integrated in the current proposal.

> Recently programmable scheduler research has proposed several primitives
Yes, I tried to stress that this ID is not limited to EDF (although sometimes that is a good strategy).
One can even reproduce Qbv behavior using a stack of deadlines (although why would one wish to do so?).

> such as PIPO and PIEO
I've heard of PIFO (Push In First out) but not PIPO. Is this a typo or something new?
I agree that there are mechanisms that are optimized for hardware, but I have come up with a very nice hardware implementation for PEDF
and prefer to find hardware implementations for optimal schedulers, rather than to determine schedulers based on optimal hardware.
>> Sorry that's a typo. I mean PIFO (although we do have a paper under review using the name PIPO). Yes I agree those are just abstract primitives. The actual implementation, if customized to a particular algorithm, would be simpler.

Y(J)S

From: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Sent: 05/03/2021 22:46
To: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>; detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: new draft on segment routing approach to TSN


CAUTION: External sender. Do not click links or open attachments unless you know the content is safe.
Hi Yaakov,

Just got a chance to read your draft. I agree with the comments of the others that this is a very interesting work. I'll just add a few points.


  1.  The use of clock time as deadline requires network synchronization, and accurate measurement of per-link propagation time, which can somehow limit the application scope of this work. Alternatively, one can simply budget a device latency which require a router/switch to obey. In case the overall budget is evenly divided by the hops, a single parameter is enough. Of course, if one wants to customize the budget on each hop (which might be necessary considering the different capability/capacity of each hop), a stack is still needed.
  2.  Mechanism should be provisioned to track where the timing requirement is violated and by how much (e.g., using timestamp or flag). This would be very useful for troubleshooting.
  3.  Recently programmable scheduler research has proposed several primitives such as PIPO and PIEO and provided feasible hardware implementations. The scheme proposed in this draft can easily fit into these primitives.

Best regards,
Haoyu
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Yaakov Stein
Sent: Tuesday, February 23, 2021 5:14 AM
To: detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: [spring] new draft on segment routing approach to TSN

All,

I would like to call your attention to a new ID https://www.ietf.org/archive/id/draft-stein-srtsn-00.txt<https://protect2.fireeye.com/v1/url?k=bb6c9c54-e4f7a554-bb6cdccf-86fc6812c361-ade234225c5dc3b6&q=1&e=61fd3663-a974-4041-8021-790fa60fae0d&u=https%3A%2F%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Farchive%252Fid%252Fdraft-stein-srtsn-00.txt%26data%3D04%257C01%257Cyaakov_s%2540rad.com%257C71c93afad8614e5d212e08d8e23156c8%257Cf9047108cc2c4e4897a343fad1b3bf9d%257C1%257C0%257C637508048843821932%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26sdata%3DJ5d%252Bz%252BmTnTm3C7%252FfD0YSo%252FXMk%252F67YxHlYVRfvv%252Fthcg%253D%26reserved%3D0>
which describes using a stack-based approach (similar to segment routing) to time sensitive networking.
It furthermore proposes combining segment routing with this approach to TSN
resulting in a unified approach to forwarding and scheduling.

The draft is information at this point, since it discusses the concepts and does not yet pin down the precise formats.

Apologies for simultaneously sending to 3 lists,
but I am not sure which WG is the most appropriate for discussions of this topic.

  *   DetNet is most relevant since the whole point is to control end-to-end latency of a time-sensitive flow.
  *   Spring is also directly relevant due to the use of a stack in the header and the combined approach just mentioned.
  *   PCE is relevant to the case of a central server jointly computing an optimal path and local deadline stack.
I'll let the chairs decide where discussions should be held.

Y(J)S