DetNet Minutes IETF99 (Prague) > > Session 1: > THURSDAY, July 20, 2017 > 0930-1200 Morning Session I > Congress Hall I > > Slides: https://datatracker.ietf.org/meeting/99/session/detnet > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-detnet?useMonospaceFont=true > Meetecho: http://www.meetecho.com/ietf99/detnet > Audio stream http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u > Jabber: xmpp:detnet@jabber.ietf.org?join > > Available post session: > Recording: https://www.ietf.org/audio/ietf99/ > YouTube: https://www.youtube.com/watch?v=rrqVLyJCfvk > > Num Start #Min Information > 0 9:30 10 Title: Intro, WG Status, Draft Status > Presenter: Chairs Question for discussion by WG, ready for last call on Arch draft? Use Cases mature but no rush to close door, new use cases coming in, old ones still under discussion. At some point need to ship it. Not critical for near term. Once not rev'd for a while will call it done. Will do last call on (which one?) Completing dataplane alternatives is not too critical. It was helpful coming up with the dataplane solutions draft. Security draft on the agenda, would like to ask if ready for adoption. > 1 9:40 15 Title: DetNet Architecture > Presenter: Norm Finn > Draft: https://tools.ietf.org/html/draft-ietf-detnet-architecture-02 No substantial change since March'17. Just clarifications etc. Arch doc - remove sec 5 on ideas that didn't make it. Then ask for WG last call. Everyone should look over it, meanwhile do removal as planned. If removed text is a problem, please propose text on how to resolve. Pascal Thubert: Wireless is experimental, too early to put in this draft, so not working on it Lou Berger: (poll) How many have read this version: a good number How many have read other versions: also a good number How many think ready for LC: also a reasonable number Lou Berger: Once planned update is publish will move towards last call, so please read and send comments and proposed text to the list. > 2 9:55 30 Title: DetNet Data Plane Encapsulation > Presenter: Jouni Korhonen > Draft: https://tools.ietf.org/html/draft-dt-detnet-dp-sol-01 Stewart Bryant: Would be good if had a unified approach that could then be adapted to the underlay only once. Jouni Korhonen: Last time got feedback that encapsulation was nogo due to not being done that way before. Stewart Bryant: Will need more discussion, particularly if need new HW Lou Berger: Tradeoffs - I personally agree that it's unfortunate to not have a single encapsulation, but the elimination of PWs on end stations makes their stack support of DetNet easier. I also agree that it needs to be consider further once WG document. Stewart Bryant: Look forward to have the discussion around adoption. Norm Finn: Much of the focus on the data plane docs has been on sequence number defined needed for PREF. Not necessary for hard partitioning (zero congestion, fix latency) doesn't need serialization. Maybe thus more flexible in terms of encapsulation? Some applications that don't need serialization might be easier. Stewart Bryant: Is simpler design that works for "most" applications better? Lou Berger: Separable between flow ID and encapsulation. Two building blocks. Greg Mirskey: Is PW an Ethernet PW? There are different types of PWs. Jouni Korhonen: Yes, typical Ethernet PW. Greg Mirskey: Usually no seq number in Ethernet PW? And many implementations don't even implement control word. Jouni Korhonen: Assume we always have a control word, if HW doesn't support it, too bad. If want PW device to be DetNet capable won't be available off the shelf, will need to adapt it. Thus we are brave enough to take this step. Lou Berger: Said another way if hardware doesn't support the protection function, serialization isn't need. Pat Thaler: Old HW won't support DetNet timing requirements, so probably can't do DetNet over old HW. Also, it is important to support control work in general - w/o it can't distinguish bet IPv4 vs v6. Stewart Bryant: Old HW didn't support control word (CW) so would be new implementation. Encouraging people to put CW in for reasons suggested by Pat. Expect all new hardware to support the control work. Sequence number is an option, but don't think any have implemented it. Pat Thaler: Packet Replication and Elimination Function (PREF) has been part of DetNet since the start. It is necessary for some of the use cases and requires serial numbers. Norm Finn: The detnet goal is to do PREF, need serial #. The goal of DetNet is not PWs. PW was handy place to find serial numbers. IF some don't do Lou Berger: This is a good point. We have a requirement to define a function, not use PWs. If WG decides on a different path, e.g., EPVN-based encapsulation, than this is a fine direction if this is WG consensus. Jeff Tantsura: Must reference different draft (EVPN VPWS). Also control word not mandatory, used if not entropy label (?). May consider making it required. Lou Berger: this is good feedback for WG adoption. Deborah Brungard: Speaking as AD, use of control word is fine for this new functionality. PALS will have strong statement about bad things if no control word, so can expect to have control word. There is concern on the design team work, it's time to being this work to the WG and consider it or individual drafts. Need to go forward. Lou Berger: This is a good point, there are no other contributions for DetNet data plane. If hashing out solutions, we should do this in the context of a WG document. Jouni Korhonen: DT doesn't want to continue as DT, ready to move to adoption and see if serves as solid base for further work. Lou Berger: Remember, adoption doesn't say this will be RFC, says this is what WG will start with. Greg Mirsky: Doesn't adoption mean that we've agreed with the technical solution. If don't feel e.g. PW is correct technical solution, do we adopt? What does adoption say? Lou Berger: It says this is the starting point for the documented WG solution. Again, we don't have alternative documents to start so there is no choice. Stewart Bryant: Invitation for alternative proposals Lou Berger: Yes, this invitation has always been open. Stewart Bryant: Need open discussion not closed meetings with reporting. Lou Berger: DT archives open. Can discuss any document on mailing list. Eric Gray: In most WGs once DT has been appointed, worthless effort to do alternative designs. Lou Berger: But individuals can always produce individual draft, will be considered/integrated. Eric Gray: This isn't the case in many WG. : we've seen this happen in other WGs Jouni Korhonen: can we move forward? Shahram Davari: If objection for PW is that CW not used. The RFC has control word. Objective is minimum change in standards. Don't need to create new standard. Lou Berger: Do you need control word if don't care about protection function? Jouni Korhonen: No. But less options the better, would prefer it to be required. Stewart Bryant: Get a lot of things if keep control word. Legacy HW is the only argument against. But think should always be there. Andy Malis: As PALS co-chair, we're making CW mandatory in PALS WG, should be mandatory here also. Greg Mirsky: Need CW since transit nodes doing caching, without CW might be incorrectly parsed. Must have CW. First label critical. Lou Berger: Keep in mind whether data plane functions are captured in Arch doc. For example, is resource hierarchy/aggregation covered? Jeff Tantsura: EVPN active-active could be used to provide resiliency Greg Mirsky: Confused by IPv6 using underlying v6 structure. Lou Berger: Both V6 over detent and detnet over v6 are supported. Flat TSN domain is single Ethernet domain. Greg Mirsky: in detnet v6 over TSN there is nothing to be done Lou Berger: there still is service mapping Norm Finn: Is laid out in Arch and data plane drafts. Use cases: one use case is interconnecting TSN domains w/L2 connectivity. To make large, need routers. Is in the documents. Alexander Patrescu: IPv6 - need to connect TSN link to 802.11 link. Can flows be guaranteed for WiFi? Lou Berger: Would be interesting to see how to do this in a future draft. Please contribute! Norm Finn: As Pascal pointed out, wireless (particularly WiFi) is less deterministic. We don't know how to do that - if you do, let us know. Jouni Korhonen: Time for WG adoption! A good basis, not complete, sufficient to go forward. The DT feels the document is a solid foundation to move forward. Lou Berger: As there are no other alternative proposals and that this is a product of a DT, we would like to start a WG adoption poll on the list. As part of this call, we would also like to collect issues that will be addressed in post-adoption versions (i.e., post -00) of a WG document. Are there objections to this approach. Stewart Bryant: We should follow classic call for adoption and expect alternatives to appear soon. Greg Mirsky: Often see humms then adoption on list. Agree w/ Stewart - just on the merit of this draft, and if there will be other documents there will be other documents. Deborah Brungard: Could state in various sections that it is a proposal not a final decision, and to make clear that the content is under discussion. This would allow others to provide input to merge in later. Lou Berger: We put multiple proposals in a single draft. Rev draft -00 to identify issues in a -01 draft sounds like a good way to capture issues identified during adoption. Stewart Bryant: Not just sequence numbers that are a concern. Adoption usually implies buy-in of technologies, there are areas that I have reservations on and have not been debated in the WG. Lou Berger: Such concerns can be included in the draft, section by section, then addressed as part of WG process. Anyone who looks at the draft will immediately see which sections have open issues. Eric Gray: I agree with Stewart, if issues aren't in draft 00 people who only look at drafts will get the impression that this is the direction. Suggest respin individual draft first. Stewart Bryant: can ask for issues to be identified with draft, then respin individual draft including the issues, then ask for adoption Greg Mirsky: I like this proposal. Call for comments on current version. Identify ones that need to be integrated before adoption, then call for adoption. Lou Berger: We will do this and call it a two stage WG document. Eric: WG chair said after certain issues have been addressed will call for adoption. Lou Berger: While not the norm, we will do a two-stage adoption call on the document, the first stage will be to collect issues *and* to add them to a rev of the *individual* draft. Then conduct a normal adoption call. > 3 10:25 20 Title: DetNet Flow Information Model Based on TSN > Presenter: Balázs Varga > Draft: https://tools.ietf.org/html/draft-farkas-detnet-flow-information-model-01 Lou Berger: How many have read this doc? Before discussion of adoption, hear next talk by Mach. > 4 10:45 10 Title: Considerations for Flow Information Model WG document > Presenter: Mach Chen > Draft: Greg Mirsky: If use node scope performance metrics, how do we do this. What metrics do we need? Maximum values? Other? How are they obtained? Mach Chen: Use Maximum, since DetNet guarantees worst case. Greg Mirsky: How is latency measured from node? Maybe different discussion. Dean Bogdanovic: Likes grouping shown for information model. Good to keep same for lifecycle of draft. Are these all we need, is the more? Lou Berger: Matches what IETF has been doing for many years, these same 3 blocks. Perhaps with slightly different names. Karl Weber: What do you mean by centralized in this context? the Internet? Overlapping? Mach Chen: Borrowed from TSN, centralized model. Mostly about how to use. János Farkas: We are talking about single admin domain, not big-I Internet here. Lou Berger: Not covering control in this WG yet. This is a reference model, not a requirement or plan. Control plane is currently out of scope. Karl Weber: So this is documented in the drafts? Lou Berger: Yes, in the architecture document Jeff Tantsura: So would you map in to the TE (yang) work in TEAS. Another option is L2SM. Mach Chen: Yes. Lou Berger: (to Mach) Are you asking for the issues you raise to be handled in the individual draft or in a future WG draft? Mach Chen: We're open to either. Lou Berger: Moving on to draft-farkas-detnet-flow-information-model-01: How many would like to see the -01 draft adopted now? . How many would like to see it improved, e.g., by incorporate Mach's topics first? No clear indication from the floor. János Farkas: How do we proceed? Lou Berger: Discuss on list. Don't wait for chairs on this. If you have text on these ideas, bring it. Given the lack of response from the room need to talk to co-chair on next steps. Perhaps adoption call, perhaps not. > 5 10:55 20 Title: DetNet Security Considerations > Presenter: Tal Mizrahi > Draft: https://tools.ietf.org/html/draft-sdt-detnet-security-01 Lou Berger: Poll: Should we have this type of document? How many have read it? How many would like to see this as a foundation? we will take [adoption] to the list. Pascal Thubert: Be realistic about impact - DetNet is intended to support physical systems in the real world. So if flow doesn't go through, machines can break, people can die. Lou Berger: As part of the adoption call, if you identify any issues you want addressed or text you want added, please send comments to the list. > 6 11:15 15 Title: Implementation Report: DetNet Data Plane Protection > Presenter: János Farkas > Draft: https://tools.ietf.org/html/draft-dt-detnet-dp-sol-01 Pascal Thubert: Did similar demo in 6Tisch. Can miss a single packet, but not a certain number in a row, so for many control applications this is a good technique. János Farkas: Single link is broken for this demo. Jeff Tantsura: How many packets can you lose before you switch over? János Farkas: Any lost packet is switched, so no packets are lost. Lou Berger: Classic 1+1 hitless protection. János Farkas: Must keep track of sequence numbers (state) Kiran ??: Out of order seq numbers? Assume incorrectly lost a packet? János Farkas: Can handle this, but must keep track of delay on paths, etc, as spec'd in the draft. ?: Out of order packets? If need to be ordered, must buffer. János Farkas: Can handle this, somewhere you need to buffer. Norm Finn: IEEE 802.1CB ready to be published. Covers these kinds of questions. Some are more expensive answers than others. Can share URL. > 7 11:30 30 Title: 802.1 TSN Summary and Discussion > Presenter: János Farkas, Pat Thaler, Norm Finn > Reference: http://www.ieee802.org/1/pages/tsn.html Lou Berger: Doing shaping after replication? Are there 2 shapers? Norm Finn: Not necessarily in that order, don't read too much into it. Pascal Thubert: Used for constant bit rate? But transport/network may put into different packetizing, e.g. 1 512 vs 2 256. Broken into deterministic-friendly blocks? Lou Berger: Maybe beneficial for DetNet to provide transport protocol. Pascal Thubert: Thinking of problem not solution. CBR traffic may be broken into uneven size packets? Lou Berger: Do we need to talk to someone in the transport area? Must be solved for users, IETF is the right place. TSN can inform out process here. János Farkas: These slides are TSN only, as input to what we do in DetNet. Pat Thaler: Mac logic/state is duplicated, but not a separate address. John Dowdell: Any open source for TSN? János Farkas: The demo code is our own, not open source. Lou Berger: Will start phase 1 of data plane solution adoption process, so please send comments to the list. Lou Berger: Also likely to start adoption of Info model (as forcing function). > Adjourn 12:00 Note takers: Jouni Korhonen (remote) Ethan Grossman