* 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, Deborah Brungard, Martin Vigoureux | 2015-Oct-05 —  
Chairs
 
 


IETF-103 detnet minutes

Session 2018-11-08 1350-1550: Chitlada 2 - Audio stream - detnet chatroom

Minutes

minutes-103-detnet-00 minutes



          IETF 103 (Bangkok) DetNet WG Session Notes
          NOTE TAKERS ADD YOUR NAMES HERE (not required):
          Ethan Grossman
          >  THURSDAY, November 8, 2018
          >  1350-1550  Afternoon Session I
          >  Location:    Chitlada 3
          >
          > Slides:    https://datatracker.ietf.org/meeting/103/session/detnet
          > Etherpad:    http://etherpad.tools.ietf.org/p/notes-ietf-103-detnet?useMonospaceFont=true
          
          > Meetecho:    http://www.meetecho.com/ietf103/detnet/
          > Audio stream:    http://ietf103streaming.dnsalias.net/ietf/ietf1036.m3u
          > Jabber:    xmpp:detnet@jabber.ietf.org?join
          >
          > Available post session:
          > Recording:    https://www.ietf.org/audio/ietf103/
          > YouTube:    https://www.youtube.com/user/ietf/playlists
          >
          > Slot Start     Duration    Information
          > 0    13:50    10    Title:    Intro, WG Status, Draft Status
          >                     Presenter:    Chairs
          >                     Draft:    N/A
          
          > 1    14:00    20    Title:    DetNet IP Data Plane Encapsulation,
          DetNet MPLS Data Plane Encapsulation
          >                     Presenter:    Balázs Varga
          >                    
          Draft:    https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls-01
          >                    
          Draft:    https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip-01
          Balazs Varga: IPv6 flow label use, any comments? 
          Stewart Bryant: Within a domain you can trust the flow label, given that
          you have control of all routers in domain because what they do with the
          flow label is a configurable option on the router. So we can use the flow
          label as a shortcut as long as the routers on the path are obeying our
          rules for its use and aren't using the flow label for something else,
          and given that we can ensure no stray packets will get in that will
          mimic the behavior we want. Stewart to provide text on this.
          Lou Berger: Want to see text on this in the management considerations
          section. 
          Stewart Bryant: I will provide text on this. 
          David Black: That was also raised as last call issue on Arch draft -
          need to protect edges of the domain both to protect against traffic that
          doesn't look right from getting in and from some misconfiguration letting
          non-elastic traffic out. What do the chairs want to do about that? 
          Lou Berger: a key caveat in that comment is that it applies to non-elastic
          traffic. DetNet not at xport layer, so we are not specifying what
          behaviors are at the transport layer. So that comment about elasticity
          applies to transport layer not DetNet layer. 
          David Black: My concern is that the DetNet QOS chunk of a router sends
          traffic, and if you consider that traffic by itself, not considering
          the transport, meaning if you fill all the slots, it is inelastic,
          so we need to protect the rest of the world against DetNet we have to
          assume we have inelastic traffic. 
          Stewart Bryant: Important point is that in IP we take a relatively
          relaxed approach to ingress edge protection, compared to MPLS where you
          only get into the network then do what the label says to do. 
          It is harder in IP due to more edges and exposed attack surfaces. We
          need to up our game in IP to build an IP deterministic network.  
          Lou Berger: Comments on Arch doc are implying that DetNet is a tunneling
          technology, but it isn't, it's an IP transport network, thus it is
          operating below the normal Transport protocols and doesn't impact those
          transport protocols. All it does is impact the congestion experience
          or traffic treatment received by those transport protocols. So circuit
          breaker behavior belongs in a tunnel, not in an IP transport network. The
          transport protocol is still expected to do the right thing, and if it
          has been modified to do something different than our normal congestion
          control behavior, then it needs circuit breaker behavior, not DetNet. I
          will put this on the list for discussion. 
          Stewart Bryant: With a transport network in general, things come in and
          are put into the encapsulation that the transport network has and they
          don't get to do their own thing, they only get to do what the transport
          network allows them to do. This is not a normal IP design. Normally once
          you get an IP packet in the network you do whatever the [output?] address
          says. 
          Lou Berger: Right but we don't impose transport behavior because we are
          running on a transport network down here and the comments being made
          do that, so I think there is some confusion on the part of the people
          making those comments - DetNet is not a tunnelling technology it is a
          transport technology. 
          David Black: I will read your response and figure out what to do about
          it because I don't know that circuit breakers are needed here, but it
          seems like a good idea that any DetNet traffic trying to escape from
          the DetNet should be bit-bucketed at the edge of the network.
          Lou Berger: We do that in IP networks, so if you have an uncongested
          IP network connected to a congested IP network the flows from that
          uncongested network will be "let loose" on that congested network. That's
          all we're doing with DetNet, we're assuring that for that traffic,
          it doesn't percieve that congestion. 
          David Black: Let's take this to email. 
          --------------
          David Black: Regarding 5-tuple vs 6-tuple. I will read the draft and write
          some carefully crafted text because what is described here is what the
          implementation has to do however flow identification may cause some
          people to make incorrect inferences about flow. The upshot is that a
          flow is defined by a 5-tuple, but DetNet node has to identify a flow
          with a 6-tuple to pick off traffic that gets DetNet treatment, but that
          doesn't constitute the completely generality of a 6-tuple.
          Lou Berger: When you write that text, base it on the forthcoming revised
          version of the draft. Also note that there is text in there that says
          DetNet flow identification impacts next hop selection, but you are
          saying we should do selection based on 5-tuple and treatment based on the
          6-tuple. This is the crux of the comment and is an accurate observation
          and a failing in the current text. 
          David: This is also the same rational that we should not mix DetNet and
          non-DetNet DSCPs on the same 5-tuple. 
          -------------
           > 2    14:20    10    Title:    DetNet Flow Information Model
          >                     Presenter:    János Farkas
          >                    
          Draft:    https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-02
          
          Brim from Huawei: Is it valuable to put the duration of a flow in the
          flow parameters? 
          Janos: Yes, that is a discussion item for today, what are the group's
          opinions? Need to decide whether to include this parameter.
          Lou Berger: We are getting into parameters that impact the control
          plane and the scheduling of resources outside the data plane. We
          have packet scheduling but this isn't packet scheduling this
          is scheduling of when a service will show up and when it will go
          away. Similarly with bidirectional service we're getting into something at
          the control plane level to coordinate traffic in both directions. In terms
          of the data plane forwarding when you get to the HW you must provision
          both paths in each direction separately so it is more of a control plane
          concept.  If have bidirectional service it has implications mapping from
          layer 3 to layer 2. 
          John Messenger: It could be a control plane parameter, setup and
          teardown...  or it could be considered to be with ordering, and if you
          look at the LSR reference model there are places where it might make
          sense to represent that kind of information too, at service establishment
          and ordering level. But if it was realtime in terms of short lived flows
          then it might be more appropriate to put it in the control plane. 
          Pascal Thubert: Maybe need indication of when path is set up so can send
          data over it? UNI could signal that it is up. 
          Janos: We have parameters along this line in the document for the flow,
          in line with what we have for TSN, for example about whether redundant
          paths were successfullyset up or not. 
          
          > 3    14:30    10    Title:    DetNet Configuration YANG Model
          >                     Presenter:    Xuesong Geng
          >                    
          Draft:    https://tools.ietf.org/html/draft-ietf-detnet-yang-00
          Lou Berger: A minor point: you called out that an individual
          draft you referenced is really about a DiffServ model
          and not really about QOS in general, maybe it is worth pointing this
          out to them. To help them do the right thing. 
          Xuesong Geng: I'm not sure since there is no definition for whether
          DetNet queues belong to DiffServ. 
          Lou Berger: but there's no definition of DetNet as QOS, only DetNet as
          DetNet. 
          Xuesong: This structure works for both DiffServ and ...
          Lou Berger: I wasn't commenting on your draft, I'm distinguishing between
          IETF draft work and individual draft work. 
          Greg Mirsky: You said YANG model for IP is much simpler than for MPLS data
          plane? 
          Xuesong: That is because all of the parameters are needed for IP data
          plane solution are already defined in a struct but now we have to split
          them out for IP and MPLS. 
          Greg Mirsky: But you can't say that DetNet over IP data plane is simpler
          than over MPLS data plane. 
          Xuesong: Yes, because IP dataplane design is still under construction,
          the YANG model will have to be updated based on work of data plane. So
          we will keep connected with the others of the IP data plane design team.
          Greg Mirsky: I agree with that. 
          Mach Chen: Simpler is based on the assumption that the current YANG model
          including IP and MPLS tunnels has already been included in current MPLS
          based flow configuration so it is easier to defend IP encapsulation
          model.
          Xuesong Geng: Agree. 
          Cristina Qiang: We just discussed in info model draft, if time based
          detnet service is going to support in the information model draft we
          also need to add some time related parameters. 
          Xuesong Geng: Time related params should be considered in transport
          queues YANG models. 
          Cristina Qiang: No, no.
          Lou Berger: That decision sits in flow info doc. If that gets it then
          this one will get it. This doc mirrors what we do in the other doc,
          then this one will follow.
          Xuesong: Agree. 
          Janos: Why is it difficult to use the YANG model defined by 802.1? 
          Xuesong Geng: Look at the first slide...
          Lou Berger: Given the time let's postpone this for Sunday meeting. This
          question is a preview of what we will discuss then.
          Janos: We should not duplicate work done by 802. 
          Lou Berger: We will discuss this at Sunday session. Need to work out
          what work we do where, so as not to duplicate work. 
          Lou Berger: Regarding splitting this into two drafts - they are loosely
          related, could split to allow to progress independently, so from chair
          perspective makes sense.
          How many care about this? Reasonable number.
          Who supports doing a split: Almost the same.
          Objections to split? None. 
          Lou Berger: OK please split the draft. They will both be WG
          documents. Please propose some names and we'll go ahead with it.   
          
          > 4    14:40    15    Title:    DetNet QoS Policy and Yang
          >                     Presenter:    Quan Xiong
          >                    
          Draft:    https://tools.ietf.org/html/draft-xiong-detnet-qos-policy-00
          >                    
          Draft:    https://tools.ietf.org/html/draft-xiong-detnet-qos-yang-00
          David Black: thanks for submitting these drafts, they raise
          an important architectural issue for WG to resolve. Should one or more
          PHBs be defined for DetNet? If so then DetNet traffic will use DetNet
          DSCPs not existing ones. Not sure what the right answer it. 
          Lou Berger: DetNet is about delivering service for individual flows,
          so what does "DetNet PHB" mean in this context?
          Norman Finn: Question: Regarding specific DSCP values: you often need more
          than one class of DetNet service, e.g. hi, med, lo speed requirements,
          so need 2 or 3 DSCPs. OTOH you often want to be able to give individual
          flows different kinds of service. If using cyclical queueing and
          forwarding (CQF) you don't have to identify the flow at all, you just
          use the DSCP or layer 2 priority to assign it. But in severalofthese
          cases, particularly if we are defining DSCP values then we must defend
          network against any frame using our DSCP values because it will screw up
          what we're doing if we have extraneous traffic. This implies a defense
          method which is not as important if you are looking at individual flows
          and validating them. If you are checking flow ID before giving it DetNet
          service then it isn't a problem to re-use DSCPs.The other part I don't
          understand is what a PHB is or what that means so I'd ask for others to
          explain that. 
          Lou Berger: Let's keep this document around and discuss this further
          on list.  Some new things to think about, but not yet sure what to do
          about it. 
          Lou Berger: Who wants to hear more about this: Reasonable number. OK,
          we're in sync.
          David Black: Thank you for raising this. The high level answer to
          Norm's question might be to define a sufficiently fuzzy PHB but no
          I don't yet know how to do that. 
          
          > 5    14:55    10    Title:    OAM for DetNet
          >                     Presenter:    Greg Mirsky
          >                    
          Draft:    https://tools.ietf.org/html/draft-mirsky-detnet-oam-00
          Stewart Bryant: Concerned about fate sharing - you fate share OAM with
          end to end service, but you don't fate share over the particular path
          that any given packet was taking - so there's a dilemma? 
          Greg Mirsky: If the network doesn't use payload for determining behavior
          of the packet then there will be a sharing. For example if they have
          ECMP and use payload to do hashing, selecting path, then yes .. 
          Stewart Bryant: But that won't happen because of the control word.
          Greg Mirsky: But if they use entropy label, then OAM would use the same
          label and there would be fate sharing. 
          Lou Berger: We are over time, take this to the list. 
          Stewart Bryant: Or a work session call.
          Lou Berger: If warranted to have an OAM interim or call, we are open to
          it.  
          Lou Berger: Do you see impact of OAM on the base dataplane documents? 
          Greg Mirsky: No, OAM can be a stand-alone document, not part of base
          document. 
          Janos Farkas: Do you see any changes required to base dataplane documents
          to support OAM? 
          Greg Mirsky: No, there is no redefinition for base
          protocol, we just define an informational field that we can use in DetNet
          ACH format that can be used to do PREF. 
          Stewart Bryant: Without that conversation I am not so certain. There
          might need to be characteristics we need to measure that we can't
          measure... particularly as not allpackets go on same path depending on
          arrival times and competing traffic.
          Pascal Thubert: There is work that started here which is now in BIER that
          changes the headers to provide exactly what Stewart is mentioning,
          which is the capability to explore out of the replicated and eliminated
          paths which one actually worked. And to control when you have this
          capability whether you actually replicate over all of the ports, all the
          possibilities. This work impacts this separation. If we have this interim
          I am happy to explain how this works. But you can't say now that OAM
          won't affect the signalling because it depends on which proposal we use. 
          Stewart Bryant: You might have to turn off elimination to make this work
          properly. 
          Lou Berger: How many feel it is important for us to work on OAM: 
          How many have read draft? Slightly less.
          How many want to adopt as the foundation for WG activity on OAM: An OK
          number, not great. 
          Wait until it matures?  (No result recorded).
          Don't want to adopt? Only one. 
          Chairs will discuss and see where to go next. 
          
          > 6    15:05    10    Title:    DetNet Packet Loss and Delay Performance
          Measurement
          >                     Presenter:    Mach Chen
          >                    
          Draft:    https://tools.ietf.org/html/draft-chen-detnet-loss-delay-00
          
          Greg Mirsky:  According to RFC7799 this is a hybrid method. Looks
          like alternate marking method RFC8381 doesn't have to use 2
          bits. With compressed alternate marking method quality delay and
          loss measurements can be done with one bit flag. 
          Mach Chen: Actually here it is not necessary to use that alternative
          marking solution. Because DetNet encapsulation already introduced the
          DetNet control word which contains a sequence number and that can be
          used to correlate the information. Don't need to use other means to mark
          and separate packets into separate blocks, we have enough information
          already to do that. 
          Lou Berger: Let him finish his presentation and see what he is
          proposing. 
          Stewart Bryant: An issue: Using the sequence  number works
          if you have a continuous expected rate of ingress packets, but if you
          have packets that you want DetNet treatment for, but you can't be sure
          when the next one is going to arrive, i.e. it may miss elements out,
          then you can't do it with the sequence number because you have to set the
          expected sequence number but you may not have any packets coming or you
          may get too many. You may be able to steal a bit like you are suggesting
          here to do it, but using the sequence number for alternate marking won't
          work unless you can be sure you have a constant flow of packets.
          
          Al Morten: 1. What Greg said. 2. What a long sequence number you
          have. Consider packet reordering. 
          Lou Berger: Cutting the line. good discussion for the list. 
          
          > 7    15:15    15    Title:    DetNet Bounded Latency
          >                     Presenter:    Jean-Yves Le Boudec / Norm Finn
          >                    
          Draft:    https://tools.ietf.org/html/draft-finn-detnet-bounded-latency-01
          
          Norm: Is this going in the right direction? 
          Xuesong Geng: This preso can answer the question from David about
          whether DetNet can change the PHB - this presentation shows that the
          answer is yes can because the Q'ing algorithm changes the elements of
          the PHB, including classifier, Q'ing, metering, dropper. Perhaps part
          of them, but this is actually the PHB for DetNet.  
          Norm Finn: I will study more about this. I suspect DetNet will involve
          several PHBs. 
          Janos Farkas: Let us continue this discussion on the list.
          Lou Berger: You changed something from where we left off at last
          discussion: this is now to be normative not informative? 
          Norm Finn: Yes that is my suggestion.
          Lou Berger: As we discussed last time we wouldn't expect to specify q'ing
          behavior in this WG - that probably would be defined elsewhere,and we
          could discuss which working group. I thought we reached the conclusion
          that the group thought it would be good to have this information here
          to inform people on possible implementation approaches, versus being
          required. If it is normative it is required. What we want to require
          is that we per flow give the service that is provisioning for the
          DetNet service, but we don't want to specify how it is implemented
          internally. that's where we were at the last meeting as I understood it. 
          Norm Finn: What I am looking for here is not "this is the only way to
          do it", as much as "these are the requirements for anything you do to
          produce the DetNet quality of service". 
          Lou Berger: So you want to define behavior through a mechanism but other
          mechanisms are allowed? 
          Norm Finn: Exactly. 
          Lou Berger: So for us this translates to being an informative
          document, and the requirement to deliver the service is what we
          specify. That goes into the data plane solution documents. We can point
          to this as informational.  
          Norm Finn: Thank you that was my confusion. 
          Stewart Bryant: I don't understand your point Lou. This could be a
          standards track doc and is only required behavior when you are executing
          the behavior of that document. The fact that it is standards track
          doesn't bound DetNet to do it.  
          Lou Berger: The title and context of this is DetNet Bounded Latency. So
          it says that if you want to implement bounded latency you have to do
          it this one way. We don't want to limit our vendors to say they have to
          deliver it this way. That's not something we typically do. 
          Stewart Bryant: Agree, but that doesn't mean this has to be an
          informational document. As a standard it  is only required behavior when
          you configure a piece of equipment to behave like this. 
          Lou Berger: But that is not in our interest to say that if you want to
          deliver bounded latency you have to do it this way. 
          Stewart Bryant: That's not what I'm saying. 
          Norm Finn: The intention is to provide some options, if you do these
          then this is how you have to do it, otherwise it won't work. 
          Janos: It would be cleaner if it were informational. 
          Norm Finn: It is the same info for MPLS or IP encaps; I would not want
          to put this in both of those documents. 
          
          David Black: Is what you refer to as the network calculus part of the
          definition of bounded latency DetNet service?
          Norm Finn: I don't think it is. It is information about how you can
          calculate it, not how you must calculate it. 
          David Black: So you are saying the calculus is implementation dependent
          and that different implementations can meet the service definitions in a
          way that requires different calculus to figure out service characteristics
          and admission control. 
          (No answer from Norm)
          Lou Berger: That's the limit on how much we can discuss this now. 
          How many interested: Most of the room. 
          How many think is headed in right direction, ignoring whether normative -
          reasonable number, maybe half of before. 
          We will discuss normative vs standard with the authors, come back with
          a proposal, then probably move toward adoption. 
          
          > 8    15:30    10    Title:    Large Scale DetNet
          >                     Presenter:    Cristina Qiang
          >                    
          Draft:    https://tools.ietf.org/html/draft-qiang-detnet-large-scale-detnet-02
          
          David Black: On the IP based solution, a typical way to get more bits
          is to insert a UDP shim. 
          (conversation fragments)
          Lou Berger: We are out of time, please take this to the list. 
          Lou Berger: There has been no discussion on this since the last time it
          was presented. If you want to progress it, have discussion on the list. 
          
          > 9    15:40    10    Title:    SR-Based Bounded Latency
          >                     Presenter:    Mach Chen
          >                    
          Draft:    https://tools.ietf.org/html/draft-chen-detnet-sr-based-bounded-latency-00
          
          
          Lou Berger: Have to work out where SR-related work goes. Probably SPRING
          WG but we can take that as we progress it. 
          Greg Mirsky: Did you do estimate on scale of this new adjacency SID...
          Lou Berger: We are out of time.  
          On Sunday we will try to figure out split of work between us and
          802.1. Some of what you are talking about may amount to work for 802.1
          hopefully we will clarify this on Sunday.
          
          > 10    15:50    5    Title:    SR-Based Bounded Latency
          >                     Presenter:    Yuanlong Jiang
          >                    
          Draft:    https://tools.ietf.org/html/draft-jiang-detnet-ring-02
          
          (Out of time, did not present). 
          > Adjourn    15:55
          
          



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