Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Juergen Schoenwaelder]

Anees,

does it really make sense to have to track multiple different objects
in order to find out which IP address(es) are used by an interface?
Perhaps I am old school but I do like the existing design better - one
place to find the operationally used state. I rather have additional
_metadata_ about where the values are originating from instead of a
static marker in a data model that requires to report state in
multiple places that than needs to be integrated again to answer
simple questions like which IP addresses are used by an interface.

Knowing the origin of operational state data is highly useful. Trying
to encode that in the design and structure of the data model, however,
seems complex, costly, and inefficient.

/js

On Wed, Jun 24, 2015 at 06:22:28PM -0700, Anees Shaikh wrote:
> So the model probably would have this as a choice, right?  In one case I
> set the mode as STATIC and specify the address (intended and actual config
> leaves, marked config: true, and config: false, respectively), and in the
> other case I set the interface to DHCP (again intended and actual config),
> and the received IP address would be set in an operational state variable
> (e.g., dhcp-assigned-address).  This last leaf would be marked as
> operational:true in our proposal.
> 
> thanks.
> -- Anees
> 
> On Wed, Jun 24, 2015 at 4:19 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Wed, Jun 24, 2015 at 06:39:44PM +0100, Rob Shakir wrote:
> >
> > > A portion of the operational state date (marked operational: true)
> > > is the set of variables that are not related to state that an
> > > external system can assert the value of — for example, a counter, or
> > > a negotiated protocol timer.
> >
> > Not sure I parse this correctly but it sounds a bit like you make
> > something a static data model property that in reality is a dynamic
> > property of state. Lets take as an example the IP address of an
> > interface.  It can be statically configured or it can bee optained
> > dynamically via DHCP. So would you mark this operational true (or
> > operational sometimes) in the data model?
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Andy Bierman]

On Wed, Jun 24, 2015 at 7:57 PM, Anees Shaikh  wrote:

> Hi Kent,
>
>
> 
>
>>
>>
>>
>> > If I can make some slight tweaks to the diagrams that have
>> > been distributed:
>>
>> This looks like a variant of the picture I posted here:
>> http://www.ietf.org/mail-archive/web/netmod/current/msg12738.html.   On
>> one hand I'm happy to see this because no one had acknowledged the pic
>> previously, but on the other hand, I'm concerned that you felt the need to
>> draw another picture, implying there still being a gap...
>>
>> Actually, when looking at your picture, substituting running for intended,
>> I think your picture is essentially the same as represented here:
>> http://www.ietf.org/mail-archive/web/netmod/current/msg12729.html.  Of
>> course, without ephemeral, running==intended, so your picture isn't wrong
>> either.  I think the only difference is that your picture shows slides 2-4
>> together, whereas mine had distinct slides.  Is there a more significant
>> difference in your mind?
>>
>
> we actually took your followup picture as the basis for the one we drew,
> i.e., the one with slides 3 and 4 combined (
> http://www.ietf.org/mail-archive/web/netmod/current/msg12738.html).
> You'll see the main difference is that the applied config (what you call
> actual) is part of the state (i.e., config: false
> data).
>
>
>
>> > * Intended and applied/actualised state are views of
>> > the running configuration.
>>
>> Yes, but more precisely, running==intended when there is no ephemeral
>> config, right?
>>
>
> I guess that's right, but as Rob said, we have not really considered a
> separate type of config called ephemeral.  I personally view what we are
> calling ephemeral as just control coming through a config channel (e.g.,
> the i2rs case)
>
>

The NETCONF WG has been asked by the I2RS WG to work on ephemeral
data (or configuration or whatever), so it is also high priority.

I2RS is not really "just control coming through a config channel".
It allows a controller to override device config and state in a standard way
based on machine-readable data models.  Instead of hand-coding
control protocols completely from scratch, after writing long complicated
RFCs,
just write a YANG module, turn the crank, and integrate. (That's the plan,
anyway ;-)



Andy



>
>>
>>
>> > * All intention is written to the intended configuration
>> > (whether it be by CLI, a human, an NMS via NETCONF, a
>> > system agent, etc.) ­ which then transitions to becoming
>> > the applied/actualised configuration. This is based on
>> > either an explicit request to do so (Œcommit¹) or may be
>> > implicit. The success of the intended configuration
>> > becoming the applied configuration may be due to time
>> > deltas or condition, as Kent drew.
>>
>> Yes but, again, the clients are interacting with the "running" and/or
>> "ephemeral" (not directly to "intended").  The important bit is that
>> "ephemeral" can override "running", so the "intended" is actually the
>> result of a merge operation of sorts...
>>
>
> here by intended config, we mean what the intended change to the running
> config is.
>
>
>>
>> > * In what we referred to as a Œsynchronous¹ system ­ we
>> > expect the attempt to make the intended state transition
>> > to the actual state to be completed when the operation
>> > returns (e.g., after a ) then the  should
>> > return only when this intention has been applied.
>>
>> I see.  As stated on the call last week, NETCONF/RESTCONF are currently
>> only "asynchronous" by this definition, as neither has any statement
>> regarding *when* intended becomes operational wrt  or 200 OK.
>> Dipping into design for a sec, it might be interesting to add an optional
>> commit flag indicating that the server should not respond until
>> actual==intended...
>>
>
> yes ... this is really down to implementations.  In some platforms, the
> response comes back
> once all involved downstream services have validated and applied the
> requested config -- that would be considered synchronous in the way we have
> been thinking about it.
>
>
>>
>> > * We require the ability for an NMS to be able to see both
>> > the intended and the actual configuration ­ such that it
>> > can check whether its intention is currently the applied
>> > configuration, or has not yet been applied due to some
>> > external dependency (e.g., line card not plugged in).
>>
>> Understood, at least for leafs that get a protocol negotiated value, which
>> may account for just 1% of the configuration.   Dipping again into design,
>> I was hoping we might use [XML/JSON] attributes, for instance:
>>
>>  leaf duplex {
>>type enumeration {
>>  enum "half";
>>  enum "full";
>>  enum "auto";
>>}
>>config true;
>>  }
>>
>>   get-config from running:
>>auto
>>
>>   get-operational:
>>full
>>
>
> In the proposal laid out in the draft, you would be able see any
> differences between intended, actual, and operational 

Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Juergen Schoenwaelder]

On Wed, Jun 24, 2015 at 06:39:44PM +0100, Rob Shakir wrote:

> A portion of the operational state date (marked operational: true)
> is the set of variables that are not related to state that an
> external system can assert the value of — for example, a counter, or
> a negotiated protocol timer.

Not sure I parse this correctly but it sounds a bit like you make
something a static data model property that in reality is a dynamic
property of state. Lets take as an example the IP address of an
interface.  It can be statically configured or it can bee optained
dynamically via DHCP. So would you mark this operational true (or
operational sometimes) in the data model?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Kent Watsen]

>>>Here's the updated table:
>> >
>> >   running  actual configoperational state
>> >   ---  --
>> >  t0halfhalf half
>> >  t1autohalf half
>> >  t2autohalf (*) half
>> >  t3autoauto half
>> >  t4autoauto full
>> 
>> 
>> I don't understand how actual is ever not the same as operational.
>
>If it was always the same it would not be needed.

Not a helpful answer.  Please look at the right side of this picture:
http://www.ietf.org/mail-archive/web/netmod/current/jpgm4Rk4R9iBf.jpg.
Again, it seems that actual is just the part of operational that has
schema defined by the config=true nodes...



>See Rob's picture.  In that picture, the schema for "actual" is the
>same as for "intended".

Right, same as what I've been saying - where's the disconnect?



>Well, I am still trying to understand what (if any) meaning this
>"actual config" has.  But Rob was pretty clear in his last email:
>
>  * We require the ability for an NMS to be able to see both the intended
>and
>the actual configuration
>
>If I understand this correctly, "actual config" is only interesting in
>an asynchronous implementation; in a synchronous implementation actual
>will always be equal to intended.

