Subject: [Netconf] more operational state (was Re: Developing Call-Home for the SSH and TLS transport bindings - New Charter text)

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Apr 2013 08:29:03 -0700

On Sat, Apr 13, 2013 at 3:00 PM, Martin Bjorklund <[email-masked]> wrote:
> Andy Bierman <[email-masked]> wrote:
>> On Sat, Apr 13, 2013 at 1:39 PM, Martin Bjorklund <[email-masked]> wrote:
>> > Juergen Schoenwaelder <[email-masked]> wrote:
>> >> On Sat, Apr 13, 2013 at 08:35:14AM -0700, Andy Bierman wrote:
>> >> >
>> >> > I must be thinking of draft-bjorklund-netmod-operational-00,
>> >> > which expired 5 days ago.
>> >> >
>> >>
>> >> An individual submission under a name picked by an individual. The
>> >> discussion of this I-D took place in the NETCONF WG meeting at the
>> >> last IETF:
>> >>
>> >> http://tools.ietf.org/wg/netconf/agenda?item=agenda-86-netconf.html
>> >>
>> >> While it may make sense to merge NETCONF/NETMOD, I disagree with "many
>> >> NETMOD drafts specify YANG extensions that change NETCONF protocol
>> >> behavior".
>> >
>> > And, for the record, this draft does not change the behavior of
>> > existing NETCONF protocol behavior.  It adds new optional operations
>> > to NETCONF.
>> >
>> >
>>
>> IMO <edit-operational> breaks the base:1.1 contract because
>> a base:1.1 client does not know about <edit-operational>.
>> It will think that only special leafs (like duplex=auto)
>> are allowed to have a different operational value than
>> the configured value.
>>
>> A "new client" using <edit-operational> can break a
>> compliant base:1.1 client using the same server.
>
> No.  An old client will never do <get-operational>, so it will do
> <get> or <get-config>.   This document does not change the behavior of
> these operations.  If an old client performs <get> on a node that is
> config true, it will receive the running config's value, as defined in
> RFC 6241.
>

An old client will only know about base:1.1 and the YANG modules
the server supports. Unless the semantics of a YANG data node
indicate the operational value is allowed to be different than the
configured value, the client is not expecting this to happen,

IMO, the key to your solution is a missing YANG extension
to tag a YANG data node with these semantics:

   extension with-operational {
      description
        "This extension identifies whether the operational value
          associated with a configuration data node is allowed to
          be different than the configured value for the specified
          data definition.

          If this extension is present directly within a data-def
          statement for a configuration data node, then any
          data node instance for that node is allowed to
          have an operational value which are different from the
          configured value.";
   }

     leaf duplex {
       oper:with-operational;
       type enumeration {
         enum "half";
         enum "full";
         enum "auto";
       }
       config true;
     }

IMO, this allows old clients to be compatible with new
servers and new clients, since <edit-operational>
is only allowed to alter nodes that support a different
operational value.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 14 Apr 2013 17:59:33 +0200 (CEST)

> configured value, the client is not expecting this to happen,

A client cannot make this assumption with or without this draft.

Again, take the duplex leaf as an example.  If the configured value is
'auto', the operationally used value is certainly something else.
Another example is pre-provisioning of some hardware.  If the hardware
is not there, the pre-configured values are not operationally used.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 14 Apr 2013 09:08:13 -0700

> is not there, the pre-configured values are not operationally used.

If the YANG object defines enum "auto" correctly then the
client does know the operational value can be different.
If the semantics of the object contain this property, then
a developer of a client application must know about it,
because they read the YANG module.

The point of this tag is not to say all instances of
the data node have different operational values.
Just that instances are allowed to have different
operational values.  Obviously <get-operational>
would be used to know for sure which instances
are indeed different.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Apr 2013 14:04:49 +0200

> is not there, the pre-configured values are not operationally used.

I am leaning towards duplicating the config and operational value as two separate objects, because the latter is in fact a first-class entity and it can interact with the config value (and other management interfaces, protocols etc.) in various ways and quite often their datatype would also be different. This duplex parameter is one example, and the problem of zone indices in IP addresses could also be resolved quite nicely: the zone id would be allowed with operational address but not in manual address configuration.

I think the amount of duplication would not be that large, and in fact it already happens in the routing module: static routes appear in configuration but they are also duplicated in routing table(s), with additional info and attributes.

An important advantage of having separate config and operational objects is that it can be essentially done without any changes to YANG and any new NETCONF operations. The relationship between the two could be expressed simply in descriptions.

Lada 
 
>
>
> /martin
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C