Minutes IETF100: detnet
minutes-100-detnet-01

DetNet IETF100 (Singapore)  Nov 07, 2017
0930-1200  Morning Session I, Sophia

Slides:           https://datatracker.ietf.org/meeting/100/materials#detnet
Etherpad:         http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-detnet
Audio recording: 
https://www.ietf.org/audio/ietf100/ietf100-sophia-20171116-0930.mp3 YouTube:   
      https://www.youtube.com/watch?v=WhFqlWurUuQ Jabber:          
xmpp:detnet@jabber.ietf.org?join

# Start Time Information
0) 9:30 10 Title: Intro, WG Status, Draft Status

Lou goes through the agenda and document status.
Three documents (Architecture, problems statement, use cases) close to
completion. The interesting thing is that keeping documents alive allows us
finetune them. This is good as new people come in and they do not necessarily
always see / understand all topics are we (old timers) do.

1) 9:40 10 Title: Use Cases
    Presenter: Ethan Grossman
    Draft: https://tools.ietf.org/html/draft-ietf-detnet-use-cases
    00:08:40 on the audio recording.

Greg Mirsky: agree that net slicing has a part (one out of three) that has
strict requirements
  but other 3GPP identified scenarios may not require DetNet.
Lou: Greg if you have any proposal for changes and enhancing the text post them
to the list and we'll add them. Greg: I'll suggest some text on the list.
Toerless Eckert: Not clear if slices needs DetNet. Ethan: Good point. One way
it was phrased DetNet is a candidate technology for use in infrastructure of
network slicing. It is not pure use case. Stewart Bryant: Having reviewed
Network Slicing requirements, it is a clear use case for DetNet and it would be
a mistake to remove it as a Use Case. It is perfect use case for something that
is needed in 5G.

2) 9:50 15 Title: Security Considerations
    Presenter: Tal Mizrahi
    Draft: https://tools.ietf.org/html/draft-ietf-detnet-security
    00:24:00 on the audio recording

Greg Mirsky: what about attacks on OAM. OAM will be used for SLA assurance. If
someone skews your measurements that will cause a false negative. While not
specific to DetNet, should it be mentioned? Tal Mizrahi: good point, is there
something unique to DetNet here? Greg: It depends on impact of OAM, e.g.,
Inadvertent unnecessary switch over. Issue with attack on Performance
measurements. In some networks perf. measurements are only done for billing
here I would envision they are also done to find out whether there is a need to
reroute. Tal: This is feedback we are looking for. Stewart Bryant: Also impacts
delay and jitter. Lou: OK to have meetings of authors. Suggest to publish times
of meetings to make them open to the WG. Any decision taken by authors/subgroup
is not final. Must be discussed with WG to ensure consensus, e.g., via list.
When reading the document for the first time or just reviewing, look at whether
the text is in scope or out of scope, e.g. control plane not in scope now.
Don't lose good text, e.g., move such things into an appendix, but the core
should focus on current scope of WG.

3) 10:05 45 Title: DetNet Data Plane Encapsulation -- Resolving open issues
    Presenter: Jouni Korhonen (remote)/Norm Finn
    Draft: https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-00
    00:39:00 on the audio recording

Lou: Means of implementing low loss could be implemented using other means than
PREF, e.g. Network Coding.  Such other methods are also in scope and may be
considered in the future. Pascal Thubert: Network coding is in the architecture
document, it can be defined at a later date.

