Subject: [Detnet] Raw notes from DetNet session

From: Lou Berger <[email-masked]>
Date: Wed, 4 Nov 2015 16:36:44 +0900

All,

Thanks to Charles Perkins, Dominique Barthel, and Jouni Korhonen we have
the enclosed  raw notes from Monday.  These notes are also available,
and editable, via the URL:
        http://etherpad.tools.ietf.org:9000/p/notes-ietf-94-detnet

Please review and feel free to add your corrections via the link above. 
Changes/notes will be reviewed and approved by the chairs (and WG)
before being finalized.  Please limit changes to what actually
transpired in the meeting.  Session audio is available at
https://www.ietf.org/audio/ietf94/ietf94-room301-20151102-0900.mp3

If you have a question or want to discuss any topics raised in the
session, please feel free to do so on the list, but please do so with an
appropriate Subject line.

Thank you!
Lou (and Pat)

>         DetNet  Agenda For IETF 94 
>         Version: Oct 28, 2015
>         
>         Monday, November 2, 2015 (JST)
>         9:00-11:30 Monday Morning session I
>         Room: 301
> 
> Presentation    Start Time      Information
> 0  9:00  Title:  Administrivia & Intro, WG organization & milestones
>          Presenter:      Chairs
>          Slides: http://www.ietf.org/proceedings/94/slides/slides-94-detnet-0.pptx
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 Ericsson: 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 dataplane?
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: Somethings 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.

> 1  9:30  Title:  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
<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 expection 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: commonatiolity 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 potetial users even sait twelve
9's!    
Samita: 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 is already in RFC (RFC7668). But 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 tech   
Pat: to get best result some L2 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, 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 L2 tech are quite extremely different (bandwith,
low-power), the hope is anything in the middle will be covered as well.
Liang Geng CMCC: many overlap with use cases that are also discusses
elsewhere, for example, in NGMN. Categorize also based on 5G interest.
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.

> 2  10:11 Title:  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 omplex 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 inter-related, please also
describe dependency to external pieces of work.
Pat: pertains to arch document, not pb statemnt?
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 requirementsm controller computes pathes, 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 pb statement, Norm's comment applies to arch
document.
Lou: this pb statement draft has architectural considerations. We need
to draw a line.
Pascal: problems actually depend on architectural choices.
Subir: not sure all the pb areas Pascal has listed need be solved in
this WG.
Lou: reiterates pb statement vs. architecture split.
Lou: if interested in discussing these documents or want to contribute,
stick around at the end of the meeting.
???: PCE? TEAS?
Lou: if work outside IETF, we do liaisons.

> 3  10:33 Title:  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
co-author Michael Johas-Teener is the chair of ieee802.1TSN
states objectives.
not trying to re-invent networking. Number of technologies out there
that provide solution under some assumptions.
improved -02 version of draft out.
key aspects of architecture: reservation, redundancy, defense
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. Shaping
Norm goes over list of issues: shapers, schedulers? Diffserv, Intserv?
techniques for stream ID, QoS, pinned-down pathes? allow for distributed
reservation mechanim? 
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 pb statement
documents, will need to be sorted out. Provides one candidate
architecture. May have other proposals.
??: 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 ??: 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 pathes 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
applicationis needed.
Behcet Sarikaya: problem, no pictorial architure in the draft.

> 4  11:08 Title:  Data Plane Kickoff Discussion
>          Presenter:      Jouni Korhonen/Shahram Davari
>          Draft:
>          Slides: http://www.ietf.org/proceedings/94/slides/slides-94-detnet-4.pptx
802.1CB seemless redundancy. Packet duplication. 
Detnet QoS in terms fo 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.
<<<help needed, please>>> This is acronym soup to me! (Jouni: will add
later from the record)
1:1 LSP (label switched path) protection used for .1CB fucntionality.
Sending side trivial. Receiver side needs new functionality since, it
receives two or more packets from differnt LSPs and the PW instance
needs to discard dupolicates.
Lou: call it rather PW redundacy not 1:1 LSP protection. It is for of PW
redudancy/priotection.
Shahram: it is a new form of PW protection.
???: is it unidiorectional PWs or PTMP?
Shahram: unidirectional PW
Relays use Multi Segment PW (MS-PW)
Lou: tehre is no dfraft out yet. One candidate technology. 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 timerstamp. It relies on the time window
for nn number of packets. A circular buffer.
Norm: a Q for folks thinking network coding. This is real-time.
Greg: interest of nw coding is lightweight decoding mechanism, works in
arbitrary places in the nw.
Lou: I'm fan of nw coding. We have to look at what the apllication
requirements are.

>    11:10 Title:  Discussion
Pat: come to the front if you want to continue discussion or contribute.
>    11:30 Adjourn

> Notes Contributors: <Charles Perkins, Dominique Barthel, Jouni Korhonen>