Yes, I get it, but in my view there are only two columns of interest:

   running/intended  actual/operational
     --
  t0halfhalf
  t1autohalf
  t2autohalf
  t3autofull




Your table allowed "actual" to contain the value "auto", but how is that
possible when we defined actual as being after:

  data-plane groks intended
- e.g., Δ time

  conditional enablement
- e.g., line card plugged in

  protocol negotiated values
- e.g., auto --> full / half


???



Kent





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Y45-04 and ietf-yang-library

[Andy Bierman]

On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund  wrote:

> Hi,
>
> I am preparing a new version of draft-ietf-netmod-rfc6020bis in order
> to address Y45-04.  Note that YANG 1.1 uses the module
> ietf-yang-library from draft-ietf-netconf-yang-library (hence the
> crossposting).
>
> [BTW, shouldn't ietf-yang-library be moved to NETMOD?]
>
> We have a whole bunch of documents that have a normative reference to
> draft-ietf-netmod-rfc6020bis, which has a normative reference to
> draft-ietf-netconf-yang-library.  This means we need to finish this
> document pretty soon.
>
> I ran into some issues with ietf-yang-library:
>
>   1.  The leaf "conformance" is of type "boolean".  It is not obvious
>   what "conformance = false" means.  Should we change the name
>   and/or type of this leaf?
>
>   I don't have a good proposal, but what we need is a way to
>   indicate "I implement the protocol accessible nodes in this
>   module" vs. "I just list this module b/c some other module that
>   I implement uses typdefs/groupings/... from it".
>
>   This issue is related to the github issue #3.  I think we need
>   this information; Y45-04 relies on it.
>
>

We went through this before and you didn't have a better suggestion last
time either.

conformance=false means the server is not claiming conformance for this
module.  A NETCONF  should not have any modules tagged
as conformance=false.

CoMI relies on this module as well.
It has been ready for WGLC since January.




>
>   2.  The "/modules/module" list is keyed by "name" and "revision".
>   Should we really have "revision" as key?  A server can only
>   implement one revision of a module, and should only list one
>   revision of a module w/ conformance = false.  I suggest we make
>   this leaf mandatory, and not part of the key.
>


I am not in favor of this change.
Two modules "foo" and "bar" released on the same date
could not be represented.

I think the indexing is fine in the current draft.
The  operation in NETCONF and RESTCONF need
the module name and the revision-date.

This module should not care how many revisions of each module
are listed.  This is the full YANG library, not a  message.



>


> /martin
>
>
Andy



>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Y45-04 and ietf-yang-library

[Martin Bjorklund]

Hi,

I am preparing a new version of draft-ietf-netmod-rfc6020bis in order
to address Y45-04.  Note that YANG 1.1 uses the module
ietf-yang-library from draft-ietf-netconf-yang-library (hence the
crossposting).

[BTW, shouldn't ietf-yang-library be moved to NETMOD?]

We have a whole bunch of documents that have a normative reference to
draft-ietf-netmod-rfc6020bis, which has a normative reference to
draft-ietf-netconf-yang-library.  This means we need to finish this
document pretty soon.

I ran into some issues with ietf-yang-library:

  1.  The leaf "conformance" is of type "boolean".  It is not obvious
  what "conformance = false" means.  Should we change the name
  and/or type of this leaf?

  I don't have a good proposal, but what we need is a way to
  indicate "I implement the protocol accessible nodes in this
  module" vs. "I just list this module b/c some other module that
  I implement uses typdefs/groupings/... from it".

  This issue is related to the github issue #3.  I think we need
  this information; Y45-04 relies on it.


  2.  The "/modules/module" list is keyed by "name" and "revision".
  Should we really have "revision" as key?  A server can only
  implement one revision of a module, and should only list one
  revision of a module w/ conformance = false.  I suggest we make
  this leaf mandatory, and not part of the key.


/martin


  

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Martin Bjorklund]

Anees Shaikh  wrote:
> Our understanding of the table is that it assumes you have an additional
> state leaf to reflect the negotiated mode (i.e., operational state
> negotiated by protocol) that would be reflected as the "operational" value.

Yes, in this example that is correct.  If we agree on the meaning of
these terms, we can discuss solutions.  I think two solutions have
been proposed:

  1. The data modeller defines three leafs, one for the intended config, one
 for the actual config (MUST be the same syntax as the intended), and
 one for the operational state.  

  2. The data modeller defines two leafs, one for the config, and one
 for the operational state.  The config leaf is instantiated in
 two different data stores; "running" and "operational",
 reflecting the intended and actual config, respectively.
 (It might be instantiated in other data stores as well, such as
 candidate and startup, and maybe ephemeral).

> Actual config was primarily motivated by asynchronous systems (as we
> defined it in the mail Rob sent out) though there are a number of use
> cases.  I think the meaning was clear

It's not completely clear; see my reply to Rob's email.


/martin

> and Martin's table essentially
> captures it.
> 
> thanks.
> -- Anees
> 
> On Wed, Jun 24, 2015 at 1:10 PM, Martin Bjorklund  wrote:
> 
> > Kent Watsen  wrote:
> > >
> > > Hi Martin,
> > >
> > >
> > > >Here's the updated table:
> > > >
> > > >   running  actual configoperational state
> > > >   ---  --
> > > >  t0halfhalf half
> > > >  t1autohalf half
> > > >  t2autohalf (*) half
> > > >  t3autoauto half
> > > >  t4autoauto full
> > >
> > >
> > > I don't understand how actual is ever not the same as operational.
> >
> > If it was always the same it would not be needed.
> >
> > See Rob's picture.  In that picture, the schema for "actual" is the
> > same as for "intended".
> >
> > > At
> > > least in my view, actual is just a subset of operational (the subset
> > > defined by config=true nodes).  What am I missing?
> >
> > Well, I am still trying to understand what (if any) meaning this
> > "actual config" has.  But Rob was pretty clear in his last email:
> >
> >   * We require the ability for an NMS to be able to see both the intended
> > and
> > the actual configuration
> >
> > If I understand this correctly, "actual config" is only interesting in
> > an asynchronous implementation; in a synchronous implementation actual
> > will always be equal to intended.
> >
> > > Also, what does (*)
> > > represent?
> >
> > The (*) was just to relate the text to the table.
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Andy Bierman]

On Wed, Jun 24, 2015 at 1:10 PM, Martin Bjorklund  wrote:

> Kent Watsen  wrote:
> >
> > Hi Martin,
> >
> >
> > >Here's the updated table:
> > >
> > >   running  actual configoperational state
> > >   ---  --
> > >  t0halfhalf half
> > >  t1autohalf half
> > >  t2autohalf (*) half
> > >  t3autoauto half
> > >  t4autoauto full
> >
> >
> > I don't understand how actual is ever not the same as operational.
>
> If it was always the same it would not be needed.
>
> See Rob's picture.  In that picture, the schema for "actual" is the
> same as for "intended".
>



The concept of datastores fits "operational" well because it represents
the module set and potentially same set of data node instances,
where all data node instances are considered to be in the same
network management state.

It is also extensible because leafs like the  and 
parameters in NETCONF can identify any datastore (or non-datastore,
like 'url') and new datastores can be easily added in YANG
(conditionally based on YANG features).



> > At
> > least in my view, actual is just a subset of operational (the subset
> > defined by config=true nodes).  What am I missing?
>
> Well, I am still trying to understand what (if any) meaning this
> "actual config" has.  But Rob was pretty clear in his last email:
>
>   * We require the ability for an NMS to be able to see both the intended
> and
> the actual configuration
>
> If I understand this correctly, "actual config" is only interesting in
> an asynchronous implementation; in a synchronous implementation actual
> will always be equal to intended.
>


