Minutes taken by: Jouni, Lou Last edit: 8/31/2016 > Monday, July 18, 2016 (CEST) > 18:00-20:00 Monday Afternoon session II > Room: Bellevue > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-detnet? > Video: https://www.youtube.com/watch?v=oOqD9cj96GM > Start Time Information > 18:00 Title: Administrivia & Intro > Presenter: Chairs > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-0.pptx Newly adopted problem statement draft New candidates: detnet dataplane solution alternative detnet architecture document Design team discussions to move to detnet list.. once the document gets adopted. > 18:10 Title: Use cases - update > (18:09) Presenter: Ethan Grossman (remotely) > Draft: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-10 > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-1.pptx > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-1.pdf Ethan participating & presenting remotely. See presentation for details. Concentrating to conclusions from discussions on "use case statements not covered in PS or Arch drafts" as presented in IETF95. Lou Berger: The resolution on providing sync time is not actually as he understood.. Understood that DetNet would support coordinated time across layers? John Dowdell: Link aggregation.. what about adopting some existing work done e.g. in MPTCP? Ethan Grossman: Interesting idea. Norm Finn: Had a different view on traffic segregation.. does not understand what the multicast MAC address to many devices means? Ethan Grossman: Balazs should have more insight. Balazs Varga: Mapping multiple multicast IPv4 address to one MAC address (32 to 1 ratio). Norm Finn: In 802.1TSN every stream requires unique MAC address VLAN combination for the network. The typical way of assigning IP multicast addresses to MAC addresses has the ration of 32 IPv4 addresses potentially for allocated MAC address. Don't do that. (There's 28 bits of multicast IPv4 address space and 23 bit of the available MAC address. ) Xavier Vilajosana: wind farm requirements should be also added in use cases draft. We recently submitted a draft based on analysis of other standards and experimentation. Lou Berger: How many are aware of it? should the requirements of the wind farm be added to the use cases? Some interest. Patrick Wetterwald: related to utility use case. need to check what is the difference to existing requirements what wing farms would bring in. Xavier Vilajosana: we can work on integrating requirement from wind farm to utilities if needed. Lou Berger: proposes changes to the use case document on the list. There is enough support to discuss specifics. > 18:25 Title: DetNet Terminology and Network Scenarios > Presenter: Jouni > Draft: (Based on next two drafts) > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-2.pptx > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-2.pdf Norm Finn: Transport Layer definition is better in the data plane document. Norm Finn: Is the term DetNet defined anywhere (someone asked, perhaps Lou)? Should be in the abstract of the architecture document. Pat Thaler: Prefers Loss Prevention vs. Reliability, because reliability is very broad. For instance reliability can be how many times an equipment fails. Norm Finn: Loss prevention has much less existing baggage. Lou Berger: [Polls the room] Support for loss prevention, no objections. Janos Farkas: Do you plan to move the bottom diagram on page 4 go to the architecture document. Jouni Korhonen: Maybe, will revisit/consider. All the information in the dp-alt page 4 figure are in the architecture document in some place/form. Norm Finn: One could fold whole dp-alt into architecture document, which might not be a great idea. If anything that needs to be moved is the figure (on page 4). Needs to be discussed among the authors. One term that was there before but was taken out is transit edge node. Needs to be discussed whether we need that still. Subir Das: If we use loss prevention, need to define what DetNet loss means. Pat Thaler: What about other terms. Jouni Korhonen: Only non-obvious ones discussed. 1/6: basically merge text 2/6: basically merge text 3/6: Will use "Edge Node", merge text. 4/6: see loss prevention above. 5/6: merge text. Norm Finn: Great off-line talks with Balazs and Janos (so not everybody was participating). Norm Finn: Key function of relay's is stitching of DetNet service over different transport layers. 6/6: see above (5/6). Lou Berger: actions are for authors to update their documents respectively, with Architecture draft as main location for definitions. > 18:50 Title: DetNet Architecture > Presenter: Norm Finn > Draft: https://tools.ietf.org/html/draft-finn-detnet-architecture-06 > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-3.pptx > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-3.pdf Subir Das: assumption is that there are multiple paths available? Norm Finn: for some services yes (loss prevention). If only congestion based loss is of interest then one path works. Subir Das: what about retransmissions? Norm Finn: Not considered. Many of the applications we have would resolve to too much latency. Retransmission would be too late, you do not need the information any more. Pat Thaler: Deterministic by certain time bound. Subir Das: If within the time bounds is it still allowed? Lou Berger: A node could ask for a detnet service and run TCP on top of it.. might not be useful though. Norm Finn: Not considering it as a prime candidate to achieve the detnet service. Lou Berger: When talking about detnet and detnet layers TCP is not going to be there. Pascal: Wireless typically includes layer-2 ACKs. Scheduled retransmission are sometimes possible. No need to wait for timeout. On some wireless technologies it is possible to have 2-3 retransmissions. Norm Finn: There are medias that provides ACK/NACK service at very low level (802.11 as an example). There are probably cases where those can be used by detnet. Subir Das: Takeaway is that on the detnet layer we are not talking about retransmissions or ACKs. The underlying layers can support it, though. One problem is that the lower layers may keep up retransmitting, which then shows in DetNet layer if there is only one path. Norm Finn: That winds up to delay variance. Greg Mirsky: there are ways to degradation of service. That would be part of the OAM discussion. Norm Finn: Four open issues: see slide 8. Norm Finn: Can DetNet help in wireless? Architecture/DetNet does not spend time too much on wireless. 6lopan/6tsch/etc are already on this. Lou Berger: What is preventing adoption? In addition to terminology? Norm Finn: None. Tim Chown: Like where this is going. Wireless will be challenging environment. Lou Berger: Does not expect DetNet spending much time on wireless.. in this WG. Norm Finn: Update will be published late this week > 19:15 Title: DetNet Data Plane Protocol and Solution Alternatives > 19:09 Presenter: Jouni Korhonen > Draft: https://tools.ietf.org/html/draft-dt-detnet-dp-alt-01 > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-4.pptx > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-4.pdf Plan: one update then ready for adoption. Poll: How many have read How many think this document is a good foundation for the WG? Are there any objections, assuming discussed changes are made Jouni Korhonen: Update after norm's update of the architecture doc. Estimate one week after the publication of the architecture draft. Lou Berger: will start IPR polls on both documents in anticipation of updates. > 19:40 Title: DetNet service model > 19:24 Presenter: Balazs Varga > Draft: https://tools.ietf.org/id/draft-varga-detnet-service-model-00 > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-5.pptx > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-5.pdf Lou Berger: There may be good existing work on PseudoWires that can be leveraged in the description of DetNet services. Balazs Varga: Absolutely.. just ran out of time for this version. Jouni Korhonen: How do you plan to align terminology. There are many new terms that are specific to service model draft. Balazs Varga: some terms are specific to service model.. There are two actions on terminology. Align with terms and refer to them which are used in arch and data-plane drafts. Define service model specific terms (not used/needed in arch and data-plane and achieve consensus on them. Lou Berger: not comfortable defining an internal interface to a node. Ok to have a conceptual model but not enforcing the implementation. Concentrate on how to represent something the on-wire but how they (nodes/interfaces) achieve that is their own business. Balazs Varga: yep. Norm Finn: At the lower layer there is an interaction between DetNet stuff and the other (not necessarily best effort) stuff. It is up to the subnet lower layers doing that stuff.. Lou Berger: It has to fit in out architecture models and we need to discuss the coexistence. We do not expect having DetNet layer queuing that is orthogonal to or on top of interface/link layer queuing. Greg Mirsky: within a DetNet domain there should be service consistency. Lou Berger: Sure. How a vendor chooses to implement is their business. What needs to be interoperable and goes on-wire needs to be standard. Greg Mirsky: How to interoperate? Lou Berger: On-wire format and behaviours that need to interoperate (external interfaces) need to be standardized. Greg Mirsky: Then there will be some gateway that interacts at the control plane level? DetNet will have its control plane that instantiates the data plane state. Lou Berger: I think we are in agreement that external interfaces need to be standardized. > 19:50 Title: DetNet flow information model > Presenter: Yiyong Zha > Draft: https://tools.ietf.org/id/draft-zha-detnet-flow-info-model-00 > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-6.pptx > Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-6.pdf Yiyong Zha: Demo in bits'n'bytes on the data/info model mapping. Info model mapping to data model and then that data model to actual (simulated at this point) data plane hardware. Pat Thaler: On the info model.. I do not see a model where one put what service the flow needs, like "I need this latency" etc. Yiyong Zha: Service attributes.. trying already mapping that into requirements. Tim: limited traffic means limited number of flows? Pat Thaler: I think he means limited by bandwidth. Tim: For a given reservation are the IP addresses and MAC addresses allowed to change? Yiyong Zha: Now everything is user specific and recognized by a MAC address. Tim: Needs to consider that over time the addresses might change but there is still need for the same service. > 20:00 Adjourn > Notes taken by: Jouni