Minutes for DETNET at IETF-95
minutes-95-detnet-2

IETF-95 DetNet agenda
    Session 2016-04-05 1000-1230: Buen Ayre A - Audio stream - DetNet chatroom
Agenda
** IETF 95 DetNet Agenda - version 4/4/2016 **

Tuesday April 5, 2016
10:00-12:30 Tuesday Morning session I
Room: Buen Ayre A

Start Time  Information
 10:00 (15)  Title: Administrivia & Status
            Presenter: Chairs
            Slides:
            http://www.ietf.org/proceedings/95/slides/slides-95-detnet-0.pdf

Document status:
    2 WG documents
    1 candidate (architecture)

Notes done by Jouni korhonen, Pascal Thubert, Lou Berger

> 10:15 (20)  Title: Use cases - update
>             Presenter: Ethan Grossman
>             Draft: http://tools.ietf.org/html/draft-ietf-detnet-use-cases-08
>             Slides:
http://www.ietf.org/proceedings/95/slides/slides-95-detnet-1.pdf

Ethan gives the presentation of the use cases draft.
Goal: provide industry context per use case, how it is addressed today and what
we need from IETF for the future. Line up use cases and architecture.

Ethan lists use cases, one is new, M2M for industrial, Ethan presents the use
case in more details. Ethan describes classical control loop, orders of
magnitude for time and volumes; expresses the requirement for a convergence to
IP. Ethan lists asks to IETF in slide 10, and compiles common themes in slides
11 and 12.

Slides 14-16: Looking for disconnects between existing architecture and problem
statement and the use cases. Bringing the mismatches to attention, suggest
discussions on the ML to resolve. Ethan lists the issues one by one to
stimulate feedback

Open internet: not in scope
Clock sync: not in scope
Plug and play: most use cases expect that the device is pre provisioned. But
then there's the failure/replacement scenario. Ethan suggests that we decide if
this is in scope, and if so determine how to reflect this in the architecture.

- Stuart Bryant on Jabber: Re bullet 2 - isn't DetNet useful in providing the
time sync conduit - Norm Finn: people use 1588 to schedule packets. In that
case, sync'ing time is a service that DetNet uses. DetNet may have requirements
on sync time i.e. we wouldn't want timekeeping to depend on DetNet since DetNet
depends on timekeeping. However if DetNet can be used to implement "optimized"
timekeeping e.g. by providing timely delivery of time packets (once DetNet is
up and running using some "default" timekeeping) then it would be great to have
that in the use cases. about P&P, if there is a use case, suggestion to write
it down there. - Patrick Wetterwald: in utility there is a use case of
connecting substations. They may us an SP network for that connection. Even if
we do not support internet at large, we must support 2 interconnected networks.
- Ethan Grossman: Noted

- Ethan: Link authentication/encryption is a service on top of DetNet.

Link Aggregation: streams being synchronized together
- Lou Berger: what is your objective for this (slide 14 discussion)
- Ethan Grossman: to raise topics that may not be covered in other documents
- Subir Das: are you asking about mismatches with architecture?
- Ethan: I'm listing statements that I don't see a direct reflection of in the
Problem Statement and/or Architecture drafts. It may be there, but if I don't
see it I am assuming maybe some others might not see it either, so it should be
clarified.

<discussion between Subir/Ethan...>

- Norm Finn: the P&P is mentionned in the architectue draft about P2P protocol,
havng the ability for an end system to request a service is an important
compoinent for exactly that reason. Encryption: architecture says we do not
want to break security, but also that detnet presents new aspects since
encryption does not protect on time delivery. Link aggregagtion: so far the
discussions have been about making sure a flow stay on a same path because of
the need to keep packets in order. Aggregation has to place one flow on one
link. - John Dowdell: is it more a question of whether current link
authentication, encryption and aggregation technology does not support detnet
use case, is there something that is lacking? - Ethan: yes, this is the
question I am asking. - Lou Berger: then a good discussion topic for the list -
Pat Thaler: as contributor, plug and play is important. There are cases like
A/V where there's enough bandwidth to reserve for flows along the network (note
taker understanding: as opposed to central optimization). There are use cases
where everything is preprogrammed and thus no issue e.g., with the start times.
(Ethan's understanding of the point of what Pat said about plug-and-play: It
takes some bandwidth to create a reservation (both administratively and for the
stream itself), so if the system performance is such that it must be fully
loaded by the controller then there may not be bandwidth available to allow for
even the administrative traffic required to request an on-the-fly reservation
(without disturbing existing flows). However in some applications (e.g.
AVB-type plug-and-play) there is presumably always at least enough bandwidth
available to support the administration to request a reservation, even if there
is insufficient bandwidth available to add the requested flow.)  Link
aggregation has a specific meaning at L2, there's a link aggregation standard.
Having a flow along multiple path, not sure that's something we need to involve
ourselves in - Tim Chown: is this applicable to network-intensive applications
that might use 1-20Gbit/s, or only for low speed, time-sensitive applications?
- Ethan: no restriction on that. - Pat Thaler: - Paul ??: define how we reuse
existing mechanisms of DetNet, not creating new ones. (context of link
aggregation, multicast, etc) - Pascal Thubert: I think we need to keep
aggregation in scope. Putting back together a flow that was split over
different paths is an extreme form on the elimination operation that the ‘det’
layer does for the replication/elimination service, where packets may be lost
on either side or have to be recombined and reordered - Norm Finn: On sync
between 802.1TSN. Norm Finn thinks there is enough overlap with participation
to keep DetNet and 802.1TSN aligned (which means in practice that Norm himself
is committed to making sure that the two do not diverge).

