Minutes for DETNET at IETF-96
minutes-96-detnet-3

Minutes taken by: Jouni, Lou
Last edit: 8/31/2016
> Monday, July 18, 2016 (CEST)
> 18:00-20:00        Monday Afternoon session II
> Room: Bellevue
> Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-detnet?
> Video: https://www.youtube.com/watch?v=oOqD9cj96GM
> Start Time  Information
> 18:00       Title: Administrivia & Intro
>             Presenter: Chairs
>             Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-detnet-0.pptx Newly adopted
problem statement draft New candidates: detnet dataplane solution alternative
                detnet architecture document
Design team discussions to move to detnet list.. once the document gets adopted.
> 18:10       Title: Use cases - update
> (18:09)     Presenter: Ethan Grossman (remotely)
>             Draft: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-10
>             Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-detnet-1.pptx >            
Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-1.pdf Ethan
participating & presenting remotely. See presentation for details.
Concentrating to conclusions from discussions on "use case statements not
covered in PS or Arch drafts" as presented in IETF95. Lou Berger: The
resolution on providing sync time is not actually as he understood.. Understood
that DetNet would support coordinated time across layers? John Dowdell: Link
aggregation.. what about adopting some existing work done e.g. in MPTCP? Ethan
Grossman: Interesting idea. Norm Finn: Had a different view on traffic
segregation.. does not understand what the multicast MAC address to many
devices means? Ethan Grossman: Balazs should have more insight. Balazs Varga:
Mapping multiple multicast IPv4 address to one MAC address (32 to 1 ratio).
Norm Finn: In 802.1TSN every stream requires unique MAC address VLAN
combination for the network. The typical way of assigning
      IP multicast addresses to MAC addresses has the ration of 32 IPv4
      addresses potentially for allocated MAC address.
          Don't do that. (There's 28 bits of multicast IPv4 address space and
          23 bit of the available MAC address. )
Xavier Vilajosana: wind farm requirements should be also added in use cases
draft. We recently submitted a draft based on
      analysis of other standards and experimentation.
Lou Berger: How many are aware of it? should the requirements of the wind farm
be added to the use cases? Some interest. Patrick Wetterwald: related to
utility use case. need to check what is the difference to existing requirements
what wing farms would bring in. Xavier Vilajosana: we can work on integrating
requirement from wind farm to utilities if needed. Lou Berger: proposes changes
to the use case document on the list. There is enough support to discuss
specifics. > 18:25       Title: DetNet Terminology and Network Scenarios >     
       Presenter: Jouni >             Draft: (Based on next two drafts) >      
      Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-2.pptx
>             Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-detnet-2.pdf Norm Finn:
Transport Layer definition is better in the data plane document. Norm Finn: Is
the term DetNet defined anywhere (someone asked, perhaps Lou)? Should be in the
      abstract of the architecture document.
Pat Thaler: Prefers Loss Prevention vs. Reliability, because reliability is
very broad. For instance
     reliability can be how many times an equipment fails.
Norm Finn: Loss prevention has much less existing baggage.
Lou Berger: [Polls the room] Support for loss prevention, no objections.
Janos Farkas: Do you plan to move the bottom diagram on page 4 go to the
architecture document. Jouni Korhonen: Maybe, will revisit/consider. All the
information in the dp-alt page 4 figure
       are in the architecture document in some place/form.
Norm Finn: One could fold whole dp-alt into architecture document, which might
not be a great idea.
      If anything that needs to be moved is the figure (on page 4). Needs to be
      discussed
          among the authors. One term that was there before but was taken out
          is transit edge node. Needs to be discussed whether we need that
          still.
Subir Das: If we use loss prevention, need to define what DetNet loss means.
Pat Thaler: What about other terms.
Jouni Korhonen: Only non-obvious ones discussed.
<Walk through issue slides 1-6>
  1/6: basically merge text
  2/6: basically merge text
  3/6: Will use "Edge Node", merge text.
  4/6: see loss prevention above.
  5/6: merge text.
Norm Finn: Great off-line talks with Balazs and Janos (so not everybody was
participating). Norm Finn: Key function of relay's is stitching of DetNet
service over different transport layers.
  6/6: see above (5/6).
Lou Berger: actions are for authors to update their documents respectively,
with Architecture draft as main location for definitions. > 18:50       Title:
DetNet Architecture >             Presenter: Norm Finn >             Draft:
https://tools.ietf.org/html/draft-finn-detnet-architecture-06 >            
Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-3.pptx >    
        Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-detnet-3.pdf Subir Das:
assumption is that there are multiple paths available? Norm Finn: for some
services yes (loss prevention). If only congestion based loss is of interest
then one path works. Subir Das: what about retransmissions? Norm Finn: Not
considered. Many of the applications we have would resolve to too much latency.
Retransmission would be too late,
      you do not need the information any more.