Our server supports edit callbacks that are synchronous or asynchronous,
on a per-object registration basis.

It would be better if  worked on all objects.
It is trivial to return the intended value if the server is sure it is
also the actual value.




> > Also, what does (*)
> > represent?
>
> The (*) was just to relate the text to the table.
>
>
> /martin
>


Andy


>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> Hi Martin,
> 
> 
> >Here's the updated table:
> >
> >   running  actual configoperational state
> >   ---  --
> >  t0halfhalf half
> >  t1autohalf half
> >  t2autohalf (*) half
> >  t3autoauto half
> >  t4autoauto full
> 
> 
> I don't understand how actual is ever not the same as operational.

If it was always the same it would not be needed.

See Rob's picture.  In that picture, the schema for "actual" is the
same as for "intended".

> At
> least in my view, actual is just a subset of operational (the subset
> defined by config=true nodes).  What am I missing?

Well, I am still trying to understand what (if any) meaning this
"actual config" has.  But Rob was pretty clear in his last email:

  * We require the ability for an NMS to be able to see both the intended and
the actual configuration

If I understand this correctly, "actual config" is only interesting in
an asynchronous implementation; in a synchronous implementation actual
will always be equal to intended.

> Also, what does (*)
> represent?

The (*) was just to relate the text to the table.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Martin Bjorklund]

Hi,

Rob Shakir  wrote:
> Thanks very much to everyone that has considered the problem that we laid out
> on the last interim call. I think we’re starting to reach a common
> understanding.

As Andy pointed out, there is some overlap in what you describe below
with how NETCONF already works.  This raises some concerns, see below.

>   * Intended and applied/actualised state are views of the running
> configuration.

In NETCONF terms, I think intended config is the "running" data
store.  Do you agree?

In your picture, it is clear that the schema for "intended" and
"applied/actual" is the same.  Good.

>   * All intention is written to the intended configuration (whether it be by
> CLI, a human, an NMS via NETCONF, a system agent, etc.) – which then
> transitions to becoming the applied/actualised configuration. This is
> based on either an explicit request to do so (‘commit’) or may be
> implicit. The success of the intended configuration becoming the applied
> configuration may be due to time deltas or condition, as Kent
> drew.

This part is not clear to me.  Again in NETCONF terms, "commit" is an
operation to copy the contents of the candidate data store into the
running data store.  But if we agreed that running equals intended, I
don't see what the explicit request would be to transition intended /
running into applied/actual?

In NETCONF, as soon as something is written into running (via an
explicit edit-config towards running or via commit), that data is
starting to be used internally in the system.  NETCONF does not state
that the write request must not return until the data has been
"applied", so both asynchronous and synchronous implementations seems
to be ok.

It is not possible to write something into NETCONF's running data
store (intended config) and prevent it from being used internally.

>   * In what we referred to as a ‘synchronous’ system – we expect the attempt
> to make the intended state transition to the actual state to be completed
> when the operation returns (e.g., after a ) then the 
> should return only when this intention has been applied.

Ok.  But see below.

>   * We require the ability for an NMS to be able to see both the intended and
> the actual configuration – such that it can check whether its intention is
> currently the applied configuration, or has not yet been applied due to
> some external dependency (e.g., line card not plugged in).

Are you saying that in a synchronous system, if I write the config of
a card that is not plugged in, my  will hang until the card
has been plugged in?

>   * A portion of the operational state date (marked operational: true) is the
> set of variables that are not related to state that an external system can
> assert the value of — for example, a counter, or a negotiated protocol
> timer.

Ok, but there is a simpler solution to this ;-)

>   * We believe that there is an important advantage in being able to
> syntactically / structurally retrieve the set of state that is associated
> with some set of intended state. This is not ‘easy’ today, as there is no
> common way to link the two – especially as models are composed. This does
> not imply that we understand the semantics of that set of state – but
> simply that we can retrieve all state data that relates to a particular
> entity that we expressed some intention about (e.g., all state data that
> corresponds to a particular interface or BGP peer).

Ok.

> This division is very
> important, since there is separation between elements of the NMS that
> interact with the network, and those that do need to understand the
> semantics/contents of the data leaves.  For some OpenConfig operators,
> this separation of concerns is part of their current NMS software
> architecture.
> 
>   * In terms of accessing subsets of leaves, we need to be able to:
> 
>   + Retrieve the intended state – this is done with a method that does
> similar to get-config in NETCONF.
> 
>   + Retrieve the actual + operational state of the device – done with a
> method similar to get.

Actually, this is not what NETCONF's  gives you.  It will give
you intended + operational.  But we could define a new rpc that gives
you this in NETCONF.

>   + Retrieve only the operational state – done with a method such as
> get-operational.
> 
>   + This means that we need to be able to distinguish intended/actual/
> operational variables leaves through the data model.
> 
>   + We did not define a requirement for a get-actual type call in
> openconfig-opstate, but there may be solutions that do want something
> like this (as per Benoit’s mail to the netmod list yesterday, where it
> is referenced as get-config-false).
> 
>   * We do not require that the two trees for intended and actual have
> identical paths in the data model. They are t

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Kent Watsen]

Hi Martin,


>Here's the updated table:
>
>   running  actual configoperational state
>   ---  --
>  t0halfhalf half
>  t1autohalf half
>  t2autohalf (*) half
>  t3autoauto half
>  t4autoauto full


I don't understand how actual is ever not the same as operational.  At
least in my view, actual is just a subset of operational (the subset
defined by config=true nodes).  What am I missing?  Also, what does (*)
represent?


Thanks,
Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Kent Watsen]

[As an individual contributor]


Hi Rob and OC team,


> Thanks very much to everyone that has considered the problem
> that we laid out on the last interim call. I think we¹re
> starting to reach a common understanding.

Indeed!


> If I can make some slight tweaks to the diagrams that have
> been distributed:

This looks like a variant of the picture I posted here:
http://www.ietf.org/mail-archive/web/netmod/current/msg12738.html.   On
one hand I'm happy to see this because no one had acknowledged the pic
previously, but on the other hand, I'm concerned that you felt the need to
draw another picture, implying there still being a gap...

Actually, when looking at your picture, substituting running for intended,
I think your picture is essentially the same as represented here:
http://www.ietf.org/mail-archive/web/netmod/current/msg12729.html.  Of
course, without ephemeral, running==intended, so your picture isn't wrong
either.  I think the only difference is that your picture shows slides 2-4
together, whereas mine had distinct slides.  Is there a more significant
difference in your mind?



> * We have not been considering ephemeral and startup as
> separate items. As far as we see these, the startup is
> simply a subset of the intended state that happens to
> persist after a system reboot, or seed the initial set
> of intended states when the system restarts. Ephemeral
> state is simply intended state that is not persistent.

Yup


> * Intended and applied/actualised state are views of
> the running configuration.

Yes, but more precisely, running==intended when there is no ephemeral
config, right?


> * All intention is written to the intended configuration
> (whether it be by CLI, a human, an NMS via NETCONF, a
> system agent, etc.) ­ which then transitions to becoming
> the applied/actualised configuration. This is based on
> either an explicit request to do so (Œcommit¹) or may be
> implicit. The success of the intended configuration
> becoming the applied configuration may be due to time
> deltas or condition, as Kent drew.

Yes but, again, the clients are interacting with the "running" and/or
"ephemeral" (not directly to "intended").  The important bit is that
"ephemeral" can override "running", so the "intended" is actually the
result of a merge operation of sorts...


> * In what we referred to as a Œsynchronous¹ system ­ we
> expect the attempt to make the intended state transition
> to the actual state to be completed when the operation
> returns (e.g., after a ) then the  should
> return only when this intention has been applied.

I see.  As stated on the call last week, NETCONF/RESTCONF are currently
only "asynchronous" by this definition, as neither has any statement
regarding *when* intended becomes operational wrt  or 200 OK.
Dipping into design for a sec, it might be interesting to add an optional
commit flag indicating that the server should not respond until
actual==intended...


