Minutes for DETNET at IETF-94
minutes-94-detnet-2
Meeting Minutes | Deterministic Networking (detnet) WG | |
---|---|---|
Date and time | 2015-11-02 00:00 | |
Title | Minutes for DETNET at IETF-94 | |
State | Active | |
Other versions | plain text | |
Last updated | 2015-12-10 |
minutes-94-detnet-2
DetNet WG Monday, November 2, 2015 (JST) 9:00-11:30 Monday Morning session I Room: 301 Video: https://www.youtube.com/watch?v=ChsKCMaG6UU Audio: http://www.ietf.org/audio/ietf94/ietf94-room301-20151102-0900.mp3 ** Administrivia & Intro, WG organization & milestones Presenter: Chairs Slides: http://www.ietf.org/proceedings/94/slides/slides-94-detnet-0.pptx Lou Berger: The charter will probably not be discussed very much in the future, but since this is the first meeting it is important to go over it. Eric Nordmark: Is it a significant constraint to have compatibility with 802.1? Lou Berger: DetNet is going to run over multiple layer-2 technologies. 802.1 is one example. Norm Finn: It is possible that the constraint came from the existing 802.1 standard, multicast MAC address. That needs to be discussed. Eric Nordmark: So there will be some mapping enabling it to run on a subnet technology. Pat Thaler: Once we have a problem statement and requirements draft, this will become more clear. Lou Berger: Document milestones for Use Cases and for Problem Statement adoption are pretty close, because of discussion during BoF. That does not mean that the WG agrees on the content of those documents. But we do not yet have a good starting point for the Architecture document. Greg Mirsky: Is OAM part of the discussion? Lou Berger: Yes. The group may decide to run it in parallel. Greg Mirsky: This is important for the architecture document. Lou Berger: Please contribute a document if you have something. Norm Finn: Would love to hear proposals for OAM. Shahram Davari: is time synchronization part of the data plane? Lou Berger: authors will decide what is most convenient. Shahram Davari: is traffic management part of the charter e.g., pre-emption etc? Lou Berger: Without commenting on the specific items, we will need to agree on and identify all detailed functions that are not called out on the charter, and the problem statement draft seems like a good place to do it. Pat Thaler: Some things we will leave to the date plane, for example (frame) preemption Pascal Thubert: Lou Berger: discussion about administrivia, web pages, use of mailing list, etc. IPR disclosure required before WG adoption. Although not part of IETF standard policy, we will poll the group for IPR before document WG adoption and again before WG Last Call. ** Consolidated Use Cases Presenter: Ethan Grossman Draft: http://tools.ietf.org/html/draft-grossman-detnet-use-cases Slides: http://www.ietf.org/proceedings/94/slides/slides-94-detnet-1.pptx Ethan Grossman: <from presentation> Believes doc is ready for adoption by WG. The use cases are the same as were presented at the last IETF. Draft currently a collection of use cases, not merged. Needs rework, more use cases from industry. Quickly goes over uses cases described in the draft: real time audio, utility networks, building automation system, wireless sensors/actuators for industry, radio access networks. Lists the common characteristics of uses cases, called Use Came "Themes" Charles Perkins: your slides said Ethernet. 6TiSCH uses 15.4, which is not Ethernet. Lou: this is use case document. Users listing what they want. Charles: can this lead to multiple requirements documents? Lou: It's not our current expectation to have a requirements document. We do expect the use case document to cover what the users are interested in, whether it be 802 or 6TisCH. The Problem statement will need to cover all use cases. Charles: current uses cases are broad. Lou: commonality list is important. Important to list what is common and what is not. Pat: important to serve a variety of Layer-2 technologies. Norman Finn: 99.9999% availability. Some potential users even said twelve 9's! Samita Chakrabarti: 6TiSCH provides reliability/determinism, but we should provide reliability to other constrained device networks. Lou: DetNet not tied to a specific link technology. Samita: IPv6 over BlueTooth (BT) is already in RFC (RFC7668) but it is not deterministic. Pascal: 6TiSCH has a MAC layer that is deterministic. Bluetooth doesn't as it is today. Samita: BT might develop a deterministic technology in the future. Lou: whatever we develop here, we should be able to apply to such Layer-2 Technology. Pat: to get best result some Layer-2 support needed. Subir Das: question to the chairs: expected outcome of this group is how to map DetNet on various Layer-2 technologies. How many of them do we want to address? Pat: we are contribution-driven. At this point, 802.1TSN and 6TiSCH. Lou: Those 2 technologies are enough to get started. If a 3rd comes along, rather early than later. Subir: ?? Lou: our work not specific to a few given technologies. Subir: ok, can't expect to work across all wireless technologies. Pat: a lot of wireless technologies that 802.1TSN applies to anyway. Norm: TSN not tied to any specific link technology. Applicable to .11, .16, etc. Pascal: the two Layer-2 tech are quite extremely different (bandwidth, low-power), the hope is anything in the middle will be covered as well. Liang Geng: many overlap with use cases that are also discusses elsewhere, for example, in NGMN. Categorize also based on 5G interests. You are still accepting contributions/use cases. Lou: we are contribution driven. Pat: New use cases can be added if there are contributions. Lou: asking whether the document is ready for adoption? How many has read the document? Reasonable number (a dozen?) but not huge. Who thinks this is a good basis for a WG document.. same number of hands. If you have concerns bring them to list. ** Problem Statement Presenter: Pascal Thubert/Norman Finn Draft: http://tools.ietf.org/html/draft-finn-detnet-problem-statement Slides: http://www.ietf.org/proceedings/94/slides/slides-94-detnet-2.pptx Currently in version -04, believed to be "mature". Discussion about the scope (geographical size) of DetNet work, answering Alia's comments during chartering work. List of requirements, please comment back. Draft contains description of related technologies, please contribute if you know one that was left out. Most use cases have complex optimization problems. Controller-based approach is needed. Some text also allows for distributed approach. Tried to also spell out what's not in scope. Specifically time sync not in DetNet scope. That is done in other groups. Dan Romascanu: these pieces of work are interrelated, please also describe dependency to external pieces of work. Pat: pertains to arch document, not problem statement? Pascal: MAC needs to have features so that DetNet can use them. David Black: <Pascal resumes presentation> Draft assumes some sort of architecture, mostly controller based. Application expresses requirements controller computes paths, install state in the network. Norm: would expect no more than one controller in the network, or at least a port not responding to more than one controller. Lou: this presentation is problem statement, Norm's comment applies to arch document. Lou: this problem statement draft has architectural considerations. We need to draw a line. Pascal: problems actually depend on architectural choices. Subir: not sure all the problem areas Pascal has listed need be solved in this WG. Lou: reiterates problem statement vs. architecture split. Lou: if interested in discussing these documents or want to contribute, stick around at the end of the meeting. Unidentified person: What about PCE? TEAS? Lou: if work outside IETF, we do liaisons. ** Architecture Presenter: Norman Finn Draft: http://tools.ietf.org/html/draft-finn-detnet-architecture Slides: http://www.ietf.org/proceedings/94/slides/slides-94-detnet-3.pptx One of the co-authors is Michael Johas-Teener is the chair of ieee802.1TSN TG. Norm states objectives. Not trying to re-invent networking. Number of technologies out there that provide solution under some assumptions. Improved -02 version of draft is out. Key aspects of architecture: reservation, redundancy, defense (against misbehaving talker/bridge). Our applications sensitive to delay: new sort of attack, but same nature as .. Norm Finn: man-in-the-middle cannot be stopped from inserting time delays. Emmanuel Baccelli: looks like magic is needed to solve scalability + zero congestion loss+... Norm: provides detailed example of solution. Admission control assumed, of course. Norm goes over list of issues: shapers, schedulers? Diffserv, Intserv? Techniques for stream ID, QoS, pinned-down paths? Allow for distributed reservation mechanism? David Black: Diffserv not enough, need to check at the edge. Norm: absolutely, even defend at the edge against unwanted traffic. Lou: some of this document is redundant with use case and problem statement documents, will need to be sorted out. Provides one candidate architecture. May have other proposals. Unidentified person: do we need a set of candidate architectures instead of one? Norm: need broad applicability. However, some form of reservation by the application is a pre-requisite. Choice of mechanisms to achieve that. Norm: come with any technology that can help, FEC, etc. Pascal: even if you don't use centralized controller, many pieces still useful. Greg Mirsky: missing, some kind of feedback mechanism. Including all the way to the application. Misbehaving middle-boxes, for example. Norm: 802.1CB and CI has provision for raising alarm if not throwing away expected portion of packets on replicate paths recombining. This is example of such feedback. Norm: certainly designed against link failure. Greg: not talking about solutions. Arch document should have statement about it. Seems this piece is missing. Rich: plan for changes during operation of network, dialog with applications needed. Behcet Sarikaya: problem, no pictorial architecture in the draft. ** Data Plane Kickoff Discussion Presenter: Jouni Korhonen (remote)/Shahram Davari (local presenter) Draft: none Slides: http://www.ietf.org/proceedings/94/slides/slides-94-detnet-4.pptx 802.1CB seamless redundancy. Packet duplication. DetNet QoS in terms of delay, packet loss during normal operation, packet loss in presence of link/node failure. Techniques advocated for: zero congestion loss, pinned down path, path redundancy. 802.1CB has most of it. 1:1 LSP (label switched path) protection used for 802.1CB-like functionality. Sending side trivial. Receiver side needs new functionality since, it receives two or more packets from different LSPs and the PseudoWire (PW) instance needs to discard duplicates. Lou: call it rather PW redundancy not 1:1 LSP protection. It is for of PW redundancy/protection. Shahram: it is a new form of PW protection. Yuji Tochio: is it unidirectional PWs or Point to Multi-Point (PTMP)? Shahram: unidirectional PW. Relays use Multi Segment PW (MS-PW) Lou: there is no draft out yet. One candidate technology. Presentation meant to prompt discussion. Greg: this is where network coding fits in. Need for a precise timestamp in a packet? Shahram: 802.1CB does not have timestamp. It relies on the time window for NN number of packets. A circular buffer implementation. Norm: a Q for folks thinking network coding. This is real-time. Greg: interest of network coding is lightweight decoding mechanism, works in arbitrary places in the network. Lou: I'm fan of network coding. We have to look at what the application requirements are. ** Discussion Pat: come to the front if you want to continue discussion or contribute. ** Adjourn (Notes Contributors: Charles Perkins, Dominique Barthel, Jouni Korhonen)