> (10:42 actual)
> 10:35 (20)  Title: DetNet service model - discussion
>             Presenters: Lou Berger, Balazs Varga
>             Slides:
http://www.ietf.org/proceedings/95/slides/slides-95-detnet-2.pdf

Lou introduces chair-initiated discussions. Next two topics are chair
introduced and spun off the design team and architecture document work.

First topic by Balazs is related to service model

Lou explains the distinction whether the detent service is from the end node
(app/systems) or network edge nodes (end nodes not participating). Or do we
need/want both.

Balazs suggests work may be needed on terminology. Flows can be of different
nature, IP, Ethernet, TDM ... and end systems are connected to the network with
different types of interfaces (L1/L2/L3)

Balazs reviews the use cases and discusses how the service models apply.

In radio use case "radio/mobile access networks", radio and transport layers
are often integrated so we can consider end-systems as DetNet service
endpoints, however for some other scenarios where radio and transport domains
run independently the xVPN services apply. Similar consideration can be taken
for Industrial M2M use cases, where terminating DetNet service on end-systems
can be considered for new installation, whereas for legacy systems xVPN fits
better.

Discussion:
- Subir Das: can you explain what links are? (on slide <2> titled "purpose of
this discussion") - Lou: this is one way to draw the line of where the flows
exist. Links are connections between network devices, We have P2P links and
subnets in this drawing. - Subir Das: are they physical or logical? - Lou: we
do not constrain that. We include examples. - Subir Das: - Lou: if you do not
like the picture tell how it should be like. - Subir Das: how many nodes need
to run the DetNet service in the network? - Lou: I understand that you favor
edge to edge (2 to 2 on the picture) - Subir yes - Norm: hope we can do it that
way. the end station is expected to place the reservation and mark the packets.
we have use cases today where the end point are requesting the service. The
nodes recognize they are the specific DetNet flows. end systems are making the
packets specifically. - Lou: how does the end node see that? - Norm: I'm
talking about TSN. In general, there's something in the host that is aware that
there is TSN. That something is aware of 2 ports; one for normal traffic but
capable to use both. My choice is absolutely 3, both cases 1 and 2. keeping L2
and L3 separate is extremely important, but DetNet is not forwarding. A DetNet
service is a chain of boxes and wires and queues. They are not necessarily of
one type, L2 vs. L3. The service we are offering is QoS not forwarding, not
layer specific. A relay system has to pick a packet and apply a service, it
does not matter which technology/layer got the packet in the relay system.

- Samita Chakrabarti: TSN island connected to non-TSN island
- Lou: that's a form of case 2
- SC: One edge node could host application
- Lou: true. An edge node is a special case of application
- SC : could be a point of policy enforcement
- Lou: true
- Subir Das: are we going to do detnet as an application service?
- Lou: will not do a socket interface
- Lou: asking the sense in the room. only one or two. Who in the room believes
we should do a network box  application (case 1) - few
  Case 2 - more
- Pat Thaler: who thinks case 1 is important to cover: several hand
- Pat Thaler: who thinks case 2 is important to cover: several hand (slightly
more) - Lou: asks the sense of room on prioritization between case 1 and 2.
Hands shown.. no real winner.

> (Actual 11:08)
> 10:55 (15)  Title: DetNet terminology - discussion
>             Presenter: Norm Finn
>             Slides:
http://www.ietf.org/proceedings/95/slides/slides-95-detnet-3.pdf >

Norm Finn on terminology discussion
Norm notes that Lou contributed heavily on this slideware.

Norm notes that there are many ways to nail a path down. If we pick a term that
coincides with some existing draft (e.g., from segment routing) it does not
mean that we chose to work with segment routing.

Norm shows terms that are used in various technologies. It would be nice to
pick some.

Another angle shows a source on the left (maybe not aware of DetNet) and on the
right, a listener that is aware and terminating the service. We definitely have
use cases like that.

Norm expresses desire to pick terms. E.g., deterministic flow end to end going
over a DetNet service

<...>

- Lou: pick your favorite technology
- Norm: drawing issue. In the architecture we do not make a difference by layer.
- Lou: you are at the DetNet layer and the subnet is the network that you are
using. That does not mean an IP subnet. - Norm: Great. The subnet on the
picture may operate at any layer, as long as it provides that services that
DetNet needs. - Loa Andersson: why not call subnet as a DetNet subnetwork. - L
A where d the arrows on 7  start? - Lou: we kept the arrows endpoints vague to
get the discussion going. - L A: on arrow 6 that's is clearly ending - Lou: yes
because that is the end to end service

1. End system ->
2. Edge node ->
3. Network node ->
4. Sub network -> DetNet sub network
5. link ->
6. Deterministic flow ->
7. DetNet Flow ->

- Tim Chown: Need 2 diagrams? (one end to end, one edge to edge) It seems odd
to have a 'Deterministic flow' end to end where only part of the path is a
DetNet flow. - Norm Finn: confusion is that this diagram looks like a stack
diagram but it is not, it is looking at the network from above. - Balazs Varga:
DetNet flow can be the same as deterministic flow. There are cases where they
are also different and we need to be able to distinguish between those. Thus
two arrows.

Norm brings up slide "simple example:..."

Norm Finn: proposes that the DetNet data plane alternatives draft has the most
people working on it, and that it should be the reference to align to.

- Lou Berger: good idea. We should not constrain the specifics of that yet.
Would be a shame if the terminology does not align with the solution. We should
start with the data plane and keep it open. - Janos: back to both options. If
we provide both, a single name becomes confusing. - Lou Berger: We will propose
to follow Norm's proposal of aligning DetNet terminology with the data plane
terminology

> 11:10 (20)  Title: DetNet architecture - update
>             Presenter: Norm Finn
>             Draft:
http://tools.ietf.org/html/draft-finn-detnet-architecture-03 >            
Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-4.pdf

Norm presents architecture draft. Slides unchanged mostly from last meeting.
Presents slide "objective/goals". We want to invent the least possible. There
are assumptions like fixed throughput and no throttling.

Norm gives a status. Biggest change is terminology, e.g., stream-> DetNet flow,
seamless redundancy became packet replication and deletion.

Norm presents essential aspects. We are not talking about fault detection and
remediation, which could be future work. We are talking about sending the
packets twice. the model allows both end station and central controllers
placing reservations.

Norm presents open issues: Norm thinks that zero congestion loss requires per
flow state. TBD is the stream identification. The (DetNet) data plane document
provides information on that which the architecture needs to echo.

- Roland Bless: Architecture is a good starting point, but needs to elaborate a
little bit more on concepts. Guaranteed QoS usually requires three things:
Differentiation/Differential Treatment, Admission Control, Policing. Will
provide comments for the draft to the list. Maybe diffserv could provide
required guarantees. Bandwidth specification needs to be more precise, e.g.,
using Token Bucket models in order to take into account burstiness of sources.
- Norm Finn: Erm no. ..goes into explaining reservations, etc.

- Shahram Davari: is one of the goals not to keep the order of the packets.
- Norm Finn: if you look into this we may discover that we can add as a goal
easily. - Sharam Davari: it is not cheap. - Norm Finn: done at the upper
layers. - Sharam Davari: diffserv is preferable and achievable if we shape on
every node and enough buffering. - Norm Finn: if you have enough buffering and
know topology diffser can do the job. In some topologies just don't do it
(example of ring in industrial) - Pat Thaler: going back to architecture..
non-engineered plug and play is part of the scope. - Lou Berger: it important
the architecture document does not go too much into specific implementations. -
Lou Berger: one revs of the architecture and then adopt. - Norm Finn: having an
architecture doc is important to keep assumptions aligned. - Tim Chown: do we
want an environment with privacy support (e.g. might have dynamic L2 addresses,
or 5-tuple hidden due to IPsec etc) - Lou Berger: good opportunity to look at
doc and see where there are concerns and post to the list. To Norm: do you want
to address comments as individual so you place your own ideas, or do you want
to be the editor for the WG after adoption? - Norm Finn: Alignment is better
now with terminology. Better put the call out to get opinions sooner than
later. - Lou Berger: Poll -- asks how many has read the arch doc. A good
number. - Lou Berger: Poll --  how many thinks it is a good basis for the WG
document. More. - Lou Berger: ask Norm to do one more round to align with
meeting discussions and then will call for adoption.

- Lou Berger: (to WG) when supporting adoption please mention what you want
addressed in the first WG rev. This raises the importance of the issue raised.

> 11:30 (30)  Title: Data Plane Alternatives Design Team - report
>             Presenter: Jouni korhonen
>             Draft: https://tools.ietf.org/html/draft-dt-detnet-dp-alt-00
>             Slides:
http://www.ietf.org/proceedings/95/slides/slides-95-detnet-5.pdf

Jouni presents the status of the design team work on dataplane. Disclaimers,
doc is far from ready, WIP. Jouni presents the design team.

Jouni presents the goals, evaluate suitability of existing technologies for
DetNet. Also non goals: the document does not select technologies, does not
consider the control plane.

Jouni introduces the  DetNet view of layering, with a " DetNet service layer"
and a " DetNet transport layer". This partition is used to structure the
document.

Jouni presents "Why?" technologies are selected and studied, which properties
were found of interest for DetNet services. Observes that a lot of discussion
was focused on replication and deletion, which layer does what.

Goal is to call for adoption after 01, which may add/remove alternatives.

- Lou Berger: what should the DT do after that? Is there a logical next step?
- Jouni Korhonen: Follow normal WG process
- Lou Berger: people do not need to be in the DT to contribute. Send text to
the chairs. Now is the time for everyone concerned to speak up. - Stewart
Bryant: <jabber>PWs don't really have sequencing - last slide - it's only there
for the TDM PWs in practice - Uma Chundury: is goal to pick up a technology and
then fix the gaps? - Jouni Korhonen: yes - Erik Normark: how would things work
together, DetNet and RTP

- Jouni Korhonen: RTP provides services that do most of what we need here in
DetNet, sequencing, duplicate elimination... - Lou: there are things in the dc
that will need to be thrown out. - Ilya Vershkov: packets out of order,
reordering. Is that a goal? list of requirements. - Pat: we put them in order -
Lou: we'll determine which we are really going do. - Yuanlong Jiang: number 9:
what do you mean? - Jouni: receiving packet that you are not supposed to
received. which node is misbehaving? E.g., if there is duplication in the
network, need to determine the node that performed the duplication. - Yuanlong
Jiang: not sure we need to distinguish ??? - John Messenger: it's OAM part of
time synchronization. The dataplane is the only place where you can do that. -
Yuanlong Jiang: time flows of MPLS packets. - Lou: yes, there's 1588 out there,
discussion is whether there are gaps that we identify. If there was nothing to
do we would not have a WG ;)

