Minutes IETF110: detnet

Meeting Minutes Deterministic Networking (detnet) WG
Title Minutes IETF110: detnet
State Active
Other versions plain text
Last updated 2021-03-19

Meeting Minutes

# Draft Minutes for the DetNet 110 WG Session

### Note takers:
Ethan Grossman

# DetNet Agenda for IETF 110 (Online)
Version: Mar 8, 2021

Common for both sessions:
Materials:      https://datatracker.ietf.org/meeting/110/session/detnet
Note taking:    https://codimd.ietf.org/notes-ietf-110-detnet
Jabber: http://jabber.ietf.org/logs/detnet
WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet

# Session 1: Monday March 8 Session II
15:30-16:30 (CET, UTC+1) -- 14:30-15:30 (UTC)
Time Zone Converter:
Session ICS:         https://datatracker.ietf.org/meeting/110/session/28645.ics
Audio stream:            http://mp3.conf.meetecho.com/ietf110/detnet/1.m3u

Youtube: https://www.youtube.com/watch?v=8tD7hvUGhJI

## Slot Start Time (UTC +1)     Duration        Information     Session 1
## 1    15:30   15      Title:  Intro, WG Status, Draft Status
Presenter:      Chairs

## 2    15:45   45      Title:  DetNet Configuration YANG Model - Walkthrough
Presenter:      Don Fedyk
Draft:  https://datatracker.ietf.org/doc/draft-ietf-detnet-yang/

Lou Berger: Name of preso is "Configuration Yang Model" - doesn't it also
address operational state? Don Fedyk: Yes.

Don Fedyk: Question: should IP in IP be covered in the base model?
Lou Berger: Where is IP in IP tunnels documented?
Don Fedyk: Don't have good pointers to it. Is there another doc we could
incorporate? Lou Berger: Sounds like that's the answer (don't include it as
there is no reference)

John Scudder (from chat): Since Don mentioned example IP addresses, as I recall
best practice is to use the formally designated example addresses for such
purposes. RFC 5737 and RFC 3849, I believe.

Xuesong Geng: (from chat): Thanks John, we will review these documents and
modify the model if necessary.

Lou Berger: Clarify: Regarding slide (slides are not numbered?) you said
"aggregate at service level" but slide says "forwarding sublayer"? Which is it?
Don Fedyk: Forwarding sublayer is correct.

Lou Berger: These diagrams are not in the WG document?
Don Fedyk: Correct, they are not. Maybe a-1 and b-2 as examples. Others we
validated through YangLint, but they are not in ASCII format so we didn't put
them into the draft. Lou Berger: Could publish them as an appendix, I'm sure
there is some way to get them in there.

Andy Malis (from chat): You can also redraw the diagrams in SVG.
Don Fedyk: Is Andy kidding about SVG?
Lou Berger: PPTX can export SVG.
Andy Malis (in chat): Regarding SVG - SVG diagrams can be included inline in
the new XML v3 RFC format. So I was being serious, it's the easiest way to
include non-ascii diagrams in RFCs.

Tim Costello (from chat): - are any other YANG models for detnet outside of
IETF? Is this YANG model interoperable with other detnet YANG models outside of

Don Fedyk: I don't know of any DetNet YANG models outside of IETF, only TSN
ones. Not sure what "interoperable" means in this context? We have borrowed
from MPLS so those should be consistent.

Lou Berger: Are you going to have any IP only cases, or are they all IP over
MPLS? Don Fedyk: So far only IP over MPLS - shouldn't be much different. Could
point out differences? Lou Berger: Maybe do that at the end. Don Fedyk: These
are just examples to allow people to compare the charts with the YANG to
understand what is going on. Probably no more value in going through the charts
in more detail - the point is to see the difference between the charts and
match them to differences in configurations.

Eve Schooler (from chat): Are these configurations inspired by particular use
cases / known scenarios and topologies? Don Fedyk: Some are inspired by "real"
use cases, e.g. need to aggregate at each layer. But some came from nature of
YANG model - once you aggregate at Service layer and allow services to come in,
is heirearchical. So they were inspired by real use cases, but maybe the model
supports more aggregation cases than one might need. Can build them up from
more basic models. Not unnecssary, but some would be more often used than

Don Fedyk: If we need an IP only model it wouldn't be hard to create. Would
have service and forwarding sublayers labeled IP instead of MPLS. "service-id"
and "detnet-flow-type" - difference between IP and MPLS (incoming or outgoing)
is right there. That's the only difference in the model. You can specify
aggregating prefixes with IP.

Janos Farkas: So you could say the YANG model supports DetNet IP-only data
plane as well? Don Fedyk: Yes, we are showing MPLS examples, this was just done
out of habit. Lou Berger: Would like some IP examples for normal and aggregate

David Black: Agree. MPLS shows aggregation, IP would have to do extra to
support it - so good to have it shown this way for clarity. We also need to
understand if there are any gaps for IP?

