WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet
Datatracker: https://datatracker.ietf.org/group/detnet/about/
09:30-11:30 JST (00:30 – 02:30 UTC)
3F G303
Materials: https://datatracker.ietf.org/meeting/116/session/detnet
Note taking: https://notes.ietf.org/notes-ietf-116-detnet#both
Meetecho:
https://meetings.conf.meetecho.com/ietf116/?group=detnet&short=detnet&item=1
Onsite tool:
https://meetings.conf.meetecho.com/onsite116/?group=detnet&short=detnet&item=1
Audio stream: https://mp3.conf.meetecho.com/ietf116/detnet/1.m3u
Chat: https://zulip.ietf.org/#narrow/stream/detnet
Session ICS:
https://datatracker.ietf.org/meeting/116/sessions/detnet.ics
YouTube: https://www.youtube.com/watch?v=mF2CE9utDZU
Presenter: Chairs
Scott Mansfield: WRT ITU-T liaison 1 (slide 9): I want to talk about the
subset of RFCs that should be shared with ITU-T - let me know, they are
not due until 18Apr23 so have some time.
Scott Mansfield: WRT ITU-T liaison 2 (slide 10): I would like to respond
back to ITUT back on this, their next study group meeting not til July.
We want to keep pressure up on what this group is doing, to set up guide
rails for that group. Let me know if you know of anything specific that
we need to include in the response.
Lou Berger: Can you propose a response?
Scott Mansfield: Given guidance e.g. of hot topics, yes, can do, we can
take this offline.
Link:
https://datatracker.ietf.org/doc/draft-ietf-detnet-controller-plane-framework-04
Presenter: Xuesong Geng
Quan Xiong: WRT Slide Doc Structure Update. Want to put Multi-Domain
Aspects discussion into Controller Plane section, sec 3.
Xuesong Geng: We can discuss with Carlos - we were considering a
separate section to make it easier for the reader to find.
Quan Xiong: Need to consider distributed or hybrid control plane. Need
more discussion on list. Path establishment and reservation - can be
implemented separately, should not be joined.
Xuesong Geng: In Controller Plane architecture draft, we covered 3 cases
- central, hybrid, and distributed. The point here is to make more
logical organization, but the implementation would be the same.
Lou Berger: Good discussion, look forward to discussion on list. Now is
a good time for the WG to review the latest version of the draft and
send comments to the list.
Link:
https://datatracker.ietf.org/meeting/interim-2023-detnet-01/session/detnet
Presenter: David Black (remote)
Lou Berger: Regarding schedule slide: We are planning a series of
meetings to go over proposals. We want to establish directions to
recommend to WG to bring to list for consensus. Intent is also to record
the meetings so that if you can't attend, you can view it later. Plan is
now to use Webex, but could move to Meeteccho. We tried Webex at
previous meeting - apparently it recorded a lot of extra time, so not
ideal, but worth a try, can adjust as necessary. Keep chairs in loop if
there are problems or success with the process. Thanks to David Black
for help with this.
Draft:
https://datatracker.ietf.org/doc/draft-ietf-detnet-scaling-requirements-01
Presenter: Peng Liu
Greg Mirsky: I can imagine why time sync might not be critical for data
plane itself, but how can the one-way delay be measured w/o clock
synchronization? I am not aware of any such method.
Lou Berger: This draft is about requirements. Your question is about
implementation; it is not a first level requirement, but rather a
derived requirement.
Greg Mirsky: But if requirement is to be able to accurately measure
one-way delay...
Peng Liu: We had a one-way delay discussion before...
Lou Berger: Need to take this to list. It is a great discussion point,
but need to deecide where to capture it, since we need to capture it for
sure.
David Black: I suggest separating "measuring" from "achieving" - one can
perhaps achieve without measuring it, e.g. if you know the delays of
each of the segments, you can add them together to get the end result
without explicitly measuring the end-to-end delay.
Greg Mirsky: (from chat) As the saying goes "You cannot control, what
you cannot measure".
David Black: (reply, from chat) There's at least one proposed solution
that does that piecewise rather than end-to-end. (David was referring to
ADN, agenda item 6)
Toerless Eckert: the document is on the WG github, please feel free to
raise issues with the document there.
Lou Berger: As long as we keep in mind that consensus is via the list.
Draft:
https://datatracker.ietf.org/doc/draft-ietf-detnet-topology-yang-00
Presenter: Xuesong Geng and Zhenqiang Li
Xuesong Geng: There is an updated version of the draft. Next step is to
activate it. Prepare new doc on how to use this YANG model, and want to
ask WG about this proposal. Just want to publish and get discussion
going again.
Dean Bogdanovic: There is RFC8345 Network Topo yang model, why not use
that and just augment with DetNet specificities?
Xuesong Geng: Want to also consider queueing delays.
Tianji Jiang: There are lots of additional parameters in 5G, like
interval mean packet - not just delay.
Lou Berger: This is building on TEAS work, topologies, building on other
work, not starting from scratch.
Dean Bogdanovic: TEAS work is deriving from RFC8345
Draft
https://datatracker.ietf.org/doc/draft-joung-detnet-asynch-detnet-framework-01
Presenter: Jinoo Joung
Lou Berger: sorry no time now for comments. This topic will be the
subject of future discussion meetings, will have more time to discuss
there.
Draft: https://datatracker.ietf.org/doc/draft-eckert-detnet-tcqf-02
Presenter: Toerless Eckert
Lou Berger: Good discussion, we will have more discussion in open
meetings to come.
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding-05
Presenter: Shaofu Peng
Lou Berger: Please work with David Black to schedule further discussion
at side meetings.
Draft:
https://datatracker.ietf.org/doc/draft-yzz-detnet-enhanced-data-plane-02
Presenter: Xuesong Geng
Quan Xiong: You mentioned flow aggregation and priority, and time info.
But enhancement is for the forwarding layer - what is the relation to
service layer?
Xuesong Geng: Service layer is not only about flow label for PREOF, but
also in ipv4/6 data plane there is flow ID (e.g. n-tuples) - this is a
general concept, not just flow label as already defined.
Quan Xiong: Need more discussion relating forwarding layer and service
layer.
Xuesong Geng: Bounded latency belongs to forwarding layer, sure.
Quan Xiong: Still could have discussion.
Greg Mirsky: Going forward, please use current MPLS terminology - some
field names shown are very old, obsolete now. Also, what is your
intention for how to carry shaper credit information? If you want to
carry the quantity, i.e. amount credited, you can look at MPLS Network
Action work to add ancillary data in label stack.
Xuesong Geng: I am not an MPLS expert, and this is an early proposal,
but will look at it.
Greg Mirsky: It is good to understand what work is available to base
this new work on.
Draft:
https://datatracker.ietf.org/doc/draft-xiong-detnet-data-fields-edp-00
Presenter: Quan Xiong
Lou Berger: Clearly there is interest in doing additions to data plane
from the queuing side; it would be good to have both of these
discussions proceed in lockstep.
Draft:
https://datatracker.ietf.org/doc/draft-guo-detnet-vpfc-planning-01
Presenter: Kehan Yao 姚柯翰
Xuesong Geng: I notice that this draft is shown as standards track, but
it discusses implementation status. I suggest to the authors to change
this to informational track.
Kehan Yao: We will consider this.
Quan Xiong: This is a good proposal for queueing configuration model,
but it is explicitly based on cycle mechanism - please consider all
queueing mechanisms.
Kehan Yao: We will consider this in future versions.
Draft:
https://datatracker.ietf.org/doc/draft-eckert-detnet-criteria-assessment-00
Speaker: Toerless Eckert
Greg Mirsky: You said that in uncongested overprovisioned systems there
is no delay - I think you meant no jitter, right?
Toerless Eckert: Right - if uncongested and overprovisioned, there is no
queing delay variation, but delay still exists.
Lou Berger: Please take to the list. This highlights the importance of
common terminology, something to add to criteria discussion.
Draft:
https://datatracker.ietf.org/doc/draft-sw-detnet-network-slice-mapping-yang-02
Presenter: Xueyan Song
Lou Berger: You presented this before, and we discusssed alignment with
TEAS - I suggest you send a message to them letting them know that this
work is happening here and being discussed here.
Xueyan Song: OK
Draft: https://datatracker.ietf.org/doc/draft-km-detnet-for-ocn-00
Presenter: Kiran Makhijani
Dean Bogdanovic: I agree that the app should not have to understand the
internals of DetNet, but app design is not black/white, or only
considering the action in the cloud. Industrial applications using
realtime operating systems are often organized as high level swarms. For
example in automotive, many calculations are done in the car, but then
global context is updated to the cloud only at longer intervals. In an
industrial environment, for example robots, they often work like swarms,
and the computation that is done in the cloud is then sent to a local
controller(s) to control the swarm(s). So in such cases it is not so
clearly delineated, it is more granular, so perhaps Detnet would only
need to be deployed on local devices.
Kiran Makhijani: But there are many scenarios, and yes DetNet may only
apply to some.
For example we may have many sites of factory floors, for which we want
to control the supply chain, so that doesn't need to be local at all.
Lou Berger: This is interesting discussion, since it is less about the
data plane side, so it is a different sort of topic for the DetNet WG -
we look forward to more on-list discussion on this, and in open meetings
(note that webexes are already announced for some).
Lou Berger: Thanks to everyone here and online - see you in San
Francisco!!
Adjourn 11:30
Self identified note takers:
Ethan Grossman
Lou Berger