Minutes IETF103: netconf
minutes-103-netconf-00

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.

<Presentation continues>

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