Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Kent Watsen]

>If there was a way that YANG patch (or equivalent) were able to return 
>both old and new values (in the same tree) then I think that would be 
>better.  I don't think that such as solution would be specific to the 
>opstate requirements and may be useful more generally.

Already the  RPC accepts an enumeration specifying the response 
format.  It seems that all that is needed is to define another enumeration for 
something like “yang-diff” that can do all you say.   We don’t have yang-diff 
today, but someone can write a draft to define it and then it can be added or 
used instead.  

Alternatively, the  RPC could be moved into a diff-draft that defines 
both the RPC and the format together.  Something like this might make sense as 
 is generally useful outside of this opstate application. 

Kent  // contributor 

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

[netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016

[IESG Secretary]

The NETCONF Data Modeling Language (NETMOD) WG will have a virtual 
interim meeting on 22 February 2016 at 10:00 EST (15:00 UTC) to discuss 
use-cases and solutions for combining YANG modules into the schema 
defined in other YANG modules, as this is a blocking item for some other 
working groups currently. The agenda for the meeting is:

5 min: agenda bashing, scribes, note well, etherpad, etc.
20 min: use-case summary (draft-rtgyangdt-rtgwg-device-model-02)
20 min: proposal #1 (draft-lhotka-netmod-ysdl-00)
20 min: proposal #2 (draft-bjorklund-netmod-structural-mount-00)
55 min: general discussion or end early

All participants should come prepared to discuss these drafts.

Note: it is understood that draft-clemm-netmod-mount is related work, 
but the chairs wish to only focus on the schema composition issue at 
this time.

Etherpad: http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222

Regards,

NETMOD Chairs

--
NETMOD Virtual Interim Meeting
Monday, February 22, 2016
4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hrs

Join WebEx meeting:
https://ietf.webex.com/ietf/j.php?MTID=me171803d3dfe83d3f0d003f8332b032f
Meeting number: 646 684 956
Meeting password: Qbds3nPZ

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: 646 684 956
Toll-free calling restrictions

Add this meeting to your calendar. (Cannot add from mobile devices.)
https://ietf.webex.com/ietf/j.php?MTID=mf4e7a67f2b45f6542947fa3464d35e05

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

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

[Juergen Schoenwaelder]

On Tue, Feb 09, 2016 at 11:17:13AM +, Robert Wilton wrote:
> 
> 
> On 08/02/2016 16:20, Juergen Schoenwaelder wrote:
> >On Mon, Feb 08, 2016 at 01:21:52PM +, Robert Wilton wrote:
> >>So, IIRC, your concern is specifically that a generic YANG client
> >>library cannot validate that the RPC reply is well formed against the
> >>schema without knowledge about the request.  Is that correct?
> >>
> >None of the existing tools that assume YANG defined data is XML
> >encoded according to RFC 6020 will not be able to process data in a
> >new encoding.
> OK.
> 
> As Lou indicates, the proposed protocol schema encoding could also be 
> generated by tooling (i.e. a pyang plugin).
> 
> I.e. a client can take the source YANG models (e.g. as defined by IETF) 
> and apply a transformation to them that would generate a set of YANG 
> models that are the same except that they have the extra applied 
> configuration nodes added to them.
> 
> An opstate aware client could use the generated YANG models to both 
> internally manage the manageability data, and also to validate that the 
> messages sent to/from the server conform with the extended schema.
>

I fail to see how on the fly schema translations makes things simpler
(and I am sure there are a number of little questions that pop up if
you really do this).

I am still waiting for the argument that convinces me that merging
datastores into a single tree makes the writing of clients orders of
magnitude simpler. If the only real technical argument is "I need to
be able to retrieve data from multiple datastores in a single RPC
operation", then lets simply define such an RPC (that works for
arbitrary combinations of datastores and not just two specific ones)
and move on. If the problem is in the existing RPC primitives, then
lets extend them instead of building hacks around them using on the
fly schema translations and what not.

/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] a few comments on draft-wilton-netmod-opstate-yang

[Kent Watsen]

