Minutes DetNet IETF106, rev Dec 9 NOTE TAKERS ADD YOUR NAMES HERE (not required): Ethan Grossman, Ethan Grossman János Farkas > > DetNet Agenda IETF106 (Singapore) > Version: Nov 17, 2019 > > Thursday, November 21, 2019 (+08) > 15:50-17:20 Thursday Afternoon session II > 17:40-18:40 Thursday Afternoon session III > Collyer > > Slides: https://datatracker.ietf.org/meeting/106/session/detnet > Etherpad: https://etherpad.ietf.org/p/notes-ietf-106-detnet > Meetecho: http://www.meetecho.com/ietf106/detnet/ > Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1062.m3u > Jabber: xmpp:detnet@jabber.ietf.org?join > > Available post session: > Recording: https://www.ietf.org/audio/ietf106/ > YouTube: https://www.youtube.com/watch?v=nsTrZOIxSYM > > Presentation Start Time Duration Information DetNet Session I > 1 15:50 15 Title: Intro, WG Status, Draft Status > Presenter: Chairs > Ehsan Mohammadpur: Update on bounded latency draft: Next is calculation of delay bounds, data can be used in DetNet, should add this by IETF 107. Hope to finish writing whole draft in IETF 108. Currently working on terminology updates and consistency checks. Lou Berger: re Security draft: Looking for WG LC by IETF 107. Will request early review from SECDIR once authors give the go-ahead for this. Re rechartering at IETF 107: RAW: would like to see as complementary activity. IESG to determine if should be its own WG vs being done in DetNet; either way is fine as long as the work gets done. Loa Anderson: What is status of Security draft today? Lou Berger: Very close, will be an update preso today, with discussion time. David Black: Security draft: good text in there, but want early IESG review of Security draft since that may produce significant input to the draft. Greg Mirsky: Authors believe draft provides viable technical solution, and would like to request WG adoption of OAM draft. Lou Berger: Didn't adopt last time since few had read it. Today will do adoption call for support. Greg Mirsky: There is another doc for OAM, OAM over DetNet IP; I sent a proposal but there is a technical challenge of mapping OAM session between endpoints into DetNet IP flow to be monitored - we are looking for comments and input on list. Once we get agreement on a solution we can agree with, then we can consider adoption of this second document. Xuesong Geng: Does SRv6 belong in current DetNet charter or next charter? Lou Berger: We need to work out whether to do that work here or in SPRING. For new dataplane methods you usually go to owners of that dataplane, and they own that dataplane, so we would need their agreement to do it here; so for now we assume will be there. It is a new dataplane mechanism, good topic to raise, need to raise with our AD and SPRING AD. Xuesong Geng: OK with doing in SPRING but it has been very bust there so we would prefer to see it in DetNet. We have had a timeslot in SPRING in the past, hasn't been much interest there. Lou Berger: They have first say since it is their technology, their WG chair and AD's call. To us it doesn't matter where it gets done, but they have first call on it. They have to say they don't want it before we can take it on. Xuesong Geng: I will talk to their Chair. Lou Berger: to all: To ensure you get a slot at IETF 107, please submit your draft before that. There is an IEEE 802 TSN meeting the week before us in Bangkok next year - maybe we will meet or have joint workshop on the Saturday in between? IEEE ends Friday, then IETF meeting starts on Saturday. Not confirmed yet, but want feeling of the room on participation for this: Q: How many participated in last one?: small number. How many interested in next one?: somewhat more. Greg Mirsky: Will it be more lecture, or discussion? Janos Farkas: I would like to see more discussion next time. Last time was first of such meetings - want to foster more discussion. Lou Berger: Depends on how many people show up - last time we expected a small group, but was large. Harder to have discussion with larger group. Greg Mirsky: Would be good to have call for papers and have people bring in specific use cases and problems to look at, rather than overview of technology. > 2 16:05 10 Title: DetNet Data Plane Framework - Last Call Update > Presenter: Balázs Varga > Draft: https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-03 (No comments) > 3 16:15 10 Title: DetNet Data Plane - Four Drafts - Last Call Update > Presenter: Balázs Varga > Draft: https://tools.ietf.org/html/draft-ietf-detnet-ip-03 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-mpls-03 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-03 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-udp-ip-03 Lou Berger: A comment came in this week on IP document (about omitting ECN field)? Balazs Varga: Yes I have noted this in the slides, this is not in the current version of the draft, I will add that in a new version. Balazs Varga: Also there were comments about the references (normative vs informative), so even though slide says it is ready for WG LC, it will be one more version. Lou Berger: So there is one more version before it is ready? Balazs Varga: Yes but we know word for word what has to be done. We can do that during IETF 107 and republish. Lou Berger: Since the Chairs are contributors to the draft, Ethan Grossman is Shepherd for these drafts and owns the process. Ethan Grossman: The current Shepherd writeups are still marked as in process, would appreciate some review on them. Lou Berger: OK. > 4 16:25 20 Title: DetNet Data Plane - TSN Drafts - Update and Plans > Presenter: Balázs Varga > Draft: https://tools.ietf.org/html/draft-ietf-detnet-ip-over-tsn-01 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-over-mpls-01 > Draft: https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-tsn-01 Ethan Grossman: The Security sections seem small in these drafts - are you confident this is sufficient security analysis, particularly with respect to considerations that are time-specific and specifically related to TSN? Balazs Varga: No, we have identified this as something that needs further investigation. Ethan Grossman: OK so the plan is to fill in that information in the Security draft. But what if we have new data planes such as some wireless thing. At that point the technology-specific security considerations for such new data planes couldn't go into the Security draft, because it would be already published, so they would have to go into the individual new draft? So should we move the currently existing sections from the Security draft back out to these DP drafts instead, to be consistent with future such additions? Balazs Varga: No preference. Janos Farkas: The Security draft has been gated by the base Architecture and DP drafts, i.e. waiting for final decision of data plane technologies, and thus of their technology-specific security considerations. So presumably the technology-specific security considerations will go into the Security draft, but any future data plane considerations would go into those future data plane drafts. Is that the plan? Ethan Grossman: Yes, since the Data Plane drafts will already have been published. So unless we restructure these sections now to move these considerations back to the individual DP drafts, we will have that inconsistency going forward. Although, as of today, we have not identified any such technology-specific security considerations, so the IP and MPLS sections just say "nothing found" which is consistent with what the Security draft sections say, so it is a non-issue. But if we were to identify some such issue(s) after the existing DP drafts are published but the Security draft is not yet published, then we would have to put them in the Security draft. But what about future data planes, or even TSN data plane, for which we have a blank section in the Security draft? Lou Berger: My view is we have a foundational set of documents in which we will address the known security considerations, and we can refer back to them, but for the future if we identify something new, then it would have to be put into a new document. We have to ensure that the current drafts adequately cover the security considerations, so as discussed earlier we will have early IESG review of the Security draft, and also a Security Directorate review of the whole set of DP documents, so we expect them to keep us honest. Janos Farkas: Another example of this is the SRv6 data plane draft - my personal view is that it should have its own data-plane-technology-specific Security Considerations section. Ethan Grossman: So do we include the TSN data plane considerations in the Security draft, or cut it off at just IP and MPLS? Lou Berger: Is there a section for TSN in the Security draft now? Ethan Grossman: There is just a "to be written" placeholder. Lou Berger: I would say cover the core technologies only and move TSN to the TSN drafts. So the plan would be to put the IP and MPLS specific considersations into the Security draft, but leave TSN and future data plane security considerations for those drafts. Put a statement to that effect in the Security draft. The core data plane drafts' Security Considerations sections reference the Security draft as Informational, and so would future data plane drafts. Lou Berger: What is the timeline for the TSN documents? Balazs Varga: We need about 2 more meeting cycles, so targeting Madrid IETF. Lou Berger: How many have read this version of the document? Really very few. Has not had much review, so although we'd like one cycle, we need to adjust to aim for two cycles. So anyone interested, please read and contribute to the draft. Xuesong Geng: Maybe we should also send this over to the IEEE since IEEE people are very interested in how to do the mapping betweenTSN and DetNet, so there are many potential reviewers out there. Lou Berger: Is the intent to send the current doc over there and say "please help us" or is it to get to a stable place and then send it over there for review? Xuesong Geng: I think the current document is ready to send over. Balazs Varga: I would like to collect and include more feedback from this group first, and also work on conformance language. Janos Farkas: I think it is better to wait until we have stable conformance language before we send it over to another standards organization for review. Xuesong Geng: OK, either way is fine. > 5 16:45 15 Title: DetNet Flow Information Model - Update and Plans > 39 Presenter: Janos Farkas > Draft: https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-06 Janos Farkas: Please review for posible missing atttributes. David Black: OAM - Scope question - which is cart, which is horse: MPLS OAM looks like clean add-on by the ACH, but IP OAM looks different. How far do we have to go into IP OAM to see if we really have everything we need to support OAM? Janos Farkas: No discussion on list yet, so open question - how do we get done? My understanding of Greg's proposal was to don't bind together IP and MPLS OAM, but let them progress independently. One question is whether we should hold back Flow Info model until we get MPLS OAM? David Black: The MPLS OAM is clean, we know how to tag flows as OAM. Greg's proposal will probably affect IP data plane draft. So the question for the Chairs is "Do we pause IP data plane or do we just go ahead and then figure out OAM afterwards?" Lou Berger: With Chair hat (but also contirbutors): we think consensus is: define core, get those out, keep pushing along, and do OAM when it shows up. Also made technical call: OAM will have to follow flows so must meet flow definitions. Have had conversations but don't have a document to answer this yet. So from a process standpoint we plan to move forward with OAM trailing, there is some risk there, need WG to understand that. David Black: So WG consensus is that we will move forward with IP draft, then revise IP once OAM is figured out. Lou Berger: Right. We will have to do wire flow rules to cover both the OAM traffic and the 6-tuple for data flow, as good as we are going to get. Need to go in that direction and see where we end up. Stewart Bryant: Isn't a way for regular IP to address getting an OAM message to be congruent with it, leave alone for DetNet. Lou Berger: That's why we have multiple flows by adjusting flow rules. Stewart Bryant: We know how to do this for MPLS, but not for IP. There is no solution for this in the IETF. Lou Berger: Agree. So the question for the WG is do we not push IP data plane forward, and wait for OAM solution, or do we go forward with IP and see if we can align an OAM solution to the IP document? Does WG disagree with our assessment? David Black: Push IP data plane forward, aligning OAM with data plane, aligning IP data plane as necessary. Janos Farkas: As a contributor, we have made a good effort to make IP data plane in line with IP principles, and should be good to go, but developing OAM will be a hard problem but also should be inline with IP principles. PascalThubert: You asked if all ways to signal a flow were listed in this document. There is another way to signal flows which is not listed in this document, in case you are interested. Inside a RPL domain where using RPL to do routing, there is work at ROLL which is about enabling route projection, which is about installing a route from the root directly into the network. This route is what we call a "track" in 6TiSCH, a complex route, akin to what we do here. It is signalled in the packet, using hop by hop header, which contains info akin to a via ref info. There are local and global via refs, local ones tied to destination of the packet, which is the exit of this track, with a number which is locally significant which tells you which routing table you need to look at. You can have huge numbers of these things in a RPL network. That's how we signal not the flow, but the path, that the flow and also the OAM is intended to follow. This is an alternate way of signaling a path in an IP header that is not mentioned in the document. Is this something we want to capture here, or is it not really interesting here? Janos Farkas: So this is an encoding of path in the data packets, like SPRING, with benefit of making OAM co-routed? Pascal Thubert: Not source routing, what you put in the packet is more like topology identification in multi topology routing, not source routing. Each path called a Track is a topology, like a VRF. Lou Berger: The mechanisms we built the IP data plane on are closer to policy routing. So with policy routing we can do similar things, but don't have to have topology IDs, have policies instead of MRTs or SIDs like in SPRING. So we should pursue a path that maps different flows to the same basic policies. Pascal Thubert: The policy tells you which flows go in which RIB, and the packet follows this RIB. The question is this is how we signal the equivalent of a flow, or topology. Janos Farkas: I see something below, not a flow, but routing. Could be a good technology choice at a lower level, below flow information. Lou Berger: Can you collaborate with Greg on his document to capture these ideas and move forward? They could fit in quite well. > 6 17:00 20 Title: DetNet Configuration YANG Model Update and Plans > Presenter: Xuesong Geng > Draft: https://tools.ietf.org/html/draft-ietf-detnet-yang-04 Janos Farkas: We will have something like weekly meetings to work on aligning info model and Yang model. David Black (as Transport area tech advisor): As work towards next version, still have DSCP field to be fixed. Lou Berger: Probably a major revision coming. Currently too flat, needs to be more extensible as a foundation for future augmentation. Xuesong Geng: We remember your similar comments from last IETF, haven't updated it yet. If you find something else wrong please let us know via the mailing list. > 7 17:00 10 Title: DetNet Security Considerations - Update, Open Issues, Plans > Presenter: Ethan Grossman > Draft: https://tools.ietf.org/html/draft-ietf-detnet-security-06 David Black: As one of the people who has drawn a blank on data plane technology-specific security considerations, here is my rationale for why my gut feel is saying that it is OK, and why I'm not upset about it, and maybe someone will debate me on this. The Security draft is written from a threat model perspective. It takes a general functional model of time sensitive networking and outlines the various threats that could disrupt that,and at that level has relatively complete threat coverage . Then considering a specific data plane, the threats haven't changed, but how they impact the data plane probably has. But given that the draft is written in terms of threats, not effects on the data plane, then not finding any new threats against the data plane is not a big surprise. Ethan Grossman: So does that mean we should be talking about those specific impacts on the data planes? Or does it mean we are sticking with threat models and call it good? David Black: Awhile ago the die was cast to write the Security draft as an overall deterministic networking security draft, and its current threat model structure, I'm not criticizing that. So is there a gap there? Answer: no. In other words do the various data planes add threats to Deterministic Networking? Perhaps not. Ethan Grossman: But should we be focusing more on specific effects on a given data plane? Should we be focusing more on this than on more general threats? David Black: No, those are considerations for the specific data plane drafts. Lou Berger (as contributor): What is really different between different data planes is how we do flow identification, that's about it. Maybe we should focus on that. That is, the additional threat/vulnerability may be based on whether it is easier or harder for one flow to impersonate another flow or cause a denial of services based on the number of fields that are used, which is based on specifics of the given data plane technology - the rest is based on services, which is 100% common. David Black: And when we get OAM done, we'll have another difference. Lou Berger: Right. > Adjourn 17:10 > > 17:40-18:40 Thursday Afternoon session III > Location: Collyer > Meetecho: http://www.meetecho.com/ietf106/detnet/ > Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1062.m3u Youtube: https://www.youtube.com/watch?v=mAcMHjzi4Us > > Presentation Start Time Duration Information DetNet Session II > 1 17:40 5 Title: Intro to Session II > Presenter: Chairs > 8 17:45 10 Title: DetNet Controller Plane Framework > Presenter: Mach Chen > Draft: https://tools.ietf.org/html/draft-malis-detnet-controller-plane-framework-02 Janos Farkas: Should we not consider SRv6 as a data plane before we consider it in the context of controller plane? Mach Chen: Yes, based on WG consensus. Lou Berger: From Jabber, from Bernard Sale: Segment Routing is normally having only routing protocol extensions and no signalling protocol? Mach Chen: SR has its own signalling protocol, but if we want to use SR for DetNet, some additional work needs to be done. Lou Berger: I think what they are saying is that controller plane has to be signalled, and the reason we are using "controller plane" rather than the older term "control plane" is that the control is fully centralized, so can do resource management for SR without having to signal it. Mach Chen: We don't discuss any specific solutions here, just potential solutions. Janos Farkas: Resource allocation/reservation for SR is an unsolved problem, there is no known solution. Lou Berger: So far we have no def of what TE for SR means. We have been discussing this with SPRING chairs and ADs. So maybe let's not focus on SR to start, and get there as we work out other topics. Online commment from Bernard Sale: But centralized is Yang, right? Andy Malis: Not necessarily. Reply from Bernard: But in general it is. Lou Berger: How many think we should be working on this topic, i.e. controller plane for detnet, in this group? A reasaonable number. How many think not? (A gap analysis, not a solution). None. Lou Berger: Is this a reasonable foundation for our work, i.e. we should adopt this doc as a starting point? Few. Lou Berger:How many have read the document? About the same number as the few who read it. We will confirm with our AD that this is something we can be working on, and if so we can take it to the list. > 9 18:05 10 Title: Spring SRv6 for DetNet > 17:55 Presenter: Xuesong Geng > Draft: https://tools.ietf.org/html/draft-geng-spring-srv6-for-detnet-00 Toerless Eckert: Would be good to have a comparison between naked IPv6 data plane with per-hop shaper for latency control, then compare with SRv6 solution and explain the benefits. Hard to tell this from looking at the figures shown. Interesting part is the transit. Balazs Varga: Is it a new data plane? Xuesong Geng: Yes. Balazs Varga: But focusing on PREOF. Is there also Service and Forwarding layer? Xuesong Geng: Yes, in the draft this is described. In MPLS can't really separate forwarding from service sublayer until we do device process, but corresponding info from SRH will be there. Nothing like MPLS data plane. Balazs Varga: Major problem is that in transit node we need detnet forwarding sublayer - how to recognize as detnet flow? Based on SRv6 header which byh definition should not be touched by transit nodes? Xuesong Geng: More functions are needed for transit node to indicate this, e.g. a field. In this case only service protection is included, since replication and elimination is the main focus of current draft. After this is accepted, we can go further to other functions such as what Transit node should do. Balazs Varga: But this definition prohibits doing sublayer functions? Xuesong Geng: There is a slide for this (but not part of draft): service protection info is in optional TLV for SRH. There are some special functions to do this, including replication ordering etc. So we need new functions for this. Also need resource allocation, maybe new functions for scheduling or new resource allocation or maybe more metadata or functions. Balazs Varga: But my question is that in SRv6 fields this is something not considered by the transit nodes? Not looking to SRv6 fields at transit nodes, only at next destination. Xuesong Geng: This transit node is not the same concept as in SRv6, it is the DetNet transit node. So it doesn't handle replication and elimination, it is not exactly the SRv6 transit node. Balazs Varga: So it is a new capability of SRv6 transit nodes? Xuesong Geng: Yes, defining DetNet corresponding functions in SRv6 to implement DetNet. Balazs Varga: What about compatibility of existing SRv6 definitions? Xuesong Geng: Yes that is why Lou said we should see what SRv6 people think about this. Balazs Varga: If it is to be a data plane for DetNet, then we need to see how to implement the abstractions of DetNet like Service and Forwarding layer. Xuesong Geng: Yes that is very reasonable, so thank you we appreciate your comments on how to move this forward. Lou Berger: Where are there new SR functions needed? Xuesong Geng: Just in replication and elimination nodes, relay nodes R1 and R2 in the diagram, respectively. David Allen: Does R1 or R2 modify the segment list? Xuesong Geng: No. Just change the outer IPv6 header. David Allen: So you add an encapsulation with its own segment list - at R2 you remove outer IPv6 header entirely? Xuesong Geng: Yes. David Allen: Are there two layers of tunneling here? Xuesong Geng: Only one layer, one IPv6 header is changed. David Allen: But at ingress node, getting to Egress doesn't appear to be there? Xuesong Geng: There is no indication at Ingress to get to Egress - only getting from Ingress to R1. Second part is to steer from R1 to R2. David Allen: So you push an additional header, then at R2 you pop that - where does the info to get to the Egress exist? Xuesong Geng: It is described in Function design - we re-use some info from previous SRH header - e.g. the sequence number and flowID in optional TLV in first SRH. After elimination we put it into a new SRH optional TLV to make up the info between first and second part. David Allen: I still don't get it but I need to go read the draft. Xuesong Geng: Yes please comment. Lou Berger: Anything like this split/merge we have to take to Spring. Xuesong Geng: Yes. Toerless Eckert: There is an SR architecture, so how are we doing DetNet in SR with the ability to support both SR MPLS and SRv6. Some gaps may be different in terms of forwarding plane features, but the architectures should be the same, so we should have a consistent solution. Xuesong Geng: Should be addressed by existing SR MPLS it should be supported naturally by the existing MPLS DP solutions. Toerless Eckert: Is that true for hop by hop MPLS? Stewart Bryant: Is there only ever one SR header which is removed and replaced as go through each stage of PREOF? Xuesong Geng: Yes, in the current design. Stewart Bryant: But you can have arbitrary number of splits and merges - is there an assumption of only one replication at a time? Can your design cope with generality? Xuesong Geng: This is the simplest case. If we do another replication there will be header on header on header, very complex. This was the simple thing. Stewart Bryant: In the next version, take some of the arbitrary various examples from framework draft to make sure they can all be handled. Simple case is easy, need to prove more general case. Xuesong Geng: Yes, please contribute. Balazs Varga: You are talking about point to multi-point to point paths. Regarding controller plane, what does that mean? Xuesong Geng: Not simple point to MP, but we can discuss further how to describe this case. Balazs Varga: This is confusing since using point to point.... Lou Berger: Need to take this to the list, and talk to SPRING chairs. > 10 18:15 10 Title: DetNet Data Plane: IEEE 802.1 TSN over SRv6 > 21 Presenter: David Dai > Draft: https://tools.ietf.org/html/draft-wang-detnet-tsn-over-srv6-00 Xuesong Geng: What is the difference between this work and our work? Our draft was published a year ago, looks very similar to this. I would prefer you put this kind of work on the list so we can be aware of it - I don't see anything new here. David Dai: Yours is about DetNet over SRv6, this is about TSN over SRv6. Janos Farkas: These are both individual contributions, neither are adopted yet here or in SPRING. Maybe these two teams should work together? Xuesong Geng: Yes, this is welcome, but my point is that we have already done this work, and then you publish a different draft saying the same thing, this is not very welcome. David Dai: We can work together, each doing our own research, and I see them as different from each other. Lou Berger: If you have comments on an existing document, please send it to the list. David Dai: OK we can work together through the list. > 11 18:25 10 Title: DetNet QoS Policy > 31 Presenter: Quan Ziong > Draft: https://tools.ietf.org/html/draft-xiong-detnet-qos-policy-02 > https://tools.ietf.org/html/draft-xiong-detnet-qos-yang-02 Lou Berger: What is a DetNet PHB? Are you defining a new PHB for DetNet? In DetNet we have per flow resources, so it is hard to understand the relationship between a DetNet PHB and DetNet per flow resources? This is the same question from the last time it was presented, and I don't think it has been addressed? Quan Ziong: Using Diffserv model we use per class mechanism. Lou Berger: So the only assurances you can provide are class-based? Quan Ziong: Yes. Lou Berger: Not sure how that fits in with the whole DetNet architecture? Quan Ziong: The mechanism has not been confirmed whether we are using per class or per flow. Lou Berger: Still not sure how that fits in with the whole DetNet architecture, maybe it is just me who dosn't understand? Quan Ziong: We need to perfect this, please join us and provide suggestions. Janos Farkas: Not clear to me either. Lou Berger: Need to communicate how this fits in with the rest of the DetNet architecture. Lou Berger: How many have read? Very few. Lou Berger: How many would like to hear more, such as clarification about how this fits in with DetNet architecture? Very Few. Lou Berger: How many would like to hear more about this work? Nobody. Lou Berger: This is not good. You need to take this to the list to help people understand what it is about, or explain it in a different way. Quan Ziong: OK. > 12 18:35 5 Title: TSN Update (if time permits) > Presenter: Janos Farkas (was presented, no comments) > Adjourn 18:35