> * We require the ability for an NMS to be able to see both
> the intended and the actual configuration ­ such that it
> can check whether its intention is currently the applied
> configuration, or has not yet been applied due to some
> external dependency (e.g., line card not plugged in).

Understood, at least for leafs that get a protocol negotiated value, which
may account for just 1% of the configuration.   Dipping again into design,
I was hoping we might use [XML/JSON] attributes, for instance:

 leaf duplex {
   type enumeration {
 enum "half";
 enum "full";
 enum "auto";
   }
   config true;
 }

  get-config from running:
   auto

  get-operational:
   full


Less understood is how to support the conditional enablement cases
(https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00) such
as plugging in a line card, or installing a license, or time-of-day.  For
these, it's not clear what  would return...



> * A portion of the operational state date (marked
> operational: true) is the set of variables that
> are not related to state that an external system
> can assert the value of ‹ for example, a counter,
> or a negotiated protocol timer.

This is what I think config=false should be used for going forwards.  That
is, as the example above shows, config=true simultaneously defines some
nodes returned by , thus we only need config=false to
define the non-config based nodes like counters.


> * We believe that there is an important advantage
> in being able to syntactically / structurally
> retrieve the set of state that is associated with
> some set of intended state. This is not Œeasy¹
> today, as there is no common way to link the two
> ­ especially as models are composed. This does
> not imply that we understand the semantics of that
> set of state ­ but simply that we can retrieve
> all state data that relates to a particular entity
> that we expressed some intention about (e.g., all
> state data that corresponds to a particular
> interf

Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Rob Shakir]

Hi Andy,

Yes, I’m definitely aware of this. The intention is to present a holistic view, 
from which any deltas to the existing functionality can be identified.

Kind regards,
r.




On 24 June 2015 at 18:56:28, Andy Bierman (a...@yumaworks.com) wrote:

Hi,

Not sure you are aware which parts of your diagram are already
standardized in NETCONF.  The startup and candidate capabilities
as defined in RFC 6241 are not related to operational state.


Andy


On Wed, Jun 24, 2015 at 10:39 AM, Rob Shakir  wrote:

Hi netmod,



Thanks very much to everyone that has considered the problem that
we laid out on the last interim call. I think we’re starting to
reach a common understanding.



If I can make some slight tweaks to the diagrams that have been
distributed:




And some further clarifying points/explanations:

We have not been
considering ephemeral and startup as separate items. As far as we
see these, the startup is simply a subset of the intended state
that happens to persist after a system reboot, or seed the initial
set of intended states when the system restarts. Ephemeral state is
simply intended state that is not persistent.
Intended and
applied/actualised state are views of the running
configuration.
All intention is
written to the intended configuration (whether it be by CLI, a
human, an NMS via NETCONF, a system agent, etc.) – which then
transitions to becoming the applied/actualised configuration. This
is based on either an explicit request to do so (‘commit’) or may
be implicit. The success of the intended configuration becoming the
applied configuration may be due to time deltas or condition, as
Kent drew.
In what we referred
to as a ‘synchronous’ system – we expect the attempt to make the
intended state transition to the actual state to be completed when
the operation returns (e.g., after a ) then the
 should return only when this intention has been
applied.
We require the
ability for an NMS to be able to see both the intended and the
actual configuration – such that it can check whether its intention
is currently the applied configuration, or has not yet been applied
due to some external dependency (e.g., line card not plugged
in).
A portion of the
operational state date (marked operational: true) is the set of
variables that are not related to state that an external system can
assert the value of — for example, a counter, or a negotiated
protocol timer.
We believe that
there is an important advantage in being able to syntactically /
structurally retrieve the set of state that is associated with some
set of intended state. This is not ‘easy’ today, as there is no
common way to link the two – especially as models are composed.
This does not imply that we understand the semantics of that set of
state – but simply that we can retrieve all state data that relates
to a particular entity that we expressed some intention about
(e.g., all state data that corresponds to a particular interface or
BGP peer). This division is very important, since there is
separation between elements of the NMS that interact with the
network, and those that do need to understand the
semantics/contents of the data leaves.  For some OpenConfig
operators, this separation of concerns is part of their current NMS
software architecture.
In terms of
accessing subsets of leaves, we need to be able to:
Retrieve the
intended state – this is done with a method that does similar to
get-config in NETCONF.
Retrieve the actual
+ operational state of the device – done with a method similar to
get.
Retrieve only the
operational state – done with a method such as
get-operational.
This means that we
need to be able to distinguish intended/actual/operational
variables leaves through the data model.
We did not define a
requirement for a get-actual type call in openconfig-opstate, but
there may be solutions that do want something like this (as per
Benoit’s mail to the netmod list yesterday, where it is referenced
as get-config-false).
We do not require
that the two trees for intended and actual have identical paths in
the data model. They are the same set of leaves – but it MUST be
possible to check both. In openconfig-opstate then we consistently
achieve this by having the same set of leaves (typically grouping
FOO-config) that is included under both container config (where
they are intended) and container state (where they are applied)).
Since there is a common way to be able to relate these through the
structure, then this is OK for us.
Thanks again.

Kind regards,
Anees, Marcus & Rob.

On 23 June 2015 at 16:44:36, Benoit Claise (bcla...@cisco.com) wrote:

Dear all,

In order to clarify the situation, I compiled some points from my notes and 
created a couple of diagrams. This was initially created for my personal use, 
but if it helps with the discussion, please use it.

The first open issue is terminology IMO.
    - intended, applied
    - synchronous/asynchronous
There are two synchronous levels: the protocol (NETCONF) and network elemen

Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Andy Bierman]

Hi,

Not sure you are aware which parts of your diagram are already
standardized in NETCONF.  The startup and candidate capabilities
as defined in RFC 6241 are not related to operational state.


Andy


On Wed, Jun 24, 2015 at 10:39 AM, Rob Shakir  wrote:

> Hi netmod,
>
>
> Thanks very much to everyone that has considered the problem that we laid
> out on the last interim call. I think we’re starting to reach a common
> understanding.
>
>
> If I can make some slight tweaks to the diagrams that have been
> distributed:
>
> [image: img.png]
>
> And some further clarifying points/explanations:
>
>
>-
>
>We have not been considering ephemeral and startup as separate items.
>As far as we see these, the startup is simply a subset of the intended
>state that happens to persist after a system reboot, or seed the initial
>set of intended states when the system restarts. Ephemeral state is simply
>intended state that is not persistent.
>-
>
>Intended and applied/actualised state are views of the running
>configuration.
>-
>
>All intention is written to the intended configuration (whether it be
>by CLI, a human, an NMS via NETCONF, a system agent, etc.) – which then
>transitions to becoming the applied/actualised configuration. This is based
>on either an explicit request to do so (‘commit’) or may be implicit. The
>success of the intended configuration becoming the applied configuration
>may be due to time deltas or condition, as Kent drew.
>-
>
>In what we referred to as a ‘synchronous’ system – we expect the
>attempt to make the intended state transition to the actual state to be
>completed when the operation returns (e.g., after a ) then the
> should return only when this intention has been applied.
>-
>
>We require the ability for an NMS to be able to see both the intended
>and the actual configuration – such that it can check whether its intention
>is currently the applied configuration, or has not yet been applied due to
>some external dependency (e.g., line card not plugged in).
>-
>
>A portion of the operational state date (marked operational: true) is
>the set of variables that are not related to state that an external system
>can assert the value of — for example, a counter, or a negotiated protocol
>timer.
>-
>
>We believe that there is an important advantage in being able to
>syntactically / structurally retrieve the set of state that is associated
>with some set of intended state. This is not ‘easy’ today, as there is no
>common way to link the two – especially as models are composed. This does
>not imply that we understand the semantics of that set of state – but
>simply that we can retrieve all state data that relates to a particular
>entity that we expressed some intention about (e.g., all state data that
>corresponds to a particular interface or BGP peer). This division is very
>important, since there is separation between elements of the NMS that
>interact with the network, and those that do need to understand the
>semantics/contents of the data leaves.  For some OpenConfig operators, this
>separation of concerns is part of their current NMS software architecture.
>-
>
>In terms of accessing subsets of leaves, we need to be able to:
>-
>
>   Retrieve the intended state – this is done with a method that does
>   similar to get-config in NETCONF.
>   -
>
>   Retrieve the actual + operational state of the device – done with a
>   method similar to get.
>   -
>
>   Retrieve only the operational state – done with a method such as
>   get-operational.
>   -
>
>   This means that we need to be able to distinguish
>   intended/actual/operational variables leaves through the data model.
>   -
>
>   We did not define a requirement for a get-actual type call in
>   openconfig-opstate, but there may be solutions that do want something 
> like
>   this (as per Benoit’s mail to the netmod list yesterday, where it is
>   referenced as get-config-false).
>   -
>
>We do not require that the two trees for intended and actual have
>identical paths in the data model. They are the same set of leaves – but it
>MUST be possible to check both. In openconfig-opstate then we consistently
>achieve this by having the same set of leaves (typically grouping
>FOO-config) that is included under both container config (where they are
>intended) and container state (where they are applied)). Since there is a
>common way to be able to relate these through the structure, then this is
>OK for us.
>
> Thanks again.
>
> Kind regards,
> Anees, Marcus & Rob.
>
> On 23 June 2015 at 16:44:36, Benoit Claise (bcla...@cisco.com) wrote:
>
> Dear all,
>
> In order to clarify the situation, I compiled some points from my notes
> and created a couple of diagrams. T

Re: [netmod] extended datastores slide

[Andy Bierman]

On Wed, Jun 24, 2015 at 10:14 AM, Phil Shafer  wrote:

> Andy Bierman writes:
> >> How is that expressed in the data model?  "auto" would not be an
> >> operational value for "duplex".  "none" would not be a valid
> >> configuration value, but would be the operational value for an
> >> empty port.
> >
> >good point -- the operational instance would not exist is the status is
> >'none'
>
> Why not?  The interface might exist but not have an ethernet
> cable plugged in.  "show interfaces" would show the physical
> instance, but duplex could be "none".
>
>

OK -- good point

In NETCONF terms, a new  parameter or
a new  operation could be used
to read the operational datastore.


> Thanks,
>  Phil
>


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Follow up on the openconfig oper status and the NETMOD interim

[Rob Shakir]

Hi netmod,

Thanks very much to everyone that has considered the problem that we laid out 
on the last interim call. I think we’re starting to reach a common 
understanding.

If I can make some slight tweaks to the diagrams that have been distributed:  


And some further clarifying points/explanations:

We have not been considering ephemeral and startup as separate items. As far as 
we see these, the startup is simply a subset of the intended state that happens 
to persist after a system reboot, or seed the initial set of intended states 
when the system restarts. Ephemeral state is simply intended state that is not 
persistent.
Intended and applied/actualised state are views of the running configuration.
All intention is written to the intended configuration (whether it be by CLI, a 
human, an NMS via NETCONF, a system agent, etc.) – which then transitions to 
becoming the applied/actualised configuration. This is based on either an 
explicit request to do so (‘commit’) or may be implicit. The success of the 
intended configuration becoming the applied configuration may be due to time 
deltas or condition, as Kent drew.
In what we referred to as a ‘synchronous’ system – we expect the attempt to 
make the intended state transition to the actual state to be completed when the 
operation returns (e.g., after a ) then the  should return only 
when this intention has been applied.
We require the ability for an NMS to be able to see both the intended and the 
actual configuration – such that it can check whether its intention is 
currently the applied configuration, or has not yet been applied due to some 
external dependency (e.g., line card not plugged in).
A portion of the operational state date (marked operational: true) is the set 
of variables that are not related to state that an external system can assert 
the value of — for example, a counter, or a negotiated protocol timer.
We believe that there is an important advantage in being able to syntactically 
/ structurally retrieve the set of state that is associated with some set of 
intended state. This is not ‘easy’ today, as there is no common way to link the 
two – especially as models are composed. This does not imply that we understand 
the semantics of that set of state – but simply that we can retrieve all state 
data that relates to a particular entity that we expressed some intention about 
(e.g., all state data that corresponds to a particular interface or BGP peer). 
This division is very important, since there is separation between elements of 
the NMS that interact with the network, and those that do need to understand 
the semantics/contents of the data leaves.  For some OpenConfig operators, this 
separation of concerns is part of their current NMS software architecture.
In terms of accessing subsets of leaves, we need to be able to:
Retrieve the intended state – this is done with a method that does similar to 
get-config in NETCONF.
Retrieve the actual + operational state of the device – done with a method 
similar to get.
Retrieve only the operational state – done with a method such as 
get-operational.
This means that we need to be able to distinguish intended/actual/operational 
variables leaves through the data model.
We did not define a requirement for a get-actual type call in 
openconfig-opstate, but there may be solutions that do want something like this 
(as per Benoit’s mail to the netmod list yesterday, where it is referenced as 
get-config-false).
We do not require that the two trees for intended and actual have identical 
paths in the data model. They are the same set of leaves – but it MUST be 
possible to check both. In openconfig-opstate then we consistently achieve this 
by having the same set of leaves (typically grouping FOO-config) that is 
included under both container config (where they are intended) and container 
state (where they are applied)). Since there is a common way to be able to 
relate these through the structure, then this is OK for us.
Thanks again.

Kind regards,
Anees, Marcus & Rob.

On 23 June 2015 at 16:44:36, Benoit Claise (bcla...@cisco.com) wrote:

Dear all,

In order to clarify the situation, I compiled some points from my notes and 
created a couple of diagrams. This was initially created for my personal use, 
but if it helps with the discussion, please use it.

The first open issue is terminology IMO.
    - intended, applied
    - synchronous/asynchronous
There are two synchronous levels: the protocol (NETCONF) and network element 
implementation. As Kent mentioned: "Kent NETCONF is a synchronous protocol but 
state may change asynchronously."
It would beneficial for the authors to explain what happens in the following 
NETCONF server two cases:
    - an example of (non-NETCONF) asynchronous: RPC and leaf update (first 
intended, then applied)
    - example of full NETCONF synchronous: RPC and leaf update. In this case, 
duplicate leaf.

The second open issue is that it's not clear which exact 

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Rob Shakir]

Hi Martin,

The table you have is consistent with the proposal that we laid out in the last 
interim. Now that we understand the problem, it’d be great to move on to 
solutions :)

Cheers,
r.




On 24 June 2015 at 10:39:53, Martin Bjorklund (m...@tail-f.com) wrote:

Kent Watsen  wrote:  
>  
> [As an individual contributor]  
>  
> I think terminology is mostly converging, with the primary hangup  
> being if ephemeral/intended are "configuration" or "state". I'm  
> personally in favor of calling both "configuration", as they would  
> still contain values like "auto", that require actualization to obtain  
> an operational state value...so I think, if it's not state, it must be  
> config, right? Adding to this, we have a general understanding that  
> anything that can be configured persistently can also (in theory) be  
> configured ephemerally – so it behaves like config in this way too...  
>  
> More importantly though, I believe that we're converging on a  
> conceptual model and have general agreement that "running + ephemeral  
> = intended" and "intended +  = operational state".  
> This seems obvious in hindsight, but it wasn't until the OpenConfig  
> folks brought the "intended" term that we wrote it down.  

I don't think this covers what the open config people call "actual  
config". Suppose we have (ignoring ephemeral for simplicitly):  

