Minutes for IETF97 DetNet Version: 12/8/16 TUESDAY, November 15, 2016 0930-1200 Morning Session I Room: Park Ballroom 1 Slides: https://datatracker.ietf.org/meeting/97/session/detnet Jabber: https://www.ietf.org/jabber/logs/detnet/2016-11-15.html Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-97-detnet YouTube: https://www.youtube.com/watch?v=LARsZvZpe30&list=PLC86T-6ZTP5gtLuoSjpTGO_mS5Ly2pfIS Audio: https://www.ietf.org/audio/ietf97/ietf97-parkballroom1-20161115-0930.mp3 Note takers: Jouni K. Carsten Borman is the jabber scribe. > Start Time Information > > 09:30 Title: Administrivia, Intro & WG Status/Deliverables > Presenter: Chairs Agenda bashing IPR discussion: Lou recommends to not over load a draft with IPR uncumbered text nuless really necessary Yang model: Pat recommends to start thinking about Yang WG status: chairs give a startus, Use cases going on well. We are behind milestones, not too bad but need people to contribute > 09:50 Title: Use cases - update > Presenter: Ethan Grossman > Draft: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-11 New section on windfarm example to utilities use case in -11. To be discussed security. Need to be covered. 9:40 Ethan on detnet use cases - current draft is 11, includes windfarm use cases - misc discussions on the list - want to kick of security discussion Recent topics: - latency matching, not conclusively decided - availability in tems of 9s, seems to be a per flow basis question, how does the network expose that? - migration path to DetNet? Ethan presented DetNet in AVnu. - Questions on migration plan to DetNet from the existing. Actually for pre-AVB technologies to DetNet. Security - Ethan talked to Andrew J Hacker, who reviewed draft and made recommendations (laundry list) - Ethan expects comments from the group for handling these items; long list in slides, can't go through everything now - Ethan proposes next steps; per technology, "CIA" principle - Should we have a separate security document? Does logical segmentation (slicing) affect the behaviour of non deterministic traffic? - Effects of algorithms on reliability. Do extra paths affect the way malicious packets can be injected? - logging is often used a secruity tool. What should DetNet log? DetNet Security strategy: don't break security. Consider using "CIA" principle: conf/integ/availability. Question whether there should be a DetNet security document? Not every solution requires same level or type of security. Development Process - security validation for certification? - How much this belongs to DetNet? Work with AVnu on these aspects? Impact on boot time? Janos Farkas: - coexistence of L2/L3; in charter we have a common architecture; are you talking about a migration AVB to DetNet? Ethan Grossman: - intention was migration from non detnet (RTP/IP) to detnet. Carsten Bormann: has anyone written a threats document? Ethan Grossman: nope. Lou Berger: Did you just volunteer? Carsten Borman: Maybe. Does not now yet who you are afraid of.. needs to look into use cases. Lou Berger: Look into use cases to find out common threats. what are the commn threats across use cases Deborah Brungard: in IESG security ADs put few lines into the charter to look into security. John Downdell: impact of threat; can make general suggestion for system integrators; they have to do their own assessment, their own security analysis, falls down to money. What is the operational impact? Is the equipement going to go wrong? what are you willing to put on with because you can't afford to fix it? Need to take a holistic view of a system. Ethan: Pat Thaler: with brcm hat on. it is important to pay attention to security and where exposures are. Ideas how to mitigate them. Lou Berger: useful to add a desription how system level security goes down to technologies. This should be part of the architecture document. would be good to capture some of that. John Downdell: need to have a list of things integrators should pay attention to > 10:10 Title: DETNET crosshauling requirements > Presenter: Carlos Bernardos > Draft: https://tools.ietf.org/html/draft-bernardos-detnet-crosshaul-requirements-00 10:05 Carlos presents backhaul/fronthaul convergence, looks for missing items in the fronthaul use cases to enable that convergence The presentation content very close what is already in use cases document Section 6. Crosshaul is an UE 5G project looking into converging backhaul and fronthaul networks. Also fronthauls flows with different functional splits (a split resolves to different traffic profile, latency etc requirements). Similar activity also done in EU project 5G-XHaul and iCirrus. Use cases does not currently discuss multi-tenancy and transport+energy efficiency. Performance requirements for latency and packet loss from IEEE P802.1CM Found difference in joined back/fronthaul operations and multi tenancy, will suggest contribution to the use case draft Jouni Korhonen: sure, you are welcome to help fix the missing parts. Carlos Bernardos: will send text in coming weeks to the list > 10:20 Title: DetNet Service Model > Presenter: Janos Farkas > Draft: https://tools.ietf.org/html/draft-varga-detnet-service-model-01 10:10 Janos presents the service model, ork with Balazs Varga, looking for feedback Goal to clarify the service model, reference points, service components, naming Janos elaborates on content. 3 Types of flows are distinguished - app flows: native format, does not express DetNet signaling - DetNet-S-flow: adds service layer attributes to app flow like flow Id and Seq num - DetNet-ST-flow: add transport layer attributes to DetNet-S-flow. Janos refines on the end systems capabilities; depends on end system capabilities/awareness. "End systems" are fully aware and part of the detnet domain. Janos details the references points in the network Janos presents the enhancements of the L2 queeing architecture over the last 10 years. Lots. Q: how does that show at L3? In particular integrating time based scheduling Lou Berger: where do you think we should take this document? Janos Farkas: would be good to have a WG for the service model, and the flow information model Pascal Thubert: should some of this be merged with the architecture? since this document defines reference points and such. Lou Berger: a reasonable point to think about. Path Thaler: there is a desire to have service points at some place (e.g, in the architecture). Lou Berger: information flow needs to be a separate document. Lou Berger: having a seprate service document is not something that was originally in mind. Jouni Korhonen: some information is very useful, e.g. queueing at L2. For me not all parts are equally useful. Ning Zong: Some pieces are related to architecture Yuanlong Yang: thinks this is useful. What the exact sense between the service model and transport layer(???) . Lou Berger: how many people thing that working on service models is important to the group? Pat Thaler: Some confusion as to what service model means in this context. To me a service model is something lower layer offers to higher layers. This happens at every layer. Lou Berger: I agree, and think that some of the confusion is on what the doc is doing. Maybe move parts to architecture or other WG documents. Finally look at the information flow as a separate piece of work and may be easier for the WG. Pat Thaler: Do this before the next (meeting) and we can discuss further. > 10:40 Title: DetNet Data Plane > Presenter: Jouni Korhonen > Draft: None > Background: https://tools.ietf.org/html/draft-ietf-detnet-dp-alt-00 10:40 Jouni on the detnet data plane document; reminds some history of the work. Document was stable recently, brings attention to a set of solutions. Jouni presents options, PW over MPLS, PW over IP, or RTP/UDP/IP How many options do we choose? Can only fot all use cases? Should look at 2 problems and see if we can do it all with that. Need to - interwork L2 and l3 QoS mechanisms Going down the services in details 1 end to end, homogeneous detnet, IP based servic 2 interconnect 2 TSN islands, extending the L2 domain over L3 3 Network Service translation inside the core, TSN at the edges 4 TSN end point to DetNet end point interworking Need to take care of - flow ID - packet sequence within flow for replication elimination, in-order delivery - timing information PW was identified as close to the need. Jouni shows the feature mapping. Packet formats are mostly there, need service semantics. Missing Replicaiton and Eimination semantics. Better have a unified detnet encapsulation. Jouni's opinion is that options are painful. Looking at the stack of headers and cost of encapsulation Lou Berger: Pointing out we are not chartered to the transport above detnet headers for the native format (that's another area!) though we are for the interconnect case Services 1 and 2 are low hanging fruits, protocol mapping in services 3 and 4 have additional complexities Yuanlong Yang: what is te definition of the service? IP or ethernet? whzt the relation between detnet service and PSN service? Janos Farkas: just presented that Jouni Korhonen: detnet is neither IP nor Ethernet; we need to support both Lou Berger: DetNet use case is different from TSN since we have multiple domains with routing in between. We also have a native service that lives without TSN Yuanlong Yang: I cannot distinguish from ethernet. Pat Thaler: the headers will tell; Pat Thaler: It's the difference between layer 2 and layer 3 service. Lou Berger: DetNet delivers an IP based service operating over whatever technology we have. We build L2 VPN over DetNet to transport TSN. Yuanlong Yang: PE to PE is one thing, but PE to CE must be defined. Maybe terminology? Ning Zong: say I build e2e IP service. Without support from L2, how can we achieve this? Lou Berger: we expect layer underneath to implement the right thing. Might be a TSN service, might be MPLS service... We are not solving/inventing everything here, we leverage underlying technology. Pat Thaler: How to translate that work into a Data plane solution draft Jouni Korhonen: propose to reincarnate the DT and incorporate new faces to write the solution draft. Lou Berger: people may come in and others may drop off; calling for candidates to the new team. John Downdell: maybe show examples to prove it's doable. > 11:20 Title: Deterministic Networking Flow Information Model > Presenter: Yiyong Zha > Draft: https://tools.ietf.org/html/draft-zha-detnet-flow-info-model-04 11:17 Yiyong Zha on flow information model draft update. Q: What are the needed attributes? - flow information for data place - flow information for control place (PCE) Janos Farkas: I commented on draft 1 that it is not useful to start this frmo scratch. there is work in 802.1Qcc on the radar for AVnu that defines flow models;444 Recomments to look int IEEE 802.1Qcc what has been done already. Pat Thaler: To control deterministic latency to the point needed here, behaviours obtained with token bucket and leaky bucket are not precise enough. We had to go to other mechanisms for latency sensitive applications > 11:30 Adjourn >