> 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