Minutes IETF104: detnet
minutes-104-detnet-01

Notes from IETF 104

NOTE TAKERS  included
Ethan Grossman
János Farkas
Lou Berger

> DetNet Agenda IETF104 (Prague)
> Version: Mar 12, 2019
> Wednesday, March 27, 2019 (CET) (+01)
> 9:00-11:00  Wednesday Morning session I
> Congress Hall 1
> Slides: https://datatracker.ietf.org/meeting/104/session/detnet
> Etherpad:       http://etherpad.tools.ietf.org/p/notes-ietf-104-detnet
> Meetecho:       http://www.meetecho.com/ietf104/detnet/
> Audio stream:   http://mp3.conf.meetecho.com/ietf/ietf1043.m3u
> Jabber: xmpp:detnet@jabber.ietf.org?join
> Available post session:
> Recording:     
https://www.ietf.org/audio/ietf104/ietf104-congresshall1-20190327-0900.mp3 >
YouTube:        https://www.youtube.com/watch?v=hrV4VwGEgUs

> Num Start Duration Information
> 1  9:00    10      Title:  Intro, WG Status, Draft Status
> Presenter:      Chairs
> Draft:
    Architecture draft had IESG review comments from security area - these were
    addressed to their satisfaction by authors and Security draft authors.
    Should make it to RFC editor queue soon.
Security draft still being held up from publication to make sure it is aligned
with solution drafts. Hope for publication requests for solution drafts by
Montreal (i.e. next IETF 105) so once those are stable we can finish the
Security draft and consider publication. Also at Montreal we plan start
discussion of what to do next, e.g. control plane or other topics. If you have
other topics, Montreal would be a good place to consider them. Note that not
everything is in scope for DetNet, but we can discuss where to route them e.g.
to other working groups.

> 2  9:10    10      Title:  DetNet Architecture
> Presenter:      János Farkas
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-architecture-12
Lou Berger: Re: "No expectation that DetNet app-flows will respond to
congestion control": An implication, ripple effect:  At Service interface
level, must understand whether app traffic supports congestion control or not -
this affects flow model, Yang model; we hadn't before had awareness of anything
related to application. To address this have toadd extra text on requirements
for what we have to do for traffic that is not congestion controlled. Stewart
Bryant: Concern about congestion controlled traffic. Amount of traffic in the
open that wasn't congestion aware was trivial. IN cases where non-elastic is in
a controlled environment. We don't want to require full analysis of application
traffic before it can be deployed on network. Janos Farkas: Correct, we are for
a single administrative domain, a controlled environment, plus we have added
text regarding rate limiting and use of shapers; that's all you need; you don't
need to know every flow. These are the rate limiting tools you need to have
protection against misbehavior, at entrance to DetNet domain. Stewart Bryant:
Why a single domain vs a set of domains that understand what each component is
doing? János Farkas: Our charter says that. Stewart Bryant: Maybe revisit that?
Unreasonable to not be able to split domain into multiple components if that
suits you. János Farkas: Maybe add that in our charter update? First finish
current charter, then enhance? Stewart Bryant: People will ignore it if they
don't like it.

