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