NETMOD Agenda IETF 99 Session 1: MONDAY, July 17, 2017 1550-1720 Afternoon Session II Congress Hall I Audio stream: http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u Session 2: WEDNESDAY, July 19, 2017 1330-1500 Afternoon Session I Congress Hall I Audio stream: http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u Slides: https://datatracker.ietf.org/meeting/99/session/netmod Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-netmod?useMonospaceFont=true Meetecho: http://www.meetecho.com/ietf99/netmod Jabber: xmpp:netmod@jabber.ietf.org?join Available post session: Recording: https://www.ietf.org/audio/ietf99/ YouTube: https://www.youtube.com/watch?v=r_bw099k6Hg > Session 1 > Num Start #Min Information > 0 15:50 10 Title: Intro, Charter & WG Status > Presenter: Chairs > Draft: Andy Bierman: Entity draft being updated to reflect NMDA. It's probably close to being ready Lou Berger: OK that it'd be great if we could see an update in short order. So we can go to last call - all raised issues should be resolved at this point. Tim Carey: Can I just get a clarification. It looks like then entity will probably be the first draft that will see the data store guidelines if you will include it in? Lou Berger: Are you talking about first to publication request or first published? Tim Carey: I guess it will probably be the first publish. Lou Berger: There are other internet drafts that have already been refactor to the format NMDA. I think we have a good examples, if you're looking for an example there are ones that are far more complex than this one. This is actually a pretty simple model. In terms of what we submit it to IESG for publication. I certainly hope that this is out very soon. So, it is likely to be the first one submitted by this working work. Benoit Claise: It might be a good to some liaison statement to a different SDO which is doing yang models to explain our NMDA right Lou Berger: That's actually an excellent idea. The one question is do we wait until we have agreement on the guidelines text from the working group, which we don't have yet, or go just based on the AD's recommendation that's been distributed? Maybe some who work in other SDOs might have a view on this. Benoit Claise: I think we could do both. For example, it was mentioned in the IEEE IESG meeting this week. I forgot to mention that we could have a formal email, because we have the contact. One of our good text ready then we mentioned that. William Lupton: Representing for BBF, we are welcoming liaison telling us about NMDA. But equally, of course when it already. > 1 16:00 10 Title: Network Access Control List (ACL) YANG Data Model > Presenter: Sonal Agarwal > Draft: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11 Kent Watsen: Regarding the open issues, are there going to be technical changes ? Sonal Agarwal: Yes, and actually adding the "containers" that needs some thoughts on how we want to do. But I've already gotten some ideas. I've spoken to various people. Kent Watsen: OK, how many people have read this version of the draft, which is in last call. (a few) Lou Berger: At this point we may want to send a message to the list letting all know there is going to be another version, and then do another last call. Benoit Claise: When will the next version be available? Sonal Agarwal: November. Mehesh Jethanandani (speaking as co-author): I think we should be able to do a little better than November. We should have an update within the next month. > 2 16:10 20 Title: Revised Datastores > Presenter: Robert Wilton > Draft: https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-03 Mehmet Ensue: what is your proposal for the handling of the term configuration in NETCONF RFC (RFC6241)? Are You proposing to replace it? revise it? delete it? Robert Wilton: I don't know. I guess we're going to supersede it effectively. Mehmet Ensue: So we have here a new term definition. We should be interested to decide how we want to handle the old term definition. It can be deleted I mean in Netconf this RFC? Or the same can be used there too but copy and paste is not good. Lou Berger: Which RFC are you thinking about? Mehmet Ensue: The Netconf protocol RFC. Lou Berger: I think then it's a good question for the Netconf working group. Mehmet Ensue: Yes, but I assume you would have a proposal how to handle it. Lou Berger: One option is that this document lists is updating that RFC and we can identify that the update is in the name. The other option is that the supporting documents that are going on in Netconf. I would defer to the Netfconf chairs on how they would like to do. Mehmet Ensue: That needs to be a discussion in Netconf for sure. It would be probably consistent to remove this term from Netconf this RFC and refer to NDMA RFC. Lou Berger: that's a fine solution Kent Watsen: And also add to that many times in drafts when they're importing terms from other drafts, they specify which draft that are importing the term from. So you know for the term configuration, they could indicate specifically it's the old or the current Netconf RFC or the new revised datastore. David Lamparter: I agree with default values in schemas, because it's not only the device that needs to be aware that the absence of the value, something different from the default value, but it's also the client libraries and everything that passes through in the middle. So I think there's a requirement here to kind of maybe not even have the default of the schema in the best case, because otherwise you're still trading on thin ice. Robert Wilton: Yes, in the particular case you've got configure then a configuration node often has a default value associated with it, and that configuration knows exists in the operational state they store as well, so you have it often in the schema, but what I'm saying is in this case you would return that value if it's in use. Andy Bierman: The reason for suppressing defaults was to improve the transfer efficiency. So if you have a whole bunch of stuff that's in the default value and you're wasting 60% of your packet with stuff that's redundant, you don't get that efficiency. So now you're saying we don't care about efficiency, we're gonna send all the values all the time. Robert Wilton: No, We want to get a definition of “in use”. That doesn't mean that we throw back a lot of irrelevant data, but we try and find that so scope sensibly that the default values you get back. Ones you might be interested in. So if OSPF is turned off you don't return all the default values for OSPF that aren't of interest, but it means that OSPF turned on then you do return those values Andy Bierman: It seems that explicit mode is clearly not useful because you're talking about read-only data, so it can't be explicitly set to the default value. So only trim really matters which is if the nodes not there then it must be using the yang default and I think that definition is rather clear and yang 1.1. I don't understand why it needs to change now. Robert Wilton: So the other concern that I have is this ambiguity that if you don't return of value. That mean the device doesn't know about it Andy Bierman: If it's not there, you're claiming conformance to. Then it is using the default value no exceptions. So I think the part of the architecture that's completely lacking is a concept of conformance for data stores. So I'm reading a YANG module, I want to know what is a server that is conforming to this model supposed to do. And you completely failed on providing that information for data stores before we used to know this is candidate running and startup there were only three data stores. There's no way to add new ones like the operational data store which is now allowed. So really think it there has to be something in the yang module that tells developers what the conformance expectations are. And the defaults as is it could be considered part of that. But the problems that I've been hearing about from customers with operational data is how to make it more efficient. This has not been a fixed yet. Because the problem with get is if I get an entire list while I'm getting 10,000 entries. So we've had to add operations that make it much more responsive to iterate through a list. And of course you need to iterate through a list without knowing the keys because operational data the keys change all the time. So I think you really should focus more on efficiency because it especially with you know large routers which you have a lot of the getting, lots of operational data, it needs to be efficient. David Lamparter: Sometimes libraries can't tell if it was a default Robert Wilton: I think your suggestion is better to return a value even it's the same as the default. David Lamparter: I'm saying that if you want to signal this bit of information whether the value is actually in use then you need to put that bit of information somewhere. That isn't the existence of the value, because the existence of the value is not something that you can reliably test for. Angle Erikson: I don't think even the absence of the value doesn't really mean. That the default is enforced, maybe some other protocol remove the default value, and that's why it's not there. Robert Wilton: the case we’re thinking of is if one of your demons has crashed and it's not returning any data then effectively. That doesn't mean that those values are now and turn into the default values. That just there's no data to be returned there and either you hang the whole response or you've got to compromise. Ladislav Lhotka: I think semantics for defaults may differ in , so it could be difficult use them Robert Wilton: I think in terms operational we regard the default value, and yang models being guiding to the reader rather than meaning anything else. So rather than affecting the actual data returned. Sue Hares: Confusion regarding description of the 'dynamic' identity ("except derived identities") Robert Wilton: I think is there might be a typo effectively what its meaning here is the dynamic identity itself is probably more likely to be abstract and that rather than returning that at your dynamic data store you derive from your identity the right value. David Lemparter: should put in metadata if something not in-use Tim Carey: I think the problem with that is I think one of the reasons for the the default value as stated by Andy was that you were trying to save space, so if I'm sending metadata back must send the value back? Phil Shafer: with-defaults was primarily to reflect variations in how *configuration* (not state) was handled. Less with respect to space savings. Balazs Lengyel: different methods of handling before the the other method is that if you have a default it gets there and you don't care any longer how it got there. 3 different handling and I think if we have with defaults on get data that would solve the capacity issue so why not handle that way Phil Shafer: The operational data store gives actual, in-use values only. If not in-use, it's not returned. Ladislav Lhotka: regarding templates, which drafts references, how are deletes of unexpanded templates relate to validation Robert Wilton: will need to consider handling templates Balazs Lengyel: If we implement only part of the NMDA datastores (is that allowed?) How shall we indicate it? What compliance requirements exist for these non-fully NMDA compliant implementations? Robert Wilton: when you have a large change come in, will have see inconsistencies in existing models which won't be present once have NMDA data stores Chris Hopps: if an interface is configured, but down, is it returned in Phil Shafer: That was a comment on operational. It's always intended that your intended configuration in operational, you'll see what's in use, if it's not being used you shouldn't see it. Rick Taylor: confusion between 'dynamic' and 'learned' Robert Wilton:This identity really means dynamic data store so maybe the name of that identity should be dynamic data store all one of those dynamic data stores. "Learned" is coming from a protocol that's not one of the configuration protocols. And not through a dynamic datastore. So something like your BGP peers, when they return values that override your configuration, that would be marked as learned configuration. Phil Shafer: idea is that dynamic data is inside the "ecosystem", whereas 'learned' is more from an external system (e.g.: DHCP). Chris Hopps: I have a suggestion on how to resolve the interstate interface down State. One way: detect a failure by looking into operational state to see if it changed; the other way, use a notification. Jason Stern: How about the case if that line card is physically unplugged from the router? Robert Wilton: it be removed from applied configuration. Lou Berger: how much time do you need to address these open issues? Robert Wilton: don’t know yet... Lou Berger: milestones publication request in Oct, which reflects a LC in September... Phil Shafer: important to keep current deadlines/targets > 3 16:30 15 Title: NMDA Guidelines > Presenter: Robert Wilton > Draft: https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 Ladislav Lhotka: In this example (slide 6), one interesting case is this router ID. Because in the routing data model’s base feature that makes this router ID available at the global level. But if this feature is off, it doesn't mean that the router doesn’t have any ID. It only means that the ID be assigned automatically. So it means that in this case some routers will have both outer ID in configuration and in state, but some routers will have it only in state data. But if we keep this if-feature on this router ID, we need to distinguish it, if you want to have just one data node for both configurations data and state data. Robert Wilton: You can still get away with one node here, and the desire that you look at it on the same path, and then resolve with your configuration. Sue Hares: This can be set, I believe it operates in the way that is expected in the BGP configuration whether it's unique variable? How it’s populated? Can it be populated from the base? Robert Wilton: If the origin from the base, origin='defaults', or you'd have configured Igor Bryskin: how I can see this data what is actually configured versus what was intended to configure and has failed. Robert Wilton: You can't point one unless you create this duplicate separate tree. But in many case you don't actually know that (intended). All you know is the system's accepted the configuration will act on at some point. What we're proposing here will be consistent. Andy Bierman: If someone want the keys for this list to be different in operational state than config? I have one more key to add or they say the operational state value leaf is a different value. Are we discouraging people from that and forcing them to use the same keys everywhere? Or not expose a key that they wanted to put in there? What's the guidelines for when the model is not this simple? Jabber: (11:07:22 AM) Eric Voit: If I can’t be heard, my question is: When do the NMDA modeling guidelines take effect? For example, when must drafts entering WG last call match to this? Jabber: (11:15:31 AM) LouBerger: @Eric V WRT your question - currently the AD recommendations are in effect. The WG has not yet agreed on its position > 4 16:45 20 Title: NMDA Q&A > Presenter: Robert Wilton [This Q&A was mixed into the above two presentations, and the slides were not presented.] > 5 17:05 15 Title: BBF Update > Presenter: William Lupton > Draft: Benoit Claise: regarding NMDA, do you have any plans for updating your modules accordingly? William Lupton: We don't yet have a plan but will formulate one asap. I expect that we will follow the same guidance as is being given to other IETF working groups Lou Berger: We use the Q&A session(Today) to explain it. Andy Bierman: does netconf-state (6022) really need to be updated? Lou Berger: this needs to be discussed more > Session 2: > WEDNESDAY, July 19, 2017 > 1330-1500 Afternoon Session I > Congress Hall I > Audio stream: http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u > YouTube: https://www.youtube.com/watch?v=kNfYz2HldFs > > 0 13:30 5 Title: Intro & WG Status > Presenter: Chairs > 6 13:35 20 Title: Schema Mount > Presenter: Lada Lhotka > Draft: https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-06 Dhanendra Jain: How is this reference different from a bind a NI to an interface. Ladislav Lhotka: Every bind reference is bounded to a particular interface Dhanendra Jain: Check that interface tree is not available. It's really will only for the context of any evaluation, such as when statement, or must statement the inside the mount. Your system get these interfaces. Lada we added for the purpose of evaluation. Balazs Lengyel: if we have nested mounts, can the nested mount reference the parent's schema? Ladislav Lhotka: Current it is not possible. Lou Berger: You also have recursive support. Ladislav Lhotka: I don't think that it's very sensible to define many levels of scheme amounts. We are addressing here is the network device model. Lou Berger: Speaking as contributor to LNE and NI model, If you start at top an bind an interface to an an LNE then into VRFs, you don't end up getting 2 step references, you just need a single step. Balazs Lengyel: If you have interfaces at base and mounted, then do you have problems with the keys at multiple levels. Ladislav Lhotka: Discussed this last time, xpath expression evaluation would allow for both. So there needs to be some warning that this shouldn't be done. Lou Berger: This is an implementation time thing. Down to implementation choice. Phil Shafer: If I mount 3 levels, can you get out of the parent to the ancestor tree? Ladislav Lhotka: one step one step up like in the schema hierarchy Open Issue 1: Acee Lindem: no doubt this would be useful. Call it a different name than context node, perhaps parent reference instead. Ladislav Lhotka: Terminology is in the context of Xpath. Kent Watsen: Is option 1 the author’s preference. Ladislav Lhotka: Yes Kent/Ladislav Lhotka: We can take the issue to the mailing list (if no objection, then option 1 will be selected). Open Issue 2: Robert Wilton: does Martin have the same option? Ladislav Lhotka: yes. I believe that he agrees Robert Wilton: slight preference for the extension Balazs Lengyel: who controls what you can access from parent module? Ladislav Lhotka: This is true. If you do this, then the parent module has to know what is going to be used in the parent schema. Balazs Lengyel: This could be a good thing or a bad thing. It allows you to control what you expose and modularity is good, on the other hand you have to research… Ladislav Lhotka: This moves the responsibility. Currently, it has an implementation time feature, this would be when yang module be designed. Lou Berger (as a contributor): I raised this, and sees a use case for this. Both authors pushed back hard on this. This brings in design time mounts. As a contributor, I would really like to see it there, but as a user I see that it as good enough (as the person who raised the issue initially). Ladislav Lhotka: You can include it when you design a new model. Lou Berger: Don't want to discuss how we do extensions. We should be able to discuss when we do design time mounts. I think that this is a reasonable approach. Juergen Schoenwaelder: Why do you think that causes a problem with the YANG language version? Ladislav Lhotka: Clients might not need to know about the extension. Would be a problem if it understood the mount point but not parent reference extension. Balazs Lengyel: General question: if you declare support for a YANG module then you MUST support any extensions in that YANG module. If you support this module then you support all of them. Asking YANG doctors to answer this. Ladislav Lhotka: In this case, you can have these modules in yang library Lou Berger: I think the answer is yes, we can confirm in the RFC. Phil Shafer: It is a qualified yes. Things like features may mean that you never actually use it. Kent Watsen: Asks WG if the doc is ready for last call. [A reasonable show of hands] Kent Watsen: Is there a dependency on the YANG library work that has been proposed in NETCONF. Ladislav Lhotka: Currently, it have the dependency. We could use different revisions of the same module. All libraries used in the system should have a single YANG library tree. Lou Berger: Yes, OK to move forward? Ladislav Lhotka: Depends on YANG library document. Lou Berger: Still just an individual draft. Lou Berger: As a chair, we shouldn't wait for an -00 individual draft, or even WG doc. Need to be faster moving forward with YANG modules. > 7 13:55 10 Title: YANG Tree Diagrams > Presenter: Lou Berger > Draft: https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-01 Robert Wilton: x vs -x - seems confusing, not obvious enough... Ladislav Lhotka: I think this is not possible. In general, if you have this scheme amount references, it's really about instant, this tree describes the schema. It really depends on the evaluation of the reference XPath expressions. So it could happen not in the example because it's all the same. Lou Berger: That's not something that you would see it at design-time. We do believe that this is question from vendors that want to relay to customers what the schema really looks like. Ladislav Lhotka: If you use parent-reference YANG extension, it would be more clear what is available and what isn't. Lou Berger: May be forwarding looking and a future idea. We will use it in LNE examples. Juergen Schoenwaelder: The interfaces at thingy can only be generated if I have state information. So I can't get it out of the state information. Ladislav Lhotka: Wouldn't expect to see in module definitions. Balazs Lengyel: Are the top two lines (only used if I know the instance data). Lou Berger: Only the MP (mount point) which would show up in from schema data. Juergen Schoenwaelder: Should we be able to put comments in the tree? Rick Taylor: Comment on comments. Yes, add one now. Ladislav Lhotka: Opposed. Tree diagrams are normally generated by tools. Does this mean that the comments need to be in YANG modules as well. Also line space is quite long. Lou Berger: Send proposal on comments to list if there is interest. Chris Hopps: New formatting for RFCs, do these get prettified. Lou Berger: No idea. Chris Hopps: Question is really about line wrapping. Benoit Claise: Good to have a RFC, is there a commitment to update to this format from tooling folks, e.g. pyang and YANG lint. Lou Berger: Currently only change is adding "mp" for schema-mount Juergen Schoenwaelder: Is the extensions state currently empty, what do you plan to do? Lou Berger: We haven’t discussed it yet. Balazs Lengyel: Is it usage or definition of extensions that you are thinking about. Lou Berger: Usage. > 8 14:05 15 Title: Update on Routing Area WG YANG documents > Presenter: Acee Lindem > Draft: https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-08 > https://tools.ietf.org/html/draft-ietf-rtgwg-lne-model-03 > https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03 Chris Hopps: Module tags need more time to bake. Will try and push it forward. Dean Bogdanovic: On tags, other areas would be useful. Tags for YANG Catalog and YANG library would be helpful. Dean Bogdanovic: On L3VPN state, need to think about timestamping. Lou Berger: This needs to be stated in the Rtgwg. > 9 14:20 15 Title: Interface Models update > Presenter: Robert Wilton > Draft: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-05 > https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-02 > https://tools.ietf.org/html/draft-wilton-netmod-interface-properties-00 Glen Parsons:Tag/second-tag you rename it? It need to discuss in IEEE, liaison with us(IEEE?) Robert Wilton: Sure. Dean Bogdanovic: The skeleton of the draft looks that it provides another functionality that put in all the types and everything else what is needed. Lou Berger: How many people think this is an interesting work, and need to do in netmod WG? (A reasonable number) Lou Berger: How many people read this draft? (Less than previous question) Robert Wilton: can you fill in the IEEE comment from Glen Parsons? > 10 14:35 10 Title: Mounting YANG-Defined Information from Remote Datastore > Presenter: Alex Clemm > Draft: https://tools.ietf.org/html/draft-clemm-netmod-mount-06 Chris Hopps: Like a bind-mount. Lou Berger: Is there interest in this function in the working group? (tepid) Interest in talking/learning more? (a few more) Lou Berger: Doesn’t look like there is support in the room for this draft at this time. Next step is more discussion on the list for the WG to learn more. > 11 14:45 15 Title: YANG module for yangcatalog.org > Presenter: Joe Clarke > Draft: https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-00 Rick Taylor: why not try to standardize it? Robert Wilton: we want to evolve it rapidly, but may bring it in if the semantic-versioning draft takes off Phil Shafer: no need to standardize because no interoperability requirement