# DetNet Minutes for IETF 114 (Philadelphia and Online) {#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 {#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 {#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 {#slot-start-time-utc1-duration-information-detnet-session} ## #1 13:30 20 min Title: Intro, WG Status, Charter, Draft Status {#1-1330-20-min----title-intro-wg-status-charter-draft-status} ### Presenter: Chairs {#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 {#2-1350-20-min----title-oam-update} ### Presenter: Greg Mirsky {#presenter-greg-mirsky} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam {#draft-httpsdatatrackerietforgdocdraft-ietf-detnet-mpls-oam} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-oam {#draft-httpsdatatrackerietforgdocdraft-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 {#3-1400-10-min----title-asynchronous-deterministic-networking-framework-for-large-scale-networks} ### Presenter: 정진우 (Jinoo Joung) {#presenter-정진우-jinoo-joung} ### Draft: https://datatracker.ietf.org/doc/draft-joung-detnet-asynch-detnet-framework {#draft-httpsdatatrackerietforgdocdraft-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 {#41-1410-10-min----title-detnet-enhancements-for-large-scale-deterministic-networks} ### Presenter: Xiong Quan {#presenter-xiong-quan} ### Draft: https://datatracker.ietf.org/doc/draft-xiong-detnet-large-scale-enhancements/ {#draft-httpsdatatrackerietforgdocdraft-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 {#42-1420-10-min----title-detnet-queuing-option-for-ipv6} ### Presenter: Xiong Quan {#presenter-xiong-quan-1} ### Draft: https://datatracker.ietf.org/doc/draft-xiong-detnet-6man-queuing-option/ {#draft-httpsdatatrackerietforgdocdraft-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) {#5-1430-10-min----title-mpls-tc-tagging-for-cyclic-queuing-and-forwarding-mpls-tc-tcqf} ### Presenter: Toerless Eckert {#presenter-toerless-eckert} ### Draft: https://datatracker.ietf.org/doc/draft-eckert-detnet-mpls-tc-tcqf/ {#draft-httpsdatatrackerietforgdocdraft-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 {#6--1440-10-min----title-ipv6-options-for-cyclic-queuing-and-forwarding-variants} ### Presenter: Yizhou Li {#presenter-yizhou-li} ### Draft: https://datatracker.ietf.org/doc/draft-yizhou-detnet-ipv6-options-for-cqf-variant {#draft-httpsdatatrackerietforgdocdraft-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 {#7-1450-10-min----title-deadline-based-deterministic-forwarding} ### Presenter: Shaofu Peng {#presenter-shaofu-peng} ### Draft: https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/ {#draft-httpsdatatrackerietforgdocdraft-peng-detnet-deadline-based-forwarding} \[1457\] Lou Berger: Please discuss on list. ## #8 15:05 10 min Title: DetNet Enhanced Data Plane {#8-1505-10-min----title-detnet-enhanced-data-plane} ### Presenter: Fan Yang {#presenter-fan-yang} ### Draft: https://datatracker.ietf.org/doc/draft-yzz-detnet-enhanced-data-plane/ {#draft-httpsdatatrackerietforgdocdraft-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 {#9-1515-15-min----title----detnet-multidomain-extensions} ### Presenter: Carlos Bernardos {#presenter-carlos-bernardos} ### Draft: https://datatracker.ietf.org/doc/draft-bernardos-detnet-multidomain/ {#draft-httpsdatatrackerietforgdocdraft-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 {#adjourn-1530}