Re: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [RTG-DIR] handling module incompatibility => handling module transition

[Rob Shakir]

I agree that semantic versioning is only part of the solution. In
OpenConfig versioning we have the concept of release bundles that have a
semver, these contain modules that are known to work together - and are the
base for compliance descriptions. The individual modules semver has been
useful to mark where there are backwards incompatible changes in an
individual module.

On top of release bundles, we also have feature bundles which describe a
particular implementation's requirements for the modules. A feature bundle
is a description of paths within a release bundle.

We're continuing to gain experience with how well this works, but certainly
I don't see the need for the bundles alleviating the need for the semantic
versions for modules.

r.

On Fri, 3 Nov 2017 at 11:05 Andy Bierman  wrote:

> On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> My take here is that structured version numbers do only partially
>> solve the problem. Andy's work years ago on packages offers in my view
>> a superior foundation for a solution. Once we can bundle modules that
>> are designed and known to work together into meaningful packages, then
>> it may be possible to relax some of the strict RFC 7950 update
>> rules.
>>
>> Once the NETMOD WG gets the work on NMDA "completed", I believe "YANG
>> packages" are a worthwhile target to work on. There is a need to get
>> more structure into the module space, not just additional structured
>> version numbers.
>>
>>
> I agree ;-)
>
> It is nice to have a way to know current implementations will probably
> break if they upgrade to the new version. It is even nicer if the APIs
> are stable and don't break existing code.
>
> It is not encouraging that the IETF cannot produce stable YANG modules
> published in RFCs.  We expect I-Ds to ignore the YANG update rules,
> but not RFC versions.
>
> Since the semantic versioning is only per-module, it is not usefull for
> determining if module foo will work with module bar.  If it is OK
> to break backward-compatibility then it will become increasingly
> difficult to just use the latest version of a module. Real interoperability
> at the granularity of modules will become more difficult. YANG packages
> can dramatically reduce the number of API permutations.
>
>
> /js
>>
>
>
> Andy
>
>
>>
>> On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:
>> > Dear all,
>> >
>> > Let me present this draft
>> > https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
>> >
>> > New YANG Module Update Procedure
>> > draft-clacla-netmod-yang-model-update-01
>> >
>> > Abstract
>> >
>> >This document specifies a new YANG module update procedure in case of
>> >non backward-compatible changes, as an alternative proposal to the
>> >YANG 1.1 specifications.  This document updates RFC 7950.
>> >
>> >
>> > Problem statement:
>> > Changing a YANG module name each time there is a non backward compatible
>> > change (as RFC7950 requires) adds a lot of complexity to automation,
>> from an
>> > import and service composition point of view.
>> >
>> > Solution:
>> > We need a different mechanism. The solution in the draft is based on the
>> > semantic versioning YANG extension: it was proposed openconfig in the
>> past
>> > and is currently used by the openconfig YANG modules
>> >
>> > Note: there might other solutions, such as new YANG keywords, but at
>> this
>> > point in time, it's important to recognize that we need to change the
>> way we
>> > produce YANG modules at the IETF. Let's discuss on the list and during
>> the
>> > NETMOD meeting.
>> >
>> > Regards, Benoit.
>> > > On 10/12/2017 3:30 PM, Benoit Claise wrote:
>> > > > Hi Lou,
>> > > > >
>> > > > > So circling back to the original question: what do we do about
>> > > > > the non backward-compatible module being defined in rfc8049bis?
>> > > > >
>> > > > > While being sympathetic to many of the comments made below as
>> > > > > well as the "do over" concept, I find the comments about
>> > > > > adhering to the rules of 7950 compelling - which leads to
>> > > > > renaming the module in the bis to ietf-l3vpn-svc-2.
>> > > > >
>> > > > > It would be good to ensure that this is the consensus of the
>> > > > > group before asking the authors make this change.
>> > > > >
>> > > > Since this draft is AD sponsored, I'll evaluate the consensus on
>> > > > RFC8049bis.
>> > > > Moving to ietf-l3vpn-svc-2 is the easy path not to break backward
>> > > > compatibility. However, since ietf-l3vpn-svc is unimplementable (it
>> > > > has broken XPATH expressions, so a compliant implementation is
>> > > > impossible), so technically, ietf-l3vpn-svc does not even exist.
>> > > See my message on this topic, as the IETF LC follow up.
>> > >
>> https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html
>> > > If a follow up is required, I propose that we use a single 

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Rob Shakir]

