NETMOD Minutes IETF100 Version: Nov 14, 2017 Session 1: WEDNESDAY, November 15, 2017 1330-1500 Afternoon Session I Sophia Audio Recording: https://www.ietf.org/audio/ietf100/ietf100-sophia-20171115-1330.mp3 YouTube: https://www.youtube.com/watch?v=-5LJyVJVuPQ Session 2: WEDNESDAY, November 15, 2017 1520-1650 Afternoon Session II Sophia Audio Recording: https://www.ietf.org/audio/ietf100/ietf100-sophia-20171115-1520.mp3 YouTube: https://www.youtube.com/watch?v=x7go1IxMZXc Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-netmod Jabber: xmpp:netmod@jabber.ietf.org?join Session 1 Presentation Start Time Duration Information 0 13:30 10 Title: Intro, Charter & WG Status Presenter: Chairs #0.1 IEEE and BBF Liaisons: Tim Carey: BBF Liaison is similar to the IEEE. NMDA is now out there and standards organizations are trying to figure out what to do right, because they base models like on 7223. They split the config and operation. Now NMDA are bringing them back together. There needs to be some guidance. NMDA stable? When will it be complete? How long will be keep the -state in the appendix? Lou Berger: You should follow the refactoring approach that we're taking on our existing RFC's including having the stateful version in the appendix. Do you see that type of response causing being well received? Tim Carey: I think they're willing to accept that. They would want to know, in the interim, how long would we be doing like the state model separation? Lou Berger: The current of recommendation within the ietf. I would be hard pressed to see that it would be different outside of ietf. But one of the nice thing about the recommendations with having this these modules in the appendix. It is that sort of is good risk mitigation because you can go down that path while the other parts being developed without any concern about in long term incompatibilities. Lou Berger: Call for volunteer for draft liaisons response. (Michael volunteer to handle it) Benoit Claise: This week we had a meeting with IEEE management team. We went the same thing. The point is that we've got multiple source of information, we've got like the tool that Rob wrote on converting things. I could select all yang modules of IEEE and see States via catalog. I think that what we need to do is be proactive and contact all the different SDOs in the most project that are dependencies on or yang module and explain what the guidelines of the tool. Tim Carey: One of the things I know from the BBF perspective is, they want to make sure that the state models will exist for a period of time, because they've got stuff that they just published and they got to react right. Kent Watsen: You're asking about the state modules that we're publishing in the appendices of various RFC's? Tim Carey: Yeah. When we do nmda that we would also do state version of the thing. We keep doing that for a period of time until the industry can get their stuff then reformed up. Kent Watsen: I don't think we've ever put a timeline as to how long we would continue doing that, but I assume we would continue doing that for as long as the market needed it. # 0.2 Current Milestones # 0.2.1 interface-extension Lou Berger: Do you think the documents will be ready for last call? Robert Wilton: On (draft-ietf-netmod-intf-ext-yang) I need to add examples into that document. So that one's not far away. The problem one is the sub interface yang (draft-ietf-netmod-sub-intf-vlan-yang), I changed the structure to simplify it, and IEEE had some concerns with that. So, I need to follow up with them to check that they're happy with it. The current structure in terms of how the VR tags are represented. So, it depends on how quickly that goes. They say fine then then it's ready, they say no then there be more discussion. Draft: N/A 1 13:40 15 Title: Post LC Update: Schema Mount Presenter: Ladislav Lhotka Draft: https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-08 # 1.1 Prefix/namespace declaration option 1. no change; option 2. replace uri with module name; option 3. use both URI and module name Lou Berger: As both contributor and chair, we have gone to the last call on this unless there's a specific issue that we're fixing we should not make the change. Ladislav Lhotka: Authors prefer one (no change). Dean Bogdanovic: I go for no change, but if we would agree all to change, then I would say go with option number three. # 1.2 NMDA Support Dean Bogdanovic: This isn't in the real life scenario. This is a theoretical corner case. Ladislav Lhotka: yeah, it is as I said it's possible that it will never happen, but the schema case is really general. So you can use it as augments anywhere and don't care about anything in this case. It is just this small catch. I'm not saying it's a big problem, but we have to I care about this. Dean Bogdanovic: I really don't see it as a real-life problem. Dean Bogdanovic: WRT slide 5 (NACM Considerations): Regard to the rules from the LNE perspective they are really important. Data coming up with the rules in this document will just delay the schema mount. And we really learn what rules would we really need as a minimum. I suggest to put it in NACM. Ladislav Lhotka: It also make sense because this schema mount mechanism is designed to work without NACM. Kent Watsen: 6536bis is already with the IESG Lou Berger: Is there an issue with the NI case? Ladislav Lhotka: No NACM works with NI case. Lou Berger: LNE with managed=true is the same case as NI so should be okay. With managed=false. no access is supported from the parent context -- basically schema mount isn't used in this case. Dean Bogdanovic: Agrees that this isn't an issue with the LNE case. Martin Björklund (via Jabber): @mic: I think it is better in this document. Martin Björklund (via Jabber): @mic: the LNE data is readable from the parent. Martin Björklund (via Jabber): @mic: no it should be protected by NACM. Martin Björklund (via Jabber): I think we MUST handle NACM, for any mounted data, since it is readable. # 1.3 YANG Library & Schema Mount Integration Robert Wilton: YANG Library is currently open for update Re: slide 7 (Proposed Re-Organization): Lou Berger: given post-LC, a doc re-org would cause a reset. Is it really needed? You have also raised this comment multiple times as the document has progressed, and we have agreed to keep in one document. Martin Björklund (from Jabber): I don't want to split the doc Martin Björklund (via Jabber): we've discussed this before. it's just a split of the content. Dean Bogdanovic: Splitting is the wrong exercise to do and what we have is good enough to move forward. 2 13:55 15 Title: Post LC Update: ACL Update Presenter: Sonal Agarwal Draft: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-14 # 2.1 Support for different combinations of statistics Re: slide #3 (Support for different combinations of statistics): Dean Bogdanovic: The stats collection and the A are highly dependent on the basic implementation. Most can do that only on the ingress side, and not on many of them will have collection on the egress. So, in this case, you sent what you’re trying to put onto something that will not always work on all implementations. Sonal Agarwal: The model allows collection on either. Mahesh Jethanandani: Stats collection can be either ingress and/or egress. Dean Bogdanovic: Why not just do this as an ACL with an action counter? This is a standard way to implement it (that avoids the issue). Mahesh Jethanandani: We should take this offline # 2.2 Slide 4 Dean Bogdanovic: Support for ACL-set application on interface: Dean Bogdanovic: Is list of ACLs an ACL topology, applied to one interface? In many implementations, only one ACL is supported per interface.You cannot have different topologies except serial ones is a pretty hard limitation on some of them, you can put them. Robert Wilton: Vendors can put a deviation on the model to restrict the list length to a maximum of one element, if they can only support a single ACL per interface. Sonal Agarwal: We can add that in. # 2.3 Open Issues (slide 7): John Easly: You were saying the different types of ACL you're referring to ethernet, V4 and v6, right? Sonal Agarwal: Yes, there can also be mixed types. Dean Bogdanovic: ACL model is getting complicated, turn into such a mess with deviations from the vendors. Can we create a simple base model and then have extensions? Rick Taylor: May want to ACLs in software and match on any fields. Jeffrey Haas (via Jabber): @mic: In order to do a base model and extensions, you must first know what the expanded form would look like. Mahesh Jethanandani: To address Dean's concerns around creating a base model, you can declare feature "eth" and get just the "eth" container. Cannot make it more basic than that. Dean Bogdanovic: right now vendors want something common and simple, not overly complex. 3 14:20 5 Title: Session 2 kickoff: Handling Revisions Presenter: Chairs Draft: N/A 4 14:10 10 Title: Example of major revision change: rfc8022bis Presenter: Acee Lindem Draft: https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-01 5 14:25 20 Title: YANG Revisions Presenter: Benoit Claise Draft: https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-00 6 14:45 15 Title: YANG Revisions Discussion Presenter: Chairs Draft: N/A Kent Watsen: We're only able to implement a single version of a module at a time. This works because of the backward compatibility. Would we need to for instance support multiple versions of module to enable both backwards compatible view of the legacy version and also the new version? Benoit Claise: Not in a server on a typical router; but maybe in an Orchestrator or controller, where there is like service composition coming from multiple network elements that might be the case. Lou Berger: One of the things that we've been trying really hard to fix with yang is the problem we have with CLI, when the version changes on the CLI on a router the user has to change their tooling. I think we're at run a risk of repeating the same thing here, if we don't allow a server to export both the old and the new, and allow the user to choose what they use. Benoit Claise: We could export multiple who wants library but only one could be implemented. Now you want to give the choice to say I'm exporting new one and the old one you could advertise them, and you expect that one controller or one Orchestrator will say which one to use. Lou Berger: We have to be careful here because if we're not careful we'll end up repeating the same problems or reintroducing the same problems we've tried to get away from with yang. A customer has a deployment there, they have some old software and they have some new software, they want to be able to keep the old software running and they upgrade your router, but they also want to be able to use the new software. Yes maybe on a particular session you would only use one version and that might be the compromise, but you would want the server to be able to support both the old and the new. Benoit Claise: Is this an issue which is introduced by this proposal? Lou Berger: It is. In the current requirements you can't have it. Because the current requirement is to always be backward compatible. We're trying to say, let's be careful and think about it. Ladislav Lhotka: First of all, I would like to say that I support this effort. Second, I believe it would be useful to move the update rules away from the specification of yang. And maybe define them in the draft just to say what changes, what updates, are possible within one minor version, and so on. Because I believe in the definition of that data, our modeling language such a policy really has no place, because I can imagine that some groups may use yang even with slightly different meaning of the versioning rules. So, I've been against these update rules in RFC 7950 for a long time, so that would be my proposal to really do it now and move away from the current restrictive rules. Balazs Lengyel: Based on the long mail I sent yesterday. Even today we allow backward incompatible changes due to the deprecate rule. Lou Berger: Current rules define “deprecate” to support a transition period where support is phased out before being removed. The point of the rfc8022 was that we were *not* using deprecated but jumping straight to obsolete. Balazs Lengyel: I disagree, the rules allow immediate removal as it doesn’t state MUST support when deprecated. The other main point is this is also a big problem for OSS for any network management software. If I get the device with the newer model, can I still work with it, like I did with the old? Or is it dangerous because there are unknown changes? So work is absolutely needed. I feel that packages could handy handled separately. Benoit Claise: I agree with this last point. Balazs Lengyel: I recommend semantic revision be required on all future models. Also will we keep the prefix, or if we change the prefix, we have the item data migration problem because we have to go and find all the stored updates in the file system of the operator, and change the prefix there as well. Martin Björklund (via Jabber): @mic, to Balazs - a server can remove an entire current module if it wants to in a new software version on the server. Jeffrey Haas (via Jabber): @mic: This issue is somewhat analogous to the issue of multiple modules managing similar information. For example, the BGP module, which we have openconfig and one still working through IETF. Basically, structural mapping. Robert Wilton: 1) I strongly support this. I think that to change a module's name and the prefix whenever you ought to do a major version change is a real hassle for everyone involved. 2) I also quite like Lou's point that you use github develop these modules and want to put patch changes and things like that. That quite well in terms of how you naturally manage this. Developers are also very used to using this sort of version scheme. So, it's not like it's a brand new scheme that people don't understand. It's a scheme that's well used in the industry seems to work. It seems to be well understood. I also agree with the suggestion, that import by revision effect needs to be fixed. 3) Perhaps the issue came up about having to support two versions of the same module in terms of upgrade ability. That perhaps could be solved by you configuring on the device which version you want the device to provide, allowed to different clients both to access the different versions. But it does allow some control of which version it's going to export. Dean Bogdanovic: I support this work. Balazs Lengyel: My basic problems are 1) Non-backward compatible (NBC) changes should be allowed in some limited cases 2) It should be possible to determine two module versions' compatibility without a line-by-line comparison 3) It should be possible to indicate that a part of a schema is deprecated, but is still present, implemented and usable Jeffrey Haas (via Jabber): The issue isn't necessarily two versions of same module, it's the blast radius effect. You update a major module, you have to upgrade the entire ecosystem. Ladislav Lhotka: it's okay to reuse a prefix Benoit Claise: Lets agree on the problem(s) we want to solve Robert Wilton: Need to be careful on packaging implications Balazs Lengyel: 1) I need a small bit of information like the module name combined with the semantic version that tells me if this version of the module is compatible or not with the previous one. 2) We want to allow some level of incompatible changes the routing and some others stated. They should be indicated clearly. Lou Berger: We must agree on the problem statement, we have a rough problem statement (slide 2 of chairs slide), and it appears from comments in the room that this is sufficient for to start thinking about solutions. Please think about solutions and discuss on the list. Given the importance of this topic we’re likely to have an interim on the topic. Sue Hares: are augmentations covered Lou Berger: Yes they must be covered. Robert Wilton: Don’t forget about imports Dean Bogdanovic: RestConf Api version also need to be supported? Lou Berger: Should support all protocols (netconf, restconf, etc.) Benoit Claise: Can we agree that the proposed solutions go in the direction of keeping the YANG module names? Lou Berger: This has to be discussed in the context of the specific solution. Adjourn 14:25 Session 2: WEDNESDAY, November 15, 2017 1520-1650 Afternoon Session II Sophia Audio Recording: https://www.ietf.org/audio/ietf100/ietf100-sophia-20171115-1520.mp3 YouTube: https://www.youtube.com/watch?v=x7go1IxMZXc Presentation Start Time Duration Information 0 15:20 5 Title: Intro Presenter: Chairs Draft: N/A 7 15:25 20 Title: Post LC Update: Revised Datastores Presenter: Robert Wilton Draft: https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-06 # 7.1. Datastore schema & conformance Re: slide #8): John Easly: would like to seem all terms in drafts Robert Wilton: no ambiguity in this draft, the ambiguity is actually in schema mount John Easly: I would say as long as you can actually determine. That link between the two documents to find that definition would be sufficient, but to leave them undefined, I think is a bad course. # 7.2. Actions/RPCs (Re: slide #11) : Lou Berger: is it possible for the RPC/action to define where it operates Robert Wilton: this is already the case Lou Berger: need to ensure that it's adequately covered Sue Hares: ephemeral datastore may be resolve by rpc? Robert Wilton: The issue is not about where the RPC is acting, the issues about any parameters. So if you've got parameters that have to be evaluated against a different datastore, then that would require future work. That requires new work. Martin Björklund (via Jabber): which I2RS drafts has those RPCs? Sue Hares: RIB. Tim Carey: how can we execute action for a node that is dependent on the presence of hardware? Robert Wilton: can't, unless we introduce a parameter to the action statement that specifies a datastore Christian Hopps: We could use function terminology in which case an RPC. It would actually be the inputs. Martin Björklund (via Jabber): these RPCs seem the work today as they're using strings, not leafrefs Sue Hares: look at the next hop id Robert Wilton: are we happy with this update? Lou Berger: yes, just need to check on the language Lou Berger: we've reached the threshold of changes where we will need to do another LC 8 15:45 15 Title: YANG Tree Diagrams Presenter: Lou Berger Draft: https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-02 # 8.1. Re: slide #4 (3 options): 1) all guidelines in 6087bis; 2) all guidelines in a wiki; 3) all guidelines in this documents Lou Berger: prefers option #3 Robert Wilton: prefers wiki (option #2) Christian Hopps: agrees with Rob, prefers wiki (option #3) Robert Wilton: also for 6087bis Tim Carey: also seems to prefer wiki Mahesh Jethanandani: 1) Prefers option #3 2) Whatever we decide we better have a clear guideline because we have people waiting on their documents wanting to publish, but since this document is not making progress. 3) If it becomes an RFC, would this be a normative or infinitive reference? Lou Berger: I think this is an informative. Because it doesn't go on the wire and it's not a best common practice for a protocol. Balazs Lengyel: prefer #3 Lou Berger: coding standard update Benoit Claise: informational, yes Benoit Claise: prefers #1 Robert Wilton: re: IEEE looking at 6087 (not 6087bis) Ladislav Lhotka: support #2 Christian Hopps: do both draft and WIKI, make it as #4 Mehmet: not happy with these options, supports option #2 Martin Björklund (via Jabber): support #3 Kent Watsen: (polling) : support #1 -- a few support #2 -- a good number support #3 -- a good number support #4 -- a few 9 16:00 10 Title: YANG module for yangcatalog.org Presenter: Joe Clarke Draft: https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-02 Joe Clarke: Clarification on the presentation: my wording implied one can only do diffs when the MAJOR version changes. This is not the case. We present the diffs in the API if there is _any_ change to the versions for a given module name Ladislav Lhotka: would be a good idea if the metadata could go into the module itself. 10 16:10 15 Title: Module tags Presenter: Christian Hopps Draft: https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 Christian Presenting Robert Wilton: I think it's useful. I prefer the solution in terms of the configuration. I think that's fair discussion there, but generally yes, I'm positive on. Kent Watsen: (poll): How many think this is a problem that the WG should work on: A few How many think this is a document that should be adopted: The same 11 16:25 10 Title: YANG Data Extensions Presenter: Kent Watsen Draft: https://tools.ietf.org/html/draft-bierman-netmod-yang-data-ext-01 Ladislav Lhotka: why not use augment Martin Björklund (via Jabber): Augment doesn't know anything about extensions Use case for "uses-yang-data" in ANIMA with the voucher draft. Eric Voit: Support because we need it in the NETCONF notification draft(s) Lou Berger: Sounds like this is work needed by another WG and this WG is the right place for this work. Lou Berger (polling): How many have read: very few How many think this work should be adopted: a little more How many think it should not be adopted: none Lou Berger: Expect to move towards adoption on list Robert Wilton: This should be adopted and moved along quickly Juergen Schoenwaelder (via Jabber): the scope of the work remains unclear. 12 16:35 10 Title: YANG for FSMs Presenter: Nicola Sambo Draft: https://tools.ietf.org/html/draft-sambo-netmod-yang-fsm-00 Gabriele Galimberti?: Would be possible to add the output of the state machine related to the state, instead of only to the transition? Nicola Sambo: yes, this can be done, can be clarified in an update. Christian Hopps: where are the FSMs? - are they already there, or are these new ones? Nicola Sambo: aims to be generic, covering a couple of use-cases Lou Berger: Currently FSM has to be known by both client and server Nicola Sambo: The functions can be defined in the list action Lou Berger: not clear what flexibility the client has? Robert Wilton: Not sure if there is enough support. But generally useful to standardize a common capability. Lou Berger: not sufficiently clear at this point for the WG to decide if something that should be worked on in this WG Eric Voit: NETCONF working on something similar (Igor Bryskin) and perhaps work on a joint problem statement for the WG.6 Alex Clemm: Same comments, need add some problem statements. 13 16:45 5 Title: ARP YANG Model Presenter: Xiaojian Ding Draft: https://tools.ietf.org/html/draft-ding-netmod-arp-yang-model-00 Lou Berger: Will it also be presented in RTGWG? Xiaojian Ding: Yes, I will also present it in rtgwg.