Subject: [Netconf] comments on draft-ietf-netconf-system-notifications-00.txt

From: Martin Bjorklund <[email-masked]>
Date: Mon, 20 Sep 2010 23:43:11 +0200 (CEST)

Hi,

I have read this document, and have started to implement the
notifications in the YANG module.  Here are some comments.

1)  notification sys-startup.

    I think it is very implementation specific if this notification
    makes sense at all.  I suggest this notification is removed.

2)  notification sys-config-change

    a)  Is the idea that this notif is generated if and only if a
        NETCONF <edit-config> operation is executed?  What about
        <commit>?  Or <copy-config>?  What about cancellation of a
        confirmed commit?  What about changes to running from other
        management interfaces?  IMO, this notif should be generated in
        all these cases.

    b)  There is a leaf 'target', described as:

          "Topmost node associated with the configuration change.";

        What does this mean?  If the edit-config is:

             <config>
                <foo>
                  <bar>42</bar>
                </foo>
             </config>
            
        Is the topmode node "foo" or "bar"?  Or does it depend on the
        contents of the db?  If bar already has the value "42", is
        this tree reported at all, i.e. does the tree represent the
        net effect?

3)  notification sys-capability-change

    What is a modified capability?

    If a server upgrades capability
    "http//example.com?revision=2010-04-01" to
    "http//example.com?revision=2010-10-01", how is this reported?  I
    would assume that it is:

      <deleted-capability>
        http//example.com?revision=2010-04-01
      </deleted-capability>
      <added-capability>
        http//example.com?revision=2010-10-01
      </added-capability>

4)  If capabilites can be modified by "system", why can't the config
    be changed by "system"?  I.e. shoud sys-config-change also have a
    container 'changed-by'?

5)  notification sys-session-end

    a)  enum kill-session says:

            "The session was terminated with
            the <kill-session> operation.";

        What if the session was explicitly terminated using some other
        management interface, e.g. the CLI, would the reason still be
        "kill-session"?

    b)  What does "bad-start" really mean?  Does it mean
        "internal-error"?

6)  notification sys-confirmed-commit

    a)  I think the "cancel" confirm-event should also cover the
       <cancel-commit> operation.

    b)  The confirm-event "timeout" has:

            The common session parameters will not be present
            in this sub-mode
  
        If this is the case, then "leaf session-id" cannot be
        mandatory.

    c)  If it is important to report that a timeout has been extended,
        shouldn't also the timeout value be reported?

7)  (minor) The names / descriptions of "user name", "session-id" and
    "remote-host" should imo be made consistent with the names /
    descriptions in the monitoring draft.

8)  In 2.1.1:

    s/sys-conformed-commit/sys-confirmed-commit

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Sep 2010 16:03:54 -0700

>     makes sense at all.  I suggest this notification is removed.

It's up to the WG.
It is for debugging.
The same info could go into the server log files.
Is there something implementation-specific about the actual fields?
I don't think so.  The way a server vendor fills them in, or uses them at all,
is another matter.

  - the <eventTime> gives the last server startup time
  - startup-source concept is generic, although the contents would be any string,
    but this is optional-to-implement if it does not apply to the server
  - boot-error is certainly generic, but how a server treats errors in the
    NV (startup) config as it is loaded into the startup config is very
    server specific.  This is also optional-to-implement if it does not apply
    to the server.

IMO it is useful to know at least the evetTime and startup-source in every case.

>         management interfaces?  IMO, this notif should be generated in

Only generated when the <running> config actually changes, however that is done.

>         this tree reported at all, i.e. does the tree represent the

Depends on the existing config.
If there is an actual change to /foo/bar and /foo exists already,
then /foo/bar is returned, otherwise /foo is returned.

>         http//example.com?revision=2010-10-01

I see your point.
If I change  netconf-url?scheme=file to netconf-url?scheme=file,ftp
did I change netconf-url or did I delete the old one and create the new one?

IMO, it is possible to define <modified-capability> in a standard way.
If any parameters change for a base URI that was advertised,
then use <modified-capability>, and the client will know to redo the parameters
on that capability.

>     be changed by "system"?  I.e. shoud sys-config-change also have a

yes

>         management interface, e.g. the CLI, would the reason still be

what did we decide for monitoring? kill-session w/ session-id=0?
I think <kill-session> by CLI may be 'other', unless we word it right.

>     b)  What does "bad-start" really mean?  Does it mean

I guess this is a bad name.
In yuma, this means:
   - wrong state (already got a <hello> or shutting down)
   - resource errors
   - connect from subsystem to netconfd had bad parameters

Should this be removed (use 'other' instead) or clarified and kept?

>        <cancel-commit> operation.

OK

>         If this is the case, then "leaf session-id" cannot be

OK

>         shouldn't also the timeout value be reported?

OK

>     descriptions in the monitoring draft.

OK

>     s/sys-conformed-commit/sys-confirmed-commit

OK

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Sep 2010 10:19:05 +0200 (CEST)

> Is there something implementation-specific about the actual fields?

It is not obvious that the filename of the startup config db makes any
sense at all for the operator.

The boot-error list assumes that the implementation parses the startup
config file in a way such that rpc-errors can be generated.

> I don't think so.  The way a server vendor fills them in, or uses them at all,

Right, so this makes sys-startup different as compared to the other
notifs in this module, where the fields are not dependent on the
server implementation.

>   - the <eventTime> gives the last server startup time

Ok, I agree that this makes sense.

> Only generated when the <running> config actually changes, however

Good!  I suggest this is stated explicitly.

> then /foo/bar is returned, otherwise /foo is returned.

Ok, this needs to be clarified.

It might be difficult to clarify this in general, but it should be
possible to clarify for YANG data models.  For example, a P-container
can be listed as 'target' with 'operation' "create" or "delete", but
never "merge" (presumably).

Should "operation" really be of type nc:edit-operation-type?  Is it
important to make a distinction between "delete" and "remove"?

> then use <modified-capability>, and the client will know to redo the parameters

Ok, that should work.

> I think <kill-session> by CLI may be 'other', unless we word it right.

So the question is what we want.  I think it makes sense to let
'kill-session' mean "killed by an explicit operator action, such as
NETCONF <kill-session> or some CLI command."

> Should this be removed (use 'other' instead) or clarified and kept?

Maybe remove this, and list some of these in the description of
"other"? 

         enum "other" {
           value 6;
           description
             "The session was terminated for
             some other reason, e.g. resource errors, ..."

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Sep 2010 07:42:53 -0700

>Good!  I suggest this is stated explicitly.

I disagree that the solution shouldn't extend to the "startup" datastore, for devices advertizing support for :distinct-startup, as an NMS MAY want to be aware of changes to the persisted datastore

> >           "Topmost node associated with the configuration change.";

Having the device return the list of affected top-most nodes with an indication as to if it was added, modified, or removed is mighty handy, but we had trouble at Juniper getting device teams to do more than just send the notification that *something* changed.  I believe the issue was related to how the configuration is distributed to various internal daemons that complicated such an implementation.  Realizing that just getting any notification was more important than the details it may contain, we lowered the bar to get more buy-in.  Something to think about...

> > 3)  notification sys-capability-change

I'm unsure how the capability can change without the NetConf session restarting.  At least, with all the devices I'm familiar with, NetConf capabilities can only change via a firmware update, which entails a reboot, and hence loss of connection.  Is this again like "sys-startup" where the log is expected to be found in a file after the fact?

> > 5)  notification sys-session-end

I find the need for sys-session-begin/end to be low, but see how it is at least consistent with the netconf-monitoring capability.  The reason why I'm not too keen on tracking NetConf sessions is because all the devices I work with also support other access protocols (CLI, Web, TL1, SNMP, etc.), so I figure what's the point if it doesn't provide the whole picture?

Regarding sys-confirmed-commit, take a look at the attached PDF describing Juniper's current solution for config-change notifications.  This is the result of a collaborative effort between lead engineers in both the NMS and device teams.  The main differences I see are:

  - one event for both config-change and confirmed-commit
  - support for startup datastore
  - clarifies timestamp relation to config-info
  - clarifies when event needs to be sent (i.e. wrt implicit-changes, rollback-on-error, no-op, etc.)
  - clarifies how interacts with confirmed-commit (init, reset, set, and timeout)
  - clarifies how it works on devices supporting logical-systems

I understand that NetConf doesn't support config-info, implicit-changes, or logical-systems (yet), but we will have models for these someday...

BTW, one thing that I realize now that was left out (because we weren't thinking about it two years ago) is that we need a way to identify *which* startup datastore was changed.  This would be needed for systems supporting dual routing engines, as some customers chose to give each routing engine a distinct startup config, as oppose to sharing one as would be expected for a fail-over scenario

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Sep 2010 15:27:25 -0700

> I disagree that the solution shouldn't extend to the "startup" datastore, for devices advertizing support for :distinct-startup, as an NMS MAY want to be aware of changes to the persisted

OK -- but I don't think a server needs to keep track of all the specific changes when the startup
is updated.  The notification could have an enum leaf to identify the target configuration.

> Having the device return the list of affected top-most nodes with an indication as to if it was added, modified, or removed is mighty handy, but we had trouble at Juniper getting device teams to
> do more than just send the notification that *something* changed.  I believe the issue was related to how the configuration is distributed to various internal daemons that complicated such an
> implementation.  Realizing that just getting any notification was more important than the details it may contain, we lowered the bar to get more buy-in.  Something to think about...
> 
> 

The server SHOULD set this to the specific node, but it can
pick a higher-level node if it wants I guess, or leave this field
out completely.

> I'm unsure how the capability can change without the NetConf session restarting.  At least, with all the devices I'm familiar with, NetConf capabilities can only change via a firmware update,
> which entails a reboot, and hence loss of connection.  Is this again like "sys-startup" where the log is expected to be found in a file after the fact?
> 
> 

It means the parameters for a capability have changed.
If the schemes supported for :url change from 'file' to 'file,ftp', then
why tear down all the NETCONF sessions?  IMO, even if it is changed from
'file,ftp' to 'file', the session should not be destroyed.

The WG did not agree in 4741bis that a server MUST or SHOULD do anything specific
when a generic capability changes.

> I find the need for sys-session-begin/end to be low, but see how it is at least consistent with the netconf-monitoring capability.  The reason why I'm not too keen on tracking NetConf sessions is
> because all the devices I work with also support other access protocols (CLI, Web, TL1, SNMP, etc.), so I figure what's the point if it doesn't provide the whole picture?
> 
> 

I think these are useful and do not want to start boiling the ocean supporting
all kinds of non-NETCONF session start/end events.   I think if you use session ID 0
for every non-NETCONF session, that should be OK, but not inventing new data models
for non-NETCONF session information.

> 
> 
> Regarding sys-confirmed-commit, take a look at the attached PDF describing Juniper's current solution for config-change notifications.  This is the result of a collaborative effort between lead
> engineers in both the NMS and device teams.  The main differences I see are:
> 
> - one event for both config-change and confirmed-commit - support for startup datastore - clarifies timestamp relation to config-info - clarifies when event needs to be sent (i.e. wrt
> implicit-changes, rollback-on-error, no-op, etc.) - clarifies how interacts with confirmed-commit (init, reset, set, and timeout) - clarifies how it works on devices supporting logical-systems
> 

I prefer the current solution.
I do not like combining this event with a config-change event.
There is no need to overload standard notifications with multiple event types.

> I understand that NetConf doesn't support config-info, implicit-changes, or logical-systems (yet), but we will have models for these someday...

This sort of thing can be added in the future, if there is ever a standard solution for these fields.
You can use the YANG augment-stmt and add these fields to your implementation.

> BTW, one thing that I realize now that was left out (because we weren't thinking about it two years ago) is that we need a way to identify *which* startup datastore was changed.  This would be
> needed for systems supporting dual routing engines, as some customers chose to give each routing engine a distinct startup config, as oppose to sharing one as would be expected for a fail-over
> scenario
> 

I think this is a good idea, because the yuma implementation
let's the operator pick the startup config (--startup=mystartup.xml)
or reset to factory default (--no-startup).

IMO, every vendor can think of something to put in the config source,
such as 'NVRAM' or 'external' or 'route-engine-1', 'route-engine-2',
or a filespec if a file is used.

> Thanks, Kent

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Sep 2010 11:19:26 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> > I disagree that the solution shouldn't extend to the "startup" datastore, for
> > devices advertizing support for :distinct-startup, as an NMS MAY want to be
> > aware of changes to the persisted
> > datastore
> > 
> > 
> 

An enum leaf in sys-config-change would be fine.

> > Having the device return the list of affected top-most nodes with an
> > indication as to if it was added, modified, or removed is mighty handy, but
> > we had trouble at Juniper getting device teams to
> > do more than just send the notification that *something* changed.  I believe
> > the issue was related to how the configuration is distributed to various
> > internal daemons that complicated such an
> > implementation.  Realizing that just getting any notification was more
> > important than the details it may contain, we lowered the bar to get more
> > buy-in.  Something to think about...
> > 
> > 
> 

Ok.  Some new text is needed to make this clear.

> > I'm unsure how the capability can change without the NetConf session
> > restarting.  At least, with all the devices I'm familiar with, NetConf
> > capabilities can only change via a firmware update,
> > which entails a reboot, and hence loss of connection.

So these devices would not generate this notification.

> > Is this again like
> > "sys-startup" where the log is expected to be found in a file after the fact?

I hope not; that means that the new firmware must somehow know the
capabilities of the old firmware.

> > I find the need for sys-session-begin/end to be low, but see how it is at
> > least consistent with the netconf-monitoring capability.  The reason why I'm
> > not too keen on tracking NetConf sessions is
> > because all the devices I work with also support other access protocols (CLI,
> > Web, TL1, SNMP, etc.), so I figure what's the point if it doesn't provide the
> > whole picture?
> > 
> > 
> 

Just like with monitoring, I think it makes sense to report also
non-NETCONF sessions (CLI, WebUI, ...) in sys-session-start / -end IF
the server has an integrated session handling mechanism.

> > Regarding sys-confirmed-commit, take a look at the attached PDF describing
> > Juniper's current solution for config-change notifications.  This is the
> > result of a collaborative effort between lead
> > - one event for both config-change and confirmed-commit - support for startup
> > - datastore - clarifies timestamp relation to config-info - clarifies when
> > - event needs to be sent (i.e. wrt
> > implicit-changes, rollback-on-error, no-op, etc.) - clarifies how interacts
> > with confirmed-commit (init, reset, set, and timeout) - clarifies how it
> > works on devices supporting logical-systems
> > 
> 

I also prefer the current two separate notifications.

> > BTW, one thing that I realize now that was left out (because we weren't
> > thinking about it two years ago) is that we need a way to identify *which*
> > startup datastore was changed.  This would be
> > needed for systems supporting dual routing engines, as some customers chose
> > to give each routing engine a distinct startup config, as oppose to sharing
> > one as would be expected for a fail-over
> > scenario
> > 
> 
> 
> I think this is a good idea

So do you want to add a 'startup-source' leaf to sys-config-change?

> because the yuma implementation

NETCONF itself does not support more than one startup.  If the device
has a mechanism to boot from different startup files, it is not
visisble in standard NETCONF.  There is no way using standard NETCONF
to copy-config to startup-2.

If your device supports this, you can augment the sys-startup
notification with this information.  I don't want to send some dummy
value; it would just be noise to the operator.

/martin