DetNet Minutes for IETF 114 (Philadelphia and Online)

WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet

Datatracker: https://datatracker.ietf.org/group/detnet/about/

Thursday, July 28, 2022 - Afternoon session II

13:30 - 15:30 (EDT) -- 17:30 - 19:30 (UTC)
Independence A/B

Materials: https://datatracker.ietf.org/meeting/114/session/detnet
Note taking: https://notes.ietf.org/notes-ietf-114-detnet#both
Meetecho:
https://meetings.conf.meetecho.com/ietf114/?group=detnet&short=&item=1
Onsite tool:
https://meetings.conf.meetecho.com/onsite114/?group=detnet&short=&item=1

Audio stream: https://mp3.conf.meetecho.com/ietf114/detnet/1.m3u
Jabber Logs: http://jabber.ietf.org/logs/detnet
Session ICS: https://datatracker.ietf.org/meeting/114/session/29558.ics

YouTube: https://www.youtube.com/watch?v=UZnJVwT4tbI

Joint Session with PALS and MPLS on Tuesday, March 24, 2022 - Morning session I

10:00 - 12:00 (EDT) -- 14:00 - 16:00 (UTC)

See Materials: https://datatracker.ietf.org/meeting/114/session/pals

Note Takers: Ethan Grossman, Lou Berger

Slot Start Time (UTC+1) Duration Information DetNet Session

#1 13:30 20 min Title: Intro, WG Status, Charter, Draft Status

Presenter: Chairs

[Janos Presents]

Dhruv Dhody (from Chat): Do you know of any DetNet introductory
materials?
Lou Berger: Try
https://www.ieee802.org/1/files/public/docs2018/detnet-tsn-varga-detnet-basic-concepts-1118-v01.pdf
and
https://www.ieee802.org/1/files/public/docs2018/detnet-tsn-varga-detnet-details-1118-v01.pdf

#2 13:50 20 min Title: OAM Update

Presenter: Greg Mirsky

Draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam

Draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-oam

[start 13:40]

Lou Berger: We have discussed aggregated state to avoid encapsulation?
No firm proposal for this, not in current document?

Greg Mirsky: Challenge is to use specific IP protocol and ICMP or well
known UDP for diff't OAM protocols, e.g. BFD vs STAMP. Since bound by
OAM protocol UDP destination port (since using UDP port) requires
specific configuration at forwarding layer to make sure test packets are
created the same way. Could use UDP source port numbers to identify,
discussed in IP data plane doc, but not describing how to make this
correlation, operational issue, many ways to do it.

Lou Berger: Active OAM could be in a per-flow UDP tunnel, while the data
flow remains outside - and then association could be provided by the
controller plane.

Greg Mirsky: So you mean to have multiple OAM tunnels and map each to a
monitored detnet flow. I had missed that and will include in next
version of draft.

Pascal Thubert: Need correlation that is clear. For IPv4 we are stuck,
but in v6 can tag packets in option header. In hop by hop as opposed to
by flow, then can encapsulate multiple flows based on hop by hop
options, so silicon doesn't have to look below header. I have a draft on
this, not discussed much yet. A network concept, not application. So we
can tag treatment for those flows, OAM, Data. So this pipe has this
procedure. Tag flow to pipe, can do this in v6.

Greg Mirsky: Still need external tunnel, since identification/demux of
active protocols is based on well-known UDP port number - not external
UDP encapsulation, then destination port number has to be for given
protocol. So like previous slide on existing OAM.

Pascal Thubert: You don't have to change the packet, just tag it with
option header. DetNet treatment then won't depend on port, will be
determined by hop-by-hop.

Greg Mirsky: Need to discuss further - don't think processing by transit
nodes by hop-by-hop header is defined? E.g. BFD does single IP hop, but
multi-hop, we would need to see how transit IP node would act w/o BFD
descriminator - would it forward it further? It is an interesting idea
but I'm not sure it would work.

Pascal Thubert: The goal is to decouple treatment from transport ports
in the network. Want to let applications do what they want. Move to
mailing list please look at draft and we can discuss on list.

#3 14:00 10 min Title: Asynchronous Deterministic Networking Framework for Large-Scale Networks

