Subject: [Detnet] raw notes from session

From: Lou Berger <[email-masked]>
Date: Tue, 5 Apr 2016 11:36:45 -0400

Here are the raw notes from today's session.  Please review and correct
(at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-detnet).  Just a
reminder the notes should only cover what was actually said at mics in
the session, and these are input to the final minutes.  Recordings of
the session is also available.

Thanks to Pascal and Jouni and all others who contributed to the notes
and the successful meeting!

Lou and Pat

> 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, Pascal Thubert,

> 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
pb 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 feeback

Open internet: not in scope
Clock sync: not in scope
Plug and play: most use cases expect that the devce is pre provisionned.
But then there's the failure/replacement scenario. Ethan suggests that

- 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. 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 aquthentication/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 what I'm not matching

<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: exactly what we are after
- 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. 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 nned 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 agg, 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 operaion that the det layer does for the
replication/elimination service, where packets may be lost on either
side and 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.

> (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 mode:

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, ... and end systems are connected to the
network with different tyes of interfaces (L2/L3)

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

In radio use case, radio and transport layers are often integrated for
this service, but not for xVPN services.

Discussion:

- Subir Das: can you explain what links are? (on slide <unnumbered>
titled "purpose of this discussion")

- Lou: this is one way to draw the line ofwhre 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 exemples.

- Subir Das:
- Lou: if you do not like the picture tell how it should be like.
- Subir Das: hopw many nodes need to run the detnet service in the network?
   
- Lou: I understand that you favor eddge 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 piouint are requesting the service. The nodes recognize they are the
specific detnet flows. end systems are makking the apckets 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 boths. My choice is absolutely 3,
both cases 1 and 2. keeping L2 and L3 separate is extremely important,
bu 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 conected 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 note sthat there are many ways to nail a path down. If we pick a
term taht coincides with some existing draft (eg from segment routing)
it does not mean that we chose to work with segment routing.

Norm shows terms that are used in various technologies. 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. eg determinitic flow end to end
going over a detnet service

<...>

- Lou: pick your favorite technology

- Norm: drawingissue. 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 tha servcies 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. DeNet 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 netween those. Thus two arrows.

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

Norm Finn: proposes that the detnet dataplane alernatives draft hs 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 dataplane 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, eg 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 palcing reservations.

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

- Roland Bless: Maybe diffser could provide required quarantees.
- 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 achoieveable 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
indistrial)
- 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 importantce 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 practise

- 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, seqencing, 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 determinie wihch we are really gonna do.

- Yuanlong Jiang: number 9: what do you mean?

- Jouni: receiving packet that you are not supposed to received. which
node is misbehaving? eg 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 wwhere 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 candicate 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.1CA (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.1CA

- 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

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 6 Apr 2016 20:17:23 +0000

I had a comment regarding slide 9 bullet 7 in "Data Plane Alternatives Design Team - report".
I agree that this part (i.e., Time synchronization.. or rather OAM part of it) is important for the DetNet, but this function is usually independent from the data plane.
Furthermore, synchronization OAM is still a missing piece in all standards (draft-ietf-tictoc-1588overmpls-07 has mentioned OAM in Section 11, but BFD, LSP-Ping can only monitor faults in the LSP or path, they cannot deal with the loss of the timing information, mismatch of the clock, clock performance degradation and etc.)

Thanks,
Yuanlong

> -----Original Message-----
> From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Tuesday, April 05, 2016 11:37 PM
> To: DetNet WG
> Subject: [Detnet] raw notes from session
> 
> Here are the raw notes from today's session.  Please review and correct (at
> http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-detnet).  Just a
> reminder the notes should only cover what was actually said at mics in the
> session, and these are input to the final minutes.  Recordings of the session
> is also available.
> 
> Thanks to Pascal and Jouni and all others who contributed to the notes and
> the successful meeting!
> 
> Lou and Pat
> 
> > IETF-95 detnet agenda
> 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 pb
> 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 feeback
> 
> - 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.
> 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
> 
> 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.
> - 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?
> - 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. 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 nned 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?
> - Paul ??: define how we reuse existing mechanisms of detnet, not creating
> new ones. (context of link agg, 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 operaion that the det layer does for the replication/elimination
> service, where packets may be lost on either side and have to be recombined
> and reordered
> 
> Lou explains the distinction whether the detent service is from the end node
> (app/ systems) or network edge nodes (end nodes not participating).
> In radio use case, radio and transport layers are often integrated for this
> service, but not for xVPN services.
> 
> Discussion:
> 
> - Subir Das: can you explain what links are? (on slide <unnumbered> titled
> "purpose of this discussion")
> 
> - Lou: this is one way to draw the line ofwhre the flows exist. Links are
> connections between network devices, We have P2P links and subnets in this
> drawing.
> 
> - 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
> piouint are requesting the service. The nodes recognize they are the specific
> detnet flows. end systems are makking the apckets specifically.
> 
> - 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 boths. My choice is absolutely 3, both cases
> 1 and 2. keeping L2 and L3 separate is extremely important, bu 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.
> 
> - Pat Thaler: who thinks case 2 is important to cover: several hand (slightly
> more)
> 
> Norm note sthat there are many ways to nail a path down. If we pick a term
> taht coincides with some existing draft (eg from segment routing) it does not
> mean that we chose to work with segment routing.
> 
> Norm expresses desire to pick terms. eg determinitic flow end to end going
> over a detnet service
> 
> <...>
> 
> - 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 tha servcies that detnet needs.
> 
> - 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
> netween those. Thus two arrows.
> 
> Norm Finn: proposes that the detnet dataplane alernatives draft hs 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 dataplane and keep it open.
> 
> - Lou Berger: We will propose to follow Norm's proposal of aligning DetNet
> terminology with the data plane terminology
> 
> 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, eg 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
> palcing reservations.
> 
> Norm presents open issues: Norm thinks that zero congestion loss requires
> per flow state. TBD is the stream identification. The (dt) data plane document
> provides infromation on that which the architecture needs to echo.
> 
> - Norm Finn: if you look into this we may discover that we can add as a goal
> easily.
> - Sharam Davari: diffserv is preferable and achoieveable 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
> indistrial)
> - 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.
> 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.
> want addressed in the first WG rev. This raises the importantce of the issue
> raised.
> 
> Jouni presents the goals, evaluate suitability of existing technologies for
> detnet.
> 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.
> 
> properties were found of interest for detnet services. Observes that a lot of
> discussion was focused on replication and deletion, which layer does what.
> 
> - Lou Berger: what should the DT do after that? Is there a logical next step?
> 
> - 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.
> 
> - Jouni Korhonen: RTP provides services that do most of what we need here
> in detnet, seqencing, duplicate elimination...
> 
> - Ilya Vershkov: packets out of order, reordering. Is that a goal? list of
> requirements.
> 
> - Jouni: receiving packet that you are not supposed to received. which node is
> misbehaving? eg if there is duplication in the network, need to determine the
> node that performed the duplication.
> 
> - John Messenger: it's OAM part of time synchronization. The dataplane is
> the only place wwhere you can do that.
> 
> - 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 ;)
> 
> 
> Yiyong Zha reviews the architecture and then MPLS as a candicate to support
> detnet transport. Analyses open questions to get there. LSP setup. Support
> L2 tech such as PW.
> 
> - 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.
> 
> https://tools.ietf.org/html/draft-huang-detnet-xhaul-00
> >             Slides:
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet