Re: [netmod] comments on revised-datastores-00

[Juergen Schoenwaelder]

On Wed, Nov 16, 2016 at 12:34:36PM +0900, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> >> Juergen Schoenwaelder  writes:
> >> 
> >> > On Mon, Nov 14, 2016 at 11:23:04AM +0900, Ladislav Lhotka wrote:
> >> >> Hi,
> >> >> 
> >> >> I've read the revised-datastores-00 document, in general I like it, here
> >> >> are my initial comments and questions:
> >> >> 
> >> >> 1. Even if  is valid, it can still be in conflict with the
> >> >>actual content of  that may come from e.g. dynamic
> >> >>configuration protocols. How are such cases supposed to be resolved?
> >> >
> >> > Yes. The whole idea is to expose these potential differences instead
> >> > of hiding them behind a curtain.
> >> 
> >> That's fine but it doesn't answer my question.
> >>
> >
> > Then I do not understand the question. What does it mean for a
> > datastore to be in conflict with a different datastore?
> 
> For example:
> 
> - the data model has a choice with caseA and caseB. A NC/RC client
>   configures caseA,  is valid, but  already contains
>   caseB configured by a "dynamic configuration protocol"; or
> 
> - a leafref refers to a leaf that exists in  but not in
>   .

It could be that  just did not get applied yet. It may also
be that some mechanism simply overruled what  wanted to
have. The whole reason we talk about these different datastores is to
be able to expose differences that may exist.

> >> >> 2. What is the distinction between dynamic configuration protocols and
> >> >>control-plane protocols?
> >> >
> >> > Good question. I believe this to be at the end implementation specific.
> >> > The question I think really is whether a control-plane protocol interacts
> >> > with the configuration management component or not.
> >> 
> >> OK, perhaps it can be said that dynamic configuration protocols modify
> >> "config true" data. Maybe a term like "configuration interface" may be
> >> better because it needn't be a communication protocol, and it needn't be
> >> any more dynamic than NETCONF/RESTCONF is.
> >
> > Yes, we know that 'dynamic' is potentially misleading.
> 
> My take from yesterday's discussion is that in fact the classification
> is implementation-dependent. For example, if I use standard Linux
> command-line tools such as "ip", their result can be seen only in
> operational state, so they are like control-plane protocols. However, if
> an implementation patches these tools so as to write to , then
> they are dynamic configuration protocols.

Talking about 'control-plane protocols' is difficult since there is
not precise definition people agree on. That said, it is an
implementation decision how things work. I can implement a
control-plane mechanism that it either modifies operational-state
directly or that it goes through a configuration management component
to coordinate changes. But yes, the Linux "ip" command talks to the
kernel an directly modifies operational state. (And this is true for
pretty much all open source control plane daemon implementations I
have seen on Linux.)

/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] comments on revised-datastores-00

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>> 
>> > On Mon, Nov 14, 2016 at 11:23:04AM +0900, Ladislav Lhotka wrote:
>> >> Hi,
>> >> 
>> >> I've read the revised-datastores-00 document, in general I like it, here
>> >> are my initial comments and questions:
>> >> 
>> >> 1. Even if  is valid, it can still be in conflict with the
>> >>actual content of  that may come from e.g. dynamic
>> >>configuration protocols. How are such cases supposed to be resolved?
>> >
>> > Yes. The whole idea is to expose these potential differences instead
>> > of hiding them behind a curtain.
>> 
>> That's fine but it doesn't answer my question.
>>
>
> Then I do not understand the question. What does it mean for a
> datastore to be in conflict with a different datastore?

For example:

- the data model has a choice with caseA and caseB. A NC/RC client
  configures caseA,  is valid, but  already contains
  caseB configured by a "dynamic configuration protocol"; or

- a leafref refers to a leaf that exists in  but not in
  .

>
>> >> 2. What is the distinction between dynamic configuration protocols and
>> >>control-plane protocols?
>> >
>> > Good question. I believe this to be at the end implementation specific.
>> > The question I think really is whether a control-plane protocol interacts
>> > with the configuration management component or not.
>> 
>> OK, perhaps it can be said that dynamic configuration protocols modify
>> "config true" data. Maybe a term like "configuration interface" may be
>> better because it needn't be a communication protocol, and it needn't be
>> any more dynamic than NETCONF/RESTCONF is.
>
> Yes, we know that 'dynamic' is potentially misleading.

