WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet
Datatracker: https://datatracker.ietf.org/group/detnet/about/
09:30-11:30 ICT (02:30-04:30 UTC)
Room: Chitlada 1 --
https://datatracker.ietf.org/meeting/122/floor-plan?room=chitlada-1
Time zone converter:
https://www.timeanddate.com/worldclock/converter.html?iso=20250317T023000&p1=28
Materials: https://datatracker.ietf.org/meeting/122/session/detnet
Note taking: https://notes.ietf.org/notes-ietf-122-detnet?both#
Meetecho: https://meetings.conf.meetecho.com/ietf122/?session=33924
Onsite tool: https://meetings.conf.meetecho.com/onsite122/?session=33924
Video stream: https://meetings.conf.meetecho.com/ietf122/?session=33924
Audio stream: https://mp3.conf.meetecho.com/ietf122/33924.m3u
Chat: https://zulip.ietf.org/#narrow/stream/detnet
ICS: https://datatracker.ietf.org/meeting/122/session/33924.ics
YouTube: https://www.youtube.com/watch?v=zsi64ko02Pk
Meetecho recording:
https://meetecho-player.ietf.org/playout/?session=IETF122-DETNET-20250317-0230
Presenter: Chairs
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-01-intro-wg-status-draft-status-02
Lou Berger: Would like to hear from authors of the drafts on slide 14,
e.g., the Requirements document and Framework.
Jinoo Joung: I'll be in Madrid and can present at the proposed
DetNet-TSN Workshop.
Toerless Eckert: Solicit the TSN community to see if they have spefic
questions on the DetNet work.
Ask what do they need, what have we not done, in addition to their stuff
should work with IP, what are the DetNet questions they've always been
afraid to ask?
Lou Berger: We should poll our community as well to ask similar
questions.
Call for presentations re the real world to highlight own experiences
from the DetNet perspective to the TSN community.
Carlos Bernardos: Opportunity to invite industry in Madrid already doing
DetNet-TSN work, particularly those not necessarily part of the IETF
community yet.
Janos Farkas: Good suggestion.
Lou Berger: E-mail to the chairs if you want to present on a particular
topic, or if you are one of the authors and have a willingness to
present. Jinoo has already expressed interest, any others?
Toerless Eckert: The evolution of the queueing work for example
(analysis of existing mechanisms). Would be happy to help with that. How
to best reach out not only to industry, but also researchers working in
TSN to get involved in DetNet. Let's aim to get an exception for those
attending the workshop to not have to register for the IETF to easily
participate in the workshop, e.g., who are in the TSN community.
Lou Berger: Hoping the ADs can help us with registration concerns.
Janos Farkas: Thanks to John our past AD and Ketan our future AD!
Note that IEEE 802 only has had a weekly pass, but for this occasion
they are instituting a one-day pass too.
Draft:
https://datatracker.ietf.org/doc/draft-ietf-detnet-dataplane-taxonomy/02
Presenter: Jinoo Joung
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-02-dataplane-enhancement-taxonomy-01
Lou Berger: Want to bring the slide on the Seven Categories and the
document to the attention of any author of a queueing solution. If you
find that your document or solution does not map well, then we want to
hear about it on the list. We really want to hear if you think these
categories are the right categories. Update your document to reference
the taxonomy document and identify where your solution fits in. To move
things along, we are thinking about an interim meeting to review,
discuss and agree on the different queueing solutions and where they fit
in. We want to end up with a consolidated table of solutions and mapping
tp categories. Will help us identify overlap and separate solutions. Now
is the time to start to whittle down on the solutions, based on this
framework.
Peng Liu: We have 7 suitable categories, does that mean the WG will
adopt seven solutions drafts or only one framework solution draft?
Lou: We hope we won't have 7 queueing solutions, that's a lot. We
suspect there is overlap amongst them. Will we adopt multiple? We can
adopt multiple solutions if it makes sense.
Draft:
https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/04
Presenter: Jinoo Joung
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-03-latency-guarantee-with-stateless-fair-queuing-01
No comments received.
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/14
Presenter: Peng Liu
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-04-deadline-based-deterministic-forwarding-00
No comments recieved.
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/10
Presenter: Peng Liu
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-04-deadline-based-deterministic-forwarding-00
No comments received.
Draft:
https://datatracker.ietf.org/doc/draft-xiong-detnet-flow-aggregation/02
Presenter: Tianji Jiang
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-06-flow-aggregation-for-enhanced-detnet-00
Lou Berger: From chair perspective, backup to Slide 2, the draft focuses
on multi domain first, yet we don't have a definition of a single
domain. We would really like a definition of aggregation within the
domain. Also, it would be good to look at our YANG model that has
certain terminology and make sure you are aligned with it. Then talk
about how you are doing aggregation in the context of our service
definitions in the YANG model. Please align with our prior RFCs and
describe single domain then multi domain. This is good work and we'd
like to see it progress.
Draft:
https://datatracker.ietf.org/doc/draft-zhao-detnet-enhanced-use-cases/02/
Presenter: Quan Xiong
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-07-enhanced-use-cases-for-scaling-deterministic-networks-00
Jinoo Joung: Think the draft is very valuable because it suggests real
numbers, e.g., section 3.4 detailed usage scenarios (with real numbers
of max delay and jitter). How did you derive these numbers exactly? The
overall requirements and scenarios are described, but what processes
were used to attain these numbers?
Quan Xiong: The data of the requirements is from 3GPP or ETSI. We
clarified the results in the draft for each use case.
Jinoo Joung: These numbers come from a literature survey? Do not come
from real experiences from a real deployments?
Muhammad Jadoon: They are from literature and also use cases defined
from 3GPP and ETSI, wheree different companies have provided this
datafrom different sources, but we do not have experimental results.
Jinoo Joung: More explanation needed. Please fill the gap between the
overall characteristics of the scenarios and the numbers shared.
Carlos Bernardos: We will do some implementation and validation of this
in the EU project MultiX.
Muhammad Jadoon: We will incorporate these findings in the draft.
POLL: Do you think the WG should be working on this topic?
Lou Berger: Very few participants. We don't have enough information.
Please look at the draft so you can participate and voice an opinion.
Draft:
https://datatracker.ietf.org/doc/draft-ryoo-detnet-ontime-forwarding/02
Presenter: 유연철 Yeoncheol Ryoo
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-08-on-time-forwarding-with-push-in-first-out-pifo-00
Lou Berger: Regarding slide 8 (on how this work fits into the queueing
taxonomy), this is a good addition.
Draft: https://datatracker.ietf.org/doc/draft-ryoo-detnet-nscore/00
Presenter: 유연철 Yeoncheol Ryoo
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-09-non-work-conserving-stateless-core-fair-queuing-00
Rodney Van Meter: Because I am not a regular DetNet member, not sure
where the N-SCORE algorithm needs to be implemented in the network.
Which nodes in the network are actually executing this? The source, or
the first router, or core routers, or along the whole path?
Yeoncheol Ryoo: Edge routers use the N-SCORE scheduler framework.
RDV: At every router or only near the source?
Jinoo Joung: There are two kind of nodes in the network, entrance nodes
and core nodes. Entrance nodes maintain the flow state and do the old
packet meta data marking. The packet meta data will be updated in the
core network. In the core nodes the flow state does not need to be
maintained at all. Core nodes look at the packet and extract the meta
data and schedule packets accordingly, updating the meta data slightly.
That's the big advantage of this approach.
Rodney Van Meter: We are comfortable with the performance or
computational requirements per packet?
Jinoo Joung: Yes. The computational complexity goes to the entrance
node, which is located in the edge of the network and there can be fewer
number of flows compared to the core nodes.
Draft:
https://datatracker.ietf.org/doc/draft-bernardos-detnet-raw-multidomain/05
Presenter: Carlos Bernardos
Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-detnet-10-detnet-multidomain-extensions-01
Quan Ziong: Agree with you. As mentioned by Lou, we need to first define
the single domain vs multi domain. Second, suggest to add some
extensions into this draft, e.g., for the control plane.
Carlos Bernardos: I agree we need to consider those parts.
Quan Ziong: I would like to contribute.
Lou Berger: These would be good additions, though they change the
document from a framework to a solution document. No issue with that
personally. Perhaps do 2 and then do 1.
Jinoo Joung: What is the definition of a domain?
Carlos Bernardos: Good question. Two considerations. One is the actual
technology that is used, as there are differences between wired and
wireless technologies, and even between wireless technologies. The other
consideration is the administrative domain; who is in control of that
set of entities that compose a domain. From those two perspectives,
those are different domains and they imply differences in the solution.
Jinoo Joung: Agree there can be two different criteria. But that's also
a problem. Consider the technical view. If you have different data plane
solutions in each of the domains, it is very clear to distinguish these
two domains. These domains can be administered by a single administrator
and vice versa. Would like to help you define.
Carlos Bernardos: That would be great and I would like to work with you.
Thus if you have a a single adminstrative domain with different data
plane technologies that is a kind of multi-domain problem. But it is
also a problem if we have the same data plane technology with different
administrative domains. So both are multi-domain problems with
potentially different gaps to address.
Lou Berger: As a contributor, I think we are going to have a lot of
discussion here. As I read your document, I saw domain as scoped by a
single PCE controller. It was a controller plane definition of domain
and it made a lot of sense to me. A single PCE would be one domain, and
another PCE would be a different domain, you might have coordination
between them - I think that's in your draft.
The notion that different underlay technologies is the definition of a
domain, I personally disagree with (as a contributer, not as chair). I
see no reason why a single PCE couldn't control multiple technologies.
In fact I could see benefits of it controlling multiple technologies, so
I'm much more comfortable with the definition that you had in the
document versus what you said at the mic. This is the reason why we'll
work on the document and we'll clarify it.
Carlos Bernardos: Yes let's discuss further. Also think I agree with you
in the sense that I'm not saying that the solution should not be based
on a single PCE. I think exploring the multi-domain on the data plane is
also useful, even though we go for the solution with a single PCE per
administrative domain.
Lou Berger: Multiple technologies running in a single control domain and
multiple control domains is interesting, but multi-domain is not
necessary multiple technologies. Even multiple wired technologies it is
still one administrative domain.
Carlos Bernardos: Good exercise to ask if there is anything specific or
required about multiple technologies in a single control domain.
Lou Berger: We agree on what we want to solve. It is a terminology
issue.
Final Comments by the co-chairs:
JOHN SCUDDER THANK YOU VERY MUCH FOR ALL YOUR EFFORTS as the DetNet AD!
Not only for all your contributions to the working group, but also to
the IETF.
Janos Farkas: It's been a busy time. RAW
started with you and then you helped to merge it back into DetNet.
Thanks for all your efforts.
John Scudder: You've been a great group to work with and you made it
easy.
Lou Berger: We expect you to continue as a contributor, so don't go
away. Thank you John.
Lou Berger: Thank you everyone for participating and see you in Madrid!