WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet
Datatracker: https://datatracker.ietf.org/group/detnet/about/
9:30-11:30 PT (16:30-18:00 UTC)
Room: Georgia B --
https://datatracker.ietf.org/meeting/120/floor-plan?room=georgia-b
Time zone converter:
https://www.timeanddate.com/worldclock/converter.html?iso=20240723T163000&p1=256
Materials: https://datatracker.ietf.org/meeting/120/session/detnet
Note taking: https://notes.ietf.org/notes-ietf-120-detnet#both
YouTube: https://www.youtube.com/watch?v=3MS6ZVR-GJ0
Sesseion recording:
https://play.conf.meetecho.com/Playout/?session=IETF120-DETNET-20240723-1630
Presenter Chairs
From the chat: Janos Farkas: regarding Liaisoning with IEEE 802.1, they
are sending the following response:
https://www.ieee802.org/1/files/public/docs2024/liaison-response-itu-t-SG13-LS156-DetermNetwrking-0724-v01.pdf
From the chat: Xuesong Geng:
As the author of the topology yang, I want to inform that it will be
updated recently and if there are any comments from WG, please let us
know
Draft: https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/18
Presenter: Pascal Thubert and Janos Farkas
From chat: John Scudder: Tiny nit: lower-case "L" in lCPF looks like
iCPF. Consider upper-case, as in LCPF?
Lou Berger: Really appreciate the work so far. Thank you for the
changes. Before last call, it would be helpful to go back and look at
comments that came in (particularly from November).
Draft:
https://datatracker.ietf.org/doc/draft-bernardos-detnet-raw-multidomain/03/
Presenter: Carlos Bernardos
Jinoo Joung: Very interesting topic. The diagram just showed is quite
generic, in the sense that any type of multi-domain network is being
considered. What are the specific deterministic requirements? Suspect
that the data and control planes will need to be quite different, thus
do you have a particular context in mind?
Carlos Bernardos: The experimental testbed has 3 domains. Extensions
needed to sync the different domains to ensure the e2e requirements are
met from a deterministic point of view. That's where we believe the work
must be done: the control plane.
From the chat: Quan Xiong: Two concerns for multi-domain with PCE, one
is that it needs to clarify the specific requirements for DetNet. The
data plane solution which Jinoo mentioned has been discussed in PCEP
extensions in other individual drafts. The second concern is what is the
difference between inter-domain and multii-domain for DetNet?
Carlos Bernardos: Re single- vs multi-domain: interdomain is a term we
could use as well here. Nuance regarding if the multi-domains are owned
by different administrative domains.
From the chat: Quan Xiong: The second concern is that difference between
intra-domain and multi-domain. Maybe there are no additional enhancement
based on intra-domain extensions for PCE.
From the chat: János Farkas: imo, at least some aspects of multi domain
should work independent of queuing schemes.
From the chat: Quan Xiong: Agree with Janos, queuing may be considered
first in intra-domain. The queuing-based extensions related draft for
your reference:
https://datatracker.ietf.org/doc/draft-xiong-pce-detnet-bounded-latency/
Xuesong Geng: Confirm that there is good contribution here for
controller plane and multi-domain considerations. Considering the
framework document is very general description, this work is very
necessary. Protocol interworking that has been introduced in this work,
so wondering if there is an exact protocol in mind to extend it to
support this functionality?
Carlos Bernardos: We haven't yet identified/selected the protocol as
yet. First considering the logic and semantics. The protocol to be the
next step of this work.
From the chat: Loa Andersson: how much of the inter-domain specification
is specific RAW and how much is generic detnet?
From the chat: Janos Farkas: the point was to make it generic to DetNet,
not so specific to RAW.
From the chat: Lou Berger: (as contributor) I think most is likely to be
generic TE multidomain/interdomain.
From the chat: Loa Andersson: thanks Janos, that was what I thought, but
I still hear a lot of RAW.
Xuesong Geng: Noticed previously your work is about WiFi considerations,
and this time you are mentioning 5G/6G. Wonder whether this project is
related to mobile standards (3GPP) work or just a technical project?
Carlos Bernardos: Although we do not have a delegate attending 3GPP, we
are considering what they have done and we are trying to comprehend from
multiple wireless standards' standpoints.
Lou Berger: Please take the comments here and do another update. Xuesong
said something very important - multi-domain considerations have been
integrated into the control plane docs. Please have a look at other
documents to ensure the inclusion of multi- and inter-domain
considerations.
Draft:
https://datatracker.ietf.org/doc/draft-ietf-detnet-dataplane-taxonomy/01
Presenter: Jinoo Joung
Shaofu Peng:
Want to confirm that for the bursty flow, do you want to regulate the
DetNet node?
Jinoo Joung: Three important parameters (e2e latency bound, e2e jitter
bound, avg latency) are needed to regulate the flow.
Lou Berger: Thanks for the really good work and the update. The comments
made at IETF 119, have not been incorporated as yet? What's your plan to
incorporate?
Jinoo Joung: There are 6 outstanding comments to be addressed. They will
be resolved as soon as possible.
Lou Berger: It is reasonable to say you will address after completion of
the reference topology. I also want to highlight the last slide
presented. Want a framework to evaluate the various solutions. The
intent is that once we have the taxonomy flushed out, we can go and look
at the different solutions, and describe or categorize them in such a
way that we can figure out which of the solutions to advance.
Draft:
https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/03/
Presenter: Jinoo Joung
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/11/
Presenter: Shaofu Peng
Draft:
https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/07/
Presenter: Shaofu Peng
Lou Berger: the next time you present, please include a summary of the
discussion from the other working groups where you are presenting this
work.
Draft: https://datatracker.ietf.org/doc/draft-km-detnet-for-ocn/04/
Presenter: Kiran Makhijani, Luis Contreras
Antoine Fressancourt: In the data plane agnostic approach, did you
consider using RSVP for traffic engineering and the specification of the
flows in control messages not coming from a controller per se?
Luis Contreras: It could be a potential option.
Draft:
https://datatracker.ietf.org/doc/draft-varga-detnet-srv6-data-plane/00/
Presenter: Balázs Varga
From the chat: Xuesong Geng: I would like to remind that there has been
a WG document in SPRING WG for this topic:
https://www.ietf.org/archive/id/draft-ietf-spring-sr-redundancy-protection-02.html
Xuesong Geng: SPRING WG published about 2 years ago a similar draft that
is now an RFC. The new draft updates that work to consider DetNet.
Balazs Varga: There are significant differences between the drafts, with
regard to replication. Let's discuss further, to harmonize the drafts.
Xuesong: In the first stage, we wanted to put in DetNet WG, but DetNet
was still working on data plane and native IP header. Not quite ready
for SRv6 work in DetNet at that time. To clarify the current
relationship between the efforts, there is some verbiage included, but
it needs updating.
From the chat: Janos Farkas: that draft says: "Inspired by DetNet Packet
Replication and Packet Elimination functions".
Rakesh Gandhi: Have you looked at using the flow label from IPv6 header
itself? DetNet SID is in the Destination Address, by doing some kind of
SID compression there could be some implications. Have you thought about
putting those things in the Source Address?
Balazs Varga: As currently the DetNet SID must be the last SID,
compression is not so interesting, but it is a topic where further
discussion is needed.
Jinoo Joung: For clarification, currently it seems only the PREOF
function is considered. Are you planning to include any data plane
solution specific sid format? In the previous meeting Toerless suggested
such a draft to specify the header format for the data plane. I think a
similar effort must happen for this document as well.
Balazs Varga: Do you mean the latency information?
Jinoo Joung: Each data plan solution requires its own header fields,
e.g., finish time. If you plan to include that kind of information?
Balazs Vargas: Further discussion needed. In this proposal we've only
focused on the service sub-layer. But it would be interesting to extend
to the forwarding layer.
Janos Farkas (as a contributor): Good to evaluate the differences
between the two drafts. To note for the record, to my recollection, it
was commented multiple times that the earlier draft was not in line with
the DetNet architecture and the cited sentence: "Inspired by DetNet
Packet Replication and Packet Elimination functions" was a workaround,
the daraft has not been brought in-line with the DetNet architecture. In
my understanding, the draft presented by Balázs, is in-line with the
DetNet architecture.
Lou Berger: If there isn't overlap, then that should be called out. Also
if there is value-add, that should be called out. We don't need a second
draft on the same topic.
Xuesong Geng: More discussion off-line to articulate these issues.
Balazs Varga: Off-line and on the list!
13:00 - 14:30 PT (20:00 - 21:30 UTC)
Room: Regency E-F --
https://datatracker.ietf.org/meeting/120/floor-plan?room=regency-e-f
Time zone converter:
https://www.timeanddate.com/worldclock/converter.html?iso=20240725T200000&p1=256
Materials: https://datatracker.ietf.org/meeting/120/session/detnet
Note taking: https://notes.ietf.org/notes-ietf-120-detnet#both
YouTube: https://www.youtube.com/watch?v=VrL8Ye6763g
Sesseion recording: https://www.meetecho.com/ietf120/recordings#DETNET
Presenter: Chairs
Draft:
https://datatracker.ietf.org/doc/draft-xiong-detnet-flow-aggregation/01/
Presenter: Tianji Jiang
Toerless Eckert: Without having all the 5G background, it is difficult
to understand what DetNet would have to do to handle the various
aggregation options. A stripped down outcome would be helpful and might
motivate people to understand the 5G stuff.
Toerless Eckert: My Main concern is still that the key part of
aggregation is needed for large scale DetNet. From wider scale remote
control IoT application there are a humongous number of flows with very
far apart bursts, devices sending messages every 1 to 10 msecs, and if
you have 10's of thousands of those, and not coordinated, you are adding
up those bursts and wasting tremendous bandwidth in the network. Thus
aggregation without interleaving is far too short going step. 5G and
3GPP really needs to look into that.
Tianji Jiang: for the 5G part. Consider the diagram on slide 6. It is
just a black box. 5GS is just a transit node. It might become part of
multiple DetNet nodes. Depends on how 5GS is being structured and the
number of user plane functions (UPFs) used in the 5GS. If you consider
the 5GS logical node, on the left side, it is like a UE, mobile
equipment with 3GPP access. For the IoT part, actually it is being
discussed a lot, not necessarily from the DetNet perspective yet, but
how it can be accommodated in the 5G system.
Tianji Jiang: On the right side, the UPF can do the routing
functionality. The right hand side is connected to other DetNet nodes or
other networks, other sub-domains. It is like a big holistic domain.
This work for the 5GS has been standardized in the spec already. There
was a liaison between 3GPP and IETF talking about various parameters
needed to make the coordination go better. Currently, 3GPP is doing it's
own extension at the moment.
Toerless Eckert: This would ultimately be similar to using TSN
technology for DetNet subnets and TSN hops. We need to look into thsose
underlying technologies and their guaranteed behavior, especially for
the latency. While interesting to see 3GPP looking into stateless
weighted fair queueing, some of our proposals from our QoS side will
provide better scalable bounded latency and those considerations must go
into 5G. Even if we'd like them to be a black box, they need to be a
black box that scales for 5G services.
Toerless Eckert: I'm talking about the user plane. You need to point to
the UE and the queue and traffic models.
Tianji Jiang: This is a black box. You can provide other parameter
settings and requirements that choose policy functions to help 5GS to
set its QoS requirements for QoS flows. In the IETF domain, the DetNet
controller is going to do the mapping.
Toerless Eckert: If the 5G technologies are not going to supply, in the
user plane, good scalable and efficient per hop bounded latency
algorithms, then they won't be good subnets for a large-scale DetNet
system. Worried that 5G has not yet considered the full details needed.
Tianji Jiang: For bounded latency guarantees, the liaison has exchanged
with the IETF. Can the IETF domain send that latency boundary to us
(3GPP)? If so, 5GS has a particular parameter called a Packet Delay
Budget to the UE. If provided to the 5GS, then that will be handled.
Toerless Eckert: Many more technical details are needed beyond sending
an SLA and magically everything works.
Tianji Jiang: Two types of traffic parameters.
It's a per logical node with flow level. So as long as the IETF
controller provides the aggregated parameters to 5GS, the 5GS will
enforce it. And also it can enforce the flow level parameters. I think
all the details actually are in this draft.
Tianji Jiang: There was Liaison Statement exchange between 3GPP SA2 and
DetNet WG.
From the chat: Janos Farkas:
Cited LSs:
incoming: https://datatracker.ietf.org/liaison/1800/
sent: https://datatracker.ietf.org/liaison/1816/
Lou Berger: You are hitting on something that actually is pretty
important. If you have a use case that you don't think is covered in
existing documents, please do come here, present it, and the parameters
you would like to see added. Thank you very much for bringing the
document here. However, currently the document says its Standards track,
which would mean you are headed towards making some changes. Yet in
reading the document, it is not clear what changes you are asking for
and what cannot be done with the current DetNet. If you refine the
document to highlight what you think is missing and needed, that would
be very helpful. Then we can look at the specific mechanisms. Right now,
there is interesting context, but the gaps are not identified. If you
can please highlight the gaps in the current definitions and what the
required changes are, then that would be really helpful. That would
warrant moving it from Informational to Standards track. Otherwise it
should be simply Informational.
Tiang Jiang: Do you think it is a good scenario and use case?
Lou Berger: It is interesing to me and we know the group is interested
in 5G.
Draft:
https://datatracker.ietf.org/doc/draft-xiong-detnet-te-framework/00/
Presenter: Quan Xiong
Lou Berger: Have you looked at the Controller Plane Framework? Have you
looked at what you would like to change there or enhance in that
document, i.e., where do you think are the gaps in that?
Quan Xiong: Ehancements for processing in the control plane of the QoS
queuing solutions. There are no extensions for some queuing solutions in
the existing control plane framework but this is just a placeholder for
part of the document. We also would like to propose traffic engineering
work, in ongoing work and references.
Lou Berger: Traffic engineering is certainly in scope of the current
controller plane document. We'd welcome your comments. If you are
talking about aggregation and class-based aggregation, if you would like
to see that explicitly addressed, we can still add that to the document.
We are getting ready to last call that, it is not too late to change
text. Now would be a great time to propose specific text changes. One
other area you mentioned is the inter-domain piece, if you don't think
it is adequately covered, your inputs would be appreciated.
Janos Farkas: Keep in mind it is a framework document.
Quan Xiong: Will send comments to the list.
Draft:
https://datatracker.ietf.org/doc/draft-sxg-mpls-mna-deterministic-latency/01/
Presenter: Xueyan Song
Lou Berger: This was presented in in the MPLS meeting earlier in the
week. Can you summarize what happened there?
Xueyan Song: Several questions on the DetNet use case. Concern also
about needing feedback from the DetNet WG.
Rakesh Gandhi: [repeating due to audio issues] In the other working
group, the questions arose if this had been presented in the DetNet WG
yet. Also questions asking if we are solving the right problem and is it
the right way to solve it?
Lou Berger: Although the MPLS WG gets to say what is the right thing for
them, it is on us in the DetNet WG to say what are the DetNet
requirements. It would be easier to have two separate documents. Or do
joint adoption separating requirements from solution, because it allows
us to do things separately and cleanly. More documents however are not
always a good thing. So it would be good to talk to the WG chairs there
to see where they think the solution is. To us, it feels a little early
because we are still sorting through what our requirements are when
we're talking an enhanced data plane. Doing changes to the MPLS data
plane to ensure better latency conformance with the DetNet service,
that's a data plane enhancement though it is not really related to the
scaling discusssions we're having. That could be something reasonable to
proceed with. Be clear what problems exactly you want to solve. Be clear
on requirements to address. Socialize between the WGs.
Janos Farkas: A little early to develop data plane solution details,
given that the MPLS group has not made choices on which queueing
solutions to proceed with or which ones to adopt actually. We are still
working on our taxonomy.