Presenter: 정진우 (Jinoo Joung)

Draft: https://datatracker.ietf.org/doc/draft-joung-detnet-asynch-detnet-framework

[1401]

Lou Berger: First document on new area of enhanced data plane, queueing
mechanisms, and changes in how to support traffic treatment in DetNet,
as described in our updated DetNet charter. This is new area for us, so
we appreciate contributions on this subject. There have been multiple
mentions lately of "changes to dataplane" e.g. metadata needed to
support these new things. Want WG to think about whether we need to
define such new MD going forward.

Lin Han: Interesting work, important for DetNet for IP. What is your
definition of flow? IP flow? Traffic shaping - how do you get the rate?
By provisioning?

Lou Berger: Please ask these of the author on the list.

Xuesong Geng: Since we have draft addressing large scale latency, this
doc is related to that, so to authors, what is intended releationship to
that doc? Your draft focuses on synchronized case, but needs to
integrate with existing WG drafts. Your draft is called "Framework" - it
is about scheduling mechanisms, and contains a useful list of
mechanisms, but what is relation between these and mechanisms as defined
in IEEE? There is a lot of prior work in this area, so I think you
should see how to sync with the existing and ongoing work.

Toerless Eckert: Maybe need more than a list as presented here - what we
want is to get better performance from existing header info, based on
additional state based on flow's 5-tuple.

Lou Berger: There will probably be some falling out and consolidation of
drafts going forward.

#4.1 14:10 10 min Title: DetNet Enhancements for Large-Scale Deterministic Networks

Presenter: Xiong Quan

Draft: https://datatracker.ietf.org/doc/draft-xiong-detnet-large-scale-enhancements/

[1417]

Xuesong Geng: On p. 5, mentions req'ts for controller plane. I am author
on controller plane draft - are you talking about "controller plan
considerations for enhanced detnet" such that it would need to be
separate from exising dradts, or can it be integrated into the existing
DetNet controller plane work?

Janos Farkas: That is a WG document, so we should be starting from that.

Xuesong Geng: On p. 4, there are listed service sublayer req'ts such as
aggregation - these have already been defined in existing DetNet
documents, so what is "new" here for "enhanced" DetNet?

Quan Xiong: Some of these have not been covered yet in RFCs so they are
enhancements.

Lou Berger: We need to look at specific texts and see which match
existing vs what is coming in with these new drafts, such as a new
requirements; maybe this kind of thing could go into such a draft. Some
will already exist in RFCs so may need to re-align as we work through
the new requirements for "enhanced" DetNet.

#4.2 14:20 10 min Title: DetNet Queuing Option for IPv6

Presenter: Xiong Quan

Draft: https://datatracker.ietf.org/doc/draft-xiong-detnet-6man-queuing-option/

[1428]

Greg Mirsky: You propose to have this queueing info, including time
budget, included as hop by hop, end to end. What do you imagine system
behavior if the time budget for a node is exceeded?

Quan Xiong: That is determined by queueing mechanisms. Draft just
proposes to use the selected queueing mechanism, not addressing
scheduling.

Greg Mirsky: Draft talks about guarantees, but actually there is no
guarantee?

Lou Berger: Running late, please discuss on the list.

#5 14:30 10 min Title: MPLS TC Tagging for Cyclic Queuing and Forwarding (MPLS-TC TCQF)

Presenter: Toerless Eckert

Draft: https://datatracker.ietf.org/doc/draft-eckert-detnet-mpls-tc-tcqf/

[1437]

Dean Bogdanovic: Using existing dataplane mechanism simplifies
deployment, since any new data plane is slow to arrive in products.

Toerless Eckert: This is DetNet work.

Dean Bogdanovic: It would be good if any new proposal can be implemented
on available HW.

Shaofu Peng: (via remote link, very noisy) In an intermediate node,
given multiple incoming interfaces, each transmission is to be made in a
single cycle at the same time, but there may be many such single cycles
in parallel. How can we be sure that all of these together will not
exceed the maximum number of bits that can be sent in a single cycle? Is
there any compensation for this?

Toerless Eckert: Could we please take this discussion to the list, it is
very hard to understand you.

Shaofu Peng: OK, no problem.

