[Detnet] Re: WG adoption poll: draft-eckert-detnet-glbf-07

[Florian Kauer <[e-mail]>]

I support the adoption of this document.
ATS is an established method in TSN with interesting characteristics and having something with similar characteristics in scalable DetNets would be very useful.

A general comment for improvement:

The mechanism requires a SDN with a central controller that has full knowledge and control of the data plane AND all deterministic flows within.
This is probably obvious for everyone else currently active in the DetNet WG (i.e. mostly people with telecom background), but for me who has only experience in non-SDNs, it took some time and discussion with the first author to really understand what this implies.

To be concrete: The draft mentions "admission control" several times, but somehow I wrongly understood this as a function implemented locally on the ingress nodes, which obviously does not provide a deterministic network (because there would be no protection from multiple ingress nodes simultaneously admitting conflicting flows).

Thus, to be better understood by the wider IETF community (even though most if not all have much more SDN experience than myself...), I would propose to shortly outline these "prerequisites" in the very beginning of the draft more explicitly or (since the same likely holds for all drafts currently in circulation) write/reference a separate draft to better outline the scenario and differentiate it from networks without a central omniscient controller (like TSNs with SRP).

The same holds for the "path steering" aspect which is mentioned as very last in the draft, but for me the fact that the admission control is tightly coupled with the knowledge about the concrete path of every deterministic packet through the network was an essential prerequisite to understand everything above.

Some further small comments:

- The text has several TODOs/TBDs that would need to be solved, but none prevents the adoption IMHO
- The term "TSN-ATN" is used twice in the text. I assume that is a typo and should be TSN-ATS?
- Under 2.1. there is the sentence "These limitations are not starting to be resolved, and hence it seems like a good time to re-introduce this mechanism.". I guess this should be "NOW starting to be resolved"?

Greetings,
Florian

On 12/17/25 20:26, Lou Berger wrote:
> Hello,
> 
> This email begins a 4-week adoption poll for:
> 
> https://datatracker.ietf.org/doc/draft-eckert-detnet-glbf/07/
> 
> NOTE: IPR has been disclosed for this document, see https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-eckert-detnet-glbf
> 
> Please voice your support or technical objections to adoption on the list by the end of the day (any time zone) January 14th.
> 
> As a reminder this document is part of the larger set of adoption calls of thedocuments discussed at IETF 124:
> 
> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/05
> https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/18
> https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/13
> https://datatracker.ietf.org/doc/draft-eckert-detnet-tcqf/09
> https://datatracker.ietf.org/doc/draft-eckert-detnet-glbf/06
> https://datatracker.ietf.org/doc/draft-ryoo-detnet-ontime-forwarding/04
> https://datatracker.ietf.org/doc/draft-ryoo-detnet-nscore/02
> 
> Thank you,
> Lou (as Co-chair)
> 
> _______________________________________________
> detnet mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]