IETF 113 NETCONF WG Session Introduction Chairs (10 minutes) Session Intro & WG Status Liaison Statement: * Good discussion with IEEE. * Agreement to send a liaison statement * Also some doc updates. Rob Wilton: Liaison statement may need to come from the WG, but I have checked with the IESG/IAB and can help provide text. Scott Mansfield: I'm happy to help work on this as well (as the IEEE liaison), and it would also be helpful to include Russ Housley (as the IEEE/liaison) to check over the proposed text. Rob Wilton: On http-notif draft, shepherd has been identified. Chartered items: Status and Issues on Client-Server Suite of Drafts (20 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-22 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-17 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-24 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-12 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-27 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-27 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-25 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-25 Discussion Leader: Kent Watsen Joe Clarke: Are you generating public key, or a key pair, possible a different name? Kent: Perhaps could be renamed as generate asymmetric keypair. Diego Lopez: Some cyphersuites were allowed to have "NULL" value if not using a particular element of the cyphersuite. Not sure whether this has been deprecated by TLS, but such an approach could be useful for this particular case Jeff Hartley presenting on Pre-Shared Keys for TLS 1.3 and 1.2. * Acting as an informal liaison from BBF. * tls12-psk has unchanged from what was there before, just renamed. * added new choice case for tls13 No questions. Comments can be sent to the NETCONF mailing list. Kent: Jeff made a huge contribution - so thank you Jeff. Kent: Rob, do you think that an early SEC DIR review would be helpful? Rob: My understanding is that you have been working closely with the security folks and hence I don't think an early review is necessary unless you think otherwise. Kent: I don't think that an early review is necessary, but it would be helpful to flag this during the write up. Rob: Yes, I can do that. UDP-based Transport for Configured Subscriptions (15 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-05 Discussion Leader: Pierre Francois Kent: It is a good idea so that the configuration models can be adjusted so that DTLS can be configured, e.g., how does it authenticate the server certificate. This can't just be a flag, there is a configuration that needs to be specified. The YANG module that is in the this draft would import the TLS client module and maybe the TLS server module, if it needs to listen connections as well. May also need to add examples. Does that make sense? Pierre: Yes. Mahesh: I had similar comments for the UDP notif. For the distributed notif, it would also be good to see some configuration examples. Would you say that the distributed notif draft is really about having the ID about when the notifs are coming from? Pierre: Please repeat question. Mahesh: Are you including a node id of where the nofificaiton is coming from. Pierre: It is called a subscription id. Mahesh: Does that summarize what the draft is covering? Thomas: I can't make out this text. Since distributed notif is transport independent, it needs to be in a different draft. Mahesh: Should the draft give examples for each of the transports (UDP vs TCP based) that are going to be used? Thomas: ... hard to hear what was being said ... Mahesh: What I remember seeing in the draft was mention of UDP (by virtue of the fact that UDP-notif draft is cited). Can distriuted-notif be also supported over TCP? Mahesh: I will send comments to mailing list. (46-min mark) Non-Chartered items: Per-Node Capabilities for Optimum Operational Data Collection (15 mins) https://datatracker.ietf.org/doc/html/draft-claise-netconf-metadata-for-collection-03 Discussion Leader: Benoit Claise Benoit presenting Audio from the room was missing as part of trying to compile the minutes, and as such only the minutes from the remote folks have been added here. Tim: Have seen this problem statement discussed for other protocol like IPFix (the "IE" number assigned to the node). We see some usefullness. Support for multiple sources would be nice. Benoit: Very Good, Thank you. For the IPFix, there is an additional semantic behind it with key field definitions. I could go into more details later. Tim: Yeah! But it's for the same problem that you are trying to do for. So I think we can address it. Rob Wilton: Agree that recommended polling interval is more interesting than minimum polling interval. I definitely think that it makes sense in that context that you say. A minimum polling doesn't always make sense depdening on the capacity. One o the things, even with the recommended one, is that it might on what other subscription you are looking at the same time. If you have got one subscription agains the variable then that might give you the interval, whereas if you polling lots of other data at the same time, then that will change, and I think that is one aspect that is also related to the adaptive telemetry drafts, which have similar issues. How do you advertise what you can do at the extreme but what you can do in a sort of more generatized sense? I do not know whether the recommended one because that would change dynamically, or whether you need something to be able to say these are all the subscriptions, tell me what you can do for me. It is interesing what gNMI does here is that they have an option of saying "just do your best", that modifes the subscription request dynamically. As to the question as to whether we would implement now - I'm not sure, but in future, probably. Benoit: "do your best" is what we want too. We need to formalize it. As an example of IPFix flows, you are able to get your sampling rate back to your flow collector, so that you can do your own computation. In this world of adaptive, where you do your best, if you don't know what your best is, and it keeps changing, if you do not advertise to your data collection system, then you cannot reconcile information easily. But this I-D is about doing "your best" based on what you could do now. Charles Eckel: (channeling Juergen) Does the node tags work done in NETMOD provide the means to obtain the metadata? Do we really need a new RPC? Benoit: Short answer, I don't know yet. I will look into that. Joe Clarke: Agree on the issue on polling. Regarding SNMP OID mapping. There are lot of challenges. Having the OID is only part of the problem, also need the index mapping and that is on a per instance. It sounds useful, is it going to be doable enough to actually make me spend the time to do the work. How will this scale (or will it)? Moreover, on related nodes, how does this work with multiple, related nodes? Just don't know how practical it would be. Benoit: Getting the index in the MIB, or have multiple indexes, and then we have YANG, which has its own indexes, it is highly complex. Doing things in steps might be the right answer. Diego Lopez: This is the kind of feature that we have been asking for a while. I'm supportive of this work. Benoit: Which parts are you particularly interested in? Diego Lopez: From my experience, migration path (from MIB OID) would be the most important part for the people running the real networks. Balazs: Besides OID and IPFix references, 3GPP uses addressing with Distinguished Names. That reference might go beside the OID IpFix reference. Poll: 29 participants, 24 saying they had interest. Transaction ID Mechanism for NETCONF (10 min) https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-id-01 Discussion Leader: Jan Lindblad Mahesh: Jan, do you want a poll to ask if there is an interest in the work? Kent: You did not mention RESTCONF in your presentation. Does this work offer a feature parity between NETCONF and RESTCONF. In particular Etag and modification time. Jan: Yes. If you read the draft, it mentions RESTCONF and how it would work there. It's featre-parity but goes beyond that. And going beyond is also feature compatible with NETCONF. Kent: My second question is on the first bullet point in this slide (Add text for Etag intergration with YANG Push). What is the nature of the integration needed for YANG Push? Jan: When client subscribes to config updates, the pushes that form data updates as part of the config, that config is echo'ed back from a YANG Push subscription, then it is hard for the client to rationalize the changes (e.g., when multiple clients are making updates), whether this is an update of the config change or actual data. Kent: Getting the confirmation back of the change that was made may not be a bad idea. In that sense, perhaps this is not a big deal. Jan: What you want can be had with a transaction id also. This might save quite a lot of data/comparisons. Poll results: 23 responded, and 22 said that they are interested in this work progressing. 1 not interested. Kent: We can move into an adoption call. Problem Statement and Use Cases of Adaptive Traffic Data Collection (10 min) https://datatracker.ietf.org/doc/html/draft-he-adaptive-collecting-problem-usecases-00 Discussion Leader: Xiaoming He Presenter's name was not recognized in the attendee list and the presentation was moved to after the adaptive-subscription draft. Benoit: It seems like the problems are towards dataplane monitoring. Sometimes it is easier for me to know if we speak about dataplane that in-band OAM, described in the last use case. If you speak about flows, if you speak about something else as opposed to just telemetry. Periodic updates is where the use the use case should be likely more structured. It would be useful to more narrowly define the usecases for this. Kent: We had to take this presentation out of order in the hope that this draft would provide the use case for adaptive subscription draft. There were objections raised by Andy and Per on the adaptive subscription draft, but I do not see Andy online, and do see Per on the attendee list ... Jan: Per is not able to speak currently. We should take the concerns (as they relate to adaptive subscription draft) to the mailing list, I think that many of the concerns that we have raised are still relevant. Poll: 24 participants. It is divided half-half. Half want to work towards adaptive subscription being adopted as a Proposed Standard, while the other half want to continue the effort towards an experimental draft. Kent: This is not an adoption poll either way, and as Jan commented, more discussion needs to happen on list to address comments received. We will hold the door open towards a Proposed Standard a little longer. Adaptive Subscription to YANG Notification (15 mins) https://datatracker.ietf.org/doc/html/draft-wang-netconf-adaptive-subscription-09 Discussion Leader: Qiufang Ma Poll: 24 participants, 11 agreed to move it forward as a proposed standard while 13 said they would not mind moving it to experimental status. Rob: I have concerns about the sort of complexity that we are pushing onto the devices do this sort of continious monitoring and the XPath evaluation. Just feels like to me that it is very computationally expensive solution to this problem. I think one of the things I am interested in and maybe the other presentation on use cases, if that is related to this, might be interesting. How many cases do we have actually in trying to solve this generically. Are there a few point cases that we are trying to solve, and would it better to build solutions and concrete data models to solove these particular cases rather that building a generic infrastructure. I guess what I am saying is that I do not know exactly what you are monitoring in terms of your site, but could you build a data model that does that sampling at a high rate and build either an aggregated statistics or something with a decay, and then you can monitor that at a high frequency, and then leave it to the server to respond. Do you actually need all this data at a high rate or are you just trying to pick out when these particular events are occuring more generally, and hence if you had a summarized value in the data model that might give you the same solution with far less complexity. Ma: To the first question, if we leave the complexity with the subscriber then we have a few complexity issues that we need to resolve at the server side. If we leave the complexity with the subscriber then we have issue with collecting enough data to identify the important events. On the server (publisher) side we did add some complexity, although the load on the server was marginal. We can look at the other draft that discusses the use cases for adaptive subscription and whether the use cases from that draft can be fitted with this use case. That draft focuses on data collection mechanism, while this draft's focus is on YANG-Push mechanism. Rob: Some concrete examples that I could think of is for like the interface statistics. I do not know if the IETF model has this, but some of the vendor models have it, is that you have a rate calculation that is telling you what the current load is on that interface, and that decays over time so it is giving you a sort of point load value that you could potentially samle that is a reasonable frequency. Another case that I can think of it has to do with interface flaps. If you monitor the link layer flaps at the very low hardware layers, you may be getting thousands of interrupts per second coming through, and you do not want to notify all of those. Instead, you could notify a counter of how many flaps have occured at each point of time, so that you can still spot that flaps are occuring, and that they are happening at a high frequency, but you are not notifying every single flap that occurs, thereby reducing the amount of data you are pushing off the device. Ma: Ok. I will look into that, and give some more implementation results. Thanks.