Minutes IETF118: netconf: Tue 08:30
minutes-118-netconf-202311070830-00

Agenda for the NETCONF 118 WG Session

https://datatracker.ietf.org/meeting/118/materials/agenda-118-netconf

Session:

TUESDAY, November 7, 2023
Morning Session I (09:30-11:30 CET, 08:30-10:30 UTC)

WG Chairs:

Mahesh Jethanandani (mjethanandani at gmail dot com)
Kent Watsen (kent plus ietf at watsen dot net)

Secretary:
Per Anderson (perander at cisco dot com)

Available Now:
ICS: https://datatracker.ietf.org/meeting/118/sessions/netconf.ics

Available During Session: (pick one)

In-room Tool:
https://meetings.conf.meetecho.com/onsite118/?group=netconf
Remote Tool: https://meetings.conf.meetecho.com/ietf118/?group=netconf

Audio Only: https://mp3.conf.meetecho.com/ietf118/netconf/1.m3u
Chat Only: https://zulip.ietf.org/#narrow/stream/netconf

Available During and After Session:

Notes: https://notes.ietf.org/notes-ietf-118-netconf
Slides: https://datatracker.ietf.org/meeting/118/session/netconf
Drafts (PDF):
https://datatracker.ietf.org/meeting/118/agenda/netconf-drafts.pdf
Drafts (TGZ):
https://datatracker.ietf.org/meeting/118/agenda/netconf-drafts.tgz

Available After Session:

Recording: https://www.meetecho.com/ietf118/recordings#NETCONF

Introduction

Chairs (10 minutes)
Session Intro & WG Status

Mahesh and Kent:
Status of ongoing work:

• https-notif draft has been in IESG review for some time, it had some
  IANA considerations that are now worked through thanks Rob (Wilton,
  AD) for that. There are some DISCUSSES that needs to be addressed
  that will be started after this meeting.
• client-server suite of drafts, there are 9 drafts but we hope to be
  able to finish 3 of them. There is a BBF Liaison statement where
  they request also the tcp and tls drafts, we will prioritize them
  and try to get those through first. We need to compose a response,
  which we will do that with our AD. They are quite stable and
  deployed in at least two applications.
  Rob Wilton: We can't guarantee what the IESG review will result in.
  But we can say that they are quite stable, from a WG perspective
  they are done.
• tls-1.3 draft is submitted for IESG review.
• drafts udp-notif, distributed-notif, transaction-id,
  list-pagination, private-candidate, versioning-in-yang-notif are all
  work in progress and will be presented in this session.

Per A wants to start the discussion for netconf-next and restconf-next,

perhaps gather together a side meeting. We will discuss this in the
end of the session.

Chartered items:

NETCONF Private Candidates (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-privcand-01
Discussion Leader: Robert Wills

Mahesh J: even though you separate transaction-id from privcand, can it
be a SHOULD or MAY for existing implementations.
can the conflict resolution still be used?
Rob Wills: It might require a bit more thought. Will be discussing with
Jan Lindblad and send the outcome to the list.
Kent W: Can you explain the RESTCONF support?
Rob Wills: privcand is not useful in RESTCONF, because it only lasts
during the session/request. behavioral change is if the privcand
capability is advertised then candidate is committed to running if
NETCONF sessions have changed the candidate the RESTCONF request will
commit this to running. this means that if privcand capability is used
the RESTCONF session can't commit other sessions' changes.
Kent W: So RESTCONF is not supported then? If so need to rework. NETCONF
sessions typically don't close because of RESTCONF session commits.
Management systems typically have long lived NETCONF sessions, order of
days or weeks. I would like RESTCONF to be able to use privcand.
Mahesh J: Any RESTCONF edits will conflict with wathever the NETCONF
session is doing.
Kent W: The commit for NETCONF happens when the session is closed, but
many NETCONF sessions don't close the sessions.
Rob Wilton: A NETCONF session does a commit, and that will commit the
candidate at that point in time.
Mahesh J: So it isn't really tied to the closing of the NETCONF session?

Kent W: Still open issue with RESTCONF support, privcand should be
supported for RESTCONf as well.
Rob Wilton: The NETCONF issue is moot, it just means your privcand will
be open a longer period of time.
Kent W: Actually a misunderstanding, it is not at session close but at
commit.
Rob Wilton: Then you create a new privcand?
James C: Doesn't cause an issue for long lived NETCONF sessions, doesn't
cause any issue with management systems. privcand is less useful for
RESTCONF since the session only lasts during the request.
Kent W: NETCONF looks brilliant; would like to see RESTCONF support,
would like to see some ability to use it.
Rob Wilton: for RESTCONF you could create a privcand with a random id,
how to stop any other session to edit it? would be nice with more
RESTCONF support beyond a single request.
Kent W: could be tied to the RESTCONF authenticated username
Jan L: valuable work, too many modes. reducing number of modes would
enable easier implementation. one mode (auto-update), you need to keep
running in the db at all times which means calculating deltas for
auto-update continuously. privcand can be implemented as snapshots of
running or deltas towards running. if running is big this becomes a
scaling problem. i would like privcand to work in large scale systems. a
lot of things in transaction-id could be valuable for privcand as well,
perhaps a separate draft for conflict resolution.
Rob Wills: auto-update is defined as continuous rebase in the draft. the
WG should look at the modes and if they can be reduced and how it can be
made to work in large scale. would be nice to define conflict resolution
together with transaction-id.
Quifang Ma: Not all of my comments are resolved, e.g. RPC call update
but YANG model doesn't update it.
Rob Wills: correct, we will work on defining a YANG module.
Kent W: Next steps?
Rob Wills: Take comments from session and on list and discuss there for
a new revision of the draft.

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

Discussion Leader: Jan Lindblad

Transaction-ID
Per Andersson: RESTCONF ETag and transaction-id support between
protocols, e.g. HTTP ETag is defined as US-ASCII but transaction-id
identifier is UTF-8. Furthermore HTTP Etag is unique per encoding if
strong (consequences for matching), if instead weak need to prepend with
W/. See
https://mailarchive.ietf.org/arch/msg/netconf/HH8sIjx7vuLd42T71PuuUP-P4Bw/

Jan L: Very good point, we need to update the exact format for these
tags to better conform with the HTTP documents. It doesn't change the
solution.
POLL: Ready for WCLG YES: 13, NO: 0, ?: 38
Rob Wilton: I note that it is another poll with a large "no opinion",
might be a large portion of the room that don't know.
Jan L: the document is approaching LC, it is stable and now is a good
time to read and give feedback.
Rob Wilton: would be good to resolve overlap of transaction-id and
privcand before WGLC

Trace Context
No comments.

List Pagination for YANG-driven Protocols (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-02

Discussion Leader: Per Andersson

POLL: Should cursor based pagination be opt-in? Yes: 14 No: 2

Quifang Ma: How does a client know when to use snapshot?
Per A: Up to the user. Might be missing how to reuse the snapshot for
subsequent requests.
Kent W: Depending on size of the data for "config false", the user might
want snapshot.

UDP-based Transport for Configured Subscriptions (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-11
Discussion Leader: Alex Huang Feng

Mahesh J: (chair) we have sent request to transport directorate and
waiting for request.
Mahesh J: (contributor) is the recommendation to adapt to the MTU?
Alex HF: If there is risk for packet loss you should not use udp-notif.
you can set the MTU depending on your network capabilities.
Mahesh J: the SHOULD is pretty strong recommendation
Alex HF: with YANG-Push the message is variable. we reference the RFC
8085 UDP Usage Guidelines
Mahesh J: Either you state that you want to support it or limit the size
of the packets.
Alex HF: ok, it should be supported but the packets should be small.
Rob Wilton: when UDP is being used, IESG reviews often require
congestion control. maybe suggest that this should only be used when it
can be guarenteed to be no congestion or the device receiving is close
by so it doesn't matter. there needs to be some text for this.
Alex HF: there is text for it.
Rob Wilton: Hopefully that is enough.
Kent W: it is just counters, so it isn't a big deal to lose a thing.
with yang-push message is variable, perhaps there could be guidance for
when to use https notif and udp notif, e.g. suggest use https generally
but use udp for high troughput, if messages are below MTU size in the
network use udp.
Alex HF: don't like going that far in recommendations, it should really
be up to the user. ok with having a statement use https notif if the
package is big, but wouldn't go that far.
Kent W: Agreed.

Subscription to Distributed Notifications (5 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-08

Discussion Leader: Thomas Graf

Kent W: This work depends on udp-notif which depends on
udf-client-server which is not yet adopted. We could progress this but
it would be stuck in MISSREF in RFC Editor.
Thomas G: We should discuss this when that draft is presented.

Support of Versioning in YANG Notifications Subscription (5 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning-03

Discussion Leader: Thomas Graf

SIDE MEETING: YANG @ Kafka Nov 7th at 15:30 in Palmovka 1/2

Non-Chartered items:

Support of Hostname and Sequencing in YANG Notifications (5 min)
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-02

Discussion Leader: Thomas Graf

Thomas G: Requesting WG adoption
Jan L: How do you foresee that the hostname (where it is generated)
should be known for the consumer at the very end?
Thomas G: We aligned with the BMP Protocol, it should be known in the
management configuration since it needs to be configured on the host.
Mahesh J: Is there any reason why this draft is separated from the
yang-push-observation-time draft?
Thomas G: Here we extend the notification header with generated
timestamp, in the other draft we update the yang-push statement with
observed timestamp.

POLL: Have you read the notif-sequencing draft? YES: 6, NO: 13, ?: 38

Mahesh J: Not many have read it, continue the discussion on the mailing
list.

YANG model for NETCONF Event Notifications (10 min)
https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-03

Discussion Leader: Alex Huang Feng

Mahesh J: (chair) you had a slide comparing NC messages. there is a time
definition in a WG document. We can't have two documents defining the
same thing. Have you talked with the authors of
draft-ietf-netconf-notification-messages. Can this be used for you also?

Alex HF: They define a whole new structure to bundle notificitaions in
the same message. I only implement the gap missing. notif-messages
should depend on my draft.
Rob Wilton: CBOR-SID was blocked in IESG review, should now be resolved.
Is probably worth allocating a CBOR-SID range for this and generate a
SID file.
Alex HF: have asked CORE WG chairs for guidelines, there are none. Need
guidelines for subsequent work e.g. YANG-Push how to define
notifications and allocate CBOR SIDs.
Rob Wilton: The CBOR-SID should have guidelines for allocating SIDs for
existing RFCs. Maybe you want to optimize the SID allocation so this and
yang-push SIDs are close together.
Alex HF: To actually use CBOR-SID you would need the entire SID range
for all YANG dependencies. I don't mind doing it, but the WG should push
other drafts to allocate CBOR-SID.
Rob Wilton: If an RFC with a YANG file defines a SID, the depending
RFC/YANG are allocated automatically.
Kent W: Thank you for your contribution. Very welcome when people write
drafts to fill gaps.
Thomas Graf: The industry has implemented proprietary YANG-Push
implementations. They are aware of missing definitions and this work
should be progressed very quickly.
Kent W: As a chair I would like to fast track this adoption as well.
Ahmed Elhassany: You can validate messages. Why use structs for this? Is
new tooling needed?
Alex HF: We are tryng to use yangkit, they have support for this header.
Notification is defined as a keyword, that is why using structs is
needed instead of a simple container. The push-update is defined as a
type, and this notification type is not defined.
Ahmed Elhassany: Must be some implementation section on how you would
validate the messages with the structure you define.
Kent W: I have software that rewrites the structure to container
internally, then validates it. Cheap but it works.
Ahmed Elhassany: We need it documented how to perform this validation.

YANG Grouping for UDP Clients and UDP Servers (10 min)
https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-udp-client-server-00

Discussion Leader: Alex Huang Feng

Kent W: (contributor and co-author) the draft only need udp
client/server groupings, not defining tls/dtls in this draft since they
are defined in the tls-server-client draft.
Alex HF: I implemented it because it was suggested in a mail from
Mahesh.
Mahesh J: Probably must have suggested it because one grouping needs to
be used inside.
Kent W: Not needed since you can use and stack the tls/dtls where
needed.
Alex HF: If the WG agrees, I'll remove it from this draft.
Kent W: That makes this draft even smaller and quicker to get through
Thomas Graf: By moving out that to another draft, we're creating another
dependency. The industry is moving forward and looking forward to the
adoption of YANG-Push, so we welcome this being fast tracked.
Benoit Claise: always other goals with groupings. Since there are
dependencies that can't move if this is not done. Can we put a deadline
and progress if the client/server drafts are not done by then? Because
we need those dependencies now.
Kent W: The chairs are in agreement that this work should be fast
tracked since it is a dependency for an existing WG document.

YANG push Integration into Apache Kafka (10 min)
https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/INF690_presentation.pdf

https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/Zhuoyao_final_thesis.pdf

Discussion Leader: Zhuoyao Lin

Rob Wilton: one concern with adding augmentation list into yang-library
is that this could be duplicate information, alreaday specified in yang
modules but now another mechanism with the same data. this can become
out-of-sync now and you have to trust what you are going to use; I guess
the answer is to always depend on the YANG module being correct. a
possible down-side of doing this.
Benoit Claise: not different from a deviation, it's actually a timing
issue, if you want to use yang-push and ipfix, do we want to loose the
time to get the full schema. issue is real-time timing for telemetry.
this is a small cost to solve that problem.
Rob Wilton: in YANG packages we are taking deviations out to remove this
sort of duplication, i.e. going the other way.
Jan L: This information is already available elsewhere, but it could be
an ok trade-off to have it available precomputed for some clients.
(CHAT) Benoît Claise:
draft-lincla-netconf-yang-library-augmentation-00.txt

Mapping YANG Data to Label-Set Time Series (5 min)
https://datatracker.ietf.org/doc/html/draft-kll-yang-label-tsdb-00
Discussion Leader: Jan Lindblad (on behalf of Kristian Larsson)

Philatelist, YANG-based collection and aggregation framework
integrating Telemetry data and Time Series Databases (5 min)
https://datatracker.ietf.org/doc/draft-lindblad-tlm-philatelist-00
Discussion Leader: Jan Lindblad

Thomas Graf: Amazing! What you just desribed, and looking through your
draft: this is probably what a network operator does to make it work end
to end. A few comments: On slide 5 you write transport format, one
clause would be nice there preserving semantics. Today we are loosing
semantics already at the transport. In Section 3.2 in your draft
document, you describe how subscriptions need to be established and
managed. In the Data Mesh architecture we need SLAs and SLOs when we are
subscribing on something, we need guarantees that we get the data and
not loosing data because we are streaming data. In section 3.3 you
describe, you describe them streams and flows. there is already
terminology, in kafka e.g. topics and subjects. right now you are
describing when you flatten the data, you need to change the paths etc.
We are in contact with TSDB vendors to support YANG, but until that
exists this is what an operator needs to do to make end to end work.
Jan L: thanks! I wrote this draft just to have make this conversation
happen and I am very happy that you bring this up! this work is given me
impostor syndrome, there are people in the room that have worked a
decade with telemetry collection for every week I worked with it, it is
very intimidating to stand here and present but I very much welcome the
feedback and collaboration.
Ahmed Elhassany: This is very important. We are hacking around TSDB to
support YANG and the semantics, this is not about drawing graphs but
providing insights. Need a more ideal solution than a mapping to
services. There is a lot of interest with TSDB vendors to support YANG,
let's make it a two-way conversation and not just do a mapping to their
work.

End of presentations.

Per A raised if there is interest in work for starting looking at
restconf-next and netconf-next.

Per A: Now when a lot of work is getting finalized the WG could have
time to look at restconf-next and netconf-next. A first step would be to
categorize the open issues to see what can be done without yang-next,
without a new protocol version, what is already done, what is
uninteresting?

About a quarter of the room showed interest.

Per will book a side meeting and announce it on the mailing list.

15 Minutes Remaining