Re: [Detnet] Soliciting comments for detnet control signaling draft

["[e-mail]" <[e-mail]>]

Hi Bala'zs

you can see our answers to your questions inline.

Best regards,
Franz and Juergen

Von: detnet <[e-mail]> Im Auftrag von Balázs Varga A
Gesendet: Donnerstag, 19. November 2020 15:54
An: DetNet WG <[e-mail]>
Betreff: Re: [Detnet] Soliciting comments for detnet control signaling draft

Hi,

Just a couple of comments, what could be worth to sort out before an interim:

1, What is the scenario here? "TSN_over_DetNet" or "DetNet_over_TSN".
We need discussions for both, but would be great to go step-by-step.
It would be great to have a description/drawing on the scenario and see
e.g., the protocol peers (both internal and external ones), where DetNet
nodes are, where DetNet service starts/ends.
->
In the current version of the contribution our main focus is a distributed DetNet UNI based on DetNet over TSN. DetNet end-systems (assumption is DetNet is also supported by end-systems / in-band) shall be able to announce their deterministic end-2-end communication relation to the DetNet aware network. Distributed DetNet UNI (RSVP-DetNet) is required to announce their requirement or deterministic communication between DetNet end-system and first DetNet router.

2, How is this draft related to the TSN specific data plane drafts?
Those are describing requirement and solutions for "TSN-aware DetNet" nodes.
I am not fully sure that your draft follows that concept.

->
see answer 3

3, Described API contains only a portion of flow-information-model draft parameters.
Is it intentional? If yes, why the deviation?
->
In principle the RSVP DetNet APIs follows the flow-information-model draft parameters, but the assumption is beyond the RSVP DetNet APIs there exists a deterministic application programming interface. This interface contains all parameters described in flow-information-model.
The assumption is, between the deterministic application programming interface and the upper RSVP DetNet API there is a mapping layer (e.g. deterministic QoS and service protection is mapped into. DSCP).
RSVP-DetNet supports a distributed DetNet User-Network-Interface based on reservation (currently centralized scheduling is not supported).

4, Please, clarify your terminology. E.g., what do You mean by Transport Flow Identifier?
What is a DetNet IP Flow Edge Network? Many terms are new from DetNet perspective.
Some of the text is unclear e.g., text before Figure 2 "... second L2 control plane entity
bridges to ..." (What is bridged by the control plane? Do You mean data plane?)
->
Thanks, the next version of the contribution will clarify the terminology.

Cheers
Bala'zs

From: detnet <[e-mail]<mailto:[e-mail]>> On Behalf Of Dirk Trossen
Sent: Thursday, November 19, 2020 1:54 PM
To: DetNet WG <[e-mail]<mailto:[e-mail]>>
Subject: [Detnet] Soliciting comments for detnet control signaling draft

All,

As mentioned in the presentation in today's DetNet WG, we would be very interested in hearing your views and comments on the proposed RSP DetNet proposal made in the control signaling draft (https://tools.ietf.org/html/draft-trossen-detnet-control-signaling-00<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-trossen-detnet-control-signaling-00&data=04%7C01%7Cfranz-josef.goetz%40siemens.com%7C0dbd88fb783642b31a1d08d88c9b0f6b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637413944899463010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t90qk1%2Fv07Ar9DpB19SPEXwV9lDQjpf8jCCAUzBF6Rg%3D&reserved=0>)

Please send any comments to the list for discussions, which we can hopefully deepen in the suggested interims meeting. Any suggestions for contributions is also warmly welcome.

Best regards,

Dirk