DIRECT LINK TO YOUTUBE VIDEO: https://www.youtube.com/watch?v=lYVH5U6j-FQ&index=6&list=PLC86T-6ZTP5jPVzJ6juHM9W5ml4NpMEAC. Session Intro & WG Status (15 minutes) Ignas - Status update, Zerotouch should be on Telechat in December. Kent/Ignas - Request for volunteers for shepherd writeup. Chartered items: Kent Watsen (15 min) Status and Issues on Client-Server Drafts https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-02 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-02 https://tools.ietf.org/html/draft-ietf-netconf-keystore-07 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-08 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-08 https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-08 https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-08 Michael Abrams: I just want to say I like that we're not discussing if we should be able to set keepalives because I want to be able to configure it at all layer so fully support the effort and then exactly how to do it I don't have a strong opinion but this seems good to me so far. Jason Stern: I am just trying to understand the concept of having it like turn on keepalive at TCP layer on a server you're gonna turn on globally and then it's gonna have keepalives for every TCP session, or are you saying that every TCP session that's using NETCONF. What is the granularity of the control you're looking at. Kent: Well it'd be in a configuration data model and these are really groupings so whatever grouping stack is, in this case NETCONF, for instance, it's using the ssh client server grouping which itself would use TCP client-servergrouping so you would inherit some keepalive configuration for the TCP keepalive from that grouping and thenlikewise some ssh keepalive configuration from that grouping and if ever we get around to it some NETCONF level keepalive from that grouping and it would only apply to that particular configured stack. Jason: Okay so that's not a combination and so you'd be turning on TCP keep lives for this NETCONF session correct? Kent: Not for the entire operating system Jason: Yeah okay thanks. Tim: I will say, I think the approach to having keepalives at every layer makes sense because again last time we talked about it it's needed for that piece of it. To answer Jason's question is that, indeed, this is within the context of the NETCONF session. I will say that as we were doing this for some of the stuff within the BroadbandForum work that some of the implementations are that when you turn this on you touch those TCP keeplives it's actually for all the sessions. That there's some limitations on some of the implementations. Not that the approach still should be the context of the NETCONF session. Sometimes the implementation says that the only thing that you can twiddle is on all the sessions on some of the implementations. My concern with the refactoring is that we've got modules coming out of the wazoo. I mean there's just a ton of modules. I get what you're doing but there's just a lot of modules now. If you're gonna do if every layer ... So I'm just wondering if the organization and housekeeping gets beyond the benefit. Kent: And that's what I meant by anticipating exasperation. I have somewhat worn out the welcome here in terms of the refactorings we've done and I get it. But i also see this as being the best way to solve this problem. Michael: In Linux there is a knob to turn on this system wide so you could test that and see whatever you come up with for TCP, would fit into IETF system for instance and know if it would make sense. A test of this module to see if generic enough. If it is, I would say publish it, because I might want to support this. At the system level as default settings and also at the NETCONF server session level, so that the NETCONF server would use the socket option to turn this on for just its sessions and I would also like in IETF systems model for the entire system. Kent: Both. You are in support of this and also modifying IETF system potentially. Michael: I'm saying at least spend 10 minutes on seeing if the the way you do the TCP part is generic enough that itwould be able to fit into a IETF system. I would support an effort to do that for IETF system as well, because as far as I know there is no system-wide settings and at least some operating systems do turn TCP keepalives on by default. Kent: Okay well look into it. Rob Wilson: I think separating modules probably makes sense, but doesn't mean they have to separate drafts. All of these could be bundled. Some of these modules together are relatively small, and that may reduce some of the overhead or process overhead here. Michael: I wouldn't even need it per connection, or IP or something. I just need a knob default on, or default off for all sessions. Kent: At system? Michael: No, for NETCONF. TCP keepalive for NETCONF and SSH. I don't even need that. I don't know if someone else expressed the need to do this on a per connection level. I just wouldn't. I want like a default. Set it on and off basically (at the system level?) that's all is what I need. If someone else needs more then okay. Then we need to do more. I'm just saying there are a lot of scenarios in which I think you just want to be able to turn it on and off and you don't need to set it per destination or anything. Kent: Understood. Where would we put a global setting like this, is the question. Maybe IETF system? Michael: Default on and off for the NETCONF server for all sessions that come in. I don't need it to do it per IP. I just need to say the NETCONF server should by default keep tcp keepalive on. I don't need to say for this IP rangeor something like that. Rob: So definitely support your suggestion saying that if you do do this, split out to keep the minimal and in the future it needs to be expanded that could be done in the future revision. Just trying to avoid feature creep. Kent: Right and actually already that's the strategy we've taken like for instance with the SSH and TLS. We're really just focusing on the minimal necessary to configure the crypto stack so that we can do it. But if you look at various SSH and TLS implementations there's many more configurable options we're not touching any of them. So more the same in that regard. Tim: Just to make the comment from Michael, is that we're using it for various applications. So there's a TR 301within the Broadband Forum that does callhome that uses TCP keepalives. And so there's a the generic setting, whichmay or may not work. I don't know. Not sure it works because it's on a stream basis and we've got multiple endpointsthat we have to talk to. But we've also started looking at the augmentation because we weren't waiting when you'regonna do right. I think we can work with you on trying to figure out, how to get the best adaptation possible to work in different scenarios. Kent: If you know people could collaborate with me I'd truly believe this could be done by 104. We would still have to figure out how to do keep lives and I don't have an alternative proposal. This is the only proposal I have at the moment. I don't think the effort is huge if the co-author could help me. I do believe we could get it done really with probably just one more month worth of time. Alex Clemm and Reshad Rahman (10 min) Update on YANG Push and Related Drafts https://tools.ietf.org/html/draft-ietf-netconf-yang-push-20 https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-18 https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-14 https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-09 Kent: Okay. I'll just make some comments. Thank you Reshad for helping with the RESTCONF notif draft. It wasn't one of the original three that we had discussed, but adding it I think was good, mostly because it actually helped usfind some other issues right in the SUBSCRIBE notifications draft. It had a sort of a trickle cascading benefit, Ithink, beyond just sort of enabling us to allow NETCONF and RESTCONF to move forward together, which in generalisgood for the working group. To the workinggroup, as shephard, as soon as I received these drafts, I'll also send out an email to the work group asking those who had posted comments to just review that were hoping to see was is there and let the shephard know if there's anything amiss. Alex: Just one clarification. When is send to IESG? Once the Shepherd review is complete? Is it serialized like that? Kent: Yes, for the most part. The shephard does the writeup and then and shephard isn't necessarily always the chairs but the write-up occurs and then the chairs discuss whether or not it's appropriate to submit for publication which is equivalent or synonymous to going to the IESG. It almost happens at the same time. But what that really means it goes to the AD, Ignas, in this case, where he would do a AD writeup and he needs to schedule it for telechat which he just mentioned a moment back. It could be a month out but you have to get on the calendar. Oncethat occurs then there will be a number of discuss items and the various IESG members will have comments, all of them will ballot on your drafts. They will be discuss items and you will need to resolve all those discuss items. This isn't really normally in the view of the working group. It happens off the working group list. The chairs and the shepherds who are involved in that process. That can take as long as it takes it and I've seen it sometimes go quickly a couple weeks and other times months. Just depending on how it goes. Then when that concludes, it goes to RFC editor and then there are RFC editor will look into other issues and they'll be more back and forth. Alex: I was mostly concerned about getting it in front of the IESG. Ok. Thank you. Tianran Zhou (10 min) UDP based Publication Channel for Streaming Telemetry & https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-04 Kent: As a contributor First just a general clarification statement what this draft is presenting is a notif model. We have like NETCONF and RESTCONF notif model. This would be a udp-based transport notif. Tianran: Yes Kent: How we might characterize this draft with all the other notif drafts. The current notif drafts, they're really just providing dynamic subscription-only support because we never really got around to thinking that we would want to have configured NETCONF and RESTCONF subscription. But we do want to have configured udp-based subscriptions and that's how this draft came to be adopted working group supported item, and also I think having dynamics descriptions make sense as well, so that's the clarification. Secondly, I think we need to be clear that what we're describing here is a new protocol. This would be a new binary protocol. We're calling it UDP. Tianran: The name is UDP based publication channel Kent: We do have a name for but it is a UDP based protocol. It is defining its own message header and it can containdifferent encodings. Is defining a new UDP based protocol making sense relative to making use of an alternative existing UDP based protocol and I know you discussed IPFIX and COAP. I guess with IPFIX one of the things youmentioned was that it doesn't support different encodings but maybe that's okay. Maybe just a single encoding would be okay. For COAP, you mentioned that the message ID was only 65 thousand. I think the concern there is that IoT devices and their rate of transmissions would be very slow but a high-end router could send 65,000 messages within asingle second. It would lead to many issues. But if that's the only concern there is an opportunity for this working group to approach the COAP working group to ask them if there might be a possibility to extend that message header.I'm just exploring ideas other ways that we might be able to solve the general problem which the working group wants to solve which is a udp-based notification message for subscribe notifications. I think we should still consider the solution space some more. Hank: We are working on the concise yang telemetry draft and we are using COAP and the message ideas for detectingduplicates. If you expect to have a duplicate in a 16-bit space then you need a bigger message ID. But I don't think that is a concern. It can rewind in that scope, if you don't expect duplicates in that dimension. The association between the requests also. The subscription to the stream is the COAP token and that's eight bytes I don't think that's the problem. Maybe message ID is sort of misinterpret idea I think. I don't see that it is a problem but on the other hand you want to have this inside system like I heard like between line cards or in this is not leaving the the data store system component, I have the feeling, so maybe then having a listening server. This is best RESTCONF. For COAP server is a little bit over too much then you can just establish a UDP stream. Tt depends on the application. If it has to go through the internet probably COAP is a good idea, but if it is just for high volumeinside a system you can basically unpack all of the overhead tuned for Internet Protocol. ??: I was just explaining that IPFIX does leave the box. it's generated on the line card itself and it goes out the box to a collector. Hank: This is of course correct but I thought IPFIX was used in a different place. For this purpose therefore has a different scope of application. I think because of encoding. Kent: Just add that conversation I've also done udp-based logging where the log receiver was on the subnet to the line cards and it would receive all the logs and then do aggregation and compression and deduplication, and then send them over the LAN. I think that's your point. Hank: Yeah that's my point. Kent: It's over over the LAN you don't really have to tag it and besides if you miss one what would you do about it anyway. Hank: My last comment is anything but binary representation doesn't make much sense. Inside, if you're talking about burdened by TCP state I think being burdened by something else as a binary is even worse. I think it's rather obvious not to use human readable clear text formats like JSON or XML I think it would defeat the initial purpose of the block. Tianran: I should say those requirements are from our customers so we designed for them. Rob Shakir: Google. I find that the whole section of this draft to do with any kind of reliable delivery and discussion of how you should only really deploy this over reliable networks is under specified. Our operationalexperience of having tried to put something udp-based streaming into production is there are no reliable delivery channels. You have bits of your network where you can't possibly assume that all packets are going to get through or there's no congestion, because there isn't the amount of bandwidth you can buy there is not sufficient. The cost of having to assume that the channel is unreliable is the law of periodic replication of the data. So you can deal with retransmission .I would go so far as to say as soon as you have to deal with retransmission you might as well use TCP anyway. With TCP you also get the advantages of knowing that reliably when you sent an event it got to the other end so you can reduce the number of times you need to stream data. We don't think that it's actually possible to do over an unreliable channel event based updates, because any system then can't really rely on it and with any kind of latency. I think you should probably add some discussion to your draft as to what the cost of doing this over UDP is and really try and figure out how retransmission works in this model. Especially if it actually works to a line card which is kind of the motivation here. You're assuming that there's a cash on the line card to have any packet within some known window to be requested. My suspicion and operational experience of having a few thousand devices that run telemetry at this point, across number of vendors, is that you will just go to TCP again; as soon as you have to deal with these problems which are kind of the operational realities. I don't really think we should be pushing the industry in a way that doesn't really work. Tianran: The reliability is the part that is not the real reliability as in TCP. It's a kind of partial liabilityit's a trade-off between reliability and UDP. Rob S: Right. But the the problem is how do I build any kind of system that relies on the data being there, so I can if I'm trying to do anything with interface statistics and I know that there might be fidelity loss because I've got lost packets I can't rely on it. I can't do anything event based because an interface goes down in my network andthen you don't have any way to react to it.You don't know that the state is there. The natural requirement then is that you end up building a polling system to make sure that you have a current enough view to reconcile and our scaling analysis kind of shows as soon as you do that, you're going to end up with significantly more data than you would via TCP. This scalability argument kind of falls down. We've been pushing this entirely tcp-based. Kent: As a contributor. What is the motivation for your udp-based draft? Is it the reliability? I don't think that was it, so much as the desire to enable the line cards to send the UDP packets having the same source IP. For the other draft that you are about to present, the multiple stream originators, the desire is to enable that distributed source. Rob S: So we've looked at this. I think that there's a model whereby you have a distributed system that has different components that can each have TCP. I think you're going to end up going that way if you ever care about reliability. If you say this is a hundred percent unreliable then I think you can kind of talk yourself into this UDP model but if you say I want distribution because it gives me more scalability (point to be proven as to whether that's really required) and then you you can still do TCP or it is a lightweight TCP protocol to the line cards and you're kind of inventing a new protocol here, as you pointed out. I would suggest for debug ability it's kind of achallenge if you have N producers that are all producing with the same source IP. We have challenges around being able to know whether you're actually in synchronization with that system if you've got N different producers and oneline card stops producing data. You don't really know you've got no metric to be able to alert on say if this source isn't sending data anymore. Kent: I think we're jumping into the next draft but I think the idea with that draft is the is that the configuration model would allow you to configure the UDP to the system and then the system implicitly distributes to line cards and tells each of them. But if you do were to do TCP you'd have to be explicit the configuration model would actually have to configure the IP address for that line card. Rob S: Yeah I'm suggesting a bit of configuration pain is better for the overall system. Hank: Again if you are expecting to have congestions, you will have UDP datagram loss. That is a fundamental decision you have to make. Do you expect congestion with your streams or not. If you have that expectation, which I think is likely then you have to deal with retransmits and for that you should not reinvent yet another (reliable)transmission mechanism for UDP for every draft in the IETF. There is a good template for that in COAP where a reliable message every thousands message is sent, and you can then see how many messages you lost and that window can be retransmitted. It's a little bit like TCP but light weight. I call it a reliable COAP. That is analternative. My suggestion is to approach the research group that is meeting here. There are two drafts in development which talks about how to associate data items that are in series and the problem of retransmits isdiscussed. If you have a problem that is not solved in general and you want to solve it with your draft. Tianran: I know of COAP used for IoT. Do you have an example for COAP application that is used for routers? ??: In the DDoS protection working group we use a kind of our basic transport protocol for the for the scenario, if you want to look. Tianran: I would like to see. Hank: Just because something that was initially intended to be used in the constrained environments doesn't make itunfeasible for the rest of the Internet Kent: As a contributor. Just a quick follow up on the discussion about retransmissions. When I first saw the message ID with the UDP I never thought that it would be for the purpose of knowing when to request for a retransmission. I only thought it would be used for ordering of the packets received by the receiver because UDP doesn't guaranteeorder delivery. And for detecting gaps now when a message was dropped. Not to request but to know that you lost amessage. I never thought that there would be a desire to try to build reliability on top of a UDP based rotocol. Rob S: I think that that's a interesting operational like mode of operation. Like I said before with SNMP.I can poll the device and know I get some stats back. Maybe there's some loss in them but I know at what interval I'm polling in. In this (UDP) mode where there's no reliability, if the device just shuts up you can't tell because you didn't get a sequence number to tell. It becomes quite operationally difficult to not assume reliability when there isn't a guarantee that the thing at the other end is sending data. I mean we tried this. We looked at it as the preferred way to start with, and this a long thing with internal collector deployment things about how you knowwhen it can reconnect, about how you deal with redundancy between collectors and those kind of things. I think it just makes for more and more challenges. That is kind of why I think the draft could do with some discussion of like how you actually operate the system like this. Jeff Tantura(?): Just to interrupt comments. I work for a company, where we use streaming extensively from thousands of devices. Spend quite some time looking at UDP and TCP and I also discussed with potential customers. UDP was a no no. It has to be reliable otherwise you need to build additional layer to ensure it transmissions reliability. Benoît Claise: It interesting because we were discussing the same thing that we have been discussing for IPFIX for 10 years. The message ID in IPFIX was just to know about the order and just to know that you've been losing flowrecords. The point is that for IPFIX it works fine because of accounting. If you lose one packet, big deal. BTW, youexpect a router to keep information records. I think the key point is that if you rely on this mechanism for an event like Rob was mentioning,it must be reliable. If you just going to sending monitoring information,you can use UDP. Rob S: Just to add to Benoit's point, It's fine I think, fundamentally for SFlow or IPFIX to have a different nature, because we know that there's N flows on the device where know that for n packets going through the device we know that we only expect a sample of them therefore losing one... I don't know of any system that's built to say with SFlow or IPFIX where with one flow sampling I'm going to guarantee that I'll get every one of them. Whereas with telemetry data if we're building systems that now split the control plane across the device and off the device then we need it to be reliable just like you would need some of this data internally to the system like links going up and down to be reliable for routing protocols. Benoit C: Again, it depends what you call telemetry. If it's telemetry I mean to push high frequency all information from it's like IPFIX, your sending flow records; even if they're not flow whatever, if you condense everything in your telemetry so it becomes an event you can't miss it. Alex: Some application may require reliability while others where you're saying you lose one record it's not a big deal. Another question is how it is being used if you use this for periodic updates you know basically that you are expecting updates for every period already. If you have a period missing you would basically infer some of those things. I do agree actually that we need to have the discussion of these operational things and the trade-offs. At the same time I think nobody is saying that this is the be-all end-all transport for all particular use cases. This is one use case for certain scenarios where basically those operational scenarios that you described would beapplicable. Rob S: Again just a response that. I think there's a few challenges with those assumptions. As soon as you say oh I'll stream everything periodically you're going to significantly increase the data that comes from the device and by hundreds and hundreds of times. Actually it makes this system scaleability problem worse. You want to only send things when they change. It gives you a significant advantage for large data sets. It also gives you a significant advantage for interfaces that are down, on a systems with radix of a thousand or so. Which is kind of common in today's networks. As soon as you say I'll send things periodically you're going to end up with these scalability concerns and you probably are now having to deal with worse scale on the device of your UDP periodic than you would be the cost of doing TCP for reliable. Other problem about periodic is that you don't actually know what theycollect or what you meant to receive. If a whole line card stops sending did it get removed from the system. It'sactually hugely difficult without lots and lots of other accounting to know what you should have been sent during that period. The third thing I shouldn't say is we're inventing a new protocol here to send telemetry data let's notinvent one that we know is flawed and only works in like a small number of cases because that is just going to complicate things. Alex: When you subscribe the subscriptions both can support either use case. A user will decide whether they happy with periodic or whether on change is actually more applicable for their particular application. If you want to have a continuous and telemetry to do some kind of whatever whereas statistics trendline analysis for yourapplication. Not every use case requires on-change. Rob S: That's true. But I guess the point is that there's some data and an underlying you do want to sample. This doesn't mean that the system can't support sending data periodically. There is a significant amount of data that won't need to be sent. I would encourage people to go and look at is to look at the data that is being pulled from devices. This is what we've done and then look at what the proportion of it that is event based versus periodic and do some calculation, as to what the data volume is. The scaling analysis in the gRPC based telemetry where we can show you know significant reductions based on this. Even though that some data is being sampled and sent periodically because it needs to be sampled like that from underlying hardware sources. Reshad Rehman: Related questions. I remember there's previous message ID and that's how the receiver knows that somany messages have been lost. But if you're not receiving any messages how do you know that there's messages loss. re we going to do a UDP keepalive draft? Tianran: Weed this keepalive information.I don't know about this this is something we need to consider. We also have in the other draft some mechanism to solve this problem. Benoit C: In IPFIX we solve that with SCTP and get a perfect solution where actually you would have a stream which is reliable,unreliable or partially reliable. Depending what you're sending it is monitoring it would be unreliableyou miss a couple of information,fine no big deal,you might be partially reliable you do your best or reliable if it's event based. That's how we solve in IPFIX. However with SCTP didn't pick up and it's an issue with linecards. It is an operational issue and I think Rob mentioned that how do you identify your device a router is like one IP address or it's a sum of IP addresses to one per line cards. Tianran: Sorry I do not understand your question. Benoit: It's not a question it's a duration that we've been looking at these issues. Ten years ago it becomes like more an operational issue. What do you want to solve and then you will have the solution for your protocol. Mahesh: Speaking as a contributor.I think the message that I'm getting from the working group is you probably need to look at the data set to decide if you need a udp-based channel or if you if you need reliability. If you aregonna build reliability into this with the sequence number why not just use TCP. As Benoit mentioned if it's monitoring data that you're looking at losing a few packets is not a big deal. But if you're looking at event you can't afford to lose it. What is the cost of doing that? Kent: One other comments as a contributor. Just one more comment.I heard or learned last night that the I guess it's in the COAP working group. There's a an effort that's been going on for a couple years now to do a COAP based broker pub/sub mechanism, but we should learn more about it and and see how it might be usable in this space as well. Non-Chartered items: Tianran Zhou (10 min) Subscription to Multiple Stream Originators https://tools.ietf.org/html/draft-zhou-netconf-multi-stream-originators-03 (Tianran presenting) Kent W: Kent, as a contributor. can you go back to your previous slide, the one that had the diagram and had the red box that said "out-of-scope". Yes. Why is it out of scope? Tianran Z: as I mentioned in some instance, like the carrier routers, this is kind of the internal implementation, so I think must between the mainboard and the line cards. Kent W: right, okay, I think that this being out-of-scope is dependent on the conclusion of some of the operational requirements that we were discussing a moment ago. Going back to Rob's comment from before, a little more configuration complexity may be warranted if we were, for instance, needing to configure TCP instead of UDP, in which case it would have to be in scope, because you'd have to be configuring what is the TCP interface, at least, for each line card to use, so I think what you're saying is it's out-of-scope here because the expectation is that, from using UDP, the routing engine can internally communicate the line cards Tianran Z: yes, okay Kent W: so there's that assumption, which i think is not is still TBD, is what I'm thinking Tianran Z: okay, but my concern is this part is a little bit complex, and may vary from implementations, so I'm not sure if it can converge in this draft. that's my concern. Mahesh J: Mahesh, as a contributor. okay, if you could go down a couple of slides, to where you talked about being able to reliably indicate a change in the subscription [the Subscriptions State Change Notifications slide], it says "all the subscription state change notification MUST be delivered. Now, when you say "must", that means you're thinking about a reliable channel here for delivering that change in notification? Tianran Z: that's an interesting question. from the message layer, no, we do not consider it must be a reliable channel so maybe in UPD case, maybe we need to consider Alex C: this is Alex. Just to add on or respond to that, I would not mix this with the earlier transport discussion. The goal certainly is for the subscriptions, per se, has always been to basically make this, well, make the fundamental mechanism reliable, so that you can avoid having to poll things. Now obviously, with this case, if you have a new component subscription that was added, or something that was removed, that is an event that you would needs to know or that you would want to know, certainly as a collector, therefore, basically, there's something that needs to be notified. We've had some this some internal discussion whether it should be subscription-modified or whether there should be another type of notification, but either way, it is an event, and suppose it should be foreseen as part of the control channel. Now, if you want to have making this busy for the for the control part of this. Now, for the actually telemetry stream, whether this is reliable or not, that's a separate issue, I would separate those discussions, but this one would be needed for reliable control channel, so to speak. Kent W: Kent, as a contributor, maybe as a chair, I don't know. The motivation for the working group, particularly when adopting the previous draft, as this draft is not yet adopted, but the idea that this draft is discussing was one that was presented at the time that we adopted the previous draft, which was the goal to support line cards to be able to send messages themselves directly, as opposed to trying to forward them to the routing engine, in order to for the routing engine to send them because, from experience, we know that the internal backplane switching fabric does not have enough bandwidth to transmit that much data, it's just not possible, the line cards have to be able to send directly themselves and, in fact, you know things like encryption, actually, it's probably problematic, and this goes to the operational requirements, are we actually thinking that for these very high logging scenarios, would the destination be an internal receiver, something that is on the LAN, something that itself would collect the logs in unencrypted form, do deduplication and analysis and compression and, perhaps, even itself could convert it to binary. we don't really need binary in the LAN, we need binary on the WAN. When we talked to customers, their costs for bandwidth over WAN is expensive, that's when they care, they don't care about the bandwidth on the LAN. I think we need to understand what are the operational requirements, and what is the problem we're trying to solve, maybe some of this would become more clear. I still strongly support the ability for sending logs out the line cards directly, as that's important problem solve, but the motivation for it being binary, and the motivation for it being UDP even, I think we should go back to asking if that's really important to solving the problem here. Mikael A.: Mikael Abrahamsson. it struck me, the whole thing about line cards, and it being on box, I have the use case where I might have a Wi-Fi access point that basically doesn't have an IP address, so i'm speaking some kind of protocol to it or I don't want it to send anything, it's going through me, but it's a different device, and I want to like expose this in YANG so that the Wi-Fi ,it's like I'm the NETCONF server, but I'm configuring the guy over there, and I still want exposed to my NMS that these are two different devices. Isn't that kind of the same problem? don'tyou want a more generic approach in how to expose this in YANG and NETCONF? Because isn't this the same thing and like if it's a line card that is like its own computer sitting in the chassis, or if it's something else, like you're acting on behalf of that guy, I mean, I've seen many different scenarios where you need the same concept, so can we make it more general? Tianran: yeah, I think you provide an interesting use case, maybe similar to this IoT use case, and so we actually I think this framework is like a generic one Mikael: my problem is that we're talking about what's in the UDP packets that is streaming telemetry Tianran: that's another draft Mikael: yes, I know, but it's like this here is talking about subscription, but isn't this just configuration it's just it's not for me specifically, I'm doing this for another guy, that he's like near, I'm controlling him, so it's not me. Don't we need like a more generic approach? and don't we need to talk about what the configuration is instead? isn't it like how do we do this generically? isn't that what we should be discussing? we're talking about subscriptions here, and how to talk to that guy, or what to actually configure, but don't we actually need just a best common practice for exposing this entire concept of different devices managed through one NETCONF server? Kent W: I have a response for this, but I think Rob does as well. It is for this question Rob? yes, please go ahead. Rob S. Rob. I completely agree. so in the GRPC space, for both telemetry and configuration, we added a generic way to be able to make a path be addressable to a certain target that they entered the managing entity deals with it, and it's used for both telemetry and for configuration. I think having case-by-case solutions is not optimal, I think having a single way that you can say there is this management agent that is responsible for this other domain is super useful for many many cases Kent W: okay, so up-leveling the problem space, great! My closing thought is, not it's not really on this draft, but kind of to the other one as well. Currently, the YANG Push and Friends drafts are almost out of Last Call and into Shepherd write-up. As a working group, we've only defined support for dynamic subscriptions, we do not yet have any support for configured subscriptions. This draft is on the path towards enabling support for enabling configured subscriptions, but I think that there may be other paths that we could explore that would get us there faster, specifically HTTP-based push mechanism is something along these lines. I don't know, maybe somebody would be interested in putting together an ID to propose another notif draft. The nice thing about the way that we've constructed, or deconstructed, the the YANG Push notification drafts is that we do have all these notif mechanisms, so it's like a Swiss Army knife. It's great that we have a UDP-based mechanism available, certain deployments will use it for their use cases, others won't because it doesn't match their use cases. So I think we should also consider other notif mechanisms that would enable us to have configured subscriptions. Tianran: I think the idea is become mature, and the the solution and the scope is kind of clear, so I am I'm wondering if I can ask the working group to adopt this document doc but Mahesh: I think before we get to the point of adoption I, we probably need to address the question that Mikael raised, which is do we need to upscale this problem definition before we get to the question of adoption. Maybe you should consider all that first. Tianran: okay, thanks. Qin Wu (10 min) Inline Action Capability for NETCONF https://tools.ietf.org/html/draft-zheng-netconf-inline-action-capability-01 (Qin presenting) Mikael A: Mikael Abrahamsson. I don't know, I haven't read the draft, if I understood correctly, is this only for when the will you change the configuration but the end result operational state does not change? so you're splitting the range into two, but the effective configuration on the line card, or whatever, never changes? is it only for that type of configuration, or is it also it like you split it and then you delete one and you do that in one operation? Qin W: uh Mikael A: okay so you had the example one-to-five and six-to-ten, you can merge you can merge those and into one record Qin W: yeah Mikael A: if this changes, nothing in in real life changes, I mean, the line card's hardware doesn't get reprogrammed by that operation, you're changing the configuration but the state of the device doesn't change, is it only for that type of operation or is it also for deleting one of the VLANs in the middle (i.e., it's for both)? Qin W: yeah, I think we right now we really support both actually. the motivation we can have the merge several tag into one allow you to do better NETCONF query, you know, but actually we also support also, in some cases, you may need to delete a some of the value from the VLAN tag ranges, so we provide such capability in some cases, actually we need to support both and and then we can actually, you know optimize the actual, by merge several range into the one range. Mikael A: so yeah do you see this as an optimation in number of transactions, or is it processing power on the server, or on the client? Qin W: we don't want you add overhead to the client, actually maybe you just need a one transaction, but this is actually transaction you know you send a request to the server actually we are actually you know using some existing config template to merge you the range into the one, actually all happened in the server side, actually you reduce overhead on the client side. Rob W: Rob Wilton, Cisco. So I'm still not convinced that this particular use case is actually a problem. I'm not convinced there's scale issue in terms of configuration here. Even if you split out the number of VLANs over hundreds of interfaces, then I still think the amount of config is gonna be 10k or 20k. Something that would be small in terms of the master consuming it. so I'm not convinced by that aspect, that it is a problem here to be solved. In terms of if you want to do more advanced VLAN operations, ie breaking tags or inserting tags into into particular strings, for example then, yes, that's okay, but I think of those maybe just be rpcs potentially on a VLAN model is how I would implement those. So then, coming back to the general inline actions, I'm still sort of conflicted is where this is a good thing to do, I think this more generally is about transactions, and saying I want to give a sequence of events to the server as one transaction, after it perform all of these things and either succeed or fail, so that's the the guide I'd look at for this problem, rather than just adding actions into configuration requests, but even with that I still question whether that's a useful thing or not, I'm not convinced this is a problem to be solved at this stage. Qin W: but a you say that you don't know where it came, actually, we use a edit-config as an example, if you modify the VLAN tag around the merge and a split, actually, you may need, because you may operate on some list that leads to the key index cannot be deleted, so you have several disparate range, so you need to delete several disparate range first and then you create then a new range with larger range, that's a difference with NETCONF, we want to address this. Rob W: okay, so that's a different problem, potentially, to solve and I think, again, we need to look at the data model that you're talking about, so the one I've been through, IETF, doesn't have that issue, as the VLANs are just information on a subinterface, so it's not actually something where you have this concern, it's just manipulating that string, and the ability of a client to mangle VLAN IDs into string is it's probably bordering on trivial to do, I mean, it's that an easy of a thing to solve. so it might be that your data model is different and then hence there's a different requirement comming from that, so I'm happy to look at what your specific data model is to see what the changes are, what's different Qin W: yeah, we do have such a model. we can show you offline about this Rob W: okay. Mahesh J: Mahesh, as a contributor, adding to Robert's concern for why we might need this, is the problem specifically for case where we're talking about a range, like we're trying to specify whether we're trying to expand it or break it up? is that the specific use case that we looking a solution for? Qin W: yeah the case we give is maybe kinda limited, but we really want to generalize this idea. The general idea, actually, we can provide the operation for NETCONF for protocols so you can actually improve the NETCONF efficiency, and here we gave the example the VLAN tag range, the value is interval type, maybe there's some other case where the value actually is a string type, and you also do this merge operation Mahesh J: what other use case would you have? Qin W: in some case where you haven't bring up actually, so you may transpose some learned configuration into static configuration or dynamic configuration data. By the way, we only talk about these cases, but we have some other cases with haven't bring up Mahesh J: yeah, okay, I think if you bring those cases, it might help the workgroup appreciate and understand the problem a little better. Qin W: we can do that Kent W: Kent, as a contributor I agree with Rob. I don't understand the motivation for wanting to solve this. I guess scalability and efficiency, but does it really get to the level of concern that we need to solve the problem, and that the solution seems like a point solution, and the fact that it's NETCONF-only is concerning, I request that we have a solution that works for both NETCONF and RESTCONF. If it is truly a transaction-like mechanism, I think that's what Rob was saying, then maybe enabling YANG Patch (note: Kent accidentially said "push") to be used by NETCONF would be another way of enabling something like this. Then going to Mahesh's comment right here, if it's truly just for ranges, then it seems like maybe we'd want to have a datatype, a "typedef range", and then this operation would be available whenever that typedef was in play. it's just unclear at the moment, I guess going to Mahesh's last point, more examples and data analysis is needed, it's currently unclear why we would want to pursue this. Qin W: yeah I think the intension is that we provide such kind of solution, hopefully we can generalize this so we can not only apply to the YANG Push, but also can apply to the existing NETCONF operation, so not limit to the existing NETCONF protocol operation. we haven't investigated how these can be applied to YANG Push either, if that's a case, we think maybe first we need to clarify the problem space first. I think we should look further to apply to that YANG Push. Kent W: you're saying "YANG Push", but you mean to say "YANG Patch", right? Qin W: YANG Push, not a YANG Patch Kent W: how is it related to YANG Push? Qin W: oh, you meant, you mention... Kent W: YANG Patch Qin W: patch, right patch, oh sorry I miss Kent W: no worries