Minutes interim-2020-detnet-02: Wed 14:00
minutes-interim-2020-detnet-02-202010141400-00

>         DetNet Agenda for Interim (virtual)
> Version: Oct 12, 2020
> October 14, 2020
> Time Zone Converter:       
https://www.timeanddate.com/worldclock/converter.html?iso=20201014T120000&p1=1440
> Slides:       
https://datatracker.ietf.org/meeting/interim-2020-detnet-02/session/detnet >
Notes & Bluesheet       
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-detnet-02-detnet >
WebEx       
https://ietf.webex.com/ietf/j.php?MTID=m0722700adfb966edebb80dad46b077cd >
Jabber:        xmpp:detnet@jabber.ietf.org?join

> Presentation        Start Time (UTC)        Duration        Information
> 1        12:00        10        Title:        Intro, WG Status, Draft Status
> Presenter:        Chairs
> Slides:         
https://datatracker.ietf.org/doc/slides-interim-2020-detnet-02-sessa-intro-wg-status-draft-status/
(Janos Farkas presented slides) (No comments or questions)

> 2        12:10        80        Title:        DetNet Configuration YANG Model
- Update > Presenter:     Don Fedyk   Authors > Draft:       
https://tools.ietf.org/html/draft-ietf-detnet-yang-08 > Slides: Don Fedyk:
Working on aligning flow document Xuesong Geng: 1 year of work, discussion
every week, progressing. Many updates last 2-3 months, aggregation, others. Don
presenting: Lou Berger: (slide 11) When say not needed, means not that it isn't
supported, just that don't need an extra element in tree? Don Fedyk: Mulitple
services aggregate to forwarding layer, can do that since add label with
forwarding label. With service layer need another label. But reviewing cases,
may have missed one where needed at forwarding layer. Maybe haven't ruled out
everything. Lou Berger: So answer is "yes"? Don Fedyk: Yes.

Lou Berger: How to run discussion? Want at end? Questions in middle? WG
Feedback opportunity. Don Fedyk: Please comment, e.g. if prefer one option over
another. Plan to incorporate data into document, adds clarity to overall model,
feedback solicited, mic is open for discusssion. Realize some are seeing this
for first time, but good to discuss.

Lou Berger:     Show differences again?
Don Fedyk: Case B2 Instance data slides
Service agg group is pullout out of service sublayer, referring to it. Each
service refers to that group. Previous model: In this model have service
sublayer, refers to agg layer, similar to last version. but agg is within
service sublayer, so within same tree structure, below it. Essentially the
same, one is inslde the service tree, other outside. Not a big difference in my
opinion.

Balazs Varga: If look to Arch doc for DetNet, service sublayer and forwarding
sublayer, agg is a functionality of service sublayer, so having that component
inside is more natural, rather than adding something not in DP or Arch docs.

Lou Berger: Need to support agg at both layers, hierarchical MPLS, so allowing
for both makes sense. Examples are good - instance data, maybe put as an
appendix, to show it is not normative. Very helpful to implementation, please
make sure examples are correct and then put into doc. As much as you can do to
reduce number of nodes that have to change when a config changes, that is good
design principle, e.g. to instantiate new model, less is more. On same theme,
could model agg as in outgoing list, rather than whole new service element. In
MPLS could model as app flow, one service whose output is another service, so
can use same label. Based on what HW supports; maybe would not be nested, but
maybe HW would support it . Can we do it without extra agg component, just
chain services? Or forwarding suyblayers? Looks good on output case, maybe not
input? Don Fedyk: When look at forwarding sublayer, and do agg within that,
have some changes. Second model is trying to address that since has forwarding
sublayer all inline, so go towards that model. Other model keeps service agg,
or not, keep same. Maybe cleaner? Maybe this one is just as good, keeps 3
levels. Didn't want to create another layer. Another point, when configuring
this way, don't have to spec completely down to (incomplete sentence -
restarts) Once we have a pointer to agg group, can fill in other details, so if
can simplify config that way, say don't have outgoing list, this one may do
that, seems to achieve that, probably the way to go, in slide service sublayer
with agg label. Other question was can we do this w/o even adding agg, just use
a label? Have a label stack, service sublayer, agg layer part of label stack.
Didn't do that since harder to keep consistency between pieces if didn't
specify agg piece. Lou Berger: Wasn't suggesting all in one label stack; saying
agg service, could put a-label there. Don Fedyk: Have to think about that,
can't think on the fly that fast. Lou Berger: Take to list or Monday meeting to
discuss.

