Subject: [netmod] proposal : <get-operational-data>

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Sep 2009 14:24:33 -0400

There are huge issues with the overlap between config data and
operational data.  Trying to model these both in a single YANG
module will be difficult and will introduce some annoying bits of
hackery (like "mtu-configured" .vs. "mtu-right-now").

Instead, I propose a new operation for YANG-based models.  The
<get-operational-data> RPC will return operational data associated
with a YANG module.  The module name is a mandatory argument to the
RPC, with an optional "revision" argument.  In addition, a filter
argument will take a stock NETCONF filter hierarchy.

In response, the server will return a set of XML elements that
follow many of the constraints of the YANG module, but are
freed from a few, in order to allow useful data to be returned.

A union's "type" statement and the "enum" statement will accept a
"config" statement indicating if this branch of the union will be
accepted for configuration data or only for operational data.

    module foo {
        ...
        container foo-top {
            list interface {
                key name;
                leaf name { type string; }
                leaf mtu {
                    type int;
                    default 1024;
                }
                leaf duplex {
                    type enumeration {
                        enum full;
                        enum half;
                        enum auto { config true; }
                        default auto;
                    }
                }
            }
        }
    }

Alternative: "config" here could be replaced with "operational" and
the value inverted.

   <rpc>
      <get-operational-data>
         <module>foo</module>
      </get-operational-data>
   </rpc>

   <rpc-reply>
      <data>
         <foo-top>
            <interface>
               <name>so-0/0/0</name>
               <mtu>1500</mtu>
               <duplex>full</duplex>
            </interface>
         </foo-top>
      </data>
   </rpc-reply>

Since defaults are ignored for operational data, any values MUST be
returned as part of the normal data hierarchy.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Sep 2009 14:08:44 +0200

> argument will take a stock NETCONF filter hierarchy.

A constructive proposal - thanks! I am not sure why you want to pass
the module name; we do not scope get-config by module name either and
you can use a filter on the module's namespace. Seems duplicated and
also limiting - why can I not retrieve operational state from two
related modules in one call?
 
> Alternative: "config" here could be replaced with "operational" and

Is list interface config true or false here? We have to be careful
about the usage of keywords since enum auto { config true; } likely is
very different from leaf duplex { config true; ... } - I assume this
needs more thought to get right.

/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/>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 2 Sep 2009 14:46:44 -0400

>related modules in one call?

My goal was to avoid the "return all data available on the device"
that we have with <get> to limit it to start at the top of a
particular model.  Namespace could be used also.  I guess we have
this with <filter> on <get> now, but adding a specific operation
for this type of data would be worthwhile imho.

>Is list interface config true or false here?

config defaults to true, so it remains there from container foo.
Apologies for the mistakes in my example.  Let me try again:

     module foo {
         ...
         container foo-top {
             list interface {
                 key name;
                 leaf name { type string; }
                 leaf mtu {
                     type int;
                     default 1024;
                 }
                 leaf duplex {
                     type enumeration {
                         enum full;
                         enum half;
                         enum auto { operational false; }
                         enum down { config false; }
                         default auto;
                     }
                 }
             }
         }
     }

Two changes are required to YANG:

(a) The new "operational" statement indicates whether the leaf, container,
list, enum, or union or choice member is returned in operational
data.  It defaults to "true", similar to "config", and is inherited
by child nodes in the schema tree.  So if a choice member is
"operational false", then all children of that choice are not
returned as operational data.

When you retrieve configuration data, "name" MUST appear, and "mtu"
and "duplex" MAY appear.  "duplex" MUST NOT have the value "down".

When you retrieve operational data, "name" MUST appear, and "mtu"
and "duplex" MAY appear.  "duplex" MUST NOT have the value "auto".

(b) The "config" statement can appear in a number of new locations
including enums and unions.