Stewart Bryant: (Regarding "scope of DetNet is a single administrative
domain"): We would be better served to say "within a controlled domain, not the
open Internet". Because we did that with pseudowires, but then we had to do
multi-segment pseudowires which are not a single administrative domain. Could
imagine needing similar thing with DetNet also. Better to say "one or more
controlled domains", not a single one which has its own set of restrictions.

János Farkas: But if two domains, do you mean they might have separate owners?
Stewart Bryant: Yes so that labels could be managed by the domains separately.
Better to point to the real problem, which is that this is about control and
oversight of the deployment, not about restriction to a single administration.

Lou Berger: Good to check exact text of docs - the only place where explicitly
says single administrative domain is when talking about security. Architecture
text says "not for large groups of domains such as the Internet". We can agree
on that much, as stated in our charter, so probably no contention there. So
regarding single admin or not, please read draft text in context.

Deborah Brungard: This is a "hot button" item, "Domain, what is the domain?"
Could say a DetNet domain crosses multiple adminstrative domains. The most
important is that it is a controlled domain. Sub-networks may not be not DetNet
aware but can still get across them. So if it says "Administrative domains" in
the Security section please review, give it a bit more thought before deciding.

Lou Berger: Doc is now owned by IESG.
Deborah Brungard: These are not technical changes, just clarification, charter
is clear, mostly want to say "not the open Internet"

János Farkas: Text in doc was copied from Charter. Says "closed group of
administrative control".

Lou Berger: But Security Considerations section says "intent of a single
administrative domain". Deborah Brungard: How about instead saying "single
administrative control".

Lou Berger: So replace "single administrative domain" with "single
administrative control"? Deborah Brungard: Or "closed group of administrative
control", get away from use of "domain". Lou Berger: But I'm worried about any
changes here, we have to be careful since draft already with IESG, need to be
coordinated with IESG.

Deborah Brungard: If they push back on removing "domain" I can explain to them
that it is very confusing.

Stewart Bryant: Text "Within closed group of administrative control" is good,
sets out what we need to do. Need to make sure that is reflected everywhere.
János Farkas: Need to review new Security text for this, since was recently
revised, maybe we weren't too careful about this there, but we were careful in
charter about this.

David Black: On behalf of Transport area, thanks for massive improvments over
draft 8. Going back to Stewart's comment, I agree that it should not be
necesary to analyze applications for congestion control or lack thereof. There
are many DetNet applications that are not congestion controlled, e.g. broadcast
video editing. Paradigm to apply is assume it is not congestion controlled
unless you know it is congestion controlled, and take appropriate measures at
the boundaries. Applies double if doing PREOF - if a replicated flow escapes,
the elimination node may not notice that it is only recieving the other flow,
so you can have an unresponsive flow going out and causing damage.

János Farkas: We did add text for this (sec 3.3.2)
Lou Berger: This will impact Yang models, so we need a way to indicate this,
which is not there now; make it optional with a default value of false. David
Black: Right; treat it as a potential source of problems, deal with them, but
if you have no problem, so much the better.

> 3  9:20    30      Title:  DetNet Data Plane drafts (IP and MPLS)
> Presenter:      Balázs Varga
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip-02
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls-02

Balázs Varga: Question to WG: Are we are creating building blocks or a
solution? Means how many documents to define the data plane? If building
blocks, then we would split the data plane drafts into more drafts (see
proposal in slide). Usually IETF specifies building blocks, but some other
SDO's are specifying solutions. We would like to do last call before Montreal.

Norm Finn: Breaking up docs sounds promising. Do you have comments on how to
address zero congestion loss, finite latency? I know how we do this in TSN
parts, but how to tie this into doc structure for non-TSN parts?

János Farkas: Maybe it isn't part of data plane docs? Put in Bounded Latency
draft? Norm Finn: Hopefully it can do that for all of them.

Lou Berger: Items 3,4,5,6 would need to talk about requirements on underlying
layers for queueing mechanisms. This group generally doesn't define queueing
mechanism, but we do discuss how to use queueing mechanism, or where an
implementatino is required to use one, e.g. IntServ and DiffServ; mechanism to
achieve service is not described, only behavior on the wire is required.

Norm Finn: Understood.

David Black: Where would the guide be to tell how to put these together? Which
docs apply to what they are trying to build and how to put it together? Lou
Berger: Is there ever something like that? David Black: This WG is building an
overall technology. I know some examples at smaller scope, like in Transport,
after the fact we had to write guide to TCP specs. Maybe good to do this before
people try to implement. Where does that go? Lou Berger: It would be in a
separate draft. János Farkas: Trying to do what Michael Scharf: (as reviewer of
Arch doc). Noticed that there is a mix of different arch solutions in the doc,
made review difficult. Good to separate into separate docs. But please pay
attention to this. Split is a good idea based on Arch doc.

Balázs Varga: Have several scenarios in Arch doc.

Michael Scharf: But in reading it I dad to distinguish between things that
apply in MPLS only, which should have been easier if it was split out. Stewart
Bryant: Some will come from the proposed framework component of first docs.
Maybe wait until split is done before trying to do summary.

Deborah Brungard: (As AD) Good to think about this now, was late in some other
cases. Looks daunting with 2 docs becoming 7. But looks clearer, and it is good
to think about users and what they are looking for. User will see all of these
titles - can be daunting - so take care to have good titles - at this point
naming is inconsistent, e.g. "detnet" at start vs in the middle of title names.

 Balázs Varga: Agree need work on titles.

Andy Malis: As contributor to large docs, reading them is a chore. This split
will help make this more approachable for newcomers. Mach Chen: Is split based
on current 2 data plane drafts? Or consider other potential dataplane e.g. SRv6
solution? Balázs Varga: This list is about splitting current two. That is where
we have the structure. János Farkas: Maybe discuss this in SRv6 slot? Lou
Berger: Makes it easier to bring in new technologies having it split like
this;, don't have to hold base document until all possible technologies have
been covered. Balázs Varga: We have identified these seven so far but not
limiting to these.

Balázs Varga: MPLS data plane content should be ready for last call after split
into multiple drafts.

> 4  9:50    15      Title:  DetNet Flow Information Model draft
> Presenter:      Balázs Varga
> Draft: 
https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-03

(No discussion)

> 5  10:05   15      Title:  DetNet Configuration YANG and Topology YANG Model
Updates > Presenter:      Xuesong Geng / Mach Chen > Draft: 
https://tools.ietf.org/html/draft-ietf-detnet-yang-01 > Draft: 
https://tools.ietf.org/html/draft-ietf-detnet-topology-yang-00

Xuesong Geng: Ask for help from group in defining YANG model, is complex.
Lou Berger: Work with BV and flow info model since changes there will affect
YANG model. OK to contact them individually, then post discussions/proposals to
list.

János Farkas: (regarding structure re-organization of current Yang models):
Which option do you prefer? Xuesong Geng: Maybe option 3. Lou Berger: Need some
reorganization, align with flow info model, e.g. service and forwarding layer
separation. Will have to ripple down into YANG. Agree existing node-based
organization needs to be improved. Sync with flow info, alignment with other
drafts then may inform this. Also work going on in TEAS - don't want to repeat
that work - can we augment or reference TEAS models? Still early, need to sync,
which will clarify a direction for us. Early to say whether option 2 or 3.
Xuesong Geng: Need more collaboration between WGs and between our WG draft
teams. Lou Berger: Maybe we can get the groups together to talk this week.

Yeon-cheol: Prefers option 3. Better aligned with existing Yang models.
Xuesong Geng: Yeon-cheol has made useful comments on this draft.

David Black: Agree that either 2 and 3 are better than current node-centric of
1.

> 6  10:20   10      Title:  DetNet Bounded Latency
> Presenter:      Ehsan Mohammadpour
> Draft:  https://tools.ietf.org/html/draft-finn-detnet-bounded-latency-02

Lou Berger: This is an informational doc to help implementers build detnet
implementations, not prescriptive. But there was lots of interest in room last
IETF so we thought it would be good to adopt it as a WG draft. Who thinks
interesting work for this WG: reasonable number How many have read the draft:
about the same How many think is reasonable starting point for WG draft: More
How many don't think it is good: None. OK we will take it to the list.

> 7  10:30   10      Title:  DetNet Bounded Latency Requirements and Related
IETF Work > Presenter:      Liang Geng > Draft: 
https://tools.ietf.org/html/draft-geng-detnet-requirements-bounded-latency-01

Liang Geng: This is about considering issues for DetNet in large scale networks
e.g. China Mobile. It is informational. Outline of problems we face to bring
DetNet to large scale, e.g. TSN island interconnect troublesome for maintaining
bounded latency. János Farkas: TSN is a layer 2 subset, so not part of DetNet
work. Lou Berger: Appropriate to bring these operational considerations to
DetNet. Raises issues with TSN technology, probably valid, but since owned by
IEEE, we can't do anything about them here. Here all we can do is make sure we
have constraints on what implementers do in using underlying technologies. So
if you refactor the doc to "requirements for scalability for DetNet" that would
be helpful, generalizing but perhaps using TSN as an example; but in general if
a given layer 2 technology (e.g. TSN) doesn't work for a given use case or
application, then DetNet just can't use it for that. Liang Geng Then at that
point we don't have a solution. Lou Berger: We don't have to specify queueing
technologies here, it is out of scope. Maybe if have local point-point MPLS
link, with local queueing algo that can satisfy requirements. As long as it
meets the operational requirements. Bringing your experience is great, but
don't say it in the context of TSN because the answer is "go to TSN".

David Black: Lou are you overstating the context of TSN? I could read the
criticisms in this doc in 2 ways: 1) Could read as "TSN doesn't solve all of
our problems, IEEE could fix it". Or 2) "TSN was designed to solve some
problems, but not all DetNet applications, so maybe something could be done
outside of TSN to address these". Would encourage consideration of both
perspectives. Lou Berger: First perspective doesn't belong in this room. David
Black: Agree, but want to make sure second is considered. Lou Berger: Maybe
second could be done in other IETF areas, like your WG? (TSVWG)? David Black:
We can have that discussion now or in a couple of drafts, when would you like?
Lou Berger: Let's have this discussion at end of solutions document.