Hi Kent, NETMOD,

On Fri, Aug 26, 2016 at 10:54 AM, Kent Watsen  wrote:

>
>
>
>
> Please indicate your support or concerns by Thursday September 9, 2016.
>
>
>
> We are not only interested in receiving defect reports, we are equally
> interested in statements of the form:
>
>
>
>   * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
>
>   * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
>
>   * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
>
>   * I am considering to implement the data model in
> draft-ietf-netmod-routing-cfg-23
>

I'd like to add a new category to this set of statements:

 * I have reviewed this draft, and will *not* be implementing the data
model described within it.

I have concerns with the contents of this model and their suitability as a
base for the wider set of models that are intended to augment it. Indeed, I
think the elements that it tackles (e.g., arrangement of protocols within a
routing instance) are very much lowest common denominator, and none of the
wider issues around multi-tenancy of routing instances (especially those
that mix VSI and VRF type semantics) on an individual device, or the way
that protocols map to RIBs, and how they then interact/interconnect are
tackled within the model.

Whilst I understand the difficulties that the authors have been through to
try and find a solution, I'm afraid that consensus here has led to a model
that actually is operationally a no-op -- even the configuration for static
routing is not sufficient for most operator use cases that we have examined
when working on a similar problem space.

Based on this, and the lack of examination of real configurations of
network elements to the model described within the draft, I would oppose
progressing this model to RFC until such time as it has been proved to
cover a operationally viable set of functionality, and there can be any
level of confidence that further changes to the model will not be
immediately needed to be able to accommodate the use cases that are
required of it.  Given the historical opposition to revising models once
they have been cast as RFCs that we have seen within the IETF, then I feel
that avoiding incomplete models going to RFC is the best course of action.

Thanks,
r.

[0]: Please note: I am speaking as an individual here, not on behalf of any
wider set of view points.
[1]: Please further note: This opposition to publishing this document
completely ignores the issue of operational state. I have made my thoughts
clear on this previously, but these comments are entirely orthogonal to
that opposition.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Rob Shakir]

Balazs,

> On 2 Aug, 2016, at 10:29 AM, Balazs Lengyel  
> wrote:
> I prefer a tight definition so even if we allow both 1) and 2)  we should 
> state that other combinations e.g. trees spliting close to the leaves or a 
> mix of 1) and 2) in the same module are not allowed (VER STRONGLY 
> discouraged). 

What is the motivation for this very strongly discouraged statement? The 
problem I take with this is that you are not only getting zero consistency that 
will let a user determine how a model might look  (painful for those actually 
*using the models* rather than writing them - who are hugely under-represented 
in this discussion), but you’re also throwing out a bunch of models (both 
inside and outside of the IETF) at the same time.

Apologies to pick specifically on this email, but I have still yet to see any 
justification why anything other than a solution that is already being 
implemented is preferable to this WG other than it seeming like the WG doesn’t 
like the aesthetics of the modules in this case.

I am soon going to shut up on this topic, but it’s quite frankly lamentable 
that such a division is being created with no reasonable justification.

Note that the statement that Benoit/Lou/Kent made in Berlin related to applied 
config - the structure that is being objected to can be trivially implemented 
without those leaves if one wanted to.

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

Re: [netmod] derived-from-or-self leads to circular import

[Rob Shakir]

> On Jul 29, 2016, at 07:32, Juergen Schoenwaelder 
>  wrote:
> 
> I think moving the definition of entity-physical-class into
> iana-entity makes sense. Perhaps this is generally a good pattern to
> follow for base identities for which IANA maintains derived
> identities.  The required import should not be a problem; the
> ENTITY-MIB also imports from IANA-ENTITY-MIB.

I would be supportive of changes that make IANA maintained registries 
self-contained. It seems to me that this would reduce overall overlap between 
modules.

For example, right now, iana-if-type uses ietf-interfaces to define 
interface-type. This means that third-party modules cannot exploit the IANA 
registry without also including the IETF module. This does not seem ideal if 
one simply wants to ensure that the registry can be used.

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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Rob Shakir]

> On 26 Jul, 2016, at 9:52 AM, Robert Wilton  wrote:
> 
> What other alternatives are available?  As a WG we need to tell the other WGs 
> how the IETF YANG models should be structured.

An interested observer could note that the convention that was described in the 
initial OpenConfig proposal had objections to it based on the fact that it 
required models to be written in a certain way. Although this way is 
prescriptive, and could be observed to cause some pain to the model writer 
(albeit limited), it has a number of advantages in terms of being very 
deterministic as to how the model should be structured, allowing leaves to be 
easily related to each other, and can be programmatically verified.