There are also impacts on other constraints, but I've not
thought thru them (if a "must" for a knob requires duplex
be "auto", then that constraint can't be enforced for operational
data.

>I assume this

Amen to that!!  I'm just scratching the surface to see if (a) YANG
can handle this as is (I don't think so) and (b) if we really want
to wander off into this area for a while (not sure).

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Sep 2009 15:15:31 -0400

If I am reading this correctly, you are saying that if we define this 
operation then the same leaf (path, including leaf) will designate the 
configuration variable in one get and the operational variable with a 
different rpc?
While that solves the problem of how to couple the two sets of 
information, it seems to be a dangerous and misleading approach.

In a given protocol, a single name ought to clearly name a single piece 
of information.  It seems to me it should not name the configured value 
in a <get-config> and a potentially different operational value in a 
<get-operational>

(Fortunately, while this is related to the previous discussion, it seems 
to be separable.  This seems to be an effort to answer the question 
"where to ODVs appear."  As long as we agree that the answer has to be 
somewhere, rather than nowhere, we are still making progress.)

Yours,
Joel

Phil Shafer wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Sep 2009 22:05:26 +0200 (CEST)

> to wander off into this area for a while (not sure).

I do not want us to do this now.  As Dan pointed out, it extends the
scope of NETCONF, and as you pointed out we need to carefully think
about how all this will work.

I prefer to finish what we're doing now, and then look at this.  I
also believe that since both NETCONF and YANG are extensible, we can
add things w/o breaking what we have (if nothing else this would be a
good exercise for our extensibility mechansims :)

/martin

---

From: David Partain <[email-masked]>
Date: Thu, 3 Sep 2009 14:19:53 +0200

> good exercise for our extensibility mechansims :)

(contributor hat on)

I agree with Martin.  I want to ship things and then start thinking about 
extensions.   We seem to have enough to wrestle with at the moment...

Cheers,

David

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Sep 2009 14:48:47 +0200

> good exercise for our extensibility mechansims :)

I believe we make a mistake if we can't clearly point out how
NETCONF/YANG deals with the distinction of configuration and
operational state data. There are people working on YANG data models
and the way we solve this issue will likely have some impact on how
they are modeling things.

I do understand the procedural complications since two WGs are
involved (but with the same contributors) and the desire of meeting
deadlines and moving forward in small steps. But getting the
distinction between config and operational state right is for me very
fundamental so that I prefer to delay YANG for say three months and I
would be OK with making 4741bis actually NETCONF 1.1 (reducing some
optional capabilities, providing retrieval support for operational
state data). And we might not need the with-defaults document anymore.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 03 Sep 2009 14:55:24 +0200

> state data). And we might not need the with-defaults document anymore.

+1

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Sep 2009 09:24:25 -0400

To phrase this differently, I think the question of where and how ODVs 
are made visible to the Netmod / Netconf client (the managing 
application) is important.  They need to be visible somehow.
As I have said, I do not particularly like this approach of overloading 
the leaf names to provide two different values for the same leaf in 
different operations.

This does leave me (us) with the problem that I do not have a good 
answer to where the information should appear.

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Sep 2009 16:01:23 +0200

On Thu, Sep 03, 2009 at 03:24:25PM +0200, Joel M. Halpern wrote:

> To phrase this differently, I think the question of where and how
> ODVs are made visible to the Netmod / Netconf client (the managing
> application) is important.  They need to be visible somehow.  As I
> have said, I do not particularly like this approach of overloading

It is a matter how things are scoped, right? In SNMP land, we scope
OIDs to a context (contextEngineID, contextName). We are living in XML
land now and have other tools at our disposal - but somehow there
should be a solution possible that addresses your concerns. But even
today, you can do get-config() on running and candidate and what you
retrieve is already scoped to a 'datastore'...

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Sep 2009 10:19:13 -0400

Maybe it is just a deficiency of my mental model.
I have no problem with the idea that if I ask for the value of foo in 
store-a, that I get a different value than if I ask in store-b.
I can see the parallel you are drawing with asking for foo with two 
different operations.
But, at least for me, there are large differences.
The conceptual semantics of the foo in store-a and store-b are the same. 
  They are both the configured value for foo, when that store of 
configuration is in effect.  In contrast, with the get-operational 
approach, we are naming two conceptually different things (as evinced by 
the fact that their validity range is not even the same) with the same name.