Norm Finn: Appreciate your comments. Note that at next IEEE 802.1 it will be
pointed out that cyclic methods in 802 may be more powerful than currently
appears, particularly scalability. János Farkas: DetNet doesn't go into
synchronization details, we don't want to reinvent the wheel, just use time
sync techniques as needed for deployments. At DetNet to TSN interface, there
may need to be some time sync, but we are not going into those details here.
Liang Geng If long link, or large scale implementation, we can do it through
time sync, but that is also a lot of work. We bring it up here to consider
doing it with async case.

> 8  10:40   10      Title:  Large Scale DetNet Update
> Presenter:      Cristina Qiang
> Draft:  https://tools.ietf.org/html/draft-qiang-detnet-large-scale-detnet-03

Lou Berger: Not clear on doc: Says informational, but then goes into queueing
details, and comments on issues with TSN queueing mechanism - where are you
going with this doc? Cristina Qiang: It is to provide a generic framework to
deploy queueing mechanism at layer 3. A specific encapsulation to address the
need for 2 bits of cycle identifier to meet QoS guarantee. So the queueing
implementation is in the network. But the important thing is to justify the
need for the 2 bit cycle ID. Lou Berger: Sounds like definition of queueing
mechanism, which in IETF happens in Transport area. If you want to define
support for a queueing mechanism, it has to be a standard queueing mechanism so
have to run through TSV are first, and have them give us the answer for a
queueing mechanism. Then determine if requirements for queueing.

