Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01

[Rob Shakir]

Juergen Schoenwaelder wrote:

But you are right, it is not just the path that is needed to identify
data residing in configuration datastores. It is in general a tuple
  and for configuration data the selector is a
configuration datastore name.


Thanks for the clarification. Do you have examples of other (i.e., 
non-NETCONF) systems that utilise this convention that a path is not an 
absolute reference to a certain data node? Reviewing with various 
interested parties, I'm not sure that there are clear cases that form a 
precedent for this.


If we consider that this then might drive some new behaviour where the 
systems architecture for NMS differs from elsewhere then we might want 
to question whether this is necessary complexity. Indeed, for me this 
comes back to one of the discussions about the other datastores that we 
had on an interim call.


 * 'startup' is really a property of the intended configuration - as to 
whether it has been made persistent. In general, I see very few changes 
that are made where we interact only with the persistent version of the 
intended configuration; and even fewer where the intended configuration 
is not made persistent. In both cases, it tends to be the lack of a 
declarative configuration API that drives the need to interact with either.


 * 'candidate' is again a property of the intended configuration - 
insofar that the 'candidate' set of configuration represents a set of 
changes that have not been requested to be transitioned to the 'applied 
configuration'. This makes sense when a human is working through 
building up a transaction (configure protocol X, protocol Y .. protocol 
Z, then commit) - but isn't quite so clear when it programmatic 
interaction with the network.


It is quite trivial for me to see cases where an external NMS would 
never really need to interact with either of these datastores - such 
that it's quite tricky for me to determine that we really want to 
architect the entire NMS to be able to carry the  tuple 
(stealing your terms, thanks!), especially if this means that it has to 
work entirely differently w.r.t paths than the rest of OSS.


r.

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

Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings

[Andy Bierman]

On Fri, Aug 7, 2015 at 8:57 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> Lets please not mix YANG 1.1 work with other discussions at this point
> in time.
>
>
I would really like the WG and IESG to decide how YANG is going to be
updated to support ephemeral state and operational state.

It seems there are many documents waiting on YANG 1.1, yet
only 1 or 2 actually use anything from YANG 1.1.

If YANG 1.0 is not being deprecated then I do not see
any reason to link documents to YANG 1.1 unless they
actually use it.

Is the plan to start work on YANG 1.2 before YANG 1.1 is even published?
If so, then say so.  Let's not pretend YANG is stable
or that all new improvements after YANG 1.1 are going to be
done with extension hacks.

If the IESG and the WG had a development plan for this work,
it might help vendors decide when and what to support.


/js
>

Andy


>
> On Fri, Aug 07, 2015 at 05:41:33PM +0200, Benoit Claise wrote:
> > Dear all,
> >
> > During the YANG Model Coordination Group webex call today, we discussed
> > this oper status and structure open issues. We're ready to help
> > facilitate the discussion between the different proposals
> > We could compare the pros/cons of the different solutions from our point
> > of view.
> >
> > To allow us some preparation time, alternate proposals should be posted
> > a week before the NETMOD interim meeting, i.e. Sept 3rd.
> >
> > The YANG Model Coordination Group
> >  >
> > >The NETMOD WG will hold a series of weekly virtual interim meetings in
> > >order to resolve YANG 1.1 review comments. The meetings will take
> > >place on Mondays between 17:00-18:00 CEST. The dates for the virtual
> > >meetings are:
> > >
> > >2015-08-24
> > >2015-08-31
> > >2015-09-07
> > >2015-09-14
> > >2015-09-21
> > >2015-09-28
> > >2015-10-05
> > >2015-10-12
> > >
> > >We will use the meeting slots as needed (i.e., we may skip slots if
> > >there is nothing to resolve anymore).
> > >
> > >Additional information will be announced on the NETMOD mailing list:
> > >http://www.ietf.org/mail-archive/web/netmod/current/maillist.html
> > >
> > >/js
> > >
> >
>
> > ___
> > 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings

[Benoit Claise]

I obviously replied to the wrong email. My bad.
Let me start again

Regards, Benoit

Lets please not mix YANG 1.1 work with other discussions at this point
in time.

/js

On Fri, Aug 07, 2015 at 05:41:33PM +0200, Benoit Claise wrote:

Dear all,

During the YANG Model Coordination Group webex call today, we discussed
this oper status and structure open issues. We're ready to help
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point
of view.

To allow us some preparation time, alternate proposals should be posted
a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group


The NETMOD WG will hold a series of weekly virtual interim meetings in
order to resolve YANG 1.1 review comments. The meetings will take
place on Mondays between 17:00-18:00 CEST. The dates for the virtual
meetings are:

2015-08-24
2015-08-31
2015-09-07
2015-09-14
2015-09-21
2015-09-28
2015-10-05
2015-10-12

We will use the meeting slots as needed (i.e., we may skip slots if
there is nothing to resolve anymore).

Additional information will be announced on the NETMOD mailing list:
http://www.ietf.org/mail-archive/web/netmod/current/maillist.html

/js


___
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] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig

[Benoit Claise]

Dear all,

During the YANG Model Coordination Group webex call today, we discussed
this oper status and structure open issues. We're ready to help
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point
of view.

To allow us some preparation time, alternate proposals should be posted
a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group


Hello,
NETMOD Working Group invites you to join this WebEx meeting.

*NETMOD Interm meeting on OpenConfig*
Thursday, September 10, 2015
11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr

*Join WebEx meeting* 
 



Meeting number: 645 732 277
Meeting password:   1234

*Join by phone*
*1-877-668-4493* Call-in toll free number (US/Canada)
*1-650-479-3208* Call-in toll number (US/Canada)
Access code: 645 732 277
Toll-free calling restrictions 



Add this meeting 
 
to your calendar.


Can't join the meeting? Contact support. 

IMPORTANT NOTICE: Please note that this WebEx service allows audio and 
other information sent during the session to be recorded, which may be 
discoverable in a legal matter. By joining this session, you 
automatically consent to such recordings. If you do not consent to 
being recorded, discuss your concerns with the host or do not join the 
session.




___
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] NETMOD WG YANG 1.1 virtual interim meetings

[Juergen Schoenwaelder]

Lets please not mix YANG 1.1 work with other discussions at this point
in time.

/js

On Fri, Aug 07, 2015 at 05:41:33PM +0200, Benoit Claise wrote:
> Dear all,
> 
> During the YANG Model Coordination Group webex call today, we discussed 
> this oper status and structure open issues. We're ready to help 
> facilitate the discussion between the different proposals
> We could compare the pros/cons of the different solutions from our point 
> of view.
> 
> To allow us some preparation time, alternate proposals should be posted 
> a week before the NETMOD interim meeting, i.e. Sept 3rd.
> 
> The YANG Model Coordination Group 
> 
> >The NETMOD WG will hold a series of weekly virtual interim meetings in
> >order to resolve YANG 1.1 review comments. The meetings will take
> >place on Mondays between 17:00-18:00 CEST. The dates for the virtual
> >meetings are:
> >
> >2015-08-24
> >2015-08-31
> >2015-09-07
> >2015-09-14
> >2015-09-21
> >2015-09-28
> >2015-10-05
> >2015-10-12
> >
> >We will use the meeting slots as needed (i.e., we may skip slots if
> >there is nothing to resolve anymore).
> >
> >Additional information will be announced on the NETMOD mailing list:
> >http://www.ietf.org/mail-archive/web/netmod/current/maillist.html
> >
> >/js
> >
> 

> ___
> 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] NETMOD WG YANG 1.1 virtual interim meetings

[Benoit Claise]

Dear all,

During the YANG Model Coordination Group webex call today, we discussed 
this oper status and structure open issues. We're ready to help 
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point 
of view.


To allow us some preparation time, alternate proposals should be posted 
a week before the NETMOD interim meeting, i.e. Sept 3rd.


The YANG Model Coordination Group 


The NETMOD WG will hold a series of weekly virtual interim meetings in
order to resolve YANG 1.1 review comments. The meetings will take
place on Mondays between 17:00-18:00 CEST. The dates for the virtual
meetings are:

2015-08-24
2015-08-31
2015-09-07
2015-09-14
2015-09-21
2015-09-28
2015-10-05
2015-10-12

We will use the meeting slots as needed (i.e., we may skip slots if
there is nothing to resolve anymore).

Additional information will be announced on the NETMOD mailing list:
http://www.ietf.org/mail-archive/web/netmod/current/maillist.html

/js



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

Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01

[Juergen Schoenwaelder]

On Fri, Aug 07, 2015 at 10:40:06AM -0400, Rob Shakir wrote:
> 
> 
> Juergen Schoenwaelder wrote:
> >I assume you mean  instead of.
> >
> >/js
> Hi Juergen,
> 
> Generically, the intent here is express that it is ' path>' rather than merely 'path'. The 'some-access-method' might be a 
> reference to a particular datastore, or a certain operation within the 
> access protocol (GET vs. GET-OPER maybe).
>

Configuration data resides in configuration datastores. This is quite
deeply wired in the NETCONF and YANG specifications.

For operations on the configuration datastores, the datastore name is
passed as an argument in RPC calls. Hence, for configuration data, the
naming model is .

There have been many discussions over the years whether there should
be an explicitly named operational datastore since architecturally we
treat operational data somewhat differently. Some of this is hinted
at in section 4.3.3 of RFC 6244 and you can find also various I-Ds
that were posted in this context.

But you are right, it is not just the path that is needed to identify
data residing in configuration datastores. It is in general a tuple
 and for configuration data the selector is a
configuration datastore name.

/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] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig

[Benoit Claise]

Dear all,

Let me set the stage for this future interim.

First of (and let me repeat), I'm happy that the operators gathered and 
collectively worked on YANG models and related requirements.


The previous two interim meetings in June on the openconfig issues 
(draft-openconfig-netmod-opstate-01 
 and 
draft-openconfig-netmod-model-structure-00 
) 
were successful in the sense that the requirements are now understood.


Unfortunately, some key players were not in Prague and we could not 
finalize the discussion.
How to represent the operational state is one important guidance from 
RFC 6087bis that we must be providing to all existing and future YANG 
models (and not only in the IETF).


We need to bring closure on that topic, and this is the plan for that 
interim meeting in September.


http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has 
been updated. Please comment on this version.
Also, any alternate proposals must be prepared for that interim in 
September. They must be prepared with the same level of rigour as 
draft-openconfig-netmod-opstate., i.e. must have the same level of details.


In the meeting in September, the goal is to take a decision.

Regards, Benoit (OPS AD)


Hello,
NETMOD Working Group invites you to join this WebEx meeting.

*NETMOD Interm meeting on OpenConfig*
Thursday, September 10, 2015
11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr

*Join WebEx meeting* 
 



Meeting number: 645 732 277
Meeting password:   1234

*Join by phone*
*1-877-668-4493* Call-in toll free number (US/Canada)
*1-650-479-3208* Call-in toll number (US/Canada)
Access code: 645 732 277
Toll-free calling restrictions 



Add this meeting 
 
to your calendar.


Can't join the meeting? Contact support. 

IMPORTANT NOTICE: Please note that this WebEx service allows audio and 
other information sent during the session to be recorded, which may be 
discoverable in a legal matter. By joining this session, you 
automatically consent to such recordings. If you do not consent to 
being recorded, discuss your concerns with the host or do not join the 
session.




___
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] draft-openconfig-netmod-opstate: Changes in -01

[Rob Shakir]

Juergen Schoenwaelder wrote:

I assume you mean  instead of.

/js

Hi Juergen,

Generically, the intent here is express that it is 'path>' rather than merely 'path'. The 'some-access-method' might be a 
reference to a particular datastore, or a certain operation within the 
access protocol (GET vs. GET-OPER maybe).


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

Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01

[Juergen Schoenwaelder]

On Fri, Aug 07, 2015 at 09:59:55AM -0400, Rob Shakir wrote:
> Hi netmod folks,
> 
> Prior to the Prague IETF, Anees, Marcus and I took some time to update 
> draft-openconfig-netmod-opstate. The intent of this update was two-fold:

[...]

> The diff for this revision can be found at 
> https://tools.ietf.org/rfcdiff?url2=draft-openconfig-netmod-opstate-01.txt 
> - Appendix D provides a brief changelog.
>

   [...] That is,
   it avoids the need for an NMS to provide a  tuple to
   uniquely identify a data node.

I assume you mean  instead of .

/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

[netmod] draft-openconfig-netmod-opstate: Changes in -01

[Rob Shakir]

Hi netmod folks,

Prior to the Prague IETF, Anees, Marcus and I took some time to update 
draft-openconfig-netmod-opstate. The intent of this update was two-fold:


 * to provide clarifications of the types of data that we consider to
   exist within a YANG module. This very much reflects the discussions
   that we had both on the interim meeting calls, and subsequently on
   the list. We aimed to document the terms 'intended configuration',
   'applied configuration' and 'derived state', and record the
   relationship between them that we'd iterated on.
 o This is contained in Section 2. We would encourage interested
   parties to review these definitions to ensure that the common
   understanding that we reached has been documented.

 * add some clarifications to the requirements based on alternative
   suggestions that had been briefly mentioned during the interims.
   Particularly, it is worth mentioning:
 o Section 4.5: we added some clarification about paths within some
   of the NMS systems that we are working on.
 o Section 7: which is dedicated to covering some of the
   observations that have been made relating to the proposed
   solution. We (the authors) have tried to provide some feedback
   to some of these points (where it has been possible to do so).

The diff for this revision can be found at 
https://tools.ietf.org/rfcdiff?url2=draft-openconfig-netmod-opstate-01.txt 
- Appendix D provides a brief changelog.


Kind regards,
r.

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

Re: [netmod] new YANG 1.1 Issue Y61: I2RS support

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Thu, Aug 06, 2015 at 02:50:04PM +0200, Ladislav Lhotka wrote:
>> 
>> 
>> If there is no ephemeral data, then config data is what counts. However, if 
>> some config parameters may be overriden by ephemeral values, then a separate 
>> validation of running is not sufficient - it may be in conflict with 
>> ephemeral data.
>> 
>> I guess the purpose of semantic rules and validation is to make sure the 
>> parameters that the device uses, no matter where they come from, are correct.
>>
>
> So far, validation concerns a configuration data store, no more and no
> less. Expanding this to something different will be a major change how
> the curent protocol and its implementations work.
>
>> Of course it was. You didn’t answer my question though, so let me expand my 
>> example into the following scenario:
>> 
>> 1. The device boots, values of valid-lifetime and preferred-lifetime in 
>> running are initialized from startup to v and p, respectively, where p < v. 
>> The device sends RAs with there values, everything’s OK.
>> 
>> 2. I2RS sets the ephemeral value of valid-lifetime to v’ where p < v’ < v. 
>> The device now sends RAs with p and v’, which is still OK.
>> 
>> 3. A NETCONF client attempts to change preferred-lifetime in running to p’ 
>> where v’ < p’ <= v. Should this edit be rejected? On one hand, running 
>> continues to be perfectly valid, but on the other hand RAs with values of p’ 
>> and v’ are broken.
>
> The running config is valid. I think it is today an implementation
> issue how any conflicts with other dynamic information are resolved
> (e.g., whether the running config in this case overwrites or deletes
> the now broken ephemeral value or whether the NC server signals a
> runtime error while processing the edit-config - which would not be a
> validation error).
>
> We currently understand what a valid configuration datastore
> means. This is goodness and we should work hard to preserve this.
>
> When we add ephemeral configuration datastores, it is not clear what
> it means for them to be valid or whether we also have to think in
> addition in terms of validation of the resulting 'merged
> datastore'. Some people also wanted to allow references from ephemeral
> configuration data to operational state data, which adds another
> dimension of complexity to the picture.
>
> All I can say at this point in time is that the precise semantics of
> validation of ephemeral data are rather unclear to me. And there may
> also be a risk to define validation semantics that at the end nobody
> will implement fully because it does not scale (e.g., because it
> requires to monitor significant amounts of operational state to detect
> changes that trigger re-validation).

RFC 6241 says that running datastore contains "the complete
configuration currently active on the device". However, ephemeral
datastore is also designed to contain active (non-persistent)
configuration, and I understand it can sometimes override running so
that certain parameters in running become inactive. In other words, the
ephemeral datastore competes with running for providing active
configuration to the device. I think there have to be rules for merging
configurations from running and ephemeral, and producing configuration
that's really active on the device.

To this end, the openconfig idea of intended versus applied
configuration might be useful. We would in fact have

- running = configuration intended by NETCONF,

- ephemeral = configuration intended by I2RS,

- applied = active configuration, result of merging/arbitrating running
  and ephemeral

The intended configurations may be validated separately but it is the
applied configuration whose validity really matters.

This approach could also be generalised - an additional management
interface would just contribute its own intended configuration.

Lada


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

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

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