I guess I am particularly sensitive to this kind of overloading, because 
it has caused problems in other contexts.  (There is a strong argument 
that one of the strong contributors to the scaling problems in routing 
names is that the same name is used  both for the identity and for its 
location in the topology.)

Yours,
Joel

---

From: WashamFan <[email-masked]>
Date: Fri, 04 Sep 2009 09:38:47 +0800

Hi,

>  store-a, that I get a different value than if I ask in store-b.

Does <get-operational-data> work in this way? Or if you apply 
<get-operational-data> to the datastore, the datastore reply you
the operational data, if you apply <get-config> to the same datastore,
same node, it will reply you the config value. Is there two datastores,
or one datastore allowing two retrieval ways?

washam

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 04 Sep 2009 13:09:22 +0200 (CEST)

"Joel M. Halpern" <[email-masked]> wrote:
> I have no problem with the idea that if I ask for the value of foo in store-a,
> that I get a different value than if I ask in store-b.
> I can see the parallel you are drawing with asking for foo with two different
> operations.
> The conceptual semantics of the foo in store-a and store-b are the same. They
> are both the configured value for foo, when that store of configuration is in
> effect.  In contrast, with the get-operational approach, we are naming two
> conceptually different things (as evinced by the fact that their validity range
> is not even the same) with the same name.
> 
> I guess I am particularly sensitive to this kind of overloading, because it has
> caused problems in other contexts.  (There is a strong argument that one of the
> strong contributors to the scaling problems in routing names is that the same
> name is used both for the identity and for its location in the topology.)

Are you saying that it might actually be a feature, not a bug, to have
two objects, duplex and duplex-oper?

In this particular example, the connection between the configured
value and operational impact is pretty simple, but another example is
if your configure dhcp, and it operationally affect the ip-address,
mask, etc.  How do you specify this in the data model?

I am worried that adding this explicit support (in the protocol and
modeling langauge) is a pretty big project, and it is better to finish
something so people can start to use it.  In the worst case, YANG gets
very popular and lots of modules gets published, and some have
foo-oper like constructs, and these modules may then have to be
updated if we add new support for operational data.  I am more
concerned that we never finish b/c we want to publish a perfect
solution for all kinds of problems at day 1.

/martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 04 Sep 2009 10:14:55 -0400

I do understand the need to finish this document and get it out there.

Yes, I consider that having variable s foo and foo-oper, where foo is 
config true and foo-oper is config-false, is a feature, not a bug.  If 
the system is going to retain and reuse (for example, the next time it 
boots) a configuration value, but has internally decided to use 
something different, then those facts need to be represented separately.

As far as I can tell, adding this requires zero additions to the 
modeling language.  As I have said repeatedly, I am willing to go out 
with the relationship between foo and foo-oper captured in the 
description clause.  What we need is enough text in the YANG document 
that folks understand how to find the ODV.

Note that at least if you compare Phil's and my position, I think we 
actually agree on the need for this separation.  The question we are 
debating is where to put ODVs.

Yours,
Joel

PS: To use your example, clearly DHCP results can not be stored in the 
configured interface IP address variable.  They are not configured 
values, and are not reused.  On the other hand, they do need to be 
accessible operational state.

---

From: Phil Shafer <[email-masked]>
Date: Fri, 4 Sep 2009 10:54:00 -0400

"Joel M. Halpern" writes:
>config true and foo-oper is config-false, is a feature, not a bug.

My concerns here are:

(a) The model may not understand that there data plays distinct
roles in the config and state realms.  If I just see interface
addresses as config data, I'll miss that this data can be acquired
from bootp or dhcp and miss the need for two leafs.

Another example: the mtu for a device is changed in config to 1500,
which the server accepts and commits, but a microkernel memory issue
(handwave, handwave) causes the attempt to set this on the embedded
hardware to fail, leaving the mtu at the previous value.  The device
syslogs this error, but no one is watching.  When the client fetchs
mtu from config, they see the "right" value, but how can I return
the real right-now state value?  Does every leaf need a "state
twin"?  Doesn't every config value have a "what are you doing right
now" state value?  Is the difference between "what I told it to do"
and "what it's doing right now" present on every leaf?

(b) If I make a module that wants to augment a leaf, I now
need to augment twice.

