Subject: Re: [Netconf] Summary and AIs from IETF-100 meeting

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 1 Dec 2017 10:50:44 -0800

Juergen,

I want to separate the question of whether YANG Library should address anything beyond supporting NMDA from the discussion on feature requests made in the meeting. Focusing on the latter for now.

> On Nov 29, 2017, at 12:57 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Mahesh,
> 
> so do I understand correctly that all this is about yang library and
> has nothing to do with the NMDA update for RC and NC? This would
> already help reducing my level of surprise.

Yes, this is about YANG Library.

> 
> Concerning licensing: A functionality that does not exist in the
> server does not exist in the server, whatever the reason is. In the
> future, there may be a standard YANG model that allows to configure
> (enable/disable) functionality within a modular NC/RC server. So far,
> I have not seen a proposal for this and hence I consider this topic
> not ready for any WG action.

The proposal (as Andy also suggested) would be to have an additional flag that indicates the ability to support or not support a module. Since YANG Library announces the capability of the server, this additional flag could indicated whether the module (even though announced) is “not-supportable” for whatever reason. The license module could set the flag to indicate that the module is “not-supportable” if the license for a particular module is required but missing, or the infra manager could set it because the line card is missing. At the minimum, it takes the guess work out of the client for whether a particular configuration will work on not.

> 
> Concerning missing hardware: The approach of the interfaces model is
> to support provisioning of interface configuration for non-existing
> interfaces. Hence, if a server can configure say ATM line cards, then
> the server should announce support for the ATM specific YANG modules
> independently of the question whether ATM line cards are currently
> present. To find out which hardware is present at a specific point in
> time, consult the ietf-hardware model. I do not see why a change to
> yang library would be needed to deal with missing hardware nor do I
> recall what the proposed edits were.

This puts the onus on the client and for the client to figure out whether the necessary hardware is present. For that to happen, the client has to figure out which modules are impacted by the presence/absence of which hardware - no easy feat with the plethora of devices and the different pieces of hardware in them. The server on the other hand is in a better position to provide that information.

> 
> Yes, from the SNMP world I know that sometimes support for specific
> modules comes with the firmware of a piece of hardware but the NC/RC
> design never went into the details of modular servers like SNMP did
> with standards for subagent technologies etc. In the YANG world, this
> is all entirely implementation specific and frankly I would not open
> this can of worms. If the presence of some hardware enables server
> functionality (or a license that is installed), then this may lead to
> an update of the content of the yang library, like a restart of a
> NC/RC server may do. I do not see which technical change would be
> needed.

Restarting the NC/RC server every time the YANG Library content changes, is certainly an option. It will mean that existing sessions will be reset every time the server restarts. The other option I was considering was for the server to support the ‘kill HUP’ option, which forces it to re-read the YANG Library contents. Its downside is that, currently, there is no mechanism in place to announce a new set of capabilities.

> 
> The bottom line is that without concrete actionable proposals, we
> should not delay the finishing of NMDA work. And as Andy says, things
> that can be done with augmentations are good to do with augmentations.

I would like discuss the solution before deciding whether the solution should be part of the YANG Library draft, or an augmentation of the YANG Library module.

Thanks.

> 
> /js
> 
> On Tue, Nov 28, 2017 at 11:02:55AM -0800, Mahesh Jethanandani wrote:
>> 
>>> On Nov 28, 2017, at 5:17 AM, Henk Birkholz <[email-masked]> wrote:
>>> 
>>> This seems to be an unnecessary jab that has nothing to do with the actual topics raised by Mahesh, which were:
>>> 
>>> - YANG Library will support the concept of licensing impacting what models are advertised and supported
>> 
>> I do not think the minutes are going to tell you anymore about the requirement. So let me take a stab at what I think the requirement is. 
>> 
>> YANG Library currently compiles a list of modules (and sub-modules) that are supported by the device. The same device might also support the concept of licensing, where the license controls whether the feature can be enabled on the device, e.g. BGP. The server has the ability to support BGP as a feature (the software exists), but the customer has not bought a license for the BGP feature. What should the server do under the circumstances? Should it advertise BGP module, and have the request from the client fail? Or should there another flag, either in the YANG Library or some other module that informs the client that although the device is capable of supporting BGP, it cannot because it lacks the license.
>> 
>> A similar scenario exists with YANG modules that support a particular line card, and that line card is hot pluggable. What should the YANG library do for modules that it advertises, but the line card for that module may or may not exist in the system?
>> 
>>> - semantic versioning should be part of the YANG Library
>> 
>> The requirement here is whether semantic versioning can be supported in the YANG library in addition to the current version, which is a date. Details on how it relates to YANG Library should be brought up on the list, preferably on a new thread.
>> 
>>> 
>>> Which, btw, I also am not sure about how and where that came up and what it means. In consequence - as Jürgen - I am curious to see the minutes.
>> 
>> Thanks to Robert for updating the rough minutes. If anyone disagrees with what is recorded in the rough notes, please listen to the recording here <https://www.ietf.org/audio/ietf100/ <https://www.ietf.org/audio/ietf100/>> and update the rough notes. They will be published as official minutes.
>> 
>> Mahesh Jethanandani
>> [email-masked] <mailto:[email-masked]>
>> 
> 
>> _______________________________________________
>> Netconf mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> 
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Dec 2017 20:24:18 +0100

> The proposal (as Andy also suggested) would be to have an additional flag that indicates the ability to support or not support a module. Since YANG Library announces the capability of the server, t…

As explained, for interfaces we explicitely do support the
configuration of interfaces that are not currently present.
 
> This puts the onus on the client and for the client to figure out whether the necessary hardware is present. For that to happen, the client has to figure out which modules are impacted by the prese…

NMDA makes this relatively easy since it exposes the difference
between intended and applied config. Something configured for hardware
not present won't show up in applied config.

Hot plugable hardware comes and goes asynchronously. Do you expect
that removal of the last linecard of type X removes all
_configuration_ for linecards of type X? If I plug it back everything
is lost? I think the NETCONF approach is that the config is maintained
on the device (not the linecard) and that you can expect the config to
be applied again is a linecard of type X is inserted into the same
slot again.

> Restarting the NC/RC server every time the YANG Library content changes, is certainly an option. It will mean that existing sessions will be reset every time the server restarts. The other option I…

I did not suggest to restart the server every time YANG library
changes. All I said is that the content of YANG library can change,
i.e., it is not necessarily static throughout the lifetime of a
server. (I also assume that a 1:1 mapping of server features that can
be enabled/disabled or hardware resources that can be present or
absent to modules is not necessarily likely. I consider it somewhat
likely that enabling a server features cause changes in several
modules and their announced features and even deviations.

> I would like discuss the solution before deciding whether the solution should be part of the YANG Library draft, or an augmentation of the YANG Library module.

Someone to write up a solution proposal and then we have something to
discuss. But in general, the default should be to focus on extensible
(augmentable) core models and not to always hold of core models
because there is yet one more feature to add.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>