Re: [Detnet] Work on 'control plane signaling'

Dirk Trossen <> Tue, 02 February 2021 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 251A23A0C23 for <>; Tue, 2 Feb 2021 08:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rb3weV_oKfZH for <>; Tue, 2 Feb 2021 08:59:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E8C13A0C20 for <>; Tue, 2 Feb 2021 08:59:13 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4DVW8X3YS0z67jlB; Wed, 3 Feb 2021 00:53:00 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Tue, 2 Feb 2021 17:59:11 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Tue, 2 Feb 2021 16:59:10 +0000
Received: from ([]) by ([]) with mapi id 15.01.2106.006; Tue, 2 Feb 2021 16:59:10 +0000
From: Dirk Trossen <>
To: Balázs Varga A <>, DetNet WG <>
Thread-Topic: [Detnet] Work on 'control plane signaling'
Thread-Index: AdbS+lqYa7+TQjYfReuHab85wVHsgQmhJhjQAAFpzKA=
Date: Tue, 02 Feb 2021 16:59:10 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9ed9cc63d8d14641aec5390701c3eec9huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Detnet] Work on 'control plane signaling'
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Feb 2021 16:59:16 -0000

Hi Bala'zs,

Many thanks for those comments which come almost shockingly in time when I'm doing the edit for the next version.

We will try to address those and would much appreciate further comments when the next revision will come out.



From: detnet [] On Behalf Of Balázs Varga A
Sent: 02 February 2021 17:54
To: DetNet WG <>
Subject: Re: [Detnet] Work on 'control plane signaling'


Some possible improvement points for the next version:
1, Fixing terminology:
Current version contains some new terminology. It would be worth to use the already
exiting terminology of DetNet if appropriate and define new term if really needed.

2, Narrowing the scope of the draft:
I think adding a scenario description and a related figure is inevitable. You may consider
a figure similar to Figure 2 in rfc8964 or Figure 1 in draft-ietf-detnet-mpls-over-tsn-05.
Starting with a well-defined scenario could be a good starting point to increase the scope
in later versions. Furthermore it could put in context the current Figure 2. in

3, Defining the functionalities / capabilities per DetNet and/or TSN entity:
If a figure is added it is more easy to refer e.g., the signaling protocol peers (both internal
and external ones), signaling domain borders, etc.


From: detnet <<>> On Behalf Of Dirk Trossen
Sent: Tuesday, December 15, 2020 4:54 PM
To: DetNet WG <<>>
Subject: [Detnet] Work on 'control plane signaling'


many thanks for the great discussion during last week's interim on our plans to progress the 'control plane signaling' draft.

As we tried to outline in our revised structure (for the next draft update), our intention is to specify the required distributed end-to-end signaling for deterministic networking scenarios, not relying on managed, e.g., centralized, TE methods. With this in mind, we see the combination of RSVP-TE aspects and the interaction between RSVP at L3 and L2 solutions as the core of our contribution, labeled as 'RSVP-detnet' in our slide material. From this perspective, TSN is just one example for said L2 solutions.

Another possible route forward could be to narrow the discussion (and contribution) purely to the L3/L2 interactions between RSVP and specific L2 technologies, such as RAP (for TSN) - this route would lead then to something one could label as 'RSVP-tsn'.

We would like to seek your comments and thoughts on those possible routes. If anybody is interested in joining the efforts, please do let us know.


Dirk, on behalf of the draft authors