running operational state  
--- -  
t0 half half  
t1 auto half  
t4 auto full  

I.e., at time t1, we set duplex to auto. After some time (t4) this is  
reflected in the operational state.  


In the open config model we'd have:  

running actual config operational state  
--- - -  
t0 half half half  
t1 auto half half  
t2 auto half (*) half  
t3 auto auto half  
t4 auto auto auto  

This illustrates that at time t2, the actual config is still half (*)  
in an asynchrounous implementation. At time t3, the actual config is  
in sync with the intended config, and at time t4 the operational state  
has been affected.  


> I hope we can converge on the terminology and conceptual model in the  
> near term, and then use this new foundation for articulating I2RS and  
> OpenConfig solutions.  

+1 This should be our focus.  


/martin  
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Phil Shafer]

Andy Bierman writes:
>> How is that expressed in the data model?  "auto" would not be an
>> operational value for "duplex".  "none" would not be a valid
>> configuration value, but would be the operational value for an
>> empty port.
>
>good point -- the operational instance would not exist is the status is
>'none'

Why not?  The interface might exist but not have an ethernet
cable plugged in.  "show interfaces" would show the physical
instance, but duplex could be "none".

Thanks,
 Phil

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Andy Bierman]

On Wed, Jun 24, 2015 at 7:34 AM, Phil Shafer  wrote:

> Andy Bierman writes:
> >1) defaults are not used in the ephemeral datastore
> >
> >The default-stmt is altered for the ephemeral datastore.
> >Default leafs are ignored (except for XPath evaluation).
> >Otherwise the schema default would always override the configuration.
>
> List instances in the ephemeral datastore with no matching
> instance in the committed datastore would need to have
> default values from the schema.
>
> Think of defaults as the pane of glass that sits behind
> all other planes.
>
>
good point



> >2) XPath hierarchy is based on config-stmt.
> >
> >  config=true context node -> can reference config=true
> >  config=ephemeral context node -> can reference true + ephemeral
> >  config=false context node -> can reference true, ephemeral, false
>
> Are you talking about must/when statements in config false nodes?
>

yes -- all values of config-stmt


>
> I think the key point is that the committed config must be valid
> without references anything else.  The ephemeral config must be
> valid without referencing config false nodes.
>


exactly -- that is what I was trying to say above



>
> >3) must/when evaluation applies only to the datastore indicated by
> >config-stmt
> > config=true -> running
> > config=ephemeral -> ephemeral
> > config=false -> operational
>
> ephemeral nodes should be able to reference config=true nodes.
> An ephemeral interfaces should be able to reference a pre-configured
> filter/policer.  But the reverse would not be true.
>
>

The issue is where to enforce the YANG datastore validation for must/when.
The "portability" of must/when is a general problem, but more datastores
makes
it more complicated



> >4) panes of glass applied to data instances
> >all running datastore instances are visible in the ephemeral datastore
> >all ephemeral datastore instances are visible in the operational
> >datastore
>
> What is "all running datastore instances"?
>


All the data instances (like interfaces) are visible in the ephemeral
for the purpose of XPath and path-stmt (leafref) evaluation



>
> >5) admin-foo and oper-foo can go away
> >
> >  The instance of 'admin-temp' in the operational datastore would return
> >  the value in effect, not the desired value, so 'oper-temp' is not needed
> >  and the correlation between config, ephemeral, and operational is
> >maintained
> >  in the common instance-identifier in all 3 datastores
>
> The issues remain: what happens when the set of possible values
> varies between the operational world and the configuration world?
>


New notifications can be defined to let a client know when a data resource
converges or diverges from the configured value.



> How is that expressed in the data model?  "auto" would not be an
> operational value for "duplex".  "none" would not be a valid
> configuration value, but would be the operational value for an
> empty port.
>


good point -- the operational instance would not exist is the status is
'none'



>
> Thanks,
>  Phil
>


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)

[Juergen Schoenwaelder]

On Mon, Jun 15, 2015 at 10:49:28PM +, Kent Watsen wrote:
> 
> This is a notice to start a NETMOD WG last call for the document "JSON 
> Encoding of Data Modeled with YANG":
> 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04
> 
> Please indicate your support by Monday June 29, 2015 at 9PM EST.

Hi,

I have reviewed draft-ietf-netmod-yang-json-04.

- I am not sure I agree with the wording in section 3. Why is section
  8.3.3 only applicable to XML encoded data? Validation applies to
  datastores. While constraints are defined using XML-based notations
  such as XPATH, how the validation is carried out is not defined in
  the YANG specifications. I guess I actually disagree with the
  wording in section 3 of the JSON encoding I-D.

- It is unclear whether the 'if and only if' on page 4 means that an
  implementation that generates namespace prefixes that are not
  strictly needed is violating this I-D. I see the need for a MUST to
  include the module name if the parent node belongs to a different
  module. I am not sure why it is necessary to mandate minimal
  encodings (if that is the idea here). Whatever the answer is, it
  would be good to use RFC 2119 language.

- The reason for the requirement that list keys are encoded first in
  RFC 6020 is to make it easier to process data in a stream-oriented
  fashion. If keys can appear anywhere, they might appear at the very
  end and thus buffering is required in order to process data
  properly. Is this concern not relevant for the JSON encoding?
  Perhaps this is not relevant, but then we might also state this
  explicitly:

  As a consequence, implementations must be cable to buffer JSON
  encoded instances in order to locate keys that may appear at the
  end of a JSON encoded instance.

- I think that section 5.5 should say:

  If the data model for the data in an anydata instance is known,
  then the data must be encoded following the rules defined in
  this I-D.

  In other words, it is not arbitrary JSON with a few constraints but
  something that matches the JSON encoding rules once the data model
  is known.

- Section 6, I suggest s/mapped/encoded/.

- I do not understand 'An "enumeration" value is mapped in the same
  way as a string except that permitted values are defined by enum
  statements in YANG.' Perhaps this is simpler:

 An "enumeration" value is encoded as a JSON string. The allowed
 string values are the enumeration names assigned by the enum
 statement in YANG.

 The representation is identifical to the XML encoding, see
 sec. 9.6 in [RFC6020bis].

  I specifically tried to avoid 'value' in order to avoid confusion with
  the value YANG statement.

- Perhaps remove the reference to XML in section 6.5 from the
  definition of the encoding rules so that the JSON encoding rules are
  not tied into the XML encoding rules. It is OK to mention that it is
  the same.

 A "bits" value is encoded as a JSON string. Multiple bit names
 assigned by the bit statement in YANG are encoded as a
 space-separated string of bit names representing the individual
 bits that are set.

 The representation is identifical to the XML encoding, see
 sec. 9.7 in [RFC6020bis].

- Same as before for section 6.6:

 A "binary" value is encoded by first encoding the binary value in
 base64 and encoding the resulting base64-encoded value as a JSON
 string.

 The representation is identifical to the XML encoding, see
 sec. 9.8 in [RFC6020bis].

- I am not sure I understand the argument why [null] is better than
  null for the empty type. Perhaps it is but the text does not really
  tell me.

- I suggest to remove the reference to 9.13.3 in the definition. In
  fact, the representation is pretty different since XML uses
  namespace prefixes while JSON uses module names. (I must admit that
  I find the JSON representation more readable since it does not
  require XML namespace context.)

- Section 7: So what happens in the rare case of a binary value
  appearing in a RESTCONF URI? Is the resulting BASE64 value than
  simply subject to URI escaping rules?

  I assume this 'rare event' would happen if a list is indexed by a
  leaf of type binary, no? Are there any other cases?

/js

PS: Should RFC 6020bis change the section titles "XML Mapping Rules" to
"XML Encoding Rules"? I think we really talk about 'encoding', not
about 'mapping' and if we agree on this, we should try to be
consistent with the terms we use.

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Phil Shafer]