It seems to me like the working group is trying to have its cake and eat it — 
that is to say, get these advantages without being prescriptive to the model 
writer. It is not clear to me that this is actually achievable.

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

Re: [netmod] Plans for draft-openconfig-netmod-model-catalog

[Rob Shakir]

Hi Lou,

We’re currently working to rev the model that it describes - there are some 
issues we’ve come across when trying to utilise it - and define bundles of the 
models that it defines. I expect that once this work has been done we’ll rev 
the draft.

None of the authors will be at the IETF mtg, so we did not request any time to 
cover this — but this is an actively interesting, and used model.

Cheers,
r.


On 30 March, 2016 at 10:48:05 AM, Lou Berger (lber...@labn.net) wrote:

Authors,  
Just wanted to check in with you on your plans for this document.  
My understanding is that the WG expressed some interest in this work  
when last presented. What are your plans for this work?  

Thanks,  
Lou (and Kent)  


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

Re: [netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08

[Rob Shakir]

Thanks Lada and others for the responses here. Much clearer to me.

r.


On 4 March, 2016 at 5:05:03 AM, Ladislav Lhotka (lho...@nic.cz) wrote:

Hi Rob,  

Rob Shakir <r...@rob.sh> writes:  

> Hi NETMOD,  
>  
> I am in the process of implementing draft-ietf-netmod-yang-json–08, and had 
> some queries as to the content. Hopefully there is some misunderstanding on 
> my part, or it helps to clean up the text for future people 
> reviewing/implementing.  
>  
> The phrase ‘namespace-qualified’ seems to have some ambiguity through the 
> document. For example, in the case that we have two modules:  
>  
> module mod-a {  
> prefix "pfx-a";  
> namespace "http://a.tld;;  
>  
> container container-a {  
> leaf leaf-a {  
> type string;  
> }  
>  
> leaf ref-a {  
> type identityref {  
> base SOME_IDENTITY;  
> }  
> }  
> }  
> }  
>  
> module mod-b {  
> prefix "pfx-b";  
> namespace "http://b.tld;;  
>  
> container container-b {  
> leaf leaf-b {  
> type string;  
> }  
>  
> leaf ref-b {  
> type identityref {  
> base SOME_IDENTITY;  
> }  
> }  
> }  
> }  
> Then, AIUI, the encoding needs to specify the names of the modules for  
> both container-a and container-b (since they sit at the  
> root; and are in different namespaces) - so we encode  
> these as JSON objects named mod-a:container-a and  
> mod-b:container-b as per Section 4 of the document.  

Correct.  

>  
> In this case, we never use the actual namespace (i.e., http://a.tld  
> and http://b.tld) so calling it ‘namespace qualified’ appears  
> ambiguous. Should it be simply referred to as ‘module-qualified’?  

Namespaces (= sets of names) as defined by YANG are  
encoding-independent. However, XML and JSON use different namespace  
identifiers. XML uses naturally the mechanism of [XML-NAMES], i.e. namespace 
URIs  
and references via declared prefixes. JSON in general doesn't support  
namespaced member names, but we could conveniently use the module name  
as the namespace identifier. So this is what Sec. 4 defines:  

The name of a module determines the namespace of all data node names  
defined in that module. If a data node is defined in a submodule,  
then the namespace-qualified member name uses the name of the main  
module to which the submodule belongs.  

This is then later extended to other named entities such as identities.  
>  
> Secondarily, the example in Section 6.8 does not actually use the name  
> of the module, it rather uses the prefix (if for the interface-type  
> leaf). This doesn’t seem to be explained anywhere within the text. Is  
> this a mistake?  

No, it's correct. YANG adopted the XML namespace rules, so declared  
prefixes are used in YANG modules. The JSON-encoded name of the identity  
uses the rules of the yang-json document, i.e. module name as the  
namespace identifier.  

> It seems to me that using the module name consistently throughout the  
> encoding is preferable, since this cannot be different in a number of  
> places; and isn’t as long as the namespace value to make readability  
> worse.  

Module name is used consistently in JSON encoding, but we have to use  
YANG rules when dealing with YANG modules.  

It is somewhat confusing but I believe this is the best solution we  
could come up with.  

>  
> I also didn’t understand why an identityref value encodes the  
> namespace in the actual value? It seems like the “base” of the  
> identityref should qualify all possible values here; with the only  
> case that we would ever need this is one where we have:  

I think Per explained this part nicely.  

Thanks, Lada  

>  
> leaf some-reference {  
> type union {  
> type identityref {  
> base "a";  
> }  
> type identityref {  
> base "b";  
> }  
> }  
> }  
> And a and b both define a value with the same name (where one needs the 
> prefix to be able to refer to the b version).  
>  
> Thanks,  
> r.  
> ___  
> netmod mailing list  
> netmod@ietf.org  
> https://www.ietf.org/mailman/listinfo/netmod  

--  
Ladislav Lhotka, CZ.NIC Labs  
PGP Key ID: E74E8C0C  
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08

[Rob Shakir]

Hi NETMOD,

I am in the process of implementing draft-ietf-netmod-yang-json–08, and had 
some queries as to the content. Hopefully there is some misunderstanding on my 
part, or it helps to clean up the text for future people reviewing/implementing.

The phrase ‘namespace-qualified’ seems to have some ambiguity through the 
document. For example, in the case that we have two modules:

module mod-a {
prefix "pfx-a";
namespace "http://a.tld;;
 
container container-a {
leaf leaf-a {
type string;
}
 
leaf ref-a {
type identityref {
base SOME_IDENTITY;
}
}
}
}

module mod-b {
prefix "pfx-b";
namespace "http://b.tld;;
 
container container-b {
leaf leaf-b {
type string;
}
 
leaf ref-b {
type identityref {
base SOME_IDENTITY;
}
}
}
}
Then, AIUI, the encoding needs to specify the names of the modules for both 
container-a and container-b (since they sit at the root; and are in different 
namespaces) - so we encode these as JSON objects named mod-a:container-a and 
mod-b:container-b as per Section 4 of the document.

In this case, we never use the actual namespace (i.e., http://a.tld and 
http://b.tld) so calling it ‘namespace qualified’ appears ambiguous. Should it 
be simply referred to as ‘module-qualified’?

Secondarily, the example in Section 6.8 does not actually use the name of the 
module, it rather uses the prefix (if for the interface-type leaf). This 
doesn’t seem to be explained anywhere within the text. Is this a mistake?

If it’s not (and one could encode container-a and container-b above as 
pfx-a:container-a and pfx-b:container-b), then how do we deal with this case:

module a {
import b { prefix "c"; }
 
leaf id {
type identityref {
base "c:SOME_IDENTITY";
}
}
}

module b {
...
prefix "b";
...
}
when we encode, if we’re just given a value, do we add the prefix that a uses 
to import b, or the prefix that b defines itself? (If the prefix is used for 
identityref values, then the same question exists for those values - today, one 
must track all prefixes that are related to a certain identity value based on 
different imports, such that one does not incorrectly reject some 
prefix:identity statement that was valid).

It seems to me that using the module name consistently throughout the encoding 
is preferable, since this cannot be different in a number of places; and isn’t 
as long as the namespace value to make readability worse.

I also didn’t understand why an identityref value encodes the namespace in the 
actual value? It seems like the “base” of the identityref should qualify all 
possible values here; with the only case that we would ever need this is one 
where we have:

leaf some-reference {
type union {
type identityref {
base "a";
}
type identityref {
base "b";
}
}
}
And a and b both define a value with the same name (where one needs the prefix 
to be able to refer to the b version).

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

Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification

[Rob Shakir]

On 14 September 2015 at 08:43:53, Benoit Claise (bcla...@cisco.com) wrote:

> Re-reading this section 4.5, I understand 6A and 6C, but is 6B also
> required?
> Do we need to make the link between a config node and all the derived
> counters/statistics it influences, which might be in different YANG
> models btw?

Yes - we need to deterministically retrieve, for a particular configuration 
object (e.g., interface, BGP peer) the set set of derived state nodes 
associated with it, such that we do not need to maintain complex mapping tables 
on the client side for this - and can efficiently query the server for them.

For instance, knowing that we configured a BGP peer at 
$SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/config/{leaf-set} 
then we would find the counters at 
$SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/state/ - allows us 
to (based on the fact that we just configured a peer) retrieve the state and 
counters that a client application will likely want to check without having to 
map to some other (set of locations).

Note that in previous discussions, it was expressed that this implied that the 
model had knowledge of how the protocol operates such that it was known that 
leaf A corresponding to some other derived-state leaf B. However, this isn’t 
true. As I expressed before, the intention is that it is possible for a NMS 
layer to easily retrieve the set of state objects that an interested client may 
require, without many disparate queries, based on the configuration path. The 
actual meaning may be completely unknown to this layer.

The openconfig-opstate approach allows state and config to be defined in 
separate modules - since the ‘state’ module in this case can simply augment the 
relevant ‘state’ containers within the config model.

Regards,
r.

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

Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01

[Rob Shakir]

Benoit,

I want to pick up on this very specific point. I think Lou’s mails imply a 
similar position, but I want to be clear.

On September 10, 2015 at 04:40:30, Benoit Claise (bcla...@cisco.com) wrote:
> > A common architecture includes a central configuration data  
> store that is being updated by the manageability framework and  
> updates read by the subsystems affected by the change (e.g. the  
> BGP service or the interface manager). In this case, there is  
> no other source of configuration except for the content of the  
> data store.

The configuration file/‘store’ of a system shows the intent of how that system 
should be configured. We can agree that all implementations need to have this.

The applied configuration is the value of those configuration elements a 
daemon/software component/programmable memory is actually running, which can be 
compared to the intent. Essentially, this is *dynamic* information which is the 
*state* of the running system. Implementations *do* store this. I think the 
point that you are making here is not that it is not supported. The point is 
that it is dynamically built at query time, according to a different schema.

This different schema is bad news, programmatically. How did I know that the 
static (IOS-alike configuration):

router bgp 65497
 neighbor 192.0.2.1 remote-as 65500

Needs me to run:
 
show bgp ipv4 unicast neighbor 192.0.2.1 | i remote AS

and then run a regexp that extracts the following AS number after the words 
‘remote AS’. Today - I probably need to write a mapping table that tells me 
that.

The requirement is that we can determine, for a particular leaf - what the 
intended value is, AND the value which is applied, PLUS be able to “easily” 
retrieve the state associated with that construct - in a way that is 
deterministic, and does not require per-leaf mapping tables to be maintained 
like we might have to today.

The point about identical values is that *in cases where no such retrieval of 
the actual applied config values is possible* a system can simply make all the 
applied leaves pointers to the intent. This would be akin to the ‘show’ command 
doing the equivalent of ‘show running-config | i 192.0.2.1.*remote-as’ and 
extracting the remote-as from there AFAICS.

Regards,
r.



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

Re: [netmod] Motivations for Structuring Models

[Rob Shakir]

Hi Martin,

Thanks for the reply.

Martin Bjorklund mailto:m...@tail-f.com
August 28, 2015 at 02:33
So the idea is that this structure is defined in one module,
ietf-something-structure, right?

And then different oam protocol modules augment this structure?

How does this help you find the modules that augment this structure?
Yes, this is the intention. By then generating the tree of the overall 
structure, then I can see what different containers are created there. 
It's not perfect (and hey, this suggestion is a *draft* for a reason - 
but yet again, there are not alternatives) - but the fact that the 
modules augment a common path adds some information that they are 
grouped to providing the same functionality, not disparate. ietf-routing 
does the same thing, it gives me the fact that at 
/routing/routing-instance/routing-protocols there are a bunch of 
control-plane protocols that are related to routing.

“Just read through the modules” is not acceptable answer when
considering making things easy to use for YANG model consumers.

But how does the top-level node /device (sorry, but I really have to
ask this) solve this problem?  I *really* do not understand this.
Even with your solution you'd have a set of modules that augment this
structure, right?  How do I know what these other modules are?

You didn't answer this question.  So I repeated it above and below ;)
Right. There was really a reason NOT to answer it. /device is 
irrelevant. It does not matter - it is simply how *this proposal* 
chooses to group things, based on the fact that we think that operators 
logically configure devices when dealing with these models. From your 
comments on NCS below, it seems to me that if we'd made this a list, 
then there'd be significantly less concern? I just can't understand why 
this is something to get hung up on. If /device isn't the right root, 
please show me what is - and WHY it's better.


Structuring configuration and operational around some idea that all the 
configuration belongs to a physical device seems very, very logical to 
me. Further defining groups so that we have an understanding of how to 
build a coherent set of models for the functionalities required of that 
device seems a very clear next step after this.

Thanks, this is what I remember you mentioned in Dallas.

But what does this really mean?  Are you proposing:

   1)  to define one model ietf-something that contains this proposed
   structure, which then other modules augment?

   2)  to define one single ietf model, period.  no augments by the
   ietf.

   3)  to define the structure more loosely in text, and use this
   structure when new models are developed?

   4)  something else?
As part of iterating on this idea, we are working to understand the 
practicalities of (1). This is exactly the approach that ietf-routing is 
taking for routing protocol modules.

The layout of the sets of functions that we have, and how they are
grouped, is the important thing. The fact that we are configuring a
device makes /device a good starting point. I think this is how you
implemented NEDs in NCS too...?

No, each NED (device) is modelled according to its native model.  So
for example the IOS NED has /interface, /ip, /xconnect, etc.

But, as I have said before, the device abstraction is really
important - in the NMS/OSS/controller/whatever.  There we have a list
of devices, and each device has a name and meta-data and then its real
data, so for example we can have:

/devices/device[name='rtr4']/ip
/devices/device[name='rtr4']/port

and then we put all data models from the device under a common
container 'data':

/devices/device[name='rtr4']/data/interface/
/devices/device[name='rtr4']/data/xconnect/

If the device had a top-level container device this would have been:

/devices/device[name='rtr4']/data/device/interfaces
This approach *DOES* logically structure configuration around the 
concept of a device. If we are really just debating whether 
/devices/device is a list or whether it's a container, I'm even more 
confused than I was before. Please see my earlier comment.


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

Re: [netmod] Motivations for Structuring Models

[Rob Shakir]

Hi Andy,

I’m struggling with this debate.
On August 27, 2015 at 13:59:55, Andy Bierman (a...@yumaworks.com) wrote:


Sorry -- are you suggesting that maybe /device adds no value beyond /?
If so, I agree.
No, I am suggesting that should understand what the alternatives to solving 
issues are, before moving on to debating the merits of a particular solution 
that has nothing to compare and contrast against.

One container does not add value, the structure (which happens to start with 
/device in ONE proposal, to which there are no alternates) is what matters. 
Unfortunately you seem to be stuck on this container. Please ignore it and 
focus on the problems I defined.

 RTFM
Great. So, I need to go and write a bunch of different implementations of how 
to set up a ping, and trawl through a huge number of roots to find things that 
are related. If this is the approach we take with IETF modules, then they will 
be worse to use than the existing configuration approaches that we have. At 
least the vendor specific ones have some form of logic as to how they are 
usable to consumers.

2) As a creator of YANG models, how do I know the targets for references such 
that I capture references to the elements that I want, given there is no 
currently defined structure?

The modules you are using have data locations defined.
In order to define YANG data (with YANG 1.0 or 1.1)
a top-level data node or augment-stmt will be present specifying the 
/path/from/root

How do you know where data is that has not been defined yet?
You don't and YANG has no ability to reference undefined data anyway.
Consider VRRP ‘tracking’. I want to be able to add some form of new thing that 
VRRP might track. If we’ve defined a structure that says that there is some 
list of ‘tracking-objects’ that I can leafref to, then my new OAM mechanism can 
augment there. If there is no such structure, then we cannot do that, and 
rather the VRRF model only leafrefs to the currently known paths (my ‘track’ 
leaf has explicit leafref to a subset of ‘ping’ and known continuity checks 
when I wrote the module). Adding the new OAM mechanism then means a new version 
of the VRRP module - which seems suboptimal. The first approach is cleaner, but 
needs someone to define the structure such that we get it right.

Nothing whatsoever is stopping the routing area from defining some structure
for new modules.  Pick whatever you like.

The only pushback is wrt/ obsoleting existing RFC modules and moving the
data nodes in them to a different location. Some of us do not agree that
a problem has been demonstrated that warrants starting over for these RFCs.
Defining structure with arbitrary subsets of the tree doesn’t help! As an 
operator I want to be able to configure a device, because this is what my 
network is built from. Not IETF areas.

Do you suggest that the existing models are placed as a constraint on any new 
work in YANG? If so, I’d be grateful if you can point out to me what the 
precedent is to show that they are useful in the real world?

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

Re: [netmod] Motivations for Structuring Models

[Rob Shakir]

Hi Lada,

Thanks for the reply.
On August 27, 2015 at 11:21:18, Ladislav Lhotka (lho...@nic.cz) wrote:

This one is actually easy to explain, exactly as the top-level container 
interfaces in ietf-interfaces: it is a courtesy to XML encoding. 
Apologies, I’m not sure my question was clear enough. The point was, why do we 
need a model that defines a structure for routing if one that defines a 
structure for device is not useful?

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

Re: [netmod] Motivations for Structuring Models

[Rob Shakir]

Hi Andy,

On August 27, 2015 at 14:48:58, Andy Bierman (a...@yumaworks.com) wrote:

Did you really think that just because we created a nice DML that
somehow you would not need to know about the topic of your YANG module?
I actually have heard this complaint from some people.  Great.  How does
YANG help?  I still have to be an expert in MPLS to write a YANG module
that manages MPLS.  Yep.  That's right.  Nothing in YANG helps you
know more than you do now about specific networking technologies.
No, I didn’t at all.

So, I work operating networks, and the surrounding systems that we use to 
manage them. I could consider myself to have some knowledge in the various 
areas that I’m trying to model right now - and am even luckier to be able to 
work with a bunch of folk who have also operated different networks, such that 
we can figure out how things should be laid out. So, we’re writing these 
modules - and you’ll see them here: 
https://github.com/YangModels/yang/tree/master/experimental/openconfig

What I am saying is that as the person looking at how to /actually use/ these 
modules, it is much, much easier for me if I can have some idea of where to 
find things that I know are related, and have some consistency in the approach.

The group of people that are writing these modules noted the need for us to 
have some structure. However, the IETF is also writing a bunch of modules, 
which we figure it’d be super-neat if we can use.

So we wrote some conventions, one is a structure; the other is an approach for 
how opstate is modelled.

From your mail, I think that you are saying that you don’t care how we do this. 
If that’s the case we’ll head off and write our modules.

However, there are two discrepancies:

Lots of others in the IETF are writing models, and we’d like all these to 
combine to be usable. To do this, we need to agree on a structure. NETMOD 
looked like the place to do this based on the fact that 
draft-ietf-netmod-routing-cfg is a NETMOD draft. So we brought them here. 
Your objection is based on a specific subset of models that have already been 
created, that you assert will still need to exist. This is then counter to the 
fact that I can go and model things how I like. Again, it seems like raising 
the issues that we have with these models in context of a structure should be 
something raised with NETMOD, given that these documents are the output of 
NETMOD according to the data tracker.
There are really two options:

a) NETMOD does not care about how models fit together - because their contents 
are arbitrary. If this is the case, fine, I’ll talk with the area directors as 
to where we should propose these approaches such that the pan-IETF models end 
up working nicely together within the DML that this group has defined.
b) NETMOD does care, and should try and define a structure because it is the 
custodian working group for YANG and YANG models.

I think a lot of my problems are solved by having a defined structure for 
models, that has been worked through by folks with protocol knowledge, and 
knowledge of how these elements are used and managed. I would like it to be 
adopted by the IETF. My view is that b) is currently true - and hence it was 
brought to NETMOD.

At the moment, I can’t reconcile the apparent disparities between your 
statements in this mail and your objections in other messages. Further to this, 
I still cannot see any alternative to the structure that we did define - so 
whilst I can remove /device from the start of the path, which ‘protects’ 
/interfaces [0] - this doesn’t actually help me progress anything. This is why 
“/device or not” is irrelevant.

r.

[0]: Note that actually, some work to refactor 7223 further to just its path 
has been done… 
https://github.com/YangModels/yang/tree/master/experimental/openconfig/interfaces
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Motivations for Structuring Models

[Rob Shakir]

Martin,

Apologies, I switched to a new client and, wow, yes, it's not readable. 
I reported a bug and switched clients again... I *hope* this one is more 
readable (and it was when I checked last).


I'll put aside questions of whether the questions I'm asking are 
completely fair. Apologies. They're written from my perspective of 
problems I'm actually experiencing.

Martin Bjorklund mailto:m...@tail-f.com
August 27, 2015 at 15:45
1) As a consumer of YANG models, how do I identify the set of models 
that provide a set of functionality?


I think that neither your proposed solution or what we have today (7
published modules) solves this problem.
I respectfully disagree. By defining some form of structure for the 
models, I can have a logical grouping that gives me some pointers as to 
where to find the right things that I need. I want to configure OAM, 
great, let's go look at 
/device/logical-network-elements/logical-network-element/network-instances/network-instance/oam-protocols 
- because that's where all OAM stuff happens to live. If I have to 
rather look through / to find a subset of some ping functionality in one 
module, and some in another, it's not clear to me how I even start to 
find the right thing - because at the moment one type of ping lives in 
one module, and another in a completely different one, even though 
they're almost identical in terms of management plane interface.


I agree, an alternative is that one can have something that has a 
registry that defines sets of functionality, and we then need to define 
the 'blocks' of functionality that we need (hey! this looks a lot like 
some definition of a set of modules!). If this is a better solution, 
yes, please, propose it. The way that we proposed in 
openconfig-model-structure tries to have a way that you can not have a 
single model code-block and pull in different logical sub-modules, but 
know where to find the functionality you need.

How do YANG model writers
ensure that their models are as easy to deal with as possible by
having consistent modelling approaches for config?


Hmm, your question contains the answer; that's cheating ;-)

Shouldn't the question be:

   How do YANG model writers ensure that their models are as easy to
   deal with as possible?

The answer to this one is the same as to the question how do a C
programmer ensure that his program is as easy to deal with as
possible?
How do I write code that is generally easy to deal with? Follow 
conventions that generally tell me where to put stuff, and how to name 
it. What I don't understand is why model-structure or opstate is 
actually different to defining such conventions?

2) As a creator of YANG models, how do I know the targets for
references such that I capture references to the elements that I
want, given there is no currently defined structure?


Again your question is biased...  shouldn't it be:

   As a creator of YANG models, how do I know the targets for
   references such that I capture references to the elements that I
   want?

And the answer to this one is the same as to question 1 - I don't
think your proposal solves this, and the solution is that you need to
find these other modules.
Structure really helps me here, since when someone creates a module that 
wants to reference a particular type of function, then we reference a 
well-known path for that. If someone adds a function of that type, it 
must sit in that path so it can be referenced. See the VRRP example I 
wrote out before.

“Just read through the modules” is not acceptable answer when
considering making things easy to use for YANG model consumers.


But how does the top-level node /device (sorry, but I really have to
ask this) solve this problem?  I *really* do not understand this.
Even with your solution you'd have a set of modules that augment this
structure, right?  How do I know what these other modules are?

Now, I should add that the way I see your solution is a YANG module
that defines a structure of NP-containers.  You (or was it Anees?)
then mentioned that we shouldn't focus so much on the *YANG module*;
it was the structure that was important.

First off, we drew a picture [0] that showed the set of modules that we 
figured we might need. These break down into various bits of device 
functionality. To make this more accessible as something that could be 
shown in a draft, we expressed it in YANG and used pyang to draw out the 
tree.


The layout of the sets of functions that we have, and how they are 
grouped, is the important thing. The fact that we are configuring a 
device makes /device a good starting point. I think this is how you 
implemented NEDs in NCS too...?


Cheers,
r.

[0]: http://rob.sh/files/model-structure.pdf

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

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

[Rob Shakir]

Martin,

To be clear -- I'm not proposing any changes to YANG or NETCONF. I was 
merely trying to write down the discussion that we had on one of the 
interims about ways that 'datastores' may be considered by some 
implementations, particularly as this view can mean that they might be 
able to ignore them - based on the current ones that are implemented.


Martin Bjorklund wrote:

Even if we had the four separate datastores 'startup', 'running',
'candidate', and 'applied', it is not entirely clear to me why the
datastore would have to be carried together with the path internally
all the time.  (We do not carry the current datastores in our system
today).   Maybe this is an implementation issue?
Sure, it does not have to be carried all the time, but is /is/ required 
in some cases. If one wants a standardised 'path' format to be passed 
between systems then there's going to need to be space for the 
'datastore' to be carried in path references that are handed about (even 
if there is a 'default' datastore). I, for one, would find it messy if 
there needs to be context specific ways of handling what a path looks like.


I find the fact that there can be ambiguity for a certain path something 
that is quite different from all other systems, and hence consider it to 
be suboptimal when compared to having a unique path to a particular set 
of data. Having a path that can result in different values being 
returned seems fragile.


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

[Rob Shakir]

Juergen Schoenwaelder wrote:

I assume you meandatastore, path  instead ofRPC-call, path.

/js

Hi Juergen,

Generically, the intent here is express that it is 'some-access-method, 
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] Follow up on the openconfig oper status and the NETMOD interim

[Rob Shakir]

On 25 June 2015 at 09:35:19, Martin Bjorklund (m...@tail-f.com) wrote:


So can you give an example of when the commit would hang until a 
dependency have been fulfilled? 
In cases where there is another “commit” ongoing from another user, and this 
must complete before it is possible to apply this set of intended state.

Thanks,
r.___
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 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 r...@rob.sh 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 commit /) then the
ok / 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

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 kwat...@juniper.net 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 + actualization = 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] 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 commit /) then the ok / 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