My take from yesterday's discussion is that in fact the classification
is implementation-dependent. For example, if I use standard Linux
command-line tools such as "ip", their result can be seen only in
operational state, so they are like control-plane protocols. However, if
an implementation patches these tools so as to write to , then
they are dynamic configuration protocols.

>
>> >> 5. Is it necessary that " datastore contains all
>> >>configuration data actually used by the system"? For example, static
>> >>routes should appear in RIBs, so having them separately in operational
>> >>state seems redundant.
>> >
>> > I do not understand your question. Is the RIB exposed or not? Anyway,
>> > we need a general model and not a model for specific aspects such as
>> > routing. Yes, there can be redundancy but there can also be semantic
>> > differences. The  datastore tells me what is
>> > actually used (regardless of what has happened with the statically
>> > configured values). In other words, if I want to debug what my box is
>> > actually doing, looking at the  datastore is
>> > probably a good idea.
>> 
>> But could this part of operational state be possibly different from
>> what's already in ?
>
> This is subtle since we are not really able to define precisely what
> the boundaries of a datastore are. Is something applied if the
> responsible daemon accepted information? Or is it applied if the
> daemon communicated information to the kernel? Or is it applied if the
> linecard accepted the information from the kernel? Or is it applied if
> the specific registers of the linecard have been programmed?

In my view, at some point the configuration system hands over the data
to the backend that's responsible for performing the changes, and the
data passed to the backend should be the content of . Whether
the changes take effect in the system or not may be discovered from
operational state data but the configuration processing should be
already over.  

> Similarily, how is operational state obtained? It is likely that an
> implementation does not read linecard registers on every operational
> state request. As a consequence, we might have systems where applied
> really is just a subset of operational state and this may be true for
> a large number of systems but I would not rule out the possibility of
> having differences between applied and operational state.

We don't currently have static routes in routing-state, despite all
criticism about duplication of config and state values, so it seems
rather backwards to duplicate it in the new datastore model. What's
important for an operator is to see whether a static route appears in a
RIB or not.

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

Re: [netmod] syslog-model-11 single buffer vs list

[Clyde Wildes (cwildes)]

Hi Jason,

I presented the latest draft ietf-syslog model last night in the Netmod session 
and mentioned that you had requested that I restore buffers to a list. No one 
raised any objections so I will do that in the next model update.

Thanks,

Clyde

From: "Sterne, Jason (Nokia - CA)" 
Date: Monday, November 14, 2016 at 7:58 PM
To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" 

Subject: RE: syslog-model-11 single buffer vs list

Hi Clyde,

Most implementations probably have limits in the # of files, remote 
destinations, etc they will support.  If vendors decide to augment the model to 
add max-elements then they'd do it for a number of the lists here.  That 
doesn't seem like a big deal.  But trying to fit into a model with 1 buffer 
would require complete augmentation of the entire buffer destination.  So if we 
do keep buffer I really think it should be a list.

On the other hand I'm fine with removing both buffer and user sessions (similar 
reasoning for both -> they are supported by 2 vendors and each does it 
differently). Then vendors can just augment for those types of destinations.  
The other types have broader support/applicability.

Here is how we left off with the table (view this with fixed width font):

>Feature  Nokia   Brocade  Ciena  Cisco IOS/XE  Cisco 
> IOS/XR  Cisco NXOS  Juniper JunOS  Linux Rsyslog  Comments
>log-input-transports   
>   x
>log-action console xx x  x 
>  xx   x
>log-action buffer  x  x  x
>log-action filex  x  x 
>  xx   x
>log-action remote  xx   x x  x 
>  xx   x
>log-action terminal   x  x 
>  xx
>log-action session x   
>   x
>feature buffer-limit-bytes   x  x
>feature buffer-limit-messages  x
>feature file-limit-size   x  x 
>   x
>feature file-limit-durationx  x
>   x
>feature
> terminal-facility-device-logging
>feature
> session-facility-user-logging 
>x
>feature select-sev-compare x  x
>   x
>feature select-match   x  x
>   x   x
>feature structured-data
>   x   x Required because of RFC 5424
>feature signed-messages
>   x Required because of RFC 5848
>

Regards,
Jason

-Original Message-
From: Clyde Wildes (cwildes) [mailto:cwil...@cisco.com]
Sent: Tuesday, November 15, 2016 1:43
To: Sterne, Jason (Nokia - CA) ; netmod@ietf.org
Subject: Re: syslog-model-11 single buffer vs list

