Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Robert Wilton <[e-mail]>]

On 09/11/2017 17:44, Andy Bierman wrote:
>
>
> On Thu, Nov 9, 2017 at 9:12 AM, Ladislav Lhotka <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Thu, 2017-11-09 at 08:34 -0800, Andy Bierman wrote:
>     >
>     >
>     > On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     > > Robert Wilton <[e-mail] <mailto:[e-mail]>>
>     writes:
>     > >
>     > > >>
>     > > >>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
>     > > >>> Implementation-time ...".  This section states that it is
>     a stable as
>     > > >>> YANG library, and hence cannot change due to a server
>     reboot. However,
>     > > >>> YANG library doesn't appear to have that restriction, and
>     hence this
>     > > >>> doesn't seem to align with RFC 7895, introduction paragraph 2.
>     > > >> I don't know exactly under what circumstances YANG library
>     can change
>     > > >> after a reboot, but in such a case schema-mounts data might
>     be subject
>     > > >> to a change as well. I definitely think that the "run-time"
>     case is
>     > > >> something else.
>     > > > A software upgrade could quite reasonably change YANG
>     library without a
>     > > > device reboot.  Perhaps saying less is more precise:
>     > > >
>     > > > E.g.
>     > > >
>     > > >     2.  Implementation-time: the mounted schema is defined
>     by a server
>     > > >         implementor and is as stable as YANG library
>     information. Also,
>     > > >         a client can learn the entire schema together with
>     YANG library data.
>     > > >
>     > >
>     > > It seems that neither 7950 nor 7895 defines how stable YANG
>     library data
>     > > is. The conclusion might be that it can change any time, which
>     is IMO
>     > > hardly acceptable.
>     >
>     >
>     > Actually, the YANG library is allowed to change at any time.
>     > Clients use the module-set-id and the yang-library-change
>     notification
>     > to keep their cached copy of the server's library up to date.
>
>     Notifications are optional, so basically the client needs to check
>     module-set-id
>     before every operation, and even this may not be sufficient for
>     avoiding errors.
>
>     The YANG data model was touted as a contract between the server
>     and client - and
>      it is a strange contract if the server can change it arbitrarily.
>
>
>
> The server can change the library according to the contract.
> It updates the module-set-id.
>
> In reality, there are no routers that change the module set at run-time.
> They are all mostly-monolithic firmware that need to reboot to change 
> the YANG modules.
> Modular software is more complex to test, so it is not as common in 
> embedded systems.
I think that it is becoming a lot more common.

Various network OSes allow fixes to be installed on the fly (which could 
include fixes or additions to the manageability interfaces), or the 
software to be upgraded without a formal reboot of the system.  Normally 
this would be achieved via some controlled failover of the route 
processor node to a hot standby route processor.

Linux allows packages to be installed on the fly.   This could include 
new protocols and services with associated YANG modules.  In fact, there 
are even variants of Linux that allow the running kernel to be hot 
patched without a reboot!

If a "hot" upgrade was being controlled by YANG then ideally you don't 
want to even break the management protocol session if possible.

Certainly, I would think that you need to allow LNE's to be 
provisioned/unprovisioned without restarting anything.

Thanks,
Rob