Tuesday 2021-10-12 14:00 UTC
WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=netmod
Session ICS: https://datatracker.ietf.org/meeting/interim-2021-netmod-02/sessions/netmod.ics
Timezone Converter: https://www.timeanddate.com/worldclock/converter.html?iso=20211012T140000&p1=1440&p2=tz_pt&p3=tz_mt&p4=tz_et&p5=tz_bst&p6=tz_cest&p7=tz_cst-china&p8=tz_jst
Webex: https://ietf.webex.com/ietf/j.php?MTID=mf0cca6ee36dd3c9cb9e78b2f47696534
Jabber: xmpp:netmod@jabber.ietf.org?join
Jabber Logs: http://jabber.ietf.org/logs/netmod
Materials: https://datatracker.ietf.org/meeting/interim-2021-netmod-02/session/netmod
Note taking: https://notes.ietf.org/notes-ietf-interim-2021-netmod-02-netmod
Presenter:
- Chairs
Presenter:
- Kent Watsen (and authors)
Drafts:
Jason: Type leaf is an exception in interface node. Very desirable to have running ds be client controlled. Should also consider configuration templates (when considering if running is valid).
Kent: Agree on second point. This slides don’t cover templates, but agree we need to consider your point.
Jason: I’ve seen effectively server is validating intended. Problematic for offline validation of configuration.
Kent: Example at the end is effectively a template.
Kent:
Rob: Can we overwrite a trust anchor cert, or delete them?
Kent: Can overwrite an entry, but cannot delete them because they are system.
Jason: If lots of system config turned up in running then it could end up being very cluttered. Inactive until references is a tricky concept, do you mean active in the system, or shows up in the config.
Kent: I mean active as in being referenced and then applied to the system.
Jason: Should system be overwritable vs not being modifiable. E.g., Nokia supports both classes of configuration. E.g., some system configuration the server does not want to be modifiable.
Lou: That was an important comment, as it covers support for preprovisioning (preconfig) case (e.g., config for LC not yet inserted.)
Kent: Some cases of system configuration can change (even if the datastore is not configurable). It is modifiable through other actions (e.g., plugging in a card, enabling a license). How to notify? (Perhaps: etag, or timestamp)
Jason: Agree on concept of dynamically created config, but is a separate question as to whether it should turn up in running.
Kent: Yes, how do we report this.
Jason: Still unclear if the client would want to see lots of unreferenced config.
Alex: Have you considered autonomic control plane?
Kent: Interesting comment. Would autonomic control plane use a dynamic datastore or a system datastore.
Alex: Would it be useful to distinguish the case. Haven’t really thought this through.
Kent: Notion of what a vendor can describe in a system config is somewhat static. I.e., the possible schema is known. Autonomnic control plane is more dynamic and isn’t so static.
Alex: There are not many applications for ACP, but others may come along in future.
Kent: Please track this comment.
Jason: Comment on ACP - Doesn’t sound like config. Sounds more like state, not convinced that would be reflected in configuration.
Lou: I agree with Jason, ACP, if it is an agent on the box then it is another control plane protocol.
Alex: Might not be a control plane protocol.
Lou: Not a new class of thing, we have existing classes.
Rob: Do you mean a control plane or management plane protocol
Lou: It could be either depending on how it is implemented and what it is doing. I.e., automation is being done today via the normal management protocols and no new category is needed.
Jason: Yes I agree to this slide. Discussion today is about non deletable config.
Rob: Why are considering factory default, isn’t it completely different.
Kent: Talking about it because it has come up in the discussions.
Rob:
Kent: Yes, there could be an intent mismatch.
Jason: Comment on mandatory true that cannot be deleted.
Kent: Not saying about where it exists in the data tree. Don’t want mandatory true at the top because an empty config would be invalid.
Jason: Concern that we would now be allowing this to occur, which is a problem.
Kent: Yes, I think that potentially should be allowed because at validation time the mandatory node would exist.
Jan: That validation would only work on the device itself. Mandatory true is allowed (on within containers) by RFC 7950, but is not a good idea.
Kent: Let’s hold this comment until later slides.
Jason: Should this new system come up with a different origin (other than the existing system).
Kent: I was thinking about this, but couldn’t justify to myself about creating another origin, and would like to use existing.
Kent: Agreed that we might discuss potentially have another origin.
Alex: Is adding a new datastore an option?
Kent: Yes, that is a possible solution.
Kent: Propose that we stop discussing factory default datastore. Only active configuration would end up in “operational”.
Jason: Could have all referenced/unreferenced config should turn up in operational?
Kent: No RFC says that it can’t, but as a vendor, I’m not convinced that I would want it to. If an unused value didn’t get applied then why should it turn up?
Jason: What about QoS policy? What if I have assigned some policies to some interfaces but not other policies.
Kent: This is somewhat down to the vendor.
Jason: I don’t want to preclude all the system config turning up in operational.
Kent: Potentially too variable as to whether all vendors would do it the same way.
Jason: Any copy by explicit action is a bit painful. They have to do a separate thing. Propose that there may be a variable of A that is a bit more palatable. Allow client to create a QoS policy with the same name, but don’t have to populate the child nodes, but then running would become valid.
Kent: Resonate with the difficulty of doing this manually. Interactions are ugly and pollutes the contents of running.
Jason: Would be useful to at least have the declaration of the list entries in running.
Kent: A bit like variant A and B1. Instead of being copied from, say it is explicitly created, but only the subset of the referenced config turns up.
Jason: Would it based on the data model and up to the client to add what is needed. If there is a leafref then the client would also have to add it.
Kent: There was an objective to have a client not have to add anything. E.g., ideally leafrefs would still resolve, by discovering system config. Conversely, considering descendant nodes, in complete agreement of needing to copy those into running.
Jason: When descendent nodes are being edited then the operator has to create the object anyway. I know the desire to automatically reference these things.
Kent: Perhaps a combo solution. Need to check keystore drafts, and want to check that the drafts don’t preclude them being used.
Rob: Could leave it to the operator to add config if they want to, but they don’t have to, they would still validate.
Rob: How does the merge work? Does the merge happen before intended?
Kent: Think of it as layers, with system at the bottom and running on the top.
Rob: Can you force a delete to override?
Kent: No, can only write it with a different value, but cannot delete a value from system.
Jason: Want to have a way of not breaking traditional clients. Even clients having to understand the merge config might be okay for this, but this might be harder for config groups. I’m not convinced that clients can reproduce that logic.
Kent: Can you say more about config groups?
Jason: Some thought about how config groups work. Not sure that they are all aligned. Not sure that everyones implementations are the same. E.g., how do you merge user-ordered lists. Or what about choice statements. When statements have similar complexities. Need to be careful about any soln where the client has to calculate the result. Still want an option where old clients read running and it becomes valid, in those cases clients have to create the stubs.
Kent: Don’t have a slide that talks to interop (old client to new server). Clients today are already working without references to system configuration. If this true, then we might not have to worry about this case. Perhaps need to consider new and old clients both interacting to the server at the same time.
Jason: Servers are effectively doing the validation against intended. Server validation function won’t highlight these errors. Would we need a new validate operation.
Kent: I don’t follow. Assume system config is valid, and assume that it is a client config error.
Jason: E.g., interface references system QoS policy. Most servers would accept (validate) that config. If you tried to validate offline then it would fail.
Kent: I was thinking about referencing a QoS policy that doesn’t exist.
Rob: For NMDA I think that running is valid because intended is valid, i.e., by implication.
Jason: I’m worried about changing whether running is valid or not.
Jan: I agree almost with everything that Jason has said. RFC 7950 says that everything that comes from config must be valid.
Kent: Jan, can you quote the section of the RFC that states that running is valid.
Jason: We should add an explicit statement that servers SHOULD/MUST be able to create system-created objects.
Kent: ???
Jason: Servers MUST remember if the objects are explicitly created.
Jason: Unclear whether we need a separate RPC or a new RPC.
Rob: Could use system datastore for sharing config for LNEs. Immutable flag should be a YANG next.
Kent: Yes, I think that I’m in agreement.
Jan: According to RFC 7950 you are allowed to do
immutable configuration, and always allowed to reject any transaction. However, this gets risky/confusion, and end up with the SNMP concept of transient configuration. One of YANGs goals was to never have transient configuration.
Kent: Yes RFC 7950 allows this, but not really defined, and would break backwards compatible.
Jason: This would end up documenting existing behaviour.
Jan: Yes, this is allowed, but it is easy to go wrong with this approach.
Lou: Not sure if it takes an extension or YANG next.
Jason: Junos doens’t have a leafref in the running config.
Kent: This is a real world problem and vendors are already looking for a solution.
Kent: What are the next steps? Seem to be too camps about whether everything must be in running.
Lou (as chair): Updating the draft with the conversation would be good, and use that as a mechanism to close out the open issue. Could even adopt with opposing views that we need to resolve through the purpose.
Jason: I don’t think that the views have to be opposing. I just don’t want to preclude making running valid.