Martin Bjorklund writes:
>Yes, agreed; I just wanted to be sure.  I think this is worth pointing
>out explicitly.  In many cases the oper- node is not needed, but it
>might be.

Would we be better of having YANG statements that detail the
way the model changes between config and operational modes?
Otherwise the tie-in between the oper-leaf and config-leaf
needs to be modeled.

Thanks,
 Phil

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Jun 24, 2015 at 7:23 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Andy Bierman  wrote:
> > > 5) admin-foo and oper-foo can go away
> >
> > Yes, but I assume that they don't *have* to go away.  For example, the
> > duplex example would still have two nodes, since the syntax is
> > different.
> >
> 
> 
> I didn't say "have" -- I said "can"
> I think the OC folks are right that the same syntax could be used but
> the operational value would never be 'auto'.  A separate object
> is better though (in this case).

Yes, agreed; I just wanted to be sure.  I think this is worth pointing
out explicitly.  In many cases the oper- node is not needed, but it
might be.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Phil Shafer]

Andy Bierman writes:
>1) defaults are not used in the ephemeral datastore
>
>The default-stmt is altered for the ephemeral datastore.
>Default leafs are ignored (except for XPath evaluation).
>Otherwise the schema default would always override the configuration.

List instances in the ephemeral datastore with no matching
instance in the committed datastore would need to have
default values from the schema.

Think of defaults as the pane of glass that sits behind
all other planes.

>2) XPath hierarchy is based on config-stmt.
>
>  config=true context node -> can reference config=true
>  config=ephemeral context node -> can reference true + ephemeral
>  config=false context node -> can reference true, ephemeral, false

Are you talking about must/when statements in config false nodes?

I think the key point is that the committed config must be valid
without references anything else.  The ephemeral config must be
valid without referencing config false nodes.

>3) must/when evaluation applies only to the datastore indicated by
>config-stmt
> config=true -> running
> config=ephemeral -> ephemeral
> config=false -> operational

ephemeral nodes should be able to reference config=true nodes.
An ephemeral interfaces should be able to reference a pre-configured
filter/policer.  But the reverse would not be true.

>4) panes of glass applied to data instances
>all running datastore instances are visible in the ephemeral datastore
>all ephemeral datastore instances are visible in the operational
>datastore

What is "all running datastore instances"?

>5) admin-foo and oper-foo can go away
>
>  The instance of 'admin-temp' in the operational datastore would return
>  the value in effect, not the desired value, so 'oper-temp' is not needed
>  and the correlation between config, ephemeral, and operational is
>maintained
>  in the common instance-identifier in all 3 datastores

The issues remain: what happens when the set of possible values
varies between the operational world and the configuration world?
How is that expressed in the data model?  "auto" would not be an
operational value for "duplex".  "none" would not be a valid
configuration value, but would be the operational value for an
empty port.

Thanks,
 Phil

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Andy Bierman]

On Wed, Jun 24, 2015 at 7:23 AM, Martin Bjorklund  wrote:

> Hi,
>
> Andy Bierman  wrote:
> > Hi,
> >
> > thanks.
> > A few details of the solution I am working on...
>
> I would (still!) use a new statement "i2rs:ephemeral true;" to mark
> ephemeral nodes on config false nodes.  This can be done w/o changing
> YANG.
>
> > 1) defaults are not used in the ephemeral datastore
> >
> > The default-stmt is altered for the ephemeral datastore.
> > Default leafs are ignored (except for XPath evaluation).
> > Otherwise the schema default would always override the configuration.
>
> I see your point, but if I create a list instance entirely in the
> ephemeral data store, I would assume defaults in that list instance to
> be used.
>
> I think the logic should be that if no value is set in the config or
> ephemeral, then the default value is used.  The ephemeral value
> overrides the configured value.
>
>
OK



> > 2) XPath hierarchy is based on config-stmt.
> >
> >   config=true context node -> can reference config=true
> >   config=ephemeral context node -> can reference true + ephemeral
> >   config=false context node -> can reference true, ephemeral, false
> >
> > 3) must/when evaluation applies only to the datastore indicated by
> > config-stmt
> >  config=true -> running
> >  config=ephemeral -> ephemeral
> >  config=false -> operational
> >
> > 4) panes of glass applied to data instances
> > all running datastore instances are visible in the ephemeral
> datastore
> > all ephemeral datastore instances are visible in the operational
> > datastore
> >
> > 5) admin-foo and oper-foo can go away
>
> Yes, but I assume that they don't *have* to go away.  For example, the
> duplex example would still have two nodes, since the syntax is
> different.
>


I didn't say "have" -- I said "can"
I think the OC folks are right that the same syntax could be used but
the operational value would never be 'auto'.  A separate object
is better though (in this case).



>
> >   The instance of 'admin-temp' in the operational datastore would return
> >   the value in effect, not the desired value, so 'oper-temp' is not
> needed
> >   and the correlation between config, ephemeral, and operational is
> > maintained
> >   in the common instance-identifier in all 3 datastores
>
>
> /martin
>


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Martin Bjorklund]

Hi,

Andy Bierman  wrote:
> Hi,
> 
> thanks.
> A few details of the solution I am working on...

I would (still!) use a new statement "i2rs:ephemeral true;" to mark
ephemeral nodes on config false nodes.  This can be done w/o changing
YANG.

> 1) defaults are not used in the ephemeral datastore
> 
> The default-stmt is altered for the ephemeral datastore.
> Default leafs are ignored (except for XPath evaluation).
> Otherwise the schema default would always override the configuration.

I see your point, but if I create a list instance entirely in the
ephemeral data store, I would assume defaults in that list instance to
be used.

I think the logic should be that if no value is set in the config or
ephemeral, then the default value is used.  The ephemeral value
overrides the configured value.

> 2) XPath hierarchy is based on config-stmt.
> 
>   config=true context node -> can reference config=true
>   config=ephemeral context node -> can reference true + ephemeral
>   config=false context node -> can reference true, ephemeral, false
> 
> 3) must/when evaluation applies only to the datastore indicated by
> config-stmt
>  config=true -> running
>  config=ephemeral -> ephemeral
>  config=false -> operational
> 
> 4) panes of glass applied to data instances
> all running datastore instances are visible in the ephemeral datastore
> all ephemeral datastore instances are visible in the operational
> datastore
> 
> 5) admin-foo and oper-foo can go away

Yes, but I assume that they don't *have* to go away.  For example, the
duplex example would still have two nodes, since the syntax is
different.

>   The instance of 'admin-temp' in the operational datastore would return
>   the value in effect, not the desired value, so 'oper-temp' is not needed
>   and the correlation between config, ephemeral, and operational is
> maintained
>   in the common instance-identifier in all 3 datastores


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Martin,
> 
> One quick clarification:
> 
> In your open config model example, should the operational state of the
> last line read 'full'?

yes!


> I.e
> 
>running  actual configoperational state
>---  --
>   t4autoauto*full*


Here's the updated table:

   running  actual configoperational state
   ---  --
  t0halfhalf half
  t1autohalf half
  t2autohalf (*) half
  t3autoauto half
  t4autoauto full



/martin


