Introduction
Chairs (10 minutes)
Session Intro & WG Status
No Comments.
Chartered items:
UDP-based Transport for Configured Subscriptions (15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-06
Discussion Leader: Alex Huang Feng
Alex: should we change “un” prefix to “snun” ?
Rob Wilton: Don’t see the need. It is only local to the file. If you were to change it, I suggest you adding a hyphen (e.g., sn-un). It should not block this draft.
Alex: Ok, so maybe staying with “un”.
Alex: Should we change to ip-address-no-zone?
Rob Wilton: This is trickier, unsure if there’s a clear indication exactly which way we should go with IP addresses. Using ip-address-no-zone at the moment is a fairly safe thing to do at the moment, it doesn’t cause any harm so it seems like a pragmatic solution. Maybe longer term fixing it in a better way, but doing that for now is fine and removes the problem. Sort of good enough.
Alex: should we configure the receivers as based on subscribed notifs or as https-notifs do?
Kent: the need for why https-notif did it that way was because it was a TCP based and hence the desire for the server to have a single transport connection to the receiver, regardless of the number of subscriptions that were pointing to it or using it. For UDP being session less, the technical requirement isn’t there; but for consistencies sake it make sense to me that it would use the same pattern.
Alex: Maybe the DTLS layer might impact performance, might be interesting to have a section mentioning the dtls performance impact? As authors we think this is pretty obvious, but is it necessary for this draft?
Kent: I have not seen this kind of language used in other drafts where encryption was being used for quite some time. So, I don’t really see a need for it in this draft.
Alex: Ok, we don’t do that. Thanks.
Joe: The use case referred to last time was distributing it to the line cards. That was what I was wondering, if the linecards off of the control plane are now tasked with encrypting and sending this out would there be a performance impact to what the linecards are otherwise doing from a dataplane perspective. That was what I was getting at, I realize that encryption is fairly common but this seems like a special case.
Benoit: I checked in ipfix and the section about DTLS, we don’t discuss performance there. As a comparison, we don’t need to discuss comparison.
Alex: There is no YANG model for ietf-notification, it is defined in XML schema for NETCONF in RFC 5277. Can become a problem if output is JSON or CBOR.
Thomas: One question regarding the netconf event notification. My question: Should it update RFC 5277 or should it be a separate draft?
Alex: I don’t mind updating NETCONF Event Notification (RFC 5277), but I don’t know the actual IETF process; we are open for proposals.
Mahesh: Bring it to the mailing list.
Subscription to Distributed Notifications (2 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-04
Discussion Leader: Alex Huang Feng
No updates on this draft.
Going to WGLC at the same time as draft-ietf-netconf-udp-notif
Balazs: was an earlier draft about netconf notifs (netconf messages and bundles), check that one.
List Pagination (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-00
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-nc-00
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-rc-00
Discussion Leader: Per Andersson
Jason Sterne: Is the discussion of snapshots for config vs state? Because snapshot of state could be expensive for very large lists, where this is applicable and might not be practical or feasible, but for config it might be. Maybe it might be two separate discussions.
Per Andersson: This question has been raised, e.g. how would a snapshot over operational data work for instance.
Kent Watsen: Envisioned uses cases are primarily for operational state and Jason’s points are very well taken. But for config clients have been able for over a decade to completely load the config needed, so the need for pagination of config data is not extensive. The need for pagination is primarily for operational data. When this was discussed previously, the concern was that the operational data had high churn and the want to track it. This could also be true for config data but the counterpoint was made that something like RESTCONF’s ETag or Jan’s transaction-id draft could detect when such changes have occurred.
Rob Wilton: Do you snapshot keys or all the data?
Kent Watsen: It is probably an implementation detail.
Rob Wilton: So my concern is about consistency of the data, what is returned?
Kent Watsen: Snapshot is for all the data, that’s the common understanding.
Jason Sterne: It may be odd to have a hybrid where the implementation can choose for a full snapshot or snapshotting only the keys (but the rest of the data is changing). It seems that the need for snapshot is probably for huge datasets and that is probably a challenging problem to solve.
Kent Watsen: The strongest use case is logs, where they are appended only.
Jason Sterne: I can see your point for logs which are appended to a flat buffer, but it would be interesting to see if other people are thinking of dumping their RIB and then asking for a snapshot something that is huge and dynamic.
Rob Wilton: Maybe snapshot isn’t really needed for logs (data isn’t churning/reordering, just new things being added at the end).
Andy Bierman: Cursor may not work (in a non-snapshot scenario). One implementation that has been working for 6+ years is to have the server return the last key, then the client can feed it back for the next request.
Jeff Haas: The thing that makes this messy is sorts and limits. With files you can regenerate all the necessary state as long as the files are not constantly changing. The case of large data like BGP RIB, for that case might be sufficient to store the last key to resume the iteration through the module as long as the container order is something that makes sense that can be contiued. For very large things like BPG RIBs that is generally how things are implemented. Should the use cases be split up so you can decide if you should iterate by keys versus cases where to generate position is to take the snapshot. You generate the necessary thing just by using an iterator.
Kent Watsen: The solution currenly in the draft allows for the server to specify for what operational state lists it supports various functions so the draft might implement a snapshot ability. The server can specify if it supports it by a list to list basis. For logs it might not be there, but for a RIB the server could say that it supports it.
NETCONF over TLS 1.3 (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-over-tls13-01
Discussion Leader: Sean Turner
Minor updates.
No known outstanding issues.
Request WGLC.
Meeting poll result: Rough consensus for WGLC. (Fairly strong support in the room.)
Transaction ID Mechanism for NETCONF (10 min)
https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-id-02
Discussion Leader: Jan Lindblad
Kent Watsen: Convenient if one solution could fulfill all the requirements, but I don’t understand if the other drafts fulfill these requirements in a better way.
Balazs Lengyel: The things txid solves are not immediately solved by the other drafts. There is a need for this draft. It could be harmonized with the trace drafts. There are also some problems with this removed capability that has potential for conflict, what if the transaction id is not suitable for some reason that has its problems.
Olga Havel: There is an overlap between the compared drafts, when I was thinking about use cases there is hierarchical tracing between multiple layers and a separate use case for application level tracing. I don’t think syncing and conditional configuration without txid. Perhaps there is a need for all listed/tangential drafts to co-exist.
Jean Quilbeuf: txid can continue on its own, and tracing can continue in another draft. It makes sens to have txid on one side and then the configuration tracing, with whatever method, on the other side.
Jan Lindblad: Agree that txid and tracing may be better as separate drafts. Implementors would probably need to deal with two or three drafts to implent txid and tracing.
Adaptive Subscription to YANG Notification (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-01
Discussion Leader: Qiufang Ma
No topics discussed.
Non-Chartered items:
Support of Versioning in YANG Notifications Subscription (10 min)
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-notifications-versioning-00
Discussion Leader: Thomas Graf
Jason Sterne: Sending systematically information about module, version, path might be consuming too much data. NETCONF already has mechanisms to provide a list of modules & versions a server is using - perhaps we can rely on that instead of putting that in-band with the notifications? Maybe we can find out another mechanism to capture only changes.
Rob Wilton: May need a list of modules (rather than just single module), or a YANG package that identifies something bigger. Going back to Jason’s point it’s a valid point about efficiency, the key problem being solved here is if the schema has changed you get different values for different versions.
Balazs Lengyel: what’s the link with draft-collected-data-manifest?
Thomas Graf: Similar need but draft-collected-data-manifest is about additional metadata about how the data is collected on the node itself, in this draft it is about the semantic reference. Both adds metadata, but differente metadata.
Jean Quilbeuf: The metadata collected together with YANG-Push data is necessary to do the mapping we need.
NETCONF Extension to support Trace Context propagation (10 min)
https://datatracker.ietf.org/doc/html/draft-rogaglia-netconf-trace-ctx-extension-00
Discussion Leader: Jan Lindblad
Jason Sterne: How would a trace-id work as a leaf? Would it be stored in the database or be ephemeral?
Jan Lindblad: It would be on the RPC level, compare to datastore name. The leaf would not be stored in the db per say, but for the transaction e.g. in the RPC data as an input leaf. These id’s aren’t stored against a specific leaf but for the transaction.
Ahmed Elhassany: Can a change in different system towards (possibly) the same datastores get the same trace-id or will it be implementation specific?
Jan Lindblad: We can talk about it if you have ideas.
Olga Havel: How would multiple applications be dealt with, which might conflict in trace contexts.
Jan Lindblad: Trace states can have separate states, you can append application’s states.
Charles Eckel: Is this the mechanism that the W3C recommends or is it used and working well?
Jan Lindblad: The trace-context is only a year old, the current direction in the W3C is going this way. There are tools for it already.
External Transaction ID for Configuration Tracing (10 min)
https://datatracker.ietf.org/html/draft-quilbeuf-opsawg-configuration-tracing-00
Discussion Leader: Jean Quilbeuf
Balazs Lengyel: I have a serious problem with this: Where do you get the client-id from? We can’t require the client to send this.
Jean Quilbeuf: The client must send this. But this needs work on how to solve it.
Kent Watsen: Aim for feature parity between NETCONF and RESTCONF.
Benoit Claise: Initially we posted this to OPSAWG. Looking for feedback on what WG should own this work.
Mahesh Jethanandani: Would like to see how these three (trace) drafts are related and what dependencies they have.
NETCONF Private Candidates (10 min)
https://datatracker.ietf.org/doc/html/draft-jgc-netconf-privcand-00
Discussion Leader: James Cumming
Is the WG interested in this work?
Show of hands/hum: yes
Charles Eckel: With an NMDA private candidate datastore. Would it be possible for multiple clients to share the same private candidate? Is that a use case that you have thought about and will support?
Rob Wills: This is not included in the current draft, it is per session. Hesitant to introduce shared candidates for a subset of sessions, it adds complexity.
James Cumming: We had a similar concept with the persist-id commits but it is nothing we have focused on.
Rob Wilton: Different vendors implement this differently. Is the WG going to converge on one solution or will it be similar to the with-defaults, documenting different solutions thus not having as strong standardization. That is a key question for this work.
Joe Clarke: Do you need to decide about the reconciliation methods in the draft? If there are two different private candidates, maybe one is long running but the other one is not. Regarding conflict resolution, might be good to keep it simple to not get difficult merge conflicts and otherwise abort.
Rob Wills: One of the things the authors have aimed for is to get a standard set of terminology. Although these two methods are proposed, we have tried to commonize where we can.
James Cumming: It is worth to indicate to the client about issues, so it can be handled. Not automatically resolving it, that might not work. How to then deal with the issue might be as simple as fixing the candidate, override, or update the baseline.
Andy Bierman: WG needs to clearly specify all the requirements before starting work. RESTCONF doesn’t support the session based solution for instance, it should be protocol independent and support both RESTCONF and NETCONF. It needs to be per user, no reason why an application can’t have several sessions. It needs to be explicitly managed, you can’t fire up multiple copies of the running config that easy. The original datastores were coined because that was what vendors supported and it wasn’t possible to do one size didn’t fit all. We may need similar options here.
James Cumming: Will you be able to put it on the list as well so we can track it. I definitely welcome support on the RESTCONF side.
Kent Watsen: Regarding continuous rebase. It is unexpected for clients that the server would change the datastore underneath them without clients opting in. In NETMOD WG there is a draft for with-system where the capabilities could change in-flight, that could actually impact the running datastore without the clients interaction. The fix for that was for the client to pass a parameter into it’s RPCs where the client states that it opts in to that idea. If the client is using private candidates it might already be in on using automatic conflict resolution. Perhaps the client could advertise that it can handle this mode. (i.e. client explicitly opts-in)
James Cumming: The static branch might be the default, but if the client sends an option to the server the continuous rebase would be used.
Kent Watsen: There are a lot of legacy clients out there, but if the client could indicate that it can handle continuous rebase then it’s ok.
Walid Elbokl: How will (several) confirmed commit(s) work with continuous rebase. You need to think about how you would do that because what is running now might not be true later because it might be rolled back in some point in time.
Jamus Cumming: In the static rebase you would have an out of date baseline, so it makes sense there. In the auto rebase mode you would update your baseline.