Pat Thaler: Deterministic by certain time bound.
Subir Das: If within the time bounds is it still allowed?
Lou Berger: A node could ask for a detnet service and run TCP on top of it..
might not be useful though. Norm Finn: Not considering it as a prime candidate
to achieve the detnet service. Lou Berger: When talking about detnet and detnet
layers TCP is not going to be there. Pascal: Wireless typically includes
layer-2 ACKs. Scheduled retransmission are sometimes possible. No need to wait
for timeout.
        On some wireless technologies it is possible to have 2-3
        retransmissions.
Norm Finn: There are medias that provides ACK/NACK service at very low level
(802.11 as an example). There are probably cases where
      those can be used by detnet.
Subir Das: Takeaway is that on the detnet layer we are not talking about
retransmissions or ACKs. The underlying layers can support it, though.
       One problem is that the lower layers may keep up retransmitting, which
       then shows in DetNet layer if there is only one path.
Norm Finn: That winds up to delay variance.
Greg Mirsky: there are ways to degradation of service. That would be part of
the OAM discussion. Norm Finn: Four open issues: see slide 8. Norm Finn: Can
DetNet help in wireless? Architecture/DetNet does not spend time too much on
wireless. 6lopan/6tsch/etc are already on this. Lou Berger: What is preventing
adoption? In addition to terminology? Norm Finn: None. Tim Chown: Like where
this is going. Wireless will be challenging environment. Lou Berger: Does not
expect DetNet spending much time on wireless.. in this WG. Norm Finn: Update
will be published late this week > 19:15       Title: DetNet Data Plane
Protocol and Solution Alternatives > 19:09       Presenter: Jouni Korhonen >   
         Draft: https://tools.ietf.org/html/draft-dt-detnet-dp-alt-01 >        
    Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-4.pptx >
            Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-detnet-4.pdf Plan: one
update then ready for adoption. Poll: How many have read <a reasonable number>
      How many think this document is a good foundation for the WG? <almost the
      same number> Are there any objections, assuming discussed changes are
      made <none>
Jouni Korhonen: Update after norm's update of the architecture doc. Estimate
one week after the publication of the architecture draft. Lou Berger: will
start IPR polls on both documents in anticipation of updates. > 19:40      
Title: DetNet service model > 19:24            Presenter: Balazs Varga >       
     Draft: https://tools.ietf.org/id/draft-varga-detnet-service-model-00 >    
        Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-detnet-5.pptx >            
Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-5.pdf Lou
Berger: <as contributor> There may be good existing work on PseudoWires that
can be leveraged in the description of DetNet services. Balazs Varga:
Absolutely.. just ran out of time for this version. Jouni Korhonen: How do you
plan to align terminology. There are many new terms that are specific to
service model draft. Balazs Varga: some terms are specific to service model..
There are two actions on terminology. Align with terms and refer to them which
        are used in
arch
 and
data-plane
 drafts. Define service model specific terms (not used/needed in
arch
 and
data-plane
                and achieve consensus on them.
Lou Berger: not comfortable defining an internal interface to a node. Ok to
have a conceptual model but not enforcing the implementation.
     Concentrate on how to represent something the on-wire but how they
     (nodes/interfaces) achieve that is their own business.
Balazs Varga: yep.
Norm Finn: At the lower layer there is an interaction between DetNet stuff and
the other (not necessarily best effort) stuff. It is up to
      the subnet lower layers doing that stuff..
Lou Berger: It has to fit in out architecture models and we need to discuss the
coexistence. We do not expect having DetNet layer queuing that
     is orthogonal to or on top of interface/link layer queuing.
Greg Mirsky: within a DetNet domain there should be service consistency.
Lou Berger: Sure. How a vendor chooses to implement is their business. What
needs to be interoperable and goes on-wire needs to be standard. Greg Mirsky:
How to interoperate? Lou Berger: On-wire format and behaviours that need to
interoperate (external interfaces) need to be standardized. Greg Mirsky: Then
there will be some gateway that interacts at the control plane level? DetNet
will have its control plane that instantiates
      the data plane state.
Lou Berger: I think we are in agreement that external interfaces need to be
standardized. > 19:50       Title: DetNet flow information model >            
Presenter: Yiyong Zha >             Draft:
https://tools.ietf.org/id/draft-zha-detnet-flow-info-model-00 >            
Slides: http://www.ietf.org/proceedings/96/slides/slides-96-detnet-6.pptx >    
        Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-detnet-6.pdf Yiyong Zha:
Demo in bits'n'bytes on the data/info model mapping. Info model mapping to data
model
        and then that data model to actual (simulated at this point) data plane
        hardware.
Pat Thaler: On the info model.. I do not see a model where one put what service
the flow needs,
     like "I need this latency" etc.
Yiyong Zha: Service attributes.. trying already mapping that into requirements.
Tim: limited traffic means limited number of flows?
Pat Thaler: I think he means limited by bandwidth.
Tim: For a given reservation are the IP addresses and MAC addresses allowed to
change? Yiyong Zha: Now everything is user specific and recognized by a MAC
address. Tim: Needs to consider that over time the addresses might change but
there is still need
     for the same service.
> 20:00       Adjourn
> Notes taken by: Jouni