============================================================= NETCONF Data Modeling Language WG (netmod) IETF #82, Taipei, Taiwan TUESDAY, November 15th, 2011, 13:00-15:00, Room 101a Minutes Giles Heron, Juergen Schoenwaelder ============================================================= WG Chairs: David Kessens Juergen Schoenwaelder WG URL: http://tools.ietf.org/wg/netmod/ Jabber: xmpp:netmod@jabber.ietf.org Agenda: 1) Administrivia (chairs) [ 5 min ] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing - published RFCs: - RFC 6020 (draft-ietf-netmod-yang) - RFC 6021 (draft-ietf-netmod-yang-types) - RFC 6087 (draft-ietf-netmod-yang-usage) - RFC 6110 (draft-ietf-netmod-dsdl-map) - RFC 6244 (draft-ietf-netmod-arch) - status and milestones 2) Core system data model (Andy) [ 20 min ] - draft-bierman-netmod-system-mgmt-01 3) Core interface data model (Martin ?) [ 20 min ] - draft-ietf-netmod-interfaces-cfg-02 - draft-ietf-netmod-iana-if-type-01 - draft-ietf-netmod-ip-cfg-01 4) Core routing data model (Ladislav) [ 20 min ] - draft-ietf-netmod-routing-cfg-01 5) SMIv2 translation to YANG (Juergen) [ 20 min ] - draft-ietf-netmod-smi-yang-01 6) Related work (Martin ?) [ 10 min ] - draft-bjorklund-netmod-snmp-cfg-01 Summary: The NETMOD working group has met for two hours on Tuesday during the 82st IETF meeting. The meeting was attended by about 20 people in room with a few additional remote participants (including some key contributors). - was discussed and there are a few changes to be made. The next revision of the draft will appear as a WG document. - and the related IANA document are in WG last call and so far no major issues have been raised. The discussion focused more on where it is not clear cut what needs to be included and how model elements are split between this draft and . This will require more discussion on the mailing list. - has been discussed and received some positive support from some routing people in the room. The revision of this document is likely soon going to WG last call to encourage more reviews. The only bigger open issue seems to be whether the IP forwarding tables should be moved into the IP configuration draft. This will require more discussion on the mailing list. - Several issues concerning have been recently brought up on the mailing list. Several have been resolved during the IETF meeting (mostly on the mailing list) and an updated draft is expected shortly after the meeting. - A new attempt has been started to find agreement on an charter addition to cover work on a data model for configuring SNMP. There was no specific input at the meeting. It seems only one contributor had an issue with the originally proposed text and we will have to see whether the new text finds consensus. Actors: - DR = Dan Romascanu - JS = Juergen Schoenwaelder - AB = Andy Bierman - MB = Martin Bjorklund - LL = Ladislav Lhotka - DK = David Kessens - AM = Andrew McGregor - PS = Phil Shafer - BF = Bill Fenner - P? = Peter Slides: https://datatracker.ietf.org/meeting/82/materials.html Audio: http://www.ietf.org/audio/ietf82/ Meeting Notes: * Core system data model - System management YANG module not posted as WG document since Andy missed the -00 cutoff. - AB started by revisiting the changes since the last version. - AB: Should the document go into details how to configure NTP server? And is that in a separate submodule or a separate module? AM: Client side configuration is necessary. AB: Some vendors just ask for name of NTP server. Is that enough? AM: That's enough for basics. But would be useful to have the ability to say if that system expects you to be a peer or a client. The rest is nice to have rather than necessary. AB: That's a good addition. AB: My concern is that if we get too deep into configuring an entire server then everything a system could ever do can end up in this module. But it'd be good to work out how we'd configure an NTP server. PS says we need a high level structure with services as a top layer and networking services under it. But is that a separate work effort? Might have to take to list? JS: The system module should focus on what's common to all systems out there. Only a minority of systems have NTP servers. AB: Andy - so yeah, perhaps can keep simple and work out ntp server later. DK: Let's keep system simple and only do common stuff. BF: On the topic of being an NTP client there's more you can talk about. Do you need to configure a source address. Do you want to prefer one server over another. Are we trying to do an absolute minimum? Or should we think about more of the capabilities that systems have. AB: I think you're right. Preferred source address has come up in other contexts. BF: That's a common request from customers. I've just been checking our CLI to see what else we configure. AB: I agree. If we're targeting this at networking devices we ought to fit in the parameters that most networking devices have. JS: It is very helpful if vendors send info as to what's important from their CLIs to the mailing list (i.e., the parts that people configure). AB: I think even when you install Ubuntu it asks for a prioritized list of servers. So that much is common. - AB: DNS section: nothing changed. Also done by Martin. LL: DNS options are not explained in draft. Description should be added. AB: Yes, good point. Not quite ready for last call yet. AB: System authentication area: Martin added some text for the introduction to these sections. Nothing else changed. No objections to this. Some issues related to user names etc. but that's beyond the scope of this. Shows up in a few places where user names are assumed. AM: Should LDAP be in this list? AB: Yes, if Martin's willing to add it. Or I could help. JS: It would help if someone could tell us what ought to be there for LDAP. AM: If it should? But should it be there? MB: If it is common enough we should add it. AM: We could rule it as out of scope and make it a separate module if someone wants to put it in. JS: It would help if we had a concrete proposal so we can decide. - AB: That was a reason I didn't dive into NTP. I'm not an expert. Daro. It looks to me like this kind of request should come with argumentation that includes an offer of contribution. We're designing a basic system model. With Yang everything is expandable in the future so no need to agonize too much. If someone thinks something is important they can add a contribution. - AB: System authentication: nothing changed. not sure our text is complete. Again user name issues - what if user name comes from something other than ssh? Caveat is that NETCONF has already made sure user name is proper/correct. Don't say how NETCONF will do that, but say they must. We've been hiding behind that. NETCONF describes how to deal with this so content over NETCONF doesn't have to review it. - AB: Two new operations for restart and shutdown. These are restricted. This allows an authorized user only to restart/shutdown. By default you can't do this with NACM. Would need a rule. I am expecting comments such as "our system lets you shut down in 10 minutes. What about our syslog messages - can we configure that". So I am sure there's room to expand. Might get more complicated from looking at real systems. - AB: New issue is how we make sure we've future proofed this so we can best allow for future expansion. Do we need to break system group up into submodules. Personally I think submodules make things worse unless they're big enough - you get all the boiler-plate overhead in each submodule. To me it's hard to determine how big some group will get over time. But not inclined to use submodules. JS: (as non-chair). I have requested some time in the NETCONF meeting to discuss modules/submodules later. The issue seems to be that submodules don't export their revision. So don't know what device implements if you use submodules. Or does NETCONF want to support exporting submodule revisions? If not the whole concept doesn't work well. We probably need to move that part of discussion to NETCONF. AB: From implementation experience another issue with submodules is that you don't have any way in submodule to say "you're a submodule for a specific version of the main module". Cannot do something deterministic as one can't find main module version for a submodule. Another problem with version management. Agree with JS that we need those capabilities for submodules to make them as useful as we intended. They're certainly useful if they get big enough. With only a few items there's reading overhead (not an issue for machines). MB: For small steps we can always restructure into submodules later if model grows. We can also use include by revision so you don't have to advertise the submodule revision. JS: (as non-chair) It's true, modules can be refactored into submodules, but that would require republication of the original module. It's an issue with the standards process. AB: I've thought about that. It's a logistical problem that you have to update main module and add an include to create a submodule. Issue is that if you implement main module you need to know what's in it. But yes, this is probably NETCONF work, not netmod. AB: It is possible to have multiple versions of the same submodule loaded into a system. Grouping is a good test case for this. Can do uses of the same grouping and come up with different results depending on which version was imported. Not very useful! I want to avoid unintended side effects. MB: This has nothing to do with submodules. AB: yes, it could happen without submodules. AB: We will be updating the version and making this a netmod draft. Will look into LDAP and will update the NTP stuff. Hopefully we can finish soon. My hope is that these small modules will take a small amount of time. * Core interface data model - JS: changes from previous version. Most important is that the docs are in WG last call (until Nov 21st). Read on flight and comment (even if just to say you read it and it's ok) - JS: A technical issue in the interface list. How do we model a disabled interface. A new leaf to say "disabled". Or a boolean to say "enabled/disabled". Martin prefers consistency. AB: I don't like the empty approach. To change data model you're using different operations, rather than changing the value of an object to true or false. I prefer a boolean with a default. It is common in proprietary CLI to use empty leaves but I don't like it. LL: Advantage of disabled version is that it behaves the same for all models of the default handling. If must have disabled leaf when disabled that will get picked up. So that's positive. AB: That's a property of the default. LL: Default handling comes into question quite often. In "report all" mode you'll have all these defaults present. So not very handy in my opinion. JS: What do operators think? Would you prefer to see stuff that's set to the default, or not see it. MB: Do not use report all. AB: What is the impact to "must" and "when". What if you make some other leaf conditional on this being enabled or not. Does that impact the expressions you would write? Is it easier to say "if disabled is present do X" or "if set to disabled do X" LL: I don't think disabled leaf causes real impact. Slightly shorter expressions - but nothing really crucial. JS: Some in audience look puzzled. Should I wait a little more? AM: I think the uniformity of writing to a variable rather than creating/deleting leaves is perhaps dependent on the API and language you use to manipulate this stuff. What it does to the X path is not that big of an issue. But ought to be consistent. You'll see things like interfaces appearing and disappearing frequently. AB: There is an issue with create/delete and access control. To let someone disable you'd have to give them create/delete permissions, not just modify. AM: But doesn't that give them the ability to create and delete interfaces too? AB: It will have an impact on your access control. JS: I don't see a clear movement towards one option at the moment. So let's iterate this on the mailing list. All I get here is that we need consistency and need data model writers to stick to the same pattern. Hopefully we pick the right one. MB: I prefer the boolean. If you do a report all it's clearer. - JS: IP config data model first issue (source address selection) AM: Once you get into IPv6 you get source address selection policy which is more of a system-wide issue (not interface). JS: (as individual) - we don't have a clear concept of what's part of this data model or the general IP data model. Or is the general IP data model in this data model. Where's the boundary? AM: Source address selection is a system thing, may not be bound to interfaces. P?: What if we call this "policy"? This is not interface specific. But it is a policy as to how I want this system to behave. It's not actually related to the interface. It's an IP policy. AM: So this is of wider scope than interface BF: Speaking to what we've been asked by customers. The most common request is for the system to use a single source address regardless of interface for various management protocols (syslog, RADIUS etc.) It's more a case of per protocol configuration. I want this for RADIUS, that for Syslog, etc. MB: This is config per interface as to which source to use if there is more than one on the interface. AM: But it's a rational policy to want the outgoing source address to be none of the above. MB: (replying to BF). A per session/protocol default is fine. This is default for IPv4 packets where no other info is available. AB: I think Brocade has what Bill was talking about. P?: This is used to say e.g. "I have an internal loopback in network 10, another for DNS, another for log server etc." So it's a box policy as to which one to use. It is not an interface thing. JS: Trying to summarize. It seems to be important that the application running on the box can choose the source address. It is less clear that we need something per interface. AM: The way Linux does this is puts it in the RIB. It's a matter of which route matches the outgoing packet that determines which source address to use (based on policy for route and assuming the service hasn't already picked an address). BF: Interface and per session config are orthogonal. - JS: second issue (v6 as presence container. do we need explicit parameter to turn on auto-configuration). AM: Yes we need that. And we need a way to bring up link-local only. JS: It seems clear we want a switch for auto-config. I agree. -JS: third issue: (stateless address auto-configuration. Should we add variable required for all nodes - duplicate address detection). JS: If an RFC says you must provide configuration then unless we have a strong argument we ought to do it. AM: There is no reason not to do what the RFC says. But I've seldom seen anything that allowed you to do this. AB: In RFC2119 language we don't have a choice. JS: So we'll do this. - JS: fourth issue: (neighbour discovery - same as third issue, this time is interval for RA messages) JS: Is this in scope of this data model. Is it interface specific? AM: All the CLIs I can recall allow you to configure per interface. Ours does. So I can see a real call for doing this differently on different interfaces, so it belongs here. MB: These parameters don't have to be defined here. RFC4861 says per interface. - JS: Any other comments on this doc? LL: Yesterday we discussed what belongs to this interface or IP configuration module and what belongs to routing stuff. Might also make sense to implement some state data like routing table here in the IP configuration module. Every device that implements IP has to have some kind of routing table even if it doesn't do routing. So that could be moved from the routing module to the IP configuration module if we want to make it more comprehensive. JS: What's wrong with configuring routing in the routing module? LL: Some device might not do any routing. So no need for routing module. But if it does IP it needs a routing table. So makes sense for a client to ask for contents of the routing module even if it doesn't do any routing. A routing table is an essential part of an IP device (host or router). Could just be very basic stuff. Routing protocols can augment this with their specific stuff. Even for basic IP configuration you need this. JS: Why not put this in the routing module? LL: So then the device has to advertise support for routing modules even if the device doesn't do any routing. DK: Every device does static routing. not all do routing protocols. LL: Some devices may not be able to configure any routing. JS: Talking as contributor I'd prefer one data module for routing instead of looking in two places depending on the type of device. Prefer the routing module to let simple devices to be simple. AB: Isn't it the case that default gateway is minimal? get that from DHCP. LL: Do we want all devices to be required to implement the routing module? The IP module give you no way to query routing info. As Andy says the most common way to configure a default is through DHCP. JS: I like to have one way to look at routing tables. I don't want to know up front if the box is simple-minded or not. BF: I agree with Juergen. One place to look for routing table. Very small difference between multi-homed host and router - do you forward packets. DHCP can supply routes. v6 RAs can do the same. So even on a multi-homed client you can end up with quite a complex routing table. Useful to be able to query the routing table in that case. LL: Maybe I'm misunderstood. I'm saying move the routing tables from the routing module to the IP configuration module. So this is defined in one place but can be updated by the routing modules. So simple case will be you just have IP configuration module. JS: So yes, maybe I misunderstood. What's the benefit of putting the routing table here? LL: All IP devices will have this module. So you can query the routing table. Only routers will need other routing-specific modules. AB: I agree with Juergen as to having this in one place. I don't want the data to show up in two places. LL: I'm not trying to copy, I'm trying to move. AB: It's fine the way it is, as long as it's clear that you don't have to implement routing protocols to implement YANG. JS: I think it might be best to take this to the list. A clear statement of what would move would be helpful. MB: If we move it then do we move it to IP configuration? And just for IP? IPv4 and IPv6. JS: Let's iterate on the list. And now we're moving onto the routing module anyway. * Core routing data model - LL: differences vs -00. LL: IPv4 unicast routing module now smaller as the rest moved to generic ietf-routing module. LL: creation of iana-afn-safi module makes routing module much simpler. LL: routing-process seemed to be confusing. So now called "router". represents a logical router so you can configure many of these. LL: Previously only one AFN/SAFI per router. But BGP can carry multiple address families in one routing protocol instance. LL: Delete route RPC was objected to, hence removed. LL: Fixed some bugs - e.g. illegal XPath references to main data tree. LL: Wrote security considerations. BF: At least in MP-BGP it's AFI/SAFI not AFN/SAFI. So you'll get more mindshare if you call them that. LL: I had AFI/SAFI in -00 but IANA calls it AFN/SAFI so I changed for -01. Need to follow IANA? BF: Follow the naming that IANA uses, or the naming that routing protocols use. P?: ISIS doesn't follow BGP naming. BF: AFN/SAFI feels awkward to a router guy. "what's an AFN? Oh, it's an AFI" LL: The enumerations are a big mess. JS: So what do we do? P?: nothing. Other routing protocols carry multiple network layer information. Not called AFI/SAFI. So let's stick with IANA. If we only had BGP I'd agree with BF. DK: We need to get routing people to review this. So better to follow their naming as makes it easier for them to read. Not a big thing (AFI vs AFN). Having familiar terminology (for routing guys) makes sense. Either one is correct. P?: To me it'd be cool if we use what we register. So you can index into IANA table of the same name. JS: Take it to the beer bar BoF! - LL: (showing main data tree). Now no more AFN/SAFI stuff for each router. List of routing protocols. List of route filters. List of routing tables. - LL: (showing RPC method). only method left in this data model. a means to query the routing tables of a specific router. So you say which router and what destination address. Output shows the routing entry (common items for all address families and routing protocols). Must show stuff that's specific for a given address family. May have other parameters (e.g. from routing protocols). If we decided to move routing tables to IP configuration then the method would be used there too. - JS: That was my question. This is talking about the actual FIB. Not BGP RIB etc. - LL: yes. AB: Why do we need a special get function for this (not generic NETCONF get). Does this have side effects, or just data retrieval? BF: Reason this can't be a get is that this is doing longest prefix match. You specify one address and get a route that's a prefix covering that address. AB: I've had comments from NMS developers that they prefer generic get because of the filtering capability it has. So you can pick out more than one entry at a time. No need to code each retrieval option separately. But we don't have a mechanism to do longest-match in subtree filtering. LL: In a large routing table it might be hard to figure out the active route for a given address. AB: The large table thing is a separate issue that NETCONF doesn't answer at all. Issue re bulk gets etc. to make NETCONF operational useful. LL: This method only gives you one route. Generic get can be used instead if you want something different. JS: This is operationally extremely useful. LL: Juergen proposed this one :) - AM: There's multiple routing tables here. I don't see the interface bindings? LL: Why do you need those? AM: in some use cases there are bindings between interfaces and what routing protocols are in use. LL: In the data model one can bind from routing protocols to routing tables. But no binding from routing tables to interfaces. BF: Are you talking about VRFs (to Andrew). Surely that'd be another router? AM: I agree. But Linux can do multiple table routing where you select based on things like "incoming interface". This model has outgoing interface but not incoming. LL: Should be able to define a filter where only certain incoming interfaces bind to a routing table. AM: Maybe it should be in this table. LL: Maybe this should be done by someone who really understands routing, not by this WG. Currently only routing filters are permit all and deny all. - JS: You're doing a good job editing this document. We should use the routing people in this room. Am puzzled in this example by IPv4. Do we have different get routes for different protocols? LL: Only IPv4 unicast is in this routing module. IPv6 would do the same but in a different name-space. Martin suggested using IP address type instead of IPv4 and IPv6 address. IP address type doesn't take into account other address families. Would have to be done anyway. It's only IPv4 unicast because IPv4 unicast is the only AFI/SAFI specific stuff in this draft. My idea was for the IPv6 unicast module to be developed by someone like 6MAN WG. But if done by this group could move into the IP configuration module. Does this answer your question? In other words if we have a version 6 specific module you'd see v6 unicast destination prefix and next-hop. Mistake in slide - outgoing interface isn't AFI specific - DR: You asked if we should do this here or on the routing groups. Ideally down the road we'd like to see other groups doing the work. We're doing this here as it's a proof of concept for the methodology of development of a module and as is core. - MB: If we move this do we keep the router name input parameter? LL: In IP configuration there's no concept of logical routers. Maybe we can have one method in IP configuration and another in this module. - LL: Also another open issue - same one of boolean vs disabled leaf. Not worth dwelling too much on this here. Not a major issue - either one can work. - LL: The other bigger issue is discussion of restructuring the IP configuration and routing modules. Let's continue that on the list. LL: No desire to make major changes now so see this as ready for WG Last Call. But need to discuss moving to IP configuration first. LL: I am confident this can be used with other core modules for static IPv4 routing. But I am very aware that as soon as someone uses this and wants to develop more complex models (e.g. BGP or MPLS) we will need to change things. So we need to be prepared to update these modules as we go. DK: (as WG chair). How many people have read this. Handful of people have read it. P? are you happy to send a review to the mailing list if we keep AFN? P?: I can't see anything that's really wrong. There are many things I'd like to have. This is a good start. As we go further trying to make this operational we'll learn more. For now I'm happy. And no I don't really care what you call AFI/AFN. DK: WG chairs and AD have discussed this doc. We felt we wanted more review from routing people. But recognize it's hard to get that review. So want to go to LC to force that kind of input that we still need. Probably still a few loose ends. P?: This is version 1. DK: Nothing is cast in stone. You can expect a LC on this fairly soon. LL: I got comments from Martin yesterday. Stuff to fix before last call. DK: Could last call even before that. * SMIv2 translation to YANG - JS: Doc was last called around IETF81. Was supposed to post an update. Got distracted. Good news is other people have implemented this since then. Got feedback from an implementation. So now have more open issues. Posted the issues list to the mailing list. Trying to consolidate issues and solutions. Trying to see where we have consensus and where we need more discussion. - JS: First issue is number 4. Need to decide if an octet string was supposed to be textual, or binary. Current answer is to look at the display hint. That will tell us if it's supposed to be binary or rendered as text. One of the problems is that sometimes was in description clauses not as display hint. But then causes issues if newer versions have display hint as the two versions translate differently. AB: Are we optimizing for the esoteric case that rarely happens, or the people who will be implementing Yang? JS: My MIB experience tells me everything will happen. AB: I don't want the Yang module to be cumbersome and difficult to filter etc. just because we can have pure binary strings that hardly ever happen. JS: The specification has text that says have options to handle the case where you know whether this is binary or text (even if display hint disagrees). - JS: Next is number 11. Some SMIv2 modules import from SMIv1 where there's no module-identity. So may have no name we can use as a top level. One solution is to use the module name as the top-level node (as that'll always be there) if there's no identity. Issue if SMIv1 converted to SMIv2. Another is to use shorter prefix generated from module name. Has same issue as first solution. Third option is to use module name always (even when there is a module-identity). Juergen prefers 3 as it works in all cases. - JS: Issue 12. Is the smiv2:defval clause an SMI default value or a YANG default value? AB: Isn't the issue that default values are suggestions in SMI but are mandatory in YANG? JS: Idea is to capture the SMI semantics here, not to map to YANG default statement. But is this a constant in the SMI value space or the YANG value space. Might be different. Is a YANG application to interpret the smiv2:defval according to YANG datatype or SNMP datatype? If no strong opinion I am going to say that this is SMI and if you want to use in YANG you need to convert to something that makes sense in YANG. - JS: Issue 14. Scalars. Long discussion behind this. Issues of updating SMI modules and what you're allowed to do. Potential ambiguity. So flattened all scalars to be under top level node. But then can't get scalars without getting tables. Careful filters can be used to retrieve. Considered additional artificial container that just has scalars. Email discussion. David made proposal to fix this. Certain corner cases. AB: MIB designers use object identifiers to purposely break up a module into separate sections. This is clunky, and is an artefact of object identifiers. I'd prefer to maintain that functional grouping. Don't want to put all the scalars from a MIB together if that wasn't the intent of the MIB design. Would David's solution maintain the groupings we get in MIBs? JS: David's proposal is not to look at names of the parents, but to look at how the object is defined. We take this as a guide to tell us where it should be located. Doesn't cover all cases. - JS: Issue 16. OID representation. Some discussion on mailing list. Got a new solution this morning from that. Can resolve on mailing list. AB: Andy - can we close on this? Two different ways of doing this so the OID string will always be complete. Was that acceptable. JS: I asked this question this morning, but have not seen a response yet. I like to keep the full OID so I can rely on that in my tools. Question is whether the two CAN coexist or MUST coexist. AB: If my tool has to parse the string and it has substrings that's not even usable. - JS: Issue 21: prefix generation. Algorithm to generate prefix - shorter/more readable than module name. Need to work this out on the list. - JS: Plans to revise this by the end of IETF82, post it, and then we can review it and close. Hopefully only one more revision after that. Ship it by year end. * SNMP configuration data model - DK: 3 minutes left. One more agenda topic. I sent a proposal to the mailing list about a potential charter change. No time to discuss now. We need to defer this to the mailing list. Last time we discussed we dead-ended. Please look at the proposal I sent and consider it from a mindset of trying to make progress. AB: It seems like only one person (Randy) had objection to the charter text. Experts are arguing way down in the details on stuff that isn't that common. The general community just wants something usable. If we miss a corner case then who cares? DK: The issue is that not many people have discussed. One dissenter makes a big difference in a discussion of 3 or 4 people. DR: Has there been any new information since we deadlocked last time? DK: no. DR: Can you introduce where we are and ask the question? DK: I sent the proposal to the mailing list. DR: Need to be clear why we deadlocked. JS: The discussion about precise wording of the charter has gone way overboard. The WG needs to find consensus on deliverables. Technically we're discussing corner cases such as configuring community-based security together with USM. Some tables allow you to do it. But it doesn't make sense. Do we need to preserve the ability to configure stuff that doesn't make sense? People can agree we don't need to support that. But there are cases that are less clear. The charter says the document needs to be clear where there are differences between the MIB module and YANG and why. That's all the charter can say. Anything beyond that has to be case by case. DK: Please look at the mail I sent and consider it.