> 
> 
> Thanks,
> Rob
> 
> 
> On 24/06/2015 10:39, Martin Bjorklund wrote:
> > Kent Watsen  wrote:
> >> [As an individual contributor]
> >>
> >> I think terminology is mostly converging, with the primary hangup
> >> being if ephemeral/intended are "configuration" or "state".  I'm
> >> personally in favor of calling both "configuration", as they would
> >> still contain values like "auto", that require actualization to obtain
> >> an operational state value...so I think, if it's not state, it must be
> >> config, right?  Adding to this, we have a general understanding that
> >> anything that can be configured persistently can also (in theory) be
> >> configured ephemerally – so it behaves like config in this way too...
> >>
> >> More importantly though, I believe that we're converging on a
> >> conceptual model and have general agreement that "running + ephemeral
> >> = intended" and "intended +  = operational state".
> >> This seems obvious in hindsight, but it wasn't until the OpenConfig
> >> folks brought the "intended" term that we wrote it down.
> > I don't think this covers what the open config people call "actual
> > config".   Suppose we have (ignoring ephemeral for simplicitly):
> >
> > runningoperational state
> > ----
> >t0half  half
> >t1auto  half
> >t4auto  full
> >
> > I.e., at time t1, we set duplex to auto.  After some time (t4) this is
> > reflected in the operational state.
> >
> >
> > In the open config model we'd have:
> >
> > running  actual configoperational state
> > ---  --
> >t0halfhalf half
> >t1autohalf half
> >t2autohalf (*) half
> >t3autoauto half
> >t4autoauto auto
> >
> > This illustrates that at time t2, the actual config is still half (*)
> > in an asynchrounous implementation.  At time t3, the actual config is
> > in sync with the intended config, and at time t4 the operational state
> > has been affected.
> >
> >
> >> I hope we can converge on the terminology and conceptual model in the
> >> near term, and then use this new foundation for articulating I2RS and
> >> OpenConfig solutions.
> > +1  This should be our focus.
> >
> >
> > /martin
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Andy Bierman]

Hi,

thanks.
A few details of the solution I am working on...

1) defaults are not used in the ephemeral datastore

The default-stmt is altered for the ephemeral datastore.
Default leafs are ignored (except for XPath evaluation).
Otherwise the schema default would always override the configuration.

2) XPath hierarchy is based on config-stmt.

  config=true context node -> can reference config=true
  config=ephemeral context node -> can reference true + ephemeral
  config=false context node -> can reference true, ephemeral, false

3) must/when evaluation applies only to the datastore indicated by
config-stmt
 config=true -> running
 config=ephemeral -> ephemeral
 config=false -> operational

4) panes of glass applied to data instances
all running datastore instances are visible in the ephemeral datastore
all ephemeral datastore instances are visible in the operational
datastore

5) admin-foo and oper-foo can go away

  The instance of 'admin-temp' in the operational datastore would return
  the value in effect, not the desired value, so 'oper-temp' is not needed
  and the correlation between config, ephemeral, and operational is
maintained
  in the common instance-identifier in all 3 datastores



Andy




On Wed, Jun 24, 2015 at 6:28 AM, Joel M. Halpern 
wrote:

> The separations and effects shown there match my understanding.
> Thank you,
> Joel
>
> On 6/24/15 9:24 AM, Andy Bierman wrote:
>
>> Hi,
>>
>> I prepared 1 slide (based on Kent's slide).
>> I am trying to understand the types of data
>> and how they are identified in YANG and conceptually
>> separated for protocol access.
>>
>>
>>
>> Andy
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Robert Wilton]

Hi Martin,

One quick clarification:

In your open config model example, should the operational state of the 
last line read 'full'?

I.e

   running  actual configoperational state
   ---  --
  t4autoauto*full*


Thanks,
Rob


On 24/06/2015 10:39, Martin Bjorklund wrote:

Kent Watsen  wrote:

[As an individual contributor]

I think terminology is mostly converging, with the primary hangup
being if ephemeral/intended are "configuration" or "state".  I'm
personally in favor of calling both "configuration", as they would
still contain values like "auto", that require actualization to obtain
an operational state value...so I think, if it's not state, it must be
config, right?  Adding to this, we have a general understanding that
anything that can be configured persistently can also (in theory) be
configured ephemerally – so it behaves like config in this way too...

More importantly though, I believe that we're converging on a
conceptual model and have general agreement that "running + ephemeral
= intended" and "intended +  = operational state".
This seems obvious in hindsight, but it wasn't until the OpenConfig
folks brought the "intended" term that we wrote it down.

I don't think this covers what the open config people call "actual
config".   Suppose we have (ignoring ephemeral for simplicitly):

runningoperational state
----
   t0half  half
   t1auto  half
   t4auto  full

I.e., at time t1, we set duplex to auto.  After some time (t4) this is
reflected in the operational state.


In the open config model we'd have:

running  actual configoperational state
---  --
   t0halfhalf half
   t1autohalf half
   t2autohalf (*) half
   t3autoauto half
   t4autoauto auto

This illustrates that at time t2, the actual config is still half (*)
in an asynchrounous implementation.  At time t3, the actual config is
in sync with the intended config, and at time t4 the operational state
has been affected.



I hope we can converge on the terminology and conceptual model in the
near term, and then use this new foundation for articulating I2RS and
OpenConfig solutions.

+1  This should be our focus.


/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [i2rs] extended datastores slide

[Susan Hares]

Andy: 

 

I will post this slide for the i2RS meeting. 

 

Sue 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, June 24, 2015 9:24 AM
To: netmod@ietf.org; i...@ietf.org
Subject: [i2rs] extended datastores slide

 

Hi,

 

I prepared 1 slide (based on Kent's slide).

I am trying to understand the types of data

and how they are identified in YANG and conceptually

separated for protocol access.

 

 

 

Andy

 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] extended datastores slide

[Joel M. Halpern]

The separations and effects shown there match my understanding.
Thank you,
Joel

On 6/24/15 9:24 AM, Andy Bierman wrote:

Hi,

I prepared 1 slide (based on Kent's slide).
I am trying to understand the types of data
and how they are identified in YANG and conceptually
separated for protocol access.



Andy



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] extended datastores slide

[Andy Bierman]

Hi,

I prepared 1 slide (based on Kent's slide).
I am trying to understand the types of data
and how they are identified in YANG and conceptually
separated for protocol access.



Andy


extended_datastores.pdf
Description: Adobe PDF document
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Y35: allow empty in union

[Martin Bjorklund]

Hi,

Currently we have an inconsistency in
draft-ietf-netmod-rfc6020bis-05.  With Y35, we allow type empty in
unions.  But section 7.8.2 says:

   A leaf that is part of the key can be of any built-in or derived
   type, except it MUST NOT be the built-in type "empty".

This means that this is legal:

  typedef my-empty {
type union {
  type empty;
}
  }

  list foo {
key id;
leaf id {
  type my-empty;
}
...
  }


I suggest we allow type empty also in keys:

NEW:

   A leaf that is part of the key can be of any built-in or derived
   type.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> [As an individual contributor]
> 
> I think terminology is mostly converging, with the primary hangup
> being if ephemeral/intended are "configuration" or "state".  I'm
> personally in favor of calling both "configuration", as they would
> still contain values like "auto", that require actualization to obtain
> an operational state value...so I think, if it's not state, it must be
> config, right?  Adding to this, we have a general understanding that
> anything that can be configured persistently can also (in theory) be
> configured ephemerally – so it behaves like config in this way too...
> 
> More importantly though, I believe that we're converging on a
> conceptual model and have general agreement that "running + ephemeral
> = intended" and "intended +  = operational state".
> This seems obvious in hindsight, but it wasn't until the OpenConfig
> folks brought the "intended" term that we wrote it down.

I don't think this covers what the open config people call "actual
config".   Suppose we have (ignoring ephemeral for simplicitly):

   runningoperational state
   ----
  t0half  half
  t1auto  half
  t4auto  full

I.e., at time t1, we set duplex to auto.  After some time (t4) this is
reflected in the operational state.


In the open config model we'd have:

   running  actual configoperational state
   ---  --
  t0halfhalf half
  t1autohalf half
  t2autohalf (*) half
  t3autoauto half
  t4autoauto auto

This illustrates that at time t2, the actual config is still half (*)
in an asynchrounous implementation.  At time t3, the actual config is
in sync with the intended config, and at time t4 the operational state
has been affected.


> I hope we can converge on the terminology and conceptual model in the
> near term, and then use this new foundation for articulating I2RS and
> OpenConfig solutions.

+1  This should be our focus.


/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod