DRAFT NOTES NOTE TAKERS: Ethan Grossman János Farkas Andy Mali > DetNet Agenda IETF105 (Montreal) > Version: Jul 11, 2019 > Wednesday, July 24, 2019 (EDT) > 13:30-15:30 Wednesday Afternoon session I > 15:50-16:50 Wednesday Afternoon session II > Centre Ville > Slides: https://datatracker.ietf.org/meeting/105/session/detnet > Etherpad: http://etherpad.ietf.org/p/notes-ietf-105-detnet > Meetecho: http://www.meetecho.com/ietf105/detnet/ > Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1051.m3u > Jabber: xmpp:detnet@jabber.ietf.org?join > Available post session: > Recording: https://www.ietf.org/audio/ietf105/ > YouTube: https://www.youtube.com/user/ietf/playlists > Presentation Start Time Duration Information Session I > 0 13:30 15 Title: Intro, WG Status, Draft Status > Presenter: Chairs > 1 13:45 30 Title: DetNet Data Plane drafts (IP and MPLS) > Presenter: Don Fedyk (onsite) for Balázs Varga (remote) > Draft: https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-01 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-ip-01 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-mpls-01 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-udp-ip-01 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-01 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-tsn-00 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-ip-over-tsn-00 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-over-mpls-00 Lou Berger: We have an unusual situation in which the chairs are contributing to these drafts - so Ethan as Secretary will be Document Shepherd for these drafts. David Black: (IP, slide 4) Flow ID is by 6 tuple, but the 5 tuple for the stream still has to be unique for all streams over the network. Lou Berger: Yes, obvious, so? David Black: 5 tuple is Src, Dst Addr, Protocol, ports. 6 tuple adds DSCP. Diffserv architecture says use DSCP to mark flow, not to subdivide flow into subflows. Implies for IP draft it is ok to use 6 tuple to identify, but 5 tuple must be unique since building on diffserv which says 5 tuple must be unique. Lou Berger: Need to capture in your proposed text the implication of this uniqueness. David Black: 2 implications: Easy one: there are few places in diffserv where you can mark a flow with more than one dscp. The decision to ID a flow by 6tuple says that DetNet can’t do that, no big deal, that’s a design decision DetNet is entitled to make. Lou Berger: We plan to change the flow ID to be a list rather than a mask. If it’s a list, it can allow that. David Black: Not when there is text in the IP draft that says a 6-tuple uniquely identifies a flow full stop. Lou Berger: It is a 6 tuple including masks and other things. David Black: In that case we have some interesting text to write there. David Black: The other item: A DetNet flow is also expected to be identified as a flow using 5 tuple by others e.g. IP and DiffServ. So you need to use this as an ID outside of DetNet. So it can’t be the case that a flow with this 5-tuple with an EF DSCP vs a CS1 DSCP are different flows. You would have to change the port or something to identify them. Lou Berger: Are you looking at this as an app flow or a network flow? David Black: Network, specifically DiffServ architecture. Lou Berger: What is the implication of that data? What does it mean to be a different flow? For example for an app flow, for a voice stream vs a video stream, and we are combining them, and the only diff is DSCP, that is fairly forbidden, understood. But from a network standpoint, if the stream is going to get different traffic treatment then it is a different flow, that’s what DiffServ does, gives different traffic treatment. David Black: Yes but we try not to subdivide by tuples. Lou Berger: It would be good to capture what restrictions there are on the network equipment based on that statement - I think we’re OK with the statement as it impacts applications, won’t be misinterpreted. But about network equipment, what would it have to do differently? David Black: Let's take this offline. Stewart Bryant: I am curious how a 5-tuple doesn't uniquely id a flow, excluding NATs? They are a unique description of the flow. David Black: We are in violent agreement. Lou Berger: Agreed, but I’m confused. David Black: But there is text in the draft that isn’t as precise on this point as it ought to be. So let’s see how that text gets updated and then work from there. Janos Farkas: Yes let's see the new text and work from that. Norm Finn: I assume it’s OK in a flow with a 5 tuple with diff't DSCPs if the packets get out of order? David Black: That depends on the DSCP. It is true unless otherwise specified, and there’s an important “otherwise specified” called AF. Norm Finn: In the drafts the intention of the flow ID is to route the flows to different queues, to get the diff't QoS we want. To determine which queue a packet goes into, the DSCP is an important distinction. David Black: Correct and hence when the DSCP is picking off the Q, and you don’t want reordering within a flow, don't use DSCPs in that flow to pick up different queues and cause reordering, that’s the punchline. Lou Berger: If that is the text you are putting in, people will agree. Stewart Bryant: When you actually want diff't DSCPs for same UDP port since going to same service on same application. Lou Berger: Generally we don’t worry about app flows here, that is above us. We are providing tools. Stewart Bryant: Need some clarification there, I’m trying to figure out why you would do it? David Black: Best to point you at WebRTC which is doing a lot of muxing of a lot of stuff. In general, if it hurts, don't do that, but we need precise words to say that. Stewart Bryant: I’m confused, I would like to see an example. Lou Berger: It is part of the current Internet Architecture, which allows this case. The WG has not suggested disallowing this case before. If we plan to do that we would have to reach concensus and be really sure. Stewart Bryant: It would be useful to have an example of a case where you’d want to do this. Lou Berger: Read about DiffServ, it talks a lot about this. David Black: The simple case is that DiffServ defines a piece of functionality that DetNet isn’t interested in, AF, assured forwarding. Inside an AF class, AF3, they have 3 DSCPs in order of drop precedence. DetNet won't drop packets, so can't use the ones that allow dropping. Stewart Bryant: We need something in the text for this. David Black: I have signed up for that. David Black: Next topic, I am confused about the purpose of the Mgmt and Control Information? I’m trying to figure out what to do about the v4 “type of service” and v6 “traffic class” fields. So what I’d like to understand is, what is the info on this slide used for? Don Fedyk: These are the possible fields you can choose to ID traffic, but it doesn't have to have to be all of them at once. David Black: What do you mean by identify? Lou Berger: Traffic classification. David Black: OK for traffic classification the type of service and v6 traffic class fields then need to be split because the ECN field is in there, and the ECN field must not be used to identify traffic. That’s the easy one; and then the DCSP is the other 6 bits in those two fields, and it can be used to identify and classify traffic, that’s fine. Lou Berger: We need some clarifying text for that, we already agreed to fix that; we should have broken it out already in the doc. David Black: Need to rewrite to split type of service and traffic class fields out into DSCP and ECN fields and get rid of the bitmask. I need to write an email to clarify what has to change and why, now that I understand this is to be used for traffic classification. That to me means these are the fields you can use in a filter to carve out the very small chunk of traffic that is to go through the DetNet forwarding plane in the node. DB to provide this text. > 2 14:15 20 Title: DetNet Flow Information draft > Presenter: Balázs Varga (remote) or János Farkas (onsite) > Draft: https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-04 Xuesong Geng: What is the relationship between the parameters in the green box, the dynamic flow format vs the blue box, the DetNet service delivery type? Janos Farkas: In the green box there is the DetNet payload type, that is related to the service delivery type. When you look at the DetNet service it can be like a layer 2 service that is provided by DetNet service for a layer 2 Ethernet DetNet flow, or layer 2 app flow. Xuesong Geng: I can understand the payload type is different, but the flow format and delivery type should be the same? Janos Farkas: The flow format reflects whether it is an MPLS or IP data plane. The same packet network may provide both data planes in some form, so it is good to know which it is. That’s the idea. Xuesong Geng: So we conclude that they can be different. Janos Farkas: Yes. Lou Berger: What is next to get to last call? Janos Farkas: This was contributed work, so we need feedback, a thorough review. Lou Berger: Did you capture everything that happened in all the other data plane documents? Janos Farkas: We did our best, but this is a first try from our side, and self-review is tough. Lou Berger: We need the WG to review it, now is the time. But we need to review what was done in the other documents before last-calling this one. Would it be good to last-call it at the same time as the data plane documents, or not? Janos Farkas: Not sure. Lou Berger: The tradeoff is that it would require a lot of reading by the WG, but the benefit is that it would be readable as a complete set, to get the full picture Lou Berger: Right now don’t have a strong opinion.We can think about it. Andy Malis comment via Jabber: If this document is normatively referenced by the data plane drafts, they should go at the same time > 3 14:35 15 Title: DetNet Configuration YANG Model > Presenter: Xuesong Geng > Draft: https://tools.ietf.org/html/draft-ietf-detnet-yang-03 David Black: I’ve sent to the list 2 changes to IP data plane draft to take out DSCP bitmap and ECN from use in flow ID. Xuesong Geng: Once the data plane draft is fixed, the YANG model can follow. Lou Berger: David, thanks for this contribution. There is a github for this WG, so any one can suggest specific changes and do a pull request. Xuesong Geng: Maybe it is not clear the relation between traditional DiffServ and DetNet services? Maybe we should have some explicit documentation of this, to make it easier to understand how best to use the DSCP value in DetNet? Xuesong Geng: Structure of YANG is now stable, so other parts can be added. Please review and comment. May need weekly discussion on YANG, as is done with data plane. Lou Berger: Per author's tempo, we can make sure the WG’s webex is available to you for enabling keeping pace with this work. Lou Berger: To get to last call, need other docs to be complete, then need to align to them. New structure is now in place? Xuesong Geng: Yes but subnetwork is not in the draft yet. Lou Berger: We have to have a framework that allows augmentation for specific technologies in the future. As long as we have that type of framework that allows augmentation for subnetworks and for app flow side then we can run ahead, and we can always add TSN as their own documents as an augmentation to the base model. Xuesong Geng: Yes, but also need to add aggregation case? Lou Berger: Yes, aggregation is part of core IP, MPLS docs, should be covered. Xuesong Geng: Could be last called with other docs? Lou Berger: Should follow, best to wait until just after data plane are done, so won't have to apply last call changes to this draft also. Lou Berger: Maybe by November IETF if we are halfway done it would be good. > 4 14:50 20 Title: DetNet Bounded Latency > Presenter: Norm Finn > Draft: https://tools.ietf.org/html/draft-finn-detnet-bounded-latency-04 > If published https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-00 Lou Berger: We ran a poll on adoption, so the draft has just been adopted, please resubmit as detnet draft 00 version. > 5 15:10 10 Title: DetNet Bounded Latency Requirements > Presenter: Liang Geng > Draft: https://tools.ietf.org/html/draft-geng-detnet-requirements-bounded-latency-03 Janos Farkas: You said want to set requirements w/o specifying solutions, but it sounds like you have chosen CQF as a solution? For example we just heard about asynchronous traffic shaping which doesn't have these type of problems. The other assumption you are making in the previous slide is that the TSN domains are time synchronized, but that is not a must. Liang Geng: I am not choosing a solution, the intent is just to provide these as alternatives. Have not assumed these, but could be guidance. Janos Farkas: There are other solutions that could work, as we have heard. Janos Farkas: For smart factory usually not long haul link? Liang Geng: But we have heard requirements from some large factories that have central control at several hundred km away, but perhaps that is unique to a given market. Norm Finn: Maybe something for TSN people to think about, when working on bounded latency draft, the pater noster scheme which might be more useful in meeting this particular document’s requirements. We need to think about how to do that, e.g. with a draft, or in TSN? Loa Anderson: I like this, it looks close to WG adoption, if the draft is as clear as the presentation is. The use of Must and Should, are those intended as MUST and SHOULD in IETF sense? Liang Geng: Good comment, it is written that way, but not really intended to be that formal, needs to be looked at more carefully by the authors. Loa Anderson: If not, need to change accordingly. Loa Anderson: Question about the numbers, but here in 7.1 and 7.2. Link node changes are topology changes, so rather the same thing, need to adapt language to this. Regarding link definitions of “intercontinental” vs “intercontental long” link? Are these different? Some words like "long, big" which are not defined. Should put effort into defining what they actually are. Liang Geng: Agree, need to take more care of language here. Really just long haul, need to re-word to describe. Ethan Grossman: This seems rather like the Use Cases draft, in that it looks at making sure that the capabilities of DetNet meet the real world requirements. Some of the items mentioned are already mentioned in the Common Themes of the Use Cases draft, so they are already part of what we are doing here. Also in the Use Cases draft we avoided the MUSTs and SHOULDs and word “Requirements” since we are trying to guide the work but not define what has to be done. So I’m trying to understand if we adopt this draft, what is the relation of this draft to the Use Cases draft? Have you thought about that? Liang Geng: I understand your concern, but the Use Cases draft is about the service or application point of view about what the application requires the network to be in terms of functionality and performance. This requirement is actually technical requirements for performance, so I don’t see them as overlapping, but I might need to re-read that draft to understand these concerns. Janos Farkas: Actually the Use Cases draft sets forth a good set of technical requirements, but this could have been a chapter in the Use Cases draft, but it is late now since that is already an RFC. Liang Geng: Different people mean different things by requirements or use cases, like in 3GPP requirements can stand for use cases, but this requirements document does not talk about use cases like video or audio or things like that. It is really about how we think the network should function and perform. And given that the Use Cases draft has already been published… Janos Farkas: One of the requirements in the Use Cases draft is about how many packets can be lost, it is very specific, but it doesn’t need to have its own draft. Norm Finn: Have you made a clear distinction between synchronizing time in the parts of the network and having the same frequency in the various parts of the network? I know there are service provider networks that provide frequency lock without time sync, for example CQF can be made to work with frequency sync without needing time sync. Liang Geng: Yes, we consider time sync or time variance versus clock frequency variance to be two different requirements (need to change title of slide to time and clock variance) Norm Finn: So asynchronous clocks, does that mean there are also different freq domains? Liang Geng: Yes. Norm Finn: So within the domain it is not a problem to have frequency lock? Liang Geng: It needs to be within a tolerance. Norm Finn: Everything is within a tolerance, there’s no such thing as perfect Liang Geng: For 5G backhaul, I don’t recall exact number but it is smaller than the previous two examples, and that’s the tolerance we need to obey for clocks asynchronization. Stewart Bryant: I recall the numbers being 1.2usec or you can’t work at all, and there are lots of numbers between 350ns down to 150ns to get the optimum use, and so I imagine that those kinds of timing numbers are going to be commodities in the network because every transmitter is going to need it. Mach Chen: In the numbers Stewart mentioned we need to differentiate between front and backhaul clock sync requirements? Liang Geng: I don't recall exact numbers for 5G but I can check that: Janos Farkas: As noted on the list, I’m not sure if time sync requirements should be DetNet requirements? We let implementers choose their time sync solution. Time sync solution is part of implementation. Good set of requirements, maybe study more about time sync. Lou Berger: Need to wrap up, how many think this is a topic that the WG should be working on to refine and document? Product of IETF are documents – should we be working on documenting this? Result: Reasonable number. How many not: nobody, that’s pretty clear. How many have read the doc? Less than before, but a reasonable number. Is this a good starting place for our work in this area? Somewhat fewer, so there’s some weakness here. Maybe go through some draft updates, discuss more on the list? Maybe if we want we can discuss further in the second session today. > 6 15:20 10 Title: DetNet SRv6 Data Plane Encapsulation > Presenter: Xuesong Geng > Draft: https://tools.ietf.org/html/draft-geng-detnet-dp-sol-srv6-01 Janos Farkas: What are you looking for here? We discussed SR as a tool to establish explicit routes, but we have chosen to specify an IP data plane solution without any new fields for DetNet. Reading this it is like a new data plane for DetNet that would require new fields, so is this a new data place specfic to SRv6? Xuesong Geng: Yes, this is a new story for SRv6, not native IP. Stewart Bryant: Clearly it is a new data plane but it has properties we don't have in existing ones so we should look at it seriously. And there is a lot going on in network programming e.g. SPRING. Don't know which of those would be the right one to pick. Xuesong Geng: This will also be presented tomorrow in 6MAN WG to show to more SRv6 people to get feedback from them. But we think it is necessary for DetNet to see that SRv6 can implement DetNet. Stewart Bryant: Agree, should have PREOF in the IP domain, and maybe people will want an SRv6 solution as well. Lou Berger: A lot of flux in SPRING at this time, in SRv6, should be aware of this. Is DetNet on SRv6 something we want to take on as a new data plane, i.e. expand our solution set to SRv6? How many people in the room are interested? Result: Some few hands. Should not be working on it? Result: none. Reasonable information. Pascal Thubert: There are two things, to layout path, then the dynamics of how many packets are going through the path, e.g. tuninq queues. I can see how SRv6 can be used to serialize a complex path, but I see less how we can signal everything we need to signal from the packet, like the rate, which must be maintained in the hops. So there has to be a balance between what can go in packet vs in the hop. In the extreme we have BIER, where the bits indicate the segment, but nothing about realtime. Everything is laid out, all state is in the hop, so we just decide to use it or not. In this case could signal the existing things, or signal some more, but you will still need hop state. Xuesong Geng: Understand concerns, have read BIER draft, interesting option for PREF. Similar to multicast case, if we use BIER it is a natural idea. But different story between BIER and SRv6. In BIER don't need status, but doesn't mean an SRv6 solution isn't valuable, it is just another way. If it works, it would be good. Stewart Bryant: We do need a full blown IP solution that can be deployed in regular IP networks, but whether they will be running SRv6 I don’t know, since that is more of a service provider domain. So even if we do this, still need existing IP sol'n. Needs to be aligned with IP network slicing, but industry is not quite clear there, some push for SRv6, but some 3GPP are not sold on that design. Xuesong Geng: It is just another option to do DetNet, it does not replace native IP. We are just adding a new draft. Stewart Bryant: But the current data plane doesn't support PREOF for IP, we don’t have a full service IP solution, and we need to remember that. Lou Berger: Have IP over MPLS which would be equivalent. IP over SRv6 would be equivalent. Loa Anderson: Agree with Stewart. Lou said I didn't like how the question was phrased. It is because it is too early; we need to wait and see where SRv6 goes. If SRv6 will be part of a DetNet type of network, then we need to do something. But if apart, there’s no point can't decide that today. Xuesong Geng: But SRH is stable now, a standards track RFC. So SRv6 with SRH is stable enough. Mach Chen: BIER can be a candidate for DetNet PREOF... Lou Berger: Should not talk about BIER now. Pascal Thubert: I mentioned BIER just to contrast between where state is maintained, not as suggestion for PREOF for IP. Lou Berger: We can continue this next session if we have time. Adjourn first session, return in 15 minutes. > Adjourn 15:30 > > 15:50-16:50 Wednesday Afternoon session II > > Presentation Start Time Duration Information Session II > 0 15:50 5 Title: Intro to Session II > Presenter: Chairs > 7 15:55 20 Title: DetNet OAM > Presenter: Greg Mirsky > Draft: https://tools.ietf.org/html/draft-mirsky-detnet-ip-oam-00 > Draft: https://tools.ietf.org/html/draft-mirsky-detnet-mpls-oam-00 MPLS OAM draft: Andy Malis: The draft needs to specify if the sequence number goes through zero or not, for example 255->0>1 or 255>1. That is currently not specified. Greg Mirsky: Yes, the sequence number may wrap, but I understand that for PREOF that is not critical. Janos Farkas: The data plane docs are very specific about this, so the OAM draft should follow. Greg Mirsky: Will review that draft. Lou Berger: Do people think this document is headed in the right direction? Few responses How many have read? Few. How many think we should be working on OAM for MPLS data plane? Reasonable number. We can't do much with the low number of people who have read the document. Stewart Bryant: To make progress, maybe we should review at an interim? Lou Berger: Could have an adoption poll but if it is rejected, don't consider it dead, i.e. understand it to be a guage of whether it is headed in the right direction, and can just be redirected. We generally agree need to work on OAM, question is whether there is support for this specific solution. IP OAM draft: Lou Berger: Sounds like a good description of the problem; do you have any proposed solution? Greg Mirsky: That’s what I have. IP OAM has to be mapped with DetNet flow. Maybe there needs to be some management tools. If there is ECMP in the network, then it will be more of a problem. David Black: Ouch, Greg is completely correct. Janos Farkas: On the co-routing stuff, we have in the flow info model introducing some parameters trying to make congruent with ID parameters, like flowID and so on, maybe extend to OAM to ensure it goes along the same flow. David Black: Example: Suppose that the DetNet forwarding plane is fouled up a node, but the IP forwarding plane is not. The OAM traffic, traceroute in particular has to go through the DetNet forwarding plane to tell you where the broken node is because if you send it through the IP forwarding plane it will tell you everything is OK. Lou Berger: You also have to get into the right queues because there’s a whole queueing behavior property. David Black: That is part of forwarding plane. In queue-speak if the DetNet queue is broken in a node and the corresponding queue for the pair of IP addresses is working, you send traceroute on a different path than the DetNet queue, then traceroute will fail to find the problem. Norm Finn: It is not trivial to get OAM to follow IP, understood. And not easy to get it treated with same QoS (make sure it goes in the same queues etc). Greg Mirsky: If flow is identified by 6-tuple and that controls which queue it goes to, I understand, but if we can’t make that happen then we can’t make OAM do its purpose. Norm Finn: Must look at OAM and know which flow that OAM is for. There is an OAM flow per DetNet flow. Also we must allow for bandwidth of OAM in each DetNet flow. So OAM must be limited in bandwidth and comply with same rules that apply to the DetNet flow itself. Norm Finn: Consider that with PRF, can argue that the sequence number allows the flow to be the OAM – you don’t get all the functions, but you get connectivity. So if you have two paths, getting one packet on one path but not the other, then you know something is wrong, not just that the source stopped. If you have the two paths. Greg Mirsky: Can use hybrid OAM methods. It is a good compliment but not a substitute for active OAM where packets are constructed for test purposes. Greg Mirsky: IP has some properties we need to discuss, e.g. fate sharing. There are two scenarios for OAM: Tunnelling, and interworking. Can look at DetNet or MPLS domains as one hop, or interwork as end to end DetNet. Stewart Bryant: Have never been able to solve congruent paths with IP. Maybe if use explicit routing? SR, or PPR, RSVP-TE, PCE-based, etc. So there are at least 5 possible solutions for this. Once one of those is in place for DetNet, then the OAM will naturally be fate sharing. Lou Berger: We have been here before with MPLS, discussed companion labels co-routed with shared resources, but wasn’t adequate since something in label database might be corrupted, so just because use same resources and paths, because use different traffic class identifiers then OAM may still not succeed which is why we ended up with GASH and Gal, we’ve been here before, don’t forget those lessons. But we can do something like resource sharing and congruent paths. Stewart Bryant: Would have to have all the same queueing stuff, DiffServ paths and so on. . David Black:It is worse, ICMP is crucial part of IP OAM, it has none of that. Stewart Bryant: So you have to set explicit path such that the source and dest pair are the trigger, not a richer set of information in the packet. David Black: Correct. If you do your DetNet selection based solely on IP src/addr pair, then you will pick up ECMP, but if you get fancier than that then things get risky fast. Lou Berger: Is OAM for IP DetNet something this WG wants to work on? Result: reasonable number but less than MPLS case, surprising. MPLS is an easier problem. Stewart Bryant: This is potentially a much broader problem than just DetNet since we don’t have a first class IP solution that has these properties. Lou Berger: Our forwarding is different than IP, but we have different' things available to us, e.g. all of our 6-tuple flows are explicitly controlled, so can put additional requirements on control plane (which doesn’t answer what we do in the data plane) but we have different tools. Stewart Bryant: A more constrained problem, but still one that is not solved by IETF yet. Greg Mirsky: What we are monitoring is what we are measuring, we don't know where it is in the network. We know if is between two points but we don’t know which nodes these packets are traversing. Norm Finn: More interested in plain IP OAM than MPLS since harder more fun problem than MPLS OAM. If someone comes up with a plausible solution I would like to hear about it. Lou Berger: Those who are interested, please self-organize, Mirsky to coordinate activity, maybe get critical mass on it. Maybe could have informal Webex work meetings, contact chairs to get set up. Or could ask for interim on this. But first try self-organizing, then see how chairs can help. > 8 16:15 10 Title: DetNet Controller Plane Framework Intro > Presenter: Xuesong Geng (onsite) for Andy Malis (offsite) > Draft: https://tools.ietf.org/html/draft-malis-detnet-controller-plane-framework-01 Lou Berger: Based on charter, but to be validated by Deborah as AD: We are not chartered to do control plane solutions; we are chartered to do management and control plane requirements, i.e. to identify what we need from a control plane. So part of this draft is in scope, some not. Identifying gaps in control plane solutions is within charter. If we identify a solution we’ve gone too far, we should be talking to other WGs about solutions. Discuss which specific technologies are available, that is safe ground. But proposing solutions is out of scope. Stewart Bryant: If we need to do a control plane solution, we don't want to be stalled on this. Lou Berger: There are at least 3 groups working on control plane in the routing area; we should go to them and ask them to fix any gaps in their protocols. If they have a good reason why not, then we'd have a strong reason to ask IESG to re-charter DetNet. Stewart Bryant: We need to get past that soon. We wanted to get data plane going first, but now it is in good shape, we should be starting early work on control plane, since it will take time. Lou Berger: Most of this doc is really helpful. . Stewart Bryant: We need to clear the structural and administrative obstacles to working on control plane. Lou Berger: It is only specification of control plane solutions that is out of scope. Stewart Bryant: OK as long as we have a path forward. Lou Berger: Earlier in TEAS was a proposal for doing TE for IP flows. May end up with sol'n we can use even before we discuss framework. Loa Anderson: Given we have a good document, 98% in scope, the problem I see is that if plan to go to other working groups, will it be the DetNet Chairs who will take that initiative? Lou Berger: Once we identify shortcomings, then we can discuss with IESG. If we have proposals then it will be specific, not generalities. Andy Malis: We were being conservative in our reading of the charter. Does include "management and control", what we call the controller plane. So that is in scope. Loa Anderson: Concerned that you are pushing it too far out. We should be proactive now to start discussing within the WG that we need to be involved. Lou Berger: Need some concrete control plane proposals on the table, in documents. If anyone has any control plane solutions, please contribute it somewhere in IETF. Don't hold up on process, get docs submitted. Eric Gray: We could already start this now, in TEAS, so maybe since that is Lou talking to Lou it may not be that difficult. Lou Berger: We have a controller plane framework document here. Should the WG spend time on architecture and framework discussion on controller plane, given that it is scope for our charter? Result: Similar number to previous, a smaller than expected number. Anyone think we should not be? Nobody. Lou Berger: For this doc please carve out solutions, write them up and discuss them separately, but continue discussing this document in the WG. Xuesong Geng: If have alignment on what to do or not to do, it will be clear if it is in charter. Lou Berger: Don’t worry about charter. Discuss what is missing, put solutions in another doc, contribute to appropriate working group. Main thing is to get it contributed and get discussion going. Xuesong Geng: Without detailed discussion of specific solutions, what would the purpose of this draft be? Is that the right direction? Lou Berger: Here’s what we need from a control plane, here’s what’s missing. What the options are and where the gaps are. More like a gap analysis, define what has to be done. Lou Berger: Notes that AD did not get up and shout at us, this is a good result. > 9 16:25 10 Title: Deterministic Networking Application in Ring Topologies > Presenter: Liang Geng > Draft: https://tools.ietf.org/html/draft-jiang-detnet-ring-04 Janos Farkas: What makes this so specific, given that we have DetNet MPLS data plane and other ring topology work? Is this an informational document on how to combine these into a solution? Liang Geng: This only describes how to handle ring topology in an MPLS data plane. Lou Berger: Have you looked at other MPLS ring solutions in the IETF? Liang Geng: Yes. Lou Berger: Do they not apply? Can you not build on them? Liang Geng: Principles are similar, but when you introduce DetNet, you add PREOF, which are not covered elsewhere. Lou Berger: We have PREOF at service layer. Have you looked at using existing MPLS rings soln's at the forwarding layer? Liang Geng: No, good question. Loa Anderson: This is RMR for the forwarding layer, then you need to add PREOF for service layer. We shouldn't specify anything new for the forwarding layer, should use RMR. Kireeti Kompella: How do you determine clockwise vs anticlockwise? Every node has to have the same notion. How do you get all nodes to agree on which is which? Liang Geng: Configure it before hand. Kireeti Kompella: One advantage of RMR is that it does this by advertising something then does it automatically. Other thing is in this two ring case, with "upper node" vs "low node" - how can this be algorithmically done, or you will have to configure them all. If you have a lot of rings, making sure you configure them all can be difficult. Kireeti Kompella: To make scalable, must be algorithmical. Also there can be chords, e.g. bypass some nodes, e.g. optical bypass. Is that of any interest to DetNet? Liang Geng: This is a question for the authors, will take it offline. Lou Berger: Look at RMR and try to build on it. Jeong-dong Ryoo: There many ring protection mechanisms including MPLS, RMR. For those we can't avoid traffic disruption in case of a network failure. With this DetNet ring, at least we won't lose packets, so that is an advantage of this document, of DetNet. Janos Farkas: That PREOF comes with DetNet. This is combination of ring in the forwarding plane and PREOF in the service sub-layer. The Ladder topology is comprised of rings, for which examples are given on the use of replication and elimination, e.g. as described in IEEE802.1CB. Jeong-dong Ryoo: How to use ring protection with DetNet? My answer is when you use this DetNet protection mechanism, you must disable conventional protection in forwarding sub-layer. I understand the Ladder topology, but this draft explains how to apply DetNet technology to rings. Lou Berger: You are saying there is an opportunity for a PREOF-optimized ring protection using DetNet. But we would like to leverage RMR, so if you can leverage that please do, or explain why you can’t. Need to include how to make it scalable. Jeong-Dong Ryoo: What do you mean by scalable? Lou Berger: That each ring doesn’t need to have the same number of PREOF functions as you have end to end, if there’s a way to do that, some shared protection. If your solution is that every ring is a segment, and you do a ring for every flow, maybe there is an opportunity to do something better, e.g. through aggregation. Jeong-Dong Ryoo: Can't quite catch it now, we can follow up offline. Including relation to existing rings e.g. RMR. Kireeti Kompella: Since multicasting on both rings, not really doing protection, just that if one fails get the packet over the other path. But RMR has two parts, protection and configuration. need configuration to scale. Loa Anderson: Need to look at RMR and see if we can use it, or determine if we can’t. Need autoconfiguration. Lou Berger: In general we try not to have two solutions for the same problem, so I’m just trying to follow that standard practice. If there’s an existing solution we should use it. Jeong-Dong Ryoo: Regarding autoconfiguration the example is done by any multicast protocol. Bridge node to each leaf is aware of subscriber, that is done by any multicast configuration protocol. Then maybe that once subscriber is attached, then DetNet can get a signal to enable Liang Geng: Value of draft is how to incorporate service layer in DetNet. Lou Berger: We look forward to your update, and its relation to RMR. We're out of time, if there are more comments on earlier topics please bring them to the list. > Adjourn 16:53