[chair hat on]




>But I wonder whether the OpenConfig operators might also ask the WG the 
>same question of whether a datastore solution is orders of magnitude 
>better than the OpenConfig solution?
>
>My best guess is that at the moment they would regard a datastore 
>solution as being inferior to their current working solution (for which 
>they have models that are further ahead than IETF, running code, some 
>major vendors committed to implementing those models, and seeming more 
>interest from the large network operators in using those models).
>
>Will vendors actually implement a datastore based solution if the 
>OpenConfig operators (who are raising the requirement) don't actually 
>want/need to use it?
>
>Then I guess the final question I have is whether SDO produced models 
>will still be relevant if they lag 2 years behind the OpenConfig models, 
>and those models have become a defacto standard?

Let’s just focus on solving the engineering problem at hand.  The OC folks are 
more than welcomed to assist (seriously guys, where are you?), but let’s not 
speculate on their positions.



>>   If the only real technical argument is "I need to
>> be able to retrieve data from multiple datastores in a single RPC
>> operation"... 

I want to point out again (see [1]) that there is no requirement listed to 
return two configuration datastores in one RPC response - only the diff is 
specified as being required.  Yes, solution #1 has this ability, but that 
doesn’t translate to a requirement.   Unless we hear from operators that this 
was a missed requirement, we should not view it as such.


[1] https://mailarchive.ietf.org/arch/msg/netmod/ei_Xhnz22NoeMjlqY42DrUFGalI


Thanks,
Kent


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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Robert Wilton]

On 10/02/2016 15:46, Kent Watsen wrote:





If there was a way that YANG patch (or equivalent) were able to return
both old and new values (in the same tree) then I think that would be
better.  I don't think that such as solution would be specific to the
opstate requirements and may be useful more generally.

Already the  RPC accepts an enumeration specifying the response 
format.  It seems that all that is needed is to define another enumeration for 
something like “yang-diff” that can do all you say.   We don’t have yang-diff today, 
but someone can write a draft to define it and then it can be added or used instead.

Alternatively, the  RPC could be moved into a diff-draft that defines both 
the RPC and the format together.  Something like this might make sense as  
is generally useful outside of this opstate application.

Yes, OK.

I can easily see how a  RPC message could provide two separate 
trees, i.e. one with the values before, and a separate tree with the 
values after, but I'm not sure that such a message format would really 
be any better than the current YANG patch format.


However, the bit that I'm stuck on is that I can't see how is it 
possible to provide the data in a single tree unless you end up with an 
encoding that is broadly similar to what I have suggested in my draft, 
and several folks have strong views against any such encoding.  AFAIK, 
no alternatives have been proposed.


Rob




Kent  // contributor



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

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Mon, Feb 08, 2016 at 04:59:42PM +, Robert Wilton wrote:

> >So if in my 1 million XML elements one has not been applied, how do I
> >find out efficiently in your encoding?
> By using 'diff-cfg-only' option of the  parameter, 
> you would get 3 or 4 leaves per mismatching node: (intended value, 
> applied value, status, and optionally error reason).  Only nodes with 
> differences would be returned.
> 
> A more complete example is in 
> https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2.  
> NETCONF get-config request using with-config-state with diff-cfg-only 
> option", about page 16.
> 
> Yes, this data would be larger than the patch, but it also contains more 
> information (i.e. reason why they differ, and error string).
> 

OK. Next question: How do I get the diff between  and
? How do I get the diff between  and ?
We can try to build generic primitives or we can choose to create many
point solutions.

> The client is also able to process this data straight away.  With the 
> patch, they may need to generate the before and after values to make it 
> easier to process.

I fail to get the message, what is easier to process for a client is
largely subjective or a function of the particular client environment
or what I want to do with the data.

/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] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[Juergen Schoenwaelder]

On Mon, Feb 08, 2016 at 05:50:00PM +, Gert Grammel wrote:
> Hi Juergen,
> 
> I think the indentation in  our emails play havoc which is confusing me
> too. The key point I am making is:
> 
> The mapping of what is called intended-config onto data stores would
> deserve more detailed discussion. It seems the authors of
> draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg
> with the [running] datastore. In my understanding, a failure in applying
> [running] to [applied] will update the [running] datastore to reflect
> which part is effectively applied. So a fair representation of that case
> would be:
> [candidate] -> [running] <--> [applied] -> derived state

This is not how I understood that state of the discussions. I do not
think that the NETCONF  configuration datastore changes in
existing implementations dynamically. Does it on Junos?

> In the context of intended-configuration however that doesn’t make sense
> to me. A failure in applying intended configuration doesn¹t change the
> intention and the delta between intended and applied-config is the key
> value. A server that would "clean-up" intended-cfg in presence of a
> failure to apply would look picture perfect instead of exposing the
> problem clearly. Hence the sequence should more look like:
> [candidate] -> [intended] ‹-> [running==applied] -> derived state
> 
> Whatever we choose, I believe we need to spell out what¹s the data in a
> failure case. It¹s probably a bit late to update the requirements draft,
> but we can probably find a suitable place.
> 
> ———
> 
> 
> I am also wondring if we have the same understanding related to the
> following statement:
>   I thought the whole point of having an applied config is to be able to
> see the difference between intended (oops running) and applied.
> 
> 
> The current draft-kwatsen-netmod-opstate-02.txt says:
> "Any rollback that may occur will restore both the intended and the
> applied configurations to their previous states."

This rollback requirement is in my view broken (I assume people will
figure this out when they try to implement solutions for it). Anyway,
NETCONF today commits  to  and I do not think we
should mess around with that.
 
> The challenge I have is the term “(oops running)” in the first sentence in
> combination with the citation. I reckon that any difference between
> intended-config and applied-config shall be visible whereby the
> intended-config is provided by the client and never altered by the server.
> Applied-config on the other hand represents the state of the server. If a
> failure happens in the application phase, it shall be treated accordingly
> (rollback-, stop-, continue-on-error). As a result the difference between
> intended and applied configuration shall be maintained.
> So does this square with the notion "intended=running" and “applied”
> config?

Yes (with the caveat that the rollback requirement text is kind of
broken).

/js

> - Gert
> 
> 
> 
> 
> 
> On 2016-08-02 17:38, "Juergen Schoenwaelder"
>  wrote:
> 
> >On Mon, Feb 08, 2016 at 02:53:57PM +, Gert Grammel wrote:
> >> 
> >> 
> >> >This is not what is being proposed. We always had
> >> >
> >> >[candidate] -> [running] -> operational state
> >> >
> >> >(and I mark configuration data stores in []). Both [candidate] and
> >> >[running] have the same configuration data model. Now we are asked
> >> >to expose that [running] may not be applied synchronously and hence
> >> >
> >> >[candidate] -> [running] -> [applied] -> derived state
> >> >
> >> >seems to make sense.
> >
> >Why would that be the case? If I configure an interface that is not
> >currently present today in running this is just find and running is
> >not expected to change arbitrarily.
> > 
> >> The mapping of what is called intended-config onto data stores would
> >> deserve more detailed discussion. It seems the authors of this draft had
> >> in mind to associate intended-cfg with the [running] datastore. With
> >>that
> >> mapping, a failure in applying [running] to [applied] will update the
> >> [running] datastore to reflect which part is effectively applied. So a
> >> fair representation of that case would be:
> >> [candidate] -> [running] <--> [applied] -> derived state
> >
> >What is 'this draft'? I thought the whole point of having an applied
> >config is to be able to see the difference between intended (oops
> >running) and applied. I am confused now.
> > 
> >> In the context of intended configuration however that doesn¹t make sense
> >> to me. A failure in applying intended configuration doesn¹t change the
> >> intention and the delta between intended and applied-config is the key
> >> value. A server that would "clean-up² intended-cfg in presence of a
> >> failure to apply would look picture perfect instead of exposing the
> >> problem clearly. Hence the sequence should more look like:
> >> [candidate] -> [intended] ‹> [running==applied] -> derived state
>