Slide 6: (Prologue to unified service layer solutions)
Stewart B: Do we need to support others besides IPv6 and MPLS? IPv4? Customers
need IPv4, we should support it. Jouni Korhonen: Interworking solution fine but
defining IPv4 as a transport like IPv6 no. Lou: Do we view IPv4 as E2E DetNet
service or 'just' another TSN service supported over DetNet? So far we've taken
the latter position. But we can do something different. Stewart: Do use cases
specify this? Lou: No, they are higher level. Jouni: Current solution has a
separate implementation for IPv6 and MPLS, and going separate ways, but basic
processing should be same. Lou: So the question (on the slide) is do we change
directions back to provide a unified on-wire format? So far no objection to
this. Anyone objections? (Questions #1) Norm Finn: Great to have both formats.
There's also a legitimate question whether there needs to be separate drafts to
both solutions. Lou: No objections to keeping current strategy? No objection in
the room, need to take to list to confirm.  - No objections in room. Greg
Mirsky: Expect DetNet layer in one doc, then "detnet over different
technologies" in separate docs. Segment routing done this way, IPv6 vs MPLS.
Jouni: Question #3 to split documents between IPv6 and MPLS. Pat: I heard 3
documents suggested: overview doc and each encapsulation? Or just two drafts?
We already have an architecture document as an overview. Jouni: Likes 2 docs.
The PREF part that Norm is going to present later on may change the situation
in the future i.e. that becoming a separate document. Loa Anderson: Maybe delay
split until core issues are resolved. Lou: Authors discretion on when to split,
should add a comment that the intent is to split the draft and start noting
that split is coming, and which draft each part goes in. Pascal: Think about
layering. There are aspects that won't fit into just 2 or three drafts. Jumping
ahead what Norm and I am going to talk there are things that do not really fit
into transport. Lou: we will still have multiple drafts that cover aspects e.g.
layers Slides 9 and 10 Stewart: Do you need to put anything other than Ethernet
over this service? Issue of skip 0 not catastrophic, just reduces range by 1.
4448 OK. In terms of using EVPN, there is no SPE. But SPE is the wrong concept,
so perhaps add a new construct. Lou: Are you saying that PW constructs are not
providing a lot of value and may be wrong in the DetNet context? Stewart: SPEs
are wrong Lou: Which were the main motivation for using PWs Stewart: T-PEs may
still be fine. Depends on types of traffic that will be covered. Jouni: 6658,
any packet over PW. SPE question is our question #7. Norm will have to say when
it comes to functions of SPE, replication and elimination.
    Issue of interworking with existing technologies.
    Seq # already in payload of other existing technology.
Pat: If don't skip 0 can use same on as used in Layer 2.
Norm: Skipping 0 can be an issue, if every 64K packets delivered twice, not
terrible. But if drop one instead that would be bad. Reusing technology (and
implementation) is way more useful than reusing existing specifications.
Reusing gates is important, reusing documents is nice. Lou: Find right tech
solution then back it up in our docs. Do the authors have a position on this
question? Jouni: My opinion, it is okay to define something new, but better to
reuse gates. Easier in the end to not skip 0. Norm: Possible rathole, many
opinions. Should allow for 0, just another seq num. Pascal: Layer violation if
lower layers put semantics on something defined in upper layers. Lou: if allow
0 might be able to send fewer bits on the wire. So it is an optimization. Andy
Malis: As PALS co-chair - No reason why can't define new DetNet PW with
whatever behavior is desired. Lou: Do we want to be constrained by existing PW
definition that skip 0? Current feeling is should allow 0 as valid value? Any
objections in the room? POLL: No objections Stewart: Just define a new PW and
it will 'just work'. Lou: So the next question is do we care if we model this
as PWs, EVPN, or something else? Stewart: PWs use 16-bit seq num. Maybe
underlying techs use e.g. 32 bits? We can define whatever is needed.

Jouni: Question #6:
Jouni: points out that PW and EVPN on-wire encoding look the same from the
pipeline point of view. Lou: A documentation question not a wire question. This
is more of a documentation issue, since they will be different even if the
on-wire looks the same. Norm: Prefers DetNet Wire and define what it is.
Looking at what does TSN want from DetNet? Doesn't always want an Ethernet
connection, we want a routed connection?  Can't make a bridged network large
enough. Don't want a PW that just extends Ethernet to expand volume of
broadcast space.  Should be defining what DetNet data plane is, not new PW.
Lou: You want to focus on just what the definition of what a detnet data plane
looks like -- Wouldn't call it a "wire", just a DetNet data plane. Stewart:
Most important to design the right thing for the job. Maybe reuse OAM and other
things. Lou: Using existing data plane, just about how we describe it. It
sounds like the opinion voiced in the room is don't worry about being tied to
existing constructs like PW or EVPN, and just focus on DteNet data plane and
describe it in whatever way makes most sense for detnet. Any objections? POLL: 
No objections in the room. Document this in the notes as the decision. Jouni:
Now he (Jouni) has clear guidance, good.

PREF section presented by Norm:

  01:41:00 on the audio recording, 1:15:30 on youtube.

Layers of detnet via nested CWs. Enables multiple layers of PREF for e.g.
aggregation. Loa: If break in small ring in upper right wouldn't traffic go the
other way? Norm: DetNet doesn't respond to failure by creating new path. Not a
ring that depends on direction. Lou: Lots of us are familiar with rings in
usual. Really this is 1+1 end to end protection Kireeti Kompella: Replicated
both up and down? Norm: Yes, get eliminated as they crisscross. Lou: So far
talking about end to end protection? Why now rings Norman, Pascal: Ladder has
been in arch since the beginning. This is what is in the drafts now, not
something new. Currently have thing in center of box that sees duplicate and
does forwarding. Kireeti: We should be describing what we want and if it's not
implemented, than don't use that box Lou: We have been describing at the box
level up until this point vs topologies/rings, we should focus on the function.
Norm: Have been receiving comments related to how it's been described. Lou: Not
describing internal behavior, could be implemented various ways. Stewart:
Should separate Replicators and Eliminators. Replication is on Ingress
function, elimination is on egress. Lou: I think we just made a decision to not
describe internal behavior, but rather defined box level function. Norm:
Easiest way to draw is associating with ingress/egress. Lou: Normative should
be box level, associated description on internal behavior is informative. Norm:
agree that we should require a specific implementation within a box Toerless
Eckert: This is on the right track for doc, is it on track for implementation?
Would be clearer if there were YANG models? There's prior knowledge that can be
leveraged. Lou: Yes it would be great to get some YANG model proposals that
leverage past experience. Toerless Eckert: is adding sequence numbers assumed?
Lou: Yes, but can be layered. David Black: From requirements perspective: If
replicate but fail to eliminate one, what happens? Lou: violates spec. David:
[so must specify that] At egress, duplicates must not exist.

4) 10:50 15 Title: DetNet Flow Information Model Based on TSN
    Presenter: Balázs Varga
    Draft:
    https://tools.ietf.org/html/draft-farkas-detnet-flow-information-model-02

        02:15:43 on the audio recording