Don Fedyk: We don't think there are gaps, but we can spin up a test case. We
put in only a few example models, because we didn't want to bloat the doc too
much. But if people like this "dictionary of examples", we can do that.

David Black: I find it useful. Provides solid foundation for what aggregation
looks like in the IP data plane where don't have additional address info

Balazs Varga: My question on the list was about subnet, but I now see that it
is out of scope. For the case of a TSN subnet, where the DetNet node is TSN
aware, then you need some mapping between DetNet flows and TSN streams. The
IEEE specified TSN YANG model needs common connection point with the DetNet
YANG model. I understand that this is further work that is needed.

Lou Berger: Other large YANG models have sections of future expansion,
augmentation. Like maybe RAW will build on the base model. So would be good to
undertsand where these can be augmented, versus requiring new models.

Kiran Makhijani(from chat): +1 examples are very informative. we should add

Toerless Eckert: Good work, but how does one validate this? Do you have
implementation plans other than manual review? Don Fedyk: I don't have an
answer to that. Lou Berger: What validation have you done so far? Don Fedyk:
Yanglint validation. That exercises the model but it doesn't ensure that no
pieces are missing. Toerless Eckert: So this means the model is necessary and
sufficient to run a DetNet? Don Fedyk: For IP and MPLS we have used standard
(IP and MPLS) models, so they should hang together, but we have not gone
further than that.

## Adjourn      16:30

# Session 2: Tuesday March 9 Session II
15:30-16:30 (CET, UTC+1) -- 14:30-15:30 (UTC)
Time Zone Converter:   
Session ICS:           
https://datatracker.ietf.org/meeting/110/session/28644.ics Meetecho:           
Audio stream:           http://mp3.conf.meetecho.com/ietf110/detnet/2.m3u

Youtube: https://www.youtube.com/watch?v=YNhcFNf4wbw

## Slot Start Time (UTC +1)     Duration        Information     Session 2
## 1    15:30   10      Title:  Intro to Session 2
Presenter:      Chairs

## 2    15:40   (15:33) 10      Title:  OAM Framework
Presenter:      Greg Mirsky
Draft:  https://datatracker.ietf.org/doc/draft-tpmb-detnet-oam-framework/

Greg Mirsky: Should initialization of a DetNet OAM session from a central
controller be a SHOULD or a MUST? (Currently written as SHOULD). (No replies to
this question). Greg Mirsky: We are requesting WG adoption for this draft to
progress it further. Lou Berger: This slide (slide 5, Requirements) and draft
section (Requirements) should get close review by WG in prep for adoption.
Janos Farkas: I like the approach. This will be the OAM framework for DetNet,
then OAM drafts for MPLS and IP for DetNet can refer to it for common
information. Lou Berger: Are there any objections to adopting this document?
Greg Mirsky: Could use the Hands tool in Meetecho to assess concensus? Lou
Berger: I am asking people to state objections explicitly, either on mic or on
chat. Lou Berger: I personally have some comments and will share on list, but
no objection to adoption. Lou Berger: You can expect to see adoption call on
list and we expect good comments.

## 3    15:50 (15:47)   10      Title:  DetNet Control Plane Signaling
Presenter:      Dirk Trossen
Draft:  https://datatracker.ietf.org/doc/draft-trossen-detnet-control-signaling/

David Black: Recalling the preso on DetNet YANG yesterday (Monday): Does this
preso cover all sitiuations described in that preso? Dirk Trossen: No. David
Black: It would be great if this RSVP work considered all of those. Please find
a different acronym than "TSN" to avoid overlap with IEEE definition of TSN
that we are all used to. Lou Berger: This doc is focused on interworking of
DetNet RSVP with TSN. So the title is appropriate, despite David's comment. But
we have no description for any of the use cases for RSVP, i.e. MPLS, IP, TSN -
particularly traffic engineering aspects. What is your thought on addressing
these base capabilities? Dirk Trossen: For RSVP for DetNet we wanted to
simplify our work, but it is a lot of work to do this. We wanted to first be
concrete from the TSN angle then revisit as we move forward. So it is a
compromise. Lou Berger: As chair, I would say follow David's guidance (to
consider more scenarios). Balazs Varga: This was a good update, the intent is
now clearer. I agree with the previous comment about the use of the acronym
TSN. Using RSVP for DetNet signaling and RAP for TSN signaling is well
described in draft but that should be highlighted in the draft title as well.
It is a specific focus on a specific scenario. Dirk Trossen: We left the title,
but probably should have changed it. We have discussed among the authors that
we need to be more general, but this goes beyond our competence so we want to
reduce scope as we have expresssed in the title. But we agree it would be good
to do this work. David Black: If RSVP is used for DetNet, this draft describes
how it might work for TSN. Is there running code or any prototype for how to
use RSVP/Intserv for DetNet? In other words, this is an assumption - is it
tested? Dirk Trossen: I will check with co-authors. David Black: It is a nice
assumption that it will work for DetNet, but needs sanity check. Janos Farkas:
The basis will be to first see how RSVP works with DetNet - then consider how
it mght work with TSN. I understand that you want to narrow your focus but it
would be good to see first how RSVP works for DetNet on its own. David Black: I
am not clear that RSVP/Intserv is the right thing here. But I understand that
delving into this is a lot of new work. Lou Berger: If you are considering
expanding this work, please consider the TE varieties. David Black: I agree
that the only active work I know of on this is on RSVP, not Intserv.