Toerless Ekhard: (as co-author of this draft) We are trying to break the
deadlock between what is defined by one WG vs another WG. Don't want to define
a queueing mechanism, but want to define resulting per-hop behavior. We
understand that for TSVGW to accept the work, need to have justification from
other WG, so this draft is to express that we need that solution.

Stewart Bryant: Agree with TE, this doc sets up the context of the problem.
Then need work from Transport are to validate per-hop behavior. Then neeed to
go to other groups to define marking in packet itself. Three pieces of work, so
starting with this.

Lou Berger: I understnd how the previous doc sets up requirements, but this now
looks more like a description of a solution - that should be in TSV working
group. This is a nice solution proposal to bring to a group that defines
queueing mechanisms.

David Black: Go back to Microburst slide: On this slide there isn't the word
"Q" in the slide - but yet there is a behavioral spec that could be a
foundation of a PHB, it starts from a time (oh, the word Q does appear there)
sequenced stream, and we want to ensure it doesn't pile up and turn into uneven
microbursts. That could be done by referencing some mention of time interval
without the specifics of how the queueing works inside. That kind of careful
teasing apart could get us to a PHB spec that doesn't tell the silicon people
how to implement the Q's. Lou Berger: That makes sense but I would call it an
Intserv flow spec rather than PHB since it is per flow not per class basis.
David Black: Needs longer discussion about this because I heard from authors
that they are more interested in DiffServ framework. This chart provides the
basis for on the wire behaviorable spec that gets you away from explaining how
the Q's work in the silicon. Lou Berger: That would be fine then we would
remove the queueing discussion from this doc then we'd have something useful
here. When we get to queueing behavior we get outside of DetNet scope. David
Black: Could put the queueing to give it context, but make sure it has word
"example" in it somewhere Lou Berger: But we didn't do that in Diffserv or
Intserv so it makes me uncomfortable. David Black: This one is a bit novel,
doesn't hurt to have some details on how you could make it work, but point
noted. Lou Berger: Maybe an appendix as a compromise.

Toerless Ekhard: If we haven't gotten the point over, then we need to improve
either the text or slides. Saying Intserv per flow, the point is to not have
per-flow state in midpoint P nodes, only state for class, so it can scale to
more flows. Lou Berger: That is an aggregate flow, so it looks like one flow,
but supports many other flows.

Toerless Ekhard: No because you never have a situation where more user traffic
creates more of these flows. The notion of a flow is something that has a
relationship to application levels.

Lou Berger: That's the place to focus - i.e. a discussion of how you propose to
change our architecture to better support scaling. All we have today in or Arch
to handle scaling is aggregation of flows. So if you want to move away from
this model, that should be the focus of this draft. Throw out queueing pieces,
discuss architectural implications, then we can talk about how to implement it.
queueing is down in the guts, out of our scope. If the main focus is to get
away from the aggregate model, that's new, cool, great to bring in, but make it
the focus of the discussion.

Toerless Ekhard: By the way the whole IETF mindset of trying to eliminate
discussion of anything internal to the router, I invite you to the next
generation router discussion today, because that is exactly one of their
bitching points. I don't know if TSN would have ever been implemented correctly
if they had taken this stance.

Lou Berger:We are not the IEEE and we don't want to step on their toes.

Toerless Ekhard: Not stepping on their toes, we are fine with structural stuff
like appendix, but without an idea of how someone would have implemented it. I
think people who wrote the PHB had examples in mind.

Lou Berger: Yes in the days of IntServ I was there building solutions and
queueing mechanisms, but IETF chose not to standardize them.  Implementers will
always have an idea how to implement it, but IETF won't always standardize
that, maybe some other SDO. But the notion of a different form of aggregation
is something we should consider in this document.

Ehsan Mohammadpour: In the slide for delay calculation, it is 2 times the
parameter T. Is it the same T at every node? Cristina Qiang: Yes. Ehsan
Mohammadpour: Isn't it hard to have a lot of nodes all with the same T? Maybe
different nodes need bigger T values due to number of ingress ports or flows
entering the node?

Cristina Qiang: Yes, the same T is easier to achieve compared with time sync as
used by other TSN technologies.

Cristina Qiang: For TSN it makes sense since you don't have many nodes, and you
can synchronize so you can keep same T. But with large scale network it is hard
to have the same T. Also if there is more than one T, how can you guarantee
that there is only one packet per cycle - maybe there can be more? You assume
maximum 2 packets from prev node, but if T is different then there will be more
than that. So how to address this for large scale DetNet?

Cristina Qiang: Asynchronous shaping (ATS) can have this kind of problem, but
ATS has another challenge to provide bounded jitter.

Ehsan Mohammadpour: I'm not talking about ATS, I'm talking about this approach
of LDN. Maybe there are some challenges in ATS, but the delay calculation in
this doc is not accurate. I would like to see the results proven in some
papers, and the results referenced in the draft, rather than have the
mathematical proof in the draft.

Lou Berger: Need to take details offline due to time constraints. Good to spend
some more time offline with Stuart and David to discuss where to go next with
this.

Stewart Bryant: I think it is misleading to say we're treading on IEEE's toes,
this is not the intent here. What we want is to solve this entirely at the
packet layer, which is nowhere near IEEE, we want an independent solution at
packet layer. Scope and range is larger than what IEEE is addressing. Also we
are missing a catalog document together describing the set of queueing
mechanisms so that people know which to pick for given application, its
advantages and disadvantages. This is valid work and we do need to find a home
for it.

Lou Berger: queueing is within scope of IETF, just not in DetNet.

Stewart Bryant: We need to do things in IETF, so we could incubate doc here,
then figure out with ADs where to take it next, rather than the other way
around.

Lou Berger: I would like us to describe a new form of scaling strategy into our
arch. Scaling has come up before, important to decide if it is important to
include in a DetNet solution. Right now it is explicitly excluded, i.e. we only
have aggregate flows. If need different than aggregate flows we need to address
this.

Stewart Bryant: It is, and is important to get to the next level of scaling.

Lou Berger: So we need to get consensus that this is something we want to work
on, not yet ready for queueing details.

David Black: (As TSVWG chair) TSVWG is happy to do work for others groups.
However there needs to be relationship with the group that needs the work, so
the decision needs to be made here that this is interesting work. We need scope
and requirements. TSV can work out the details but first we need to define the
forwarding behavior here.

Lou Berger: This draft of the doc is more about a solution but with the concept
of scaling without flow aggregation. The real question seems to be whether we
need a better solution for scaling. I don't think we have such a solution, but
the WG has to weigh in on this.

Toerless Ekhard: I hadn't heard the word "requirements". At 103 feedback was we
should define requirements So should the doc address how to solve this problem?

Lou Berger: Yes, previous doc was about requirements for large scale, title is
requirements for large scale, that is what this draft should be about.

Toerless Ekhard: But do we have a separate requirements doc?

Norm Finn: Bounded Latency draft points out that some specific queueing
mechanisms (including some IEEE mechanisms) don't require any state in any node
along the way. So allows rapid dynamic additions and deletions of traffic. So
it is not wholly new to desire scaling that is not related to flow aggregation.
Not clear that this is a new concept; not arguing for or against anything in
the draft, just pointing it out.

David Black: Need to distinguish between scaling of flows, however aggregated,
vs scaling in terms of network scope.

Lou Berger: Lots of aggregation semantics, need to understand failings of
current mechanism.

David Black: To the extent that there is a functional gap it seems to be in
network scope, e.g. extend time sync to arbitrarily large networks, is there
uniform time sync, or what happens on high-jitter links.

Lou Berger: Need solutions for this so we want to translate those requirements
to pass on to TSV for solutions.

Lou Berger:Out of time, apologies for skipping 2 individual doc submissions,
including SR, please read them on your own and discuss on list. Chairs need to
work with our AD and SPRING to see where the SR work should take place.

> 9  10:50   5       Title:  DetNet SRv6 Data Plane Encapsulation
> Presenter:      Xuesong Geng / Mach Chen
> Draft:  https://tools.ietf.org/html/draft-geng-detnet-dp-sol-srv6-00
<not presented>

> 10 10:55   5       Title:  DetNet VPN
> Presenter:      Zhe Chen
> Draft:  https://tools.ietf.org/html/draft-chen-detnet-det-vpn-00
<not presented>

> Adjourn         11:00
>