(c) Since there are two distinct leafs, the client may pick the
wrong one, breaking them if, say, the server dhcps the interface
address.

It truth, I'm not sure how big these issues are, and I know we can
ship now with "state twins", but can't help thinking there's got
to be a better way.

Thanks,
 Phil

---

From: "tom.petch" <[email-masked]>
Date: Fri, 4 Sep 2009 18:45:49 +0200

---- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 04, 2009 1:09 PM
Subject: Re: [netmod] proposal : <get-operational-data>

> > I have no problem with the idea that if I ask for the value of foo in
store-a,
> > I can see the parallel you are drawing with asking for foo with two
different
> > The conceptual semantics of the foo in store-a and store-b are the same.
They
> two objects, duplex and duplex-oper?

Absolutely; plenty of examples of something like this in our current MIB
modules.  I thought having operStatus and adminStatus rather weird when
I first encountered it but now accept that that is just the way to model
these things that have an administered value and a value dynamically
determined by the running system.

I can see no requirements for anything new in YANG to support this.

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Fri, 4 Sep 2009 14:06:19 -0400

>determined by the running system.

I still think SNMP's operStatus and adminStatus is weird, and
continue to hope that we can do something better.  If nearly
everything has an operational value and a configured value, why do
we use something as awkward as paired twin leafs?  Isn't configured
mtu and observed mtu sufficiently similar that we can so something
more helpful that to tell modelers to define two leafs that are
intimately related with no way to express that relationship?

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 04 Sep 2009 14:39:37 -0400

For me, the reason to separate them is that some of the time it is more 
than two values.
To use the DHCP example, one can ask "What is the configured IP address 
of the Interface?"  One could ask "Does it use DHCP, and if the answer 
is yes, what address did DHCP provide?"  And one could ask "What is it 
actually using, which is the result of a device computation based on 
those two inputs (plus others, for example with v6.)

Yours,
Joel

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 4 Sep 2009 11:18:49 -0700

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Joel M. Halpern" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, September 04, 2009 7:54 AM

> ship now with "state twins", but can't help thinking there's got

If the configuration persists in any way, so that, for example, after a
reboot the "microkernel with a memory issue" reverts to the configured
mtu of 1500, then the configuration and operational values truly are distinct
pieces of information.  This will happen whenever the former is not
the sole factor determining the value of the latter.  This shouldn't come
as a surprise to anyone who's had to model real implementations.

The question underneath this that's making people nervous is the extent
to which the model needs to represent this relationship, and whether that
relationship representation needs to be something a machine can grok.
I'd say that mentioning it in human-readable for takes it as far as it needs to go.
Yes, it is possible to describe the relationships using things like Z, but for
the description to be anywhere near complete quickly gets so deep into
implementation ideosyncracies as to be counter-productive.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 04 Sep 2009 21:26:14 +0200

> intimately related with no way to express that relationship?

Operational values may be derived from config data, hardware parameters,
network protocols etc. in many different ways. A data modeling langauge
probably can't cover all such possibilities, but the dependencies among
config and operational parameters (and the outside world) could perhaps
be specified in the data model in a form of a signature. For example, it
could state that "ip-address-oper" is a function of config parameters
"dhcp" (boolean flag) and "ip-address", and also depends on the
operation of the DHCP protocol.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 04 Sep 2009 23:34:57 +0200 (CEST)

Phil Shafer <[email-masked]> wrote:
> If nearly
> we use something as awkward as paired twin leafs?

I agree that if nearly every config leaf needs a twin -oper leaf, this
would not be a good solution.  But is that really the case?

> Isn't configured

In this simple case it might be tempting to reuse one leaf like this.
But I am not sure it works well in the dhcp/bootp/ip-address case, or
in the static vs. dynamically learned routes case.

/martin

---

From: "tom.petch" <[email-masked]>
Date: Mon, 7 Sep 2009 16:03:47 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
Sent: Friday, September 04, 2009 8:06 PM

Phil

There are plenty of examples but a minority of data objects in general.

The reason I find it weird is because adminStatus is not really a data
object at all, but a (de-)activate command - except that we do not
have commands but have data objects that have a defined side
effect - when set to this value, treat as a command to .......

It is also weird because it persists, that is, if the interface fails to come
active, then the system keeps trying and one day it may come active
when the action that initiated it is long forgotten.

So while it may be weird to model it as an object, it has a quite different
life cycle to operStatus or other operational states and should 
be a separate object.

I would apply this to any other activate/enable type function, where there
is a good chance of a disconnect between what is wanted and what happens;
start a session with a BGP peer, activate ospf on an interface

I see no similarity with ifMtu; if I set this to 1492, I expect the system to
use that and nothing else, whatever type of pic card may be plugged in.
Ditto most aspects of configuration.  If what I ask is impossible, I should 
get an error returned or, exceptionally, if it is one of those nasties that
cannot be detected immediately, an alert later.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 7 Sep 2009 17:52:46 +0200

From: "Martin Bjorklund" <[email-masked]>
Sent: Friday, September 04, 2009 11:34 PM

> in the static vs. dynamically learned routes case.

Martin

I think that static v dynamic applies to bridge forwarding, IP forwarding 
and a few others (not BGP RIB, OSPF LS database) and that there is value
in separating static from dynamic.  SNMP has a single bridge table with a 
forgotten column hidden away in which a certain value means statically
configured.  I have had to point this out to loads of people whereas I have
only ever met one person who knew about it - he showed it to me!

So were I in IEEE 802.1D, I would model the bridge table as two; 
static (small, usually empty) and dynamic (large, volatile), separating 
config and state as RFC3535 asks.  Of course the device is expected
to integrate them, so it might show the static entries as part of the dynamic
but either way, I think that that better meets the needs of the user. 

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Sep 2009 14:25:49 -0400

>those two inputs (plus others, for example with v6.)

Sure, so the interface object would provide a "at this momemt"
address leaf, and the dhcp module would augment with a "what did
dhcp tell me" leaf (which might be present but ignored in some odd
circumstances).  But the real "at this moment" address should be
maintained with a real value whether it came from dhcp or elsewhere,
so an app can say "interface[name == $name]/address" (forgive the
trivial model) to get the current address.

But the question remains: is this a leaf "at this moment" leaf or
is if the normal "address" leaf viewed in a "at this moment" scope?
Is it easier to make two leafs and odd rules about how they are
tied together or to make one leaf with odd rules about how the
value constraints change in different scopes (configuration .vs.
"right.now")?

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Sep 2009 14:49:19 -0400

From where I sit, I think it is simpler to make two leaves, with a 
relationship between them, than to try to define two views of the system 
with different elements under the same name in them.
Both approaches are clearly defensible.

What would be really unfortunate would be not to pick either one, and 
have no documented way for folks to handle this.

Yours,
Joel

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Sep 2009 14:46:35 -0400

>would not be a good solution.  But is that really the case?

Given that any attempt to implement a configuration change can fail
for obscure reasons deep in the bowels of the device, having a
"what's the current value" leaf so every "what should it be" leaf
seems like a good thing if there's no expense.  If I get an address
from dhcp that my kernel dislikes, seeing the dhcp-provided value
and the real current one is good.

But if these are twin leafs, the price for duplicating large parts
of the model would make it a bad thing.

Thanks,
 Phil

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Sep 2009 15:19:40 -0400

I think my problem is that they are not twins.
Using IP address, as related to an interface, there is
the configured value(s) leaf
the DHCP configuration leafs
The SLAAC enable / disable leaf
ANd there is the leaf-list with the list of actual values currently 
believed by the system to be validly assigned to the interface.

That last is not specifically a twin of the configuration leaf.  We can 
pretend it is, but doing so is misleading.  It is the result of mixing 
all the mechanisms for that interface.  (Fortunately, we have gotten to 
the point that tunnel behaviors generally look like different interfaces 
or this would be a complete nightmare.)

Yours,
Joel

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Sep 2009 15:09:04 -0400

>cannot be detected immediately, an alert later.

If you hit a nasty and get an alert, what value should be in <mtu>?  The
one you configured or the current one?  They are two distinct values.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Sep 2009 16:44:16 -0400

>or this would be a complete nightmare.)