## 4    16:00   10      Title:  Micro-burst Decreasing in Layer3 Network for
Low-Latency Traffic Presenter:      Zongpeng Du Draft: 

Lou Berger: On slide 2 the statement: "DetNet scoped to admistrative domain" -
DetNet can also include cooperating administratve domains - please align this
kind of statement with our charter.

David Black: Based on description this sounds like Diffserv, where flows are
individually shaped at the edge, then there is traffic conditioning at the
core. So your comments in the preso are on the mark, but I would encourage the
draft authors to look at RFC2475 as a place to start.

## 5    16:10   10      Title:  Segment Routed Time Sensitive Networking
Presenter:      Yaakov Stein
Draft:  https://datatracker.ietf.org/doc/draft-stein-srtsn/

Yaakov Stein: Is the WG interested in progressing this work?
Lou Berger: No time remaining for questions, but we saw interest on the list.
We will take the action to coordinate consideration of this work in DetNet.

## 6    16:20   10      Title:  A Queuing Mechanism with Multiple Cyclic Buffers
Presenter:      Joanna Dang

David Black: There has been a lot of discussion behind the scenes with chairs
and ADs about this draft. My advice is to split the mechanism away from the
location of the bits (needed on the wire). The crucial question for DetNet is
whether the problem proposed is one the WG wants to address. If it is found to
be a desirable mechanism, we can look for the bits elsewhere - I can think of
at least 4 places where we could find the bits.

Toerless Eckert: How is this different from Yaakov's draft in terms of queueing?
David Black: Both deal with problems that are relevant to the DetNet WG.
Toerless Eckert: Seems a similar situation to PREOF, i.e. something DetNet
should look at. David Black: But you need to put the cart and horse in their
proper order: First you have to define the mechanism, then go find the bits
needed to implement it. Toerless Eckert: This is a case like PREOF - why did
DetNet take on encap for PREOF but not for this? Yaakov Stein: Regarding
Toerless' comment: I am not recommending any encapsulation. I am bringing up an
issue. The issue brought by this draft is also a valid issue: that gating has
to absorb time between switches. So if the proposed mechanism can be proven
efficient, then we need a universal encapsulation, or some other way to put the
bits on the wire, as David said.

Stewart Bryant: This is a problem that DetNet has largest interest in, since
DetNet is working on the most critical time-related communications. So we
should start here, then maybe export to a specialist encap group. But this WG
should own the problem of getting the packets to the right place at the right

Lou Berger: So far DetNet has only taken informational docs on queuing; the
Transport area owns queueing mechanisms. But definition of a queueing method is
not outside the scope of IETF and if the ADs and Transport area agree that this
is the right place then we will follow, but we want to stay within our scope.
Determining whether we need bits on the wire is in scope, but queueing is not.

David Black: With my Transport Area WG (TSVWG) co-chair hat on, as TSVWG is one
of the places where bit allocation could be done: I am comfortable looking for
bits, but not defining the underlying mechanism - that expertise is in the
DetNet WG and not in TSVWG. I would want DetNet to deal with the underlying

Stewart Bryant: Glad to hear David say Transport is interested.

Uma Chunduri: Problems of Bounded latency and jitter need to be solved in

Lou Berger: The big issue with queueing is that it is not in our charter - in
the IETF, queueing is not done in Routing area. But we will work with the
Transport area and ADs in IESG, since they are the ones who say where work
goes, to figure out where to progress this work.

Toerless Eckert: Regarding Yaakov's draft, this is an ideal way to exploit SR.
We have not done SR as forwarding plane in DetNet - is that not a gap in DetNet?

Lou Berger: We have had this proposed in the past, and we agree to talk about
where this work goes; we would be happy do it in DetNet.

Toerless Eckert: That would be good, to get best results.

## Adjourn      16:30

# Session 3 (Joint)
Session 3: Joint Session with PALS, MPLS and SPRING on Friday Session I
13:00-15:00 (CET, UTC+1) -- 12:00-14:00 (UTC)
Time Zone Converter:   
Session ICS:    https://datatracker.ietf.org/meeting/110/session/28662.ics
Audio stream:   http://mp3.conf.meetecho.com/ietf110/pals/1.m3u Materials:     
    https://datatracker.ietf.org/meeting/110/session/pals Note taking:   
https://codimd.ietf.org/notes-ietf-110-pals Jabber:        
http://jabber.ietf.org/logs/pals Youtube: