Skip to main content

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)