Hi Jason,

Buffer was a subject of discussion on the netmod list most recently by Tom 
Petch who raised some questions. In an e-mail on 2016/5/6 Tom said:

“The description of log-buffer confuses me.  The buffer is circular in nature 
so there is only one of them; but it is a list keyed on 'name' so there are 
lots of them.  This leaf configures the amount number of log messages that can 
be stored in the local memory logging buffer, so there is only one of them. 
Or?”

In the same e-mail Tom also commented on the complexity of the current model:

“My comment was more on the complexity that results from having so many 
options. Other models are worse - some of the routing ones I find 
unintelligible as a result - but I raised the issue on this model because it is 
being discussed on this list where (almost) all the expertise in these matters 
resides to see if anyone else would bite.”

In a reaction to Tom’s comments, I tried to simplify by changing the buffers 
list back to a leaf in draft 09. In retrospect this was a mistake. Note that 
AFAIK buffer is currently implemented by only two vendors: Cisco and 
Alcatel-Lucent-Nokia.

The Cisco implementation has one buffer and specifies the limit as the total 
buffer size in bytes.

The Alcatel-Lucent-Nokia implementation has multiple buffers and specifies the 
limit in total messages.

If we make buffers a list, we still have three features in the model and the 
necessity for implementations that support only one buffer to augment the model 
to specify a max-elements statement. The three features are:

  feature buf

[netmod] FW: New Version Notification for draft-hares-netmod-i2rs-yang-01.txt

[Susan Hares]

I was so inspired by the netmod discussions on 
draft-nmdsdt-netmod-revised-datastores that I wrote up this quick draft.  For 
those with limited time you can focus on the following section for the opstate 

 

·Section 3.4 Assumptions on Data Store Model Melee

·Section 4 - Ephemeral Data 

 

Section 5 - Yang Configuration changes suggests to add an "ephemeral" keyword 
that identifies Yang Data model. 

 

This material will be discussed at I2RS WG today [15:20-16:20] Studio 2.  

 

We’ll start with this material at 15:20-15:45 so if you going to attend – make 
sure to come on time.   The new structure allows I2RS to define its validation 
process for I2rs configuration data.  It also allows control plane datastores 
which will allow multiple ephemeral data stores at the I2RS Agent – so that 
I2RS agent caching at the I2RS node can be supported.  We will talk about this 

 

Sue 

 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Tuesday, November 15, 2016 3:38 PM
To: Amit Daas; amit.d...@ericsson.com; Susan Hares
Subject: New Version Notification for draft-hares-netmod-i2rs-yang-01.txt

 

 

A new version of I-D, draft-hares-netmod-i2rs-yang-01.txt

has been successfully submitted by Susan Hares and posted to the IETF 
repository.

 

Name:  draft-hares-netmod-i2rs-yang

Revision:  01

Title: Yang for I2RS Protocol

Document date: 2016-11-15

Group:  Individual Submission

Pages:  19

URL: 
 
https://www.ietf.org/internet-drafts/draft-hares-netmod-i2rs-yang-01.txt

Status:  
 
https://datatracker.ietf.org/doc/draft-hares-netmod-i2rs-yang/

Htmlized: 
https://tools.ietf.org/html/draft-hares-netmod-i2rs-yang-01

Diff:
 
https://www.ietf.org/rfcdiff?url2=draft-hares-netmod-i2rs-yang-01

 

Abstract:

   This document requests one yang model addition that will support

   ephemeral state and provides notes for the implementers who wish to

   implement ephemeral state for the I2RS Protocol.  The purpose of this

   document is to provide implementers of ephemeral state with

   background and open issues that they should consider when

   implementing ephemeral state that satifies the I2RS protocol.

 


  

 

 

Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

 

The IETF Secretariat

 

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

[netmod] opstate breakout meeting tomorrow (wednesday)

[Kent Watsen]

NETCONF and NETMOD WGs,

As mentioned in today’s NETMOD session, there will be a breakout meeting 
tomorrow to continue the discussion of proposal in 
https://tools.ietf.org/html/draft-nmdsdt-netmod-revised-datastores-00.   If 
interested in this topic, please join us in Park Ballroom 3 starting at 13:30.  
 Just in case, the room is booked for 6 hours.

Thanks,
Kent

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