David Black: What is scope of this? I.e. how many admninistrative
domains? I will tell you: Answer: 1. You don't need TSV permission to go
forward for 1 domain.

Lou Berger: As Dean mentioned, there is desire and benefit to re-using
existing formats.

#6 14:40 10 min Title: IPv6 Options for Cyclic Queuing and Forwarding Variants

Presenter: Yizhou Li

Draft: https://datatracker.ietf.org/doc/draft-yizhou-detnet-ipv6-options-for-cqf-variant

[1447]

János Farkas (from chat): A new IEEE 802.1 project is being started to
enhance CQF: P802.1Qdv, see, e.g.:
https://www.ieee802.org/1/files/public/docs2022/dv-PAR-0722-v01.pdf

Lou Berger: Please try to collaborate with others working on similar
topics in the WG. We can continue looking at this topic in the WG.

#7 14:50 10 min Title: Deadline Based Deterministic Forwarding

Presenter: Shaofu Peng

Draft: https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/

[1457]

Lou Berger: Please discuss on list.

#8 15:05 10 min Title: DetNet Enhanced Data Plane

Presenter: Fan Yang

Draft: https://datatracker.ietf.org/doc/draft-yzz-detnet-enhanced-data-plane/

Shaofu Peng (from chat): The comment of CQF is similar to that of TCQF.
How to solve the possible congestion on intermediate nodes? Although we
can do admission control at the network ingress, traditionally this
admission control is mainly bandwidth control. If CQF/TCQF tries to
coordinate the time when multiple ingress send traffic to avoid possible
congestion on the intermediate nodes of the network, it will be very
challenging.

Tony Li (from chat): Why not use conventional TE techniques for
implementing AC?

Xuesong Geng (from chat): @shaofu，in my understanding, same as CQF does.

Greg Mirsky: What is benefit of this BLI (bounded latency information,
i.e. data plane metadata) as both hop-by-hop and end-to-end in ipv6?
Fan Yang: Different BLI for each.
Greg Mirsky: What happens if on a given hop spends more time than
allowed?
Fan Yang: (will reply on list)

Daniel Huang: What is the benefit of this BLI since forwarding decisions
are based on resource type and queueing mechanism?
Fan Yang: Depends on requirements of queueing algorithm. Can discuss on
list.

Lou Berger: Poll: How many have read DetNet Large Scale Requiements
draft?
Result: Raise Hand 19, Do not raise hand 20, Participants 39.

Lou Berger: If you have authored a document on this, please see how your
work relates to this draft. Please pay special attention to terminology
to make sure you are aligned with existing WG document terminology.

Dhruv Dhoty: We have two docs on DetNet in SPRING and other WGs - can we
get the requirements defined early to give us more time?

Lou Berger: So you want this requirements doc that we are working on
ASAP, including terminology section.

Dhruv Dhoty: Yes.

Zhenbin Li: We should not include this MD in data plane

#9 15:15 15 min Title: DetNet Multidomain Extensions

Presenter: Carlos Bernardos

Draft: https://datatracker.ietf.org/doc/draft-bernardos-detnet-multidomain/

Dean Bogdanovic: Do you define "multiple domains" as within a single
enterprise or between multiple enterprises? Which are you focusing on?

Carlos Bernardos: Both are in scope at this point, but it is to be
discussed. These are different problems with different complexities, so
we need to define the gaps and find solutions.

Rick Taylor as RAW chair. I support this work and would like this work
to start in DetNet then build on it in RAW.

Dean Bogdanovic: Want to see this work focused as intra-enterprise,
single admin domain with multiple subdomains. Else would be too diluted.
DetNet use cases are intra-enterprise networks, so good to keep that
focus.

Toerless Eckert: Maybe split halfway? One round of improving forwarding
plane, look at all candidates for packet header additions. Whole
solution will evolve later.

Dean Bogdanovic: Do you mean wider or narrower scope?
Toerless Eckert: Initially no new forwarding plane header info. If need
params for interdomain can expect to add them later.

Lou Berger: Regarding controller plane changes for multi domain - the
Controller Plane draft is still an active WG document so you don't have
to wait for adoption of this new draft, you can suggest new text to
address this in existing draft.

Adjourn 15:30