Lou: Should we adopt?
Poll: How many have read document? Not great, but not bad
        How many think this document is a reasonable starting point? More
Will take to list.

5) 11:05 15 Title: Transport Layer for Deterministic Networks
    Presenter: Pascal Thubert
    Draft: https://tools.ietf.org/html/draft-thubert-tsvwg-detnet-transport

        02:23:15 on the audio recording

Lou: Won't do Transport layer here, do in TSV WG. Google doing work on this.
David Black: Clarification needed as to what is transport, i.e., belongs in the
transport area? Link based flow control is something else. David: Link layer
flow control should stay here. Lou: Chairs agree. Lou: Maybe PREF is confusing,
David: Router should do this. Not a transport functions. Is a ring protection
mechanism. Lou: But in Routing we call that transport. David: Terminology
overload. Tease out what is used in IETF as Transport. Pat: PREF could be done
at router or endpoint, but is at Layer 3 not 4. Toerless: flow control can be
on transport tunnels as well Pascal: proposing minor changes to arch to enable
(?) Lou: Out of time for this topic, please bring this to the list. Lou: Having
an interim meeting on data plane has just been proposed privately, this topic
could also be covered there. - but don't wait, please start discussion on list.

6 11:20 15 Title: DetNet Bounded Latency
    Presenter: Norm Finn
    Draft: https://tools.ietf.org/html/draft-finn-bounded-latency-00

        02:41:08 on the audio recording

Lou: Need from WG - proposed YANG model that specifies DetNet services in an
abstract fashion. Then this draft would describe how to implement this. Balazs:
There is version 00 for a YANG model
(https://tools.ietf.org/html/draft-geng-detnet-conf-yang) Lou: Think about
presenting this at next meeting.

7 11:35 25 Title: Information and data model considerations: Applicability of
Network Calculus to DetNet
    Presenter: Jean-Yves Le Boudec
    Reference:
    02:47:30 on the audio recording

Mirsky: Look at work in SFC WG on alternate WG method and measuring nodal and
sub-nodal residence time, contribute to jitter. There is an idea of how to do
proactive resident time so can use this to characterize latency in real
networks Norm: Characterization of Queuing methods are not characterized well
in TSN in a usable form for DetNet, this will improve everything. JY: For
DetNet, don't want to specify (characterize) a specific scheduler. ???: Do you
have any hypothesis on the flow arrival process JY: No, in order to provide
bounds can enforce arrival constraint Lou: Following on Norm's point, we do not
look at specific queueing technologies. We do look at how to characterize nodal
and service behaviors, so if can help develop abstract parameters, which can be
passed around by control plane. If you want to submit some text we will find
out which draft to put it in so you don't have burden of editing (XML). Norm:
I'll be happy to help put together a draft

Lou: (Closing meeting) We ran out of time to cover Pascal's comments on
architecture, please work this among the authors Lou: Interest in Interim for
Data Plane discussion? Remote, physical? (Some interest in both in room)
  (Someone offered to host (who?)

Adjourn 12:00 100th IETF DetNet WG

NOTE TAKERS:
Ethan Grossman
Pat Thaler
Jouni Korhonen (post processing)