Minutes IETF113: netconf: Mon 14:30
minutes-113-netconf-202203211430-00

IETF 113 NETCONF WG Session

Introduction

Chairs (10 minutes)
Session Intro & WG Status

Liaison Statement:

• Good discussion with IEEE.
• Agreement to send a liaison statement
• Also some doc updates.

Rob Wilton: Liaison statement may need to come from the WG, but I have
checked with the IESG/IAB and can help provide text.
Scott Mansfield: I'm happy to help work on this as well (as the IEEE
liaison), and it would also be helpful to include Russ Housley (as the
IEEE/liaison) to check over the proposed text.

Rob Wilton: On http-notif draft, shepherd has been identified.

Chartered items:

Status and Issues on Client-Server Suite of Drafts (20 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-22

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-17

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-24
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-12

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-27

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-27

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-09

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-25

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-25

Discussion Leader: Kent Watsen

Joe Clarke: Are you generating public key, or a key pair, possible a
different name?
Kent: Perhaps could be renamed as generate asymmetric keypair.

Diego Lopez: Some cyphersuites were allowed to have "NULL" value if not
using a particular element of the cyphersuite. Not sure whether this has
been deprecated by TLS, but such an approach could be useful for this
particular case

Jeff Hartley presenting on Pre-Shared Keys for TLS 1.3 and 1.2.

• Acting as an informal liaison from BBF.
• tls12-psk has unchanged from what was there before, just renamed.
• added new choice case for tls13

No questions.
Comments can be sent to the NETCONF mailing list.

Kent: Jeff made a huge contribution - so thank you Jeff.

Kent: Rob, do you think that an early SEC DIR review would be helpful?
Rob: My understanding is that you have been working closely with the
security folks and hence I don't think an early review is necessary
unless you think otherwise.
Kent: I don't think that an early review is necessary, but it would be
helpful to flag this during the write up.
Rob: Yes, I can do that.

UDP-based Transport for Configured Subscriptions (15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-05
Discussion Leader: Pierre Francois

Kent: It is a good idea so that the configuration models can be adjusted
so that DTLS can be configured, e.g., how does it authenticate the
server certificate. This can't just be a flag, there is a configuration
that needs to be specified. The YANG module that is in the this draft
would import the TLS client module and maybe the TLS server module, if
it needs to listen connections as well. May also need to add examples.
Does that make sense?
Pierre: Yes.

Mahesh: I had similar comments for the UDP notif. For the distributed
notif, it would also be good to see some configuration examples. Would
you say that the distributed notif draft is really about having the ID
about when the notifs are coming from?
Pierre: Please repeat question.
Mahesh: Are you including a node id of where the nofificaiton is coming
from.
Pierre: It is called a subscription id.
Mahesh: Does that summarize what the draft is covering?

Thomas: I can't make out this text. Since distributed notif is transport
independent, it needs to be in a different draft.
Mahesh: Should the draft give examples for each of the transports (UDP
vs TCP based) that are going to be used?
Thomas: ... hard to hear what was being said ...
Mahesh: What I remember seeing in the draft was mention of UDP (by
virtue of the fact that UDP-notif draft is cited). Can distriuted-notif
be also supported over TCP?
Mahesh: I will send comments to mailing list. (46-min mark)

Non-Chartered items:

Per-Node Capabilities for Optimum Operational Data Collection (15 mins)

https://datatracker.ietf.org/doc/html/draft-claise-netconf-metadata-for-collection-03

Discussion Leader: Benoit Claise

Benoit presenting

Audio from the room was missing as part of trying to compile the
minutes, and as such only the minutes from the remote folks have been
added here.

Tim: Have seen this problem statement discussed for other protocol like
IPFix (the "IE" number assigned to the node). We see some usefullness.
Support for multiple sources would be nice.
Benoit: Very Good, Thank you. For the IPFix, there is an additional
semantic behind it with key field definitions. I could go into more
details later.

Tim: Yeah! But it's for the same problem that you are trying to do for.
So I think we can address it.

Rob Wilton: Agree that recommended polling interval is more interesting
than minimum polling interval. I definitely think that it makes sense in
that context that you say. A minimum polling doesn't always make sense
depdening on the capacity. One o the things, even with the recommended
one, is that it might on what other subscription you are looking at the
same time. If you have got one subscription agains the variable then
that might give you the interval, whereas if you polling lots of other
data at the same time, then that will change, and I think that is one
aspect that is also related to the adaptive telemetry drafts, which have
similar issues. How do you advertise what you can do at the extreme but
what you can do in a sort of more generatized sense? I do not know
whether the recommended one because that would change dynamically, or
whether you need something to be able to say these are all the
subscriptions, tell me what you can do for me. It is interesing what
gNMI does here is that they have an option of saying "just do your
best", that modifes the subscription request dynamically. As to the
question as to whether we would implement now - I'm not sure, but in
future, probably.

Benoit: "do your best" is what we want too. We need to formalize it. As
an example of IPFix flows, you are able to get your sampling rate back
to your flow collector, so that you can do your own computation. In this
world of adaptive, where you do your best, if you don't know what your
best is, and it keeps changing, if you do not advertise to your data
collection system, then you cannot reconcile information easily. But
this I-D is about doing "your best" based on what you could do now.

Charles Eckel: (channeling Juergen) Does the node tags work done in
NETMOD provide the means to obtain the metadata? Do we really need a new
RPC?

Benoit: Short answer, I don't know yet. I will look into that.

Joe Clarke: Agree on the issue on polling. Regarding SNMP OID mapping.
There are lot of challenges. Having the OID is only part of the problem,
also need the index mapping and that is on a per instance. It sounds
useful, is it going to be doable enough to actually make me spend the
time to do the work. How will this scale (or will it)? Moreover, on
related nodes, how does this work with multiple, related nodes? Just
don't know how practical it would be.

Benoit: Getting the index in the MIB, or have multiple indexes, and then
we have YANG, which has its own indexes, it is highly complex. Doing
things in steps might be the right answer.

Diego Lopez: This is the kind of feature that we have been asking for a
while. I'm supportive of this work.

Benoit: Which parts are you particularly interested in?

Diego Lopez: From my experience, migration path (from MIB OID) would be
the most important part for the people running the real networks.

Balazs: Besides OID and IPFix references, 3GPP uses addressing with
Distinguished Names. That reference might go beside the OID IpFix
reference.

Poll: 29 participants, 24 saying they had interest.

Transaction ID Mechanism for NETCONF (10 min)
https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-id-01

Discussion Leader: Jan Lindblad

Mahesh: Jan, do you want a poll to ask if there is an interest in the
work?

Kent: You did not mention RESTCONF in your presentation. Does this work
offer a feature parity between NETCONF and RESTCONF. In particular Etag
and modification time.

Jan: Yes. If you read the draft, it mentions RESTCONF and how it would
work there. It's featre-parity but goes beyond that. And going beyond is
also feature compatible with NETCONF.

Kent: My second question is on the first bullet point in this slide (Add
text for Etag intergration with YANG Push). What is the nature of the
integration needed for YANG Push?

Jan: When client subscribes to config updates, the pushes that form data
updates as part of the config, that config is echo'ed back from a YANG
Push subscription, then it is hard for the client to rationalize the
changes (e.g., when multiple clients are making updates), whether this
is an update of the config change or actual data.

Kent: Getting the confirmation back of the change that was made may not
be a bad idea. In that sense, perhaps this is not a big deal.

Jan: What you want can be had with a transaction id also. This might
save quite a lot of data/comparisons.

Poll results: 23 responded, and 22 said that they are interested in this
work progressing. 1 not interested.

Kent: We can move into an adoption call.

Problem Statement and Use Cases of Adaptive Traffic Data Collection (10
min)
https://datatracker.ietf.org/doc/html/draft-he-adaptive-collecting-problem-usecases-00

Discussion Leader: Xiaoming He

Presenter's name was not recognized in the attendee list and the
presentation was moved to after the adaptive-subscription draft.

Benoit: It seems like the problems are towards dataplane monitoring.
Sometimes it is easier for me to know if we speak about dataplane that
in-band OAM, described in the last use case. If you speak about flows,
if you speak about something else as opposed to just telemetry. Periodic
updates is where the use the use case should be likely more structured.
It would be useful to more narrowly define the usecases for this.

Kent: We had to take this presentation out of order in the hope that
this draft would provide the use case for adaptive subscription draft.
There were objections raised by Andy and Per on the adaptive
subscription draft, but I do not see Andy online, and do see Per on the
attendee list ...

Jan: Per is not able to speak currently. We should take the concerns (as
they relate to adaptive subscription draft) to the mailing list, I think
that many of the concerns that we have raised are still relevant.

Poll: 24 participants. It is divided half-half. Half want to work
towards adaptive subscription being adopted as a Proposed Standard,
while the other half want to continue the effort towards an experimental
draft.

Kent: This is not an adoption poll either way, and as Jan commented,
more discussion needs to happen on list to address comments received. We
will hold the door open towards a Proposed Standard a little longer.

Adaptive Subscription to YANG Notification (15 mins)
https://datatracker.ietf.org/doc/html/draft-wang-netconf-adaptive-subscription-09

Discussion Leader: Qiufang Ma

Poll: 24 participants, 11 agreed to move it forward as a proposed
standard while 13 said they would not mind moving it to experimental
status.

Rob: I have concerns about the sort of complexity that we are pushing
onto the devices do this sort of continious monitoring and the XPath
evaluation. Just feels like to me that it is very computationally
expensive solution to this problem. I think one of the things I am
interested in and maybe the other presentation on use cases, if that is
related to this, might be interesting. How many cases do we have
actually in trying to solve this generically. Are there a few point
cases that we are trying to solve, and would it better to build
solutions and concrete data models to solove these particular cases
rather that building a generic infrastructure. I guess what I am saying
is that I do not know exactly what you are monitoring in terms of your
site, but could you build a data model that does that sampling at a high
rate and build either an aggregated statistics or something with a
decay, and then you can monitor that at a high frequency, and then leave
it to the server to respond. Do you actually need all this data at a
high rate or are you just trying to pick out when these particular
events are occuring more generally, and hence if you had a summarized
value in the data model that might give you the same solution with far
less complexity.

Ma: To the first question, if we leave the complexity with the
subscriber then we have a few complexity issues that we need to resolve
at the server side. If we leave the complexity with the subscriber then
we have issue with collecting enough data to identify the important
events. On the server (publisher) side we did add some complexity,
although the load on the server was marginal. We can look at the other
draft that discusses the use cases for adaptive subscription and whether
the use cases from that draft can be fitted with this use case. That
draft focuses on data collection mechanism, while this draft's focus is
on YANG-Push mechanism.

Rob: Some concrete examples that I could think of is for like the
interface statistics. I do not know if the IETF model has this, but some
of the vendor models have it, is that you have a rate calculation that
is telling you what the current load is on that interface, and that
decays over time so it is giving you a sort of point load value that you
could potentially samle that is a reasonable frequency. Another case
that I can think of it has to do with interface flaps. If you monitor
the link layer flaps at the very low hardware layers, you may be getting
thousands of interrupts per second coming through, and you do not want
to notify all of those. Instead, you could notify a counter of how many
flaps have occured at each point of time, so that you can still spot
that flaps are occuring, and that they are happening at a high
frequency, but you are not notifying every single flap that occurs,
thereby reducing the amount of data you are pushing off the device.

Ma: Ok. I will look into that, and give some more implementation
results. Thanks.