Don Fedyk: Terminology: "Relay Node" vs "Relay Function"? Any comment?
Lou Berger: Distinction? A node can do multiple functions, relay traffic.
Asking if can do both? Don Fedyk: Asking if term "node" implies that is
monolithic. Would prefer "function" since behaving for this flow as a relay
function, as opposed to a relay node. But willing to go with whatever
terminology group likes. Xuesong Geng: Prefer "node" rather than "function"
since there could be a lot of functions, e.g. terminate tunnel, also do
replication. So relay node is more precise in this case. Don Fedyk: OK if
everyone fine with this. Lou Berger: Any effect on the model? Don Fedyk: No.
Lou Berger: Just be consistent.

Don Fedyk: Do we need all of these functions? (slide Case C, Agg of multiple
detnet fflows ar relay node) Do we need C-4? Or is model OK without it? Need to
review. (No discussion)

Don Fedyk: In C1 has stacked f-labels. In C2, single forwarding label. Question
is do we need this? Could aggregate at service sublayer? Yeoncheol maybe has
point here?

Lou Berger: Two use cases to support?
Don Fedyk: Do we need to support both, are we going overboard here?
Lou Berger: We are supporting data plane, need to support that here.
Yeoncheol Ryoo: Cases are based on data plane document.

Balazs: Using f-labels to identify flows? So creating use case for that?
Do nodes have own label space, or use interface label space?
For interface f-labels can identify detnet flows?

Lou Berger: Could just be classic LSPs.

Don Fedyk: Case C-3: Difference of B case is at ingress node with a-label, now
doing at relay node For Case 4, now aggregating f-labels so in stack have
f-label then a-label then f-label.

Lou Berger: Is this a use case in data plane doc?
Balazs Varga: Yes is covered if using f-label above a-label to identify flow.

Don Fedyk: D-4: Putting single label to agg multiple flows. What is diff
between this and saying have another DetNet serice in middle of network?
Everything is otherwise transparent? At what point do we call it a separate
service and start over again?

Lou Berger: HLSP can be done at node, or in between nodes. So want to model
both cases. Don Fedyk: Right. but how deep do we go in label stack before we
stop? Are we going too far?

Lou Berger: Node hierarchy, can do nested, but each one only understands the
one below, +1, -1, never goes beyond that, that is what we do in MPLS, GMPLS.

Don Fedyk: Agree not looking at all labels.
Don Fedyk: Can we make instance data from current models? Yeoncheol has
instance data in models to accompany these diagrams. Don Fedyk: These are the
models we have, any WG input solicited. Don Fedyk: Got some questions answered
today, helpful. No unnecessary cases so need to add references to model, andd
sample configuration to yanglint model. Nearing end of this we hope, maybe in
next iteration, get ready for last call after that.

Lou Berger: Planning to continue meeting on Mondays?
Don Fedyk: Yes, making progress.

Lou Berger: Same link as posted to list, anyone can join.

Lou Berger: Any other comments or questions?
(none)

We will be meeting online for a while, Prague to be virtual. Will continue
these informal meetings, and next IETFs online.

Janos Farkas: We should keep the momentum by meeting online until can meet in
person. Lou Berger and Janos Farkas: Thanks to contributors. Closing meeting.

> End        13:30

Virtual Bluesheet:
Name                        Affiliation
====                        ===========
Janos Farkas         Ericsson
Ethan Grossman   Dolby
Lou Berger LabN
Yuji Tochio  Fujitsu
Glenn Parsons        Ericsson
Balázs Varga           Ericsson
Carsten Bormann  TZI (mostly absent)
Don Fedyk LabN
Greg Mirsky ZTE
Pascal Thubert  Cisco
Reshad Rahman  Cisco
Taesik Cheung         ETRI
Xuesong Geng Huawei
Yuji Tochio Fujitsu
Jurgen Schmitt Siemens
Yeoncheol Ryoo   ETRI

Virtual Bluesheet -- Please add your name at the end, then help capture notes
in-line below. NOTE TAKERS ADD YOUR NAMES HERE (not required): Ethan Grossman