> 12:00 (15)  Title: Deterministic Networking Requirements on Data and Control
Plane >             Presenter: Yiyong Zha >             Draft:
https://tools.ietf.org/html/draft-zha-detnet-requirments-00 >            
Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-6.pdf

Yiyong Zha presents requirement draft
Yiyong Zha reviews the architecture and then MPLS as a candidate to support
DetNet transport. Analyses open questions to get there. LSP setup. Support L2
tech such as PW.

Yiyong Zha presents needs and issues for DetNet flow identification, and
proposes alternatives like network added.

Yiyong Zha presents TSN.

- Greg Mirsky: you assume that a particular technology can guarantee delay. I
believe that we need performance measurement to confirm that the service level
conforms SLA, else actions are to be taken. I do not think that a dataplane
technology is a guarantee and removes the need for validation through
measurement.

- Lou little time left, comments through the list.
- Lou: what goal for this doc:
- Yiyong Zha: need feedback from the group for that
>
> 12:15 (15)  Title: Integrated Mobile Fronthaul and Backhaul
>             Presenter: James Huang
>             Draft: https://tools.ietf.org/html/draft-huang-detnet-xhaul-00
>             Slides:
http://www.ietf.org/proceedings/95/slides/slides-95-detnet-7.pdf

James Huang presents Ethernet as a candidate for DetNet transport (fronthaul
and backhaul) and compares with others like IP and MPLS.

For MPLS: missing radio over MPLS. Then discusses support of / CPRI awareness

- Janos: work going on in 802.1CM (note taker: name to be confirmed) to carry
Common Public Radio Interface (CPRI)

James discusses packet loss / BER impact on CPRI

- Janos: again look at 802.1CM
- James: yes, aware of this work
- Lou: what's next
- James: new version.
- Lou: please look at use cases document
- Lou closes the meeting (2 minutes early!!!)

> 12:30      Adjourn