This is fall out from a simplistic config model.  In fact, you
may want to configure multiple addresses on a particular interface.
In JUNOS we have four levels in our interface definition:

   physical (interface so-0/2/3, interface fe-0/2/1)
      logical (unit 0, unit 4)
          address family (ipv4, ipv6, mpls)
              address (10.1.2.3/24, 10.3.2.1/28)

and each level has a set of leafs which can be configured at the level.

So the list of address which the system believes are valid for that
interface is more than a leaf-list, since it may configuration below it
(primary == use this address for the entire box, preferred == use this
address for this interface, or destination address, etc).  Example
config appended below.

But I certainly see you point that you can't have a twin leaf for
a list or leaf-list, so a simple mechanism for tying them together
may not be possible.

On the other hand, a "scope" approach where the "operational-data"
scope returns the "currently in use" values would make more sense
here, since the list from config data and the list from operational
data can be compared and analyzed as needed.  If a DHCP address
appears in the operational data that isn't in the config data, this
should be obvious.  And having scope-based augmentation should be
possible, so config for static routes can have different leafs than
the operational routing table while preserving the common schema
nodes between the two scopes.

Thanks,
 Phil

-----------

    <configuration>
            <interfaces>
                <interface>
                    <name>fe-0/2/1</name>
                    <mtu>1000</mtu>
                    <unit>
                        <name>0</name>
                        <family>
                            <inet>
                                <address>
                                    <name>10.111.222.3/24</name>
                                </address>
                            </inet>
                            <mpls>
                            </mpls>
                        </family>
                    </unit>
                </interface>
                <interface>
                    <name>so-0/2/3</name>
                    <sonet-options>
                        <z0-increment/>
                        <bytes>
                            <f1>42</f1>
                        </bytes>
                    </sonet-options>
                    <unit>
                        <name>0</name>
                        <no-traps/>
                        <no-keepalives/>
                        <family>
                            <inet>
                                <address>
                                    <name>10.3.2.1/28</name>
                                </address>
                                <address>
                                    <name>10.1.2.3/24</name>
                                    <primary/>
                                    <preferred/>
                                </address>
                            </inet>
                        </family>
                    </unit>
                    <unit>
                        <name>4</name>
                        <family>
                            <inet>
                                <address>
                                    <name>10.11.22.33/28</name>
                                </address>
                            </inet>
                        </family>
                    </unit>
                </interface>
            </interfaces>
    </configuration>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Sep 2009 17:17:57 -0400

But my argument is that there is no single config construct (leaf, 
leaf-list, list, ...) whcih should be setable / readable for the config 
values, but which with a <get-operational-values> invocation should 
return the actual values being used.
(The 4 levels of config just clarifies that the operational value may be 
computed from several different config and operational elements.)

Yours,
Joel

---

From: "tom.petch" <[email-masked]>
Date: Tue, 15 Sep 2009 12:46:02 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
Sent: Monday, September 14, 2009 9:09 PM

> one you configured or the current one?  They are two distinct values.

If I have explicitly configured ifMtu, and this is not something that a
protocol negotiates dynamically, then there is only one value, the one
I configured.

Some protocols have an initial value for a parameter which I can
specify, which can then be revised by negotiation.  I do not think that
this applies to mtu (although I am not familiar with mtu usage in IPv6
tunnel protocols) but if it were to, then there is again only one value,
the one currently in use (not my initial configuration) although I suspect
that this is best modelled with two values.

This is different to say duplex or speed on an IEEE 802.3 interface,
where the specification allows for two values, the one I would like,
and the one that is in current use as a result of negotiation, the first
is configuration, the second operation.

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Tue, 15 Sep 2009 08:55:09 -0400

>protocol negotiates dynamically, then there is only one value, the one

If you set the MTU, then the value in the configuration database
should be the value that you set.  Thers is only one value, the
one you configured.

But if the device fails during the act of setting that MTU for
a particular interface, there are two values, the one you asked
for and the one that is currently in use.  The configured value
may be 1500, but if an interface was hot-plugged that does not
accept this value, I would not want the device to report 1500
as the operational value.

Thanks,
 Phil