Minutes IETF97: detnet
minutes-97-detnet-01

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?  <a few> 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
>