* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Detnet Status Pages

Deterministic Networking (Active WG)
Rtg Area: Alvaro Retana, Martin Vigoureux, John Scudder | 2015-Oct-05 —  

IETF-110 detnet minutes

Session 2021-03-08 1530-1630: Room 3 - detnet chatroom
Session 2021-03-09 1530-1630: Room 7 - detnet chatroom


minutes-110-detnet-00 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:
          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 -
          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 IETF ?
          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 others.
          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 cases.
          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 available.
          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 them.
          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:
          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
          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
          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 time.
          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 mechanism.
          Stewart Bryant: Glad to hear David say Transport is interested.
          Uma Chunduri: Problems of Bounded latency and jitter need to be solved
          in DetNet.
          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:        https://www.youtube.com/watch?v=rt_vQTToO1s

Generated from PyHt script /wg/detnet/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -