Subject: [netmod] Comparison between two opstate datastore drafts

From: Robert Wilton <[email-masked]>
Date: Mon, 11 Jul 2016 15:30:13 +0100

Hi,

Last week I published an updated version of 
draft-wilton-netmod-refined-datastores-01 
<https://datatracker.ietf.org/doc/draft-wilton-netmod-refined-datastores/>that 
proposes an alternative datastore architecture to that proposed in 
draft-schoenw-netmod-revised-datastores-01 
<https://datatracker.ietf.org/doc/draft-schoenw-netmod-revised-datastores/>

These two drafts came out of the discussions related to the opstate 
problem, and the differences effectively represent some of the points on 
which the adhoc design team didn't reach consensus on.

Fundamentally, both of these drafts provide an architecture to solve the 
same problem, and hence there are quite a few similarities between the 
drafts:
1) both drafts split the running configuration datastore into the 
abstract concept of separate intended configuration and applied 
configuration datastores.
2) both drafts introduce a new "operational state datastore" (but with 
different contents and semantics).
3) both drafts suggest how the I2RS ephemeral state would fit into the 
architecture (but in different ways)
4) both drafts introduce the concept of system created config true nodes 
in the "operational state datastore", and both drafts agree that these 
nodes exist outside the applied configuration.

 From my understanding, I think that the following are the key points 
where the two drafts differ, and hence were input from the WG is 
particularly desirable:

1) draft-schoenw refines (or perhaps redefines) the NETCONF definition 
of the "running configuration datastore" to be just the clients 
persistent intended configuration.  draft-wilton gives this datastore a 
new name (i.e. persistent configuration) and keeps the "running 
configuration datastore" defined as the combined intended + applied (and 
supported in a mostly backwards compatible way).

2) draft-schoenw defines the intended config and applied config as 
regular datastores, that clients would optionally be able to query and 
interact with in the same way as for regular datastores.  Conversely, 
draft-wilton defines both intended config and applied config as 
"abstract datastores", meaning that although a server could expose them 
as regular datastores, but there is no requirement to, instead it is 
proposed that the information contained within them would be made 
available via an optional YANG metadata extension to the other 
datastores (e.g. along the lines described in 
draft-wilton-netconf-opstate-metadata-00 
<https://datatracker.ietf.org/doc/draft-wilton-netconf-opstate-metadata/>).

3) draft-schoenw defines the applied configuration as a datastore 
defined separately from the "operational state datastore". draft-wilton 
treats the "applied configuration" as a subset of the config true leaves 
in the "operational state datastore".  This particular difference has a 
couple of key implications:

3a) In draft-schoenw the config true leaves in the "operational state 
datastore" do not represent the configuration that has been applied, but 
instead represent the operational state of the device, but overlaid 
(where possible) onto the config true schema nodes.  E.g. a device might 
have a config true "ethernet speed" leaf that is set to "auto" in the 
"applied configuration datastore", but that would be set to the actual 
speed of the interface (e.g. 10Gbits/s) in the "operational state 
datastore".
In draft-wilton, the config true leaves in the "operational state 
datastore" represent the exact applied configuration plus system created 
entries.  In the same ethernet speed example, the "ethernet speed" 
config true leaf would be set to "auto" in the "operational state 
datastore", and a separate config false leaf also in the "operational 
state datastore" would be used to represent the actual speed of the 
interface (which may also need to be expressed using a different 
datatype anyway).  Separate config false leaves are only required where 
the system state could differ from the configured leaf value (i.e. as is 
the case for NETCONF/YANG implementations today that return running 
configuration + separate config false state nodes for operational state).

3 b) Because draft-schoenw defines the applied configuration as a 
separate datastore, this requires that clients that want to learn of the 
applied configuration have to interact with the separate applied 
configuration datastore.  With draft-wilton, clients only need to 
interact with the operational state datastore + optional metadata to 
learn of the applied configuration.

4) draft-schoenw introduces the concept of active/inactive 
configuration, this is not currently considered in draft-wilton.

5) draft-schoenw proposes that ephemeral configuration is handled after 
applied configuration, and is handled as extra input into the 
operational state datastore.  draft-wilton proposes ephemeral 
configuration to be part of both the intended and applied configuration 
for the system and hence handled more like a separate optional 
datastore.  draft-wilton defines that the "operational state datastore" 
also contains the applied ephemeral configuration and ephemeral 
operational state.

6) draft-wilton defines how statistics are handled as part of the 
"operational state datastore".

Juergen, I have tried to keep this as an objective comparison between 
the two drafts.  Of course, If I have misrepresented any of the points 
of draft-schoenw in any way then please correct my comments above.

Comments from WG participants is welcome.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jul 2016 16:49:27 +0200

On Mon, Jul 11, 2016 at 03:30:13PM +0100, Robert Wilton wrote:
> 
> Juergen, I have tried to keep this as an objective comparison between the
> two drafts.  Of course, If I have misrepresented any of the points of
> draft-schoenw in any way then please correct my comments above.
> 

I may not be clear about everything but I think it also does not help
if we start a long thread about this. What is more important, I think,
is that people read both IDs and try to understand the differences as
they are in the IDs. And then we might have an informed audience in
Berlin.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 Jul 2016 12:48:27 -0700

Hi,

I have read both drafts and I can't say either I like either solution too
much.

Some general observations:

 - the term "running config" has been in use since the 80s.
   Changing it to "intended config" is not helpful.

 - YANG and NETCONF/RESTCONF distinguish between config=true and
    config=false nodes.  There is no reason to alter these protocols wrt/ to
     existing operations. Add new operations with new features.

  - metadata maintenance is expensive.  The opstate-metadata draft seems
very expensive
    to implement and not actually required.  1 simple boolean or
enumeration should be good enough

  - any solution based on retrieval and compare or push and compare grows
linearly with
     the size of the edit.  A notification approach offers O(1)
performance, not O(N).

 - a data+metadata design allows push or pull in 1 step instead of 2. Data
cannot get out of
   sync if it is always retrieved together.

 - the enable/disable feature should be separate, based on a simplified
version of Kent's draft
   on conditional enablement

 - the server has to be aware of intended vs. applied no matter how this
feature is implemented.
   Leave most of it as an implementation detail, and focus on the
interaction model for
  determining convergence

- a solution to tag YANG config=false data nodes as operational state vs.
statistics is needed.
 (YANG Push should make it easy to configure an on-demand subscription for
just operational state
 or a periodic for statistics, or different push parameters for each type
in the same subscription.
 The client should not have to cherry-pick the opstate vs. statistics in a
subtree

Andy

On Mon, Jul 11, 2016 at 7:49 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 12 Jul 2016 15:24:11 +0000

Hi Robert,
Hi Juergen,

Robert: thanks for this comparison.  Certainly the Event and Datastore Subscription drafts would be users of whatever results from your and Juergen’s efforts.

A question on the representation of the Ephemeral Datastore.  Why not consider Ephemeral Config as part of the running datastore?  Having Ephemeral part of running should match better to people’s mental models of what Running actually means.   Also if there is no Ephemeral Config on a device, this shouldn’t present backwards compatibility issues.

Eric

From: Robert Wilton -X, July 11, 2016 10:30 AM

Hi,

Last week I published an updated version of draft-wilton-netmod-refined-datastores-01<https://datatracker.ietf.org/doc/draft-wilton-netmod-refined-datastores/> that proposes an alternative datastore architecture to that proposed in draft-schoenw-netmod-revised-datastores-01<https://datatracker.ietf.org/doc/draft-schoenw-netmod-revised-datastores/>

These two drafts came out of the discussions related to the opstate problem, and the differences effectively represent some of the points on which the adhoc design team didn't reach consensus on.

Fundamentally, both of these drafts provide an architecture to solve the same problem, and hence there are quite a few similarities between the drafts:
1) both drafts split the running configuration datastore into the abstract concept of separate intended configuration and applied configuration datastores.
2) both drafts introduce a new "operational state datastore" (but with different contents and semantics).
3) both drafts suggest how the I2RS ephemeral state would fit into the architecture (but in different ways)
4) both drafts introduce the concept of system created config true nodes in the "operational state datastore", and both drafts agree that these nodes exist outside the applied configuration.

From my understanding, I think that the following are the key points where the two drafts differ, and hence were input from the WG is particularly desirable:

1) draft-schoenw refines (or perhaps redefines) the NETCONF definition of the "running configuration datastore" to be just the clients persistent intended configuration.  draft-wilton gives this datastore a new name (i.e. persistent configuration) and keeps the "running configuration datastore" defined as the combined intended + applied (and supported in a mostly backwards compatible way).

2) draft-schoenw defines the intended config and applied config as regular datastores, that clients would optionally be able to query and interact with in the same way as for regular datastores.  Conversely, draft-wilton defines both intended config and applied config as "abstract datastores", meaning that although a server could expose them as regular datastores, but there is no requirement to, instead it is proposed that the information contained within them would be made available via an optional YANG metadata extension to the other datastores (e.g. along the lines described in draft-wilton-netconf-opstate-metadata-00<https://datatracker.ietf.org/doc/draft-wilton-netconf-opstate-metadata/>).

3) draft-schoenw defines the applied configuration as a datastore defined separately from the "operational state datastore".  draft-wilton treats the "applied configuration" as a subset of the config true leaves in the "operational state datastore".  This particular difference has a couple of key implications:

3a) In draft-schoenw the config true leaves in the "operational state datastore" do not represent the configuration that has been applied, but instead represent the operational state of the device, but overlaid (where possible) onto the config true schema nodes.  E.g. a device might have a config true "ethernet speed" leaf that is set to "auto" in the "applied configuration datastore", but that would be set to the actual speed of the interface (e.g. 10Gbits/s) in the "operational state datastore".
In draft-wilton, the config true leaves in the "operational state datastore" represent the exact applied configuration plus system created entries.  In the same ethernet speed example, the "ethernet speed" config true leaf would be set to "auto" in the "operational state datastore", and a separate config false leaf also in the "operational state datastore" would be used to represent the actual speed of the interface (which may also need to be expressed using a different datatype anyway).  Separate config false leaves are only required where the system state could differ from the configured leaf value (i.e. as is the case for NETCONF/YANG implementations today that return running configuration + separate config false state nodes for operational state).

3 b) Because draft-schoenw defines the applied configuration as a separate datastore, this requires that clients that want to learn of the applied configuration have to interact with the separate applied configuration datastore.  With draft-wilton, clients only need to interact with the operational state datastore + optional metadata to learn of the applied configuration.

4) draft-schoenw introduces the concept of active/inactive configuration, this is not currently considered in draft-wilton.

5) draft-schoenw proposes that ephemeral configuration is handled after applied configuration, and is handled as extra input into the operational state datastore.  draft-wilton proposes ephemeral configuration to be part of both the intended and applied configuration for the system and hence handled more like a separate optional datastore.  draft-wilton defines that the "operational state datastore" also contains the applied ephemeral configuration and ephemeral operational state.

6) draft-wilton defines how statistics are handled as part of the "operational state datastore".

Juergen, I have tried to keep this as an objective comparison between the two drafts.  Of course, If I have misrepresented any of the points of draft-schoenw in any way then please correct my comments above.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jul 2016 18:24:59 +0200

> A question on the representation of the Ephemeral Datastore.  Why not consider Ephemeral Config as part of the running datastore?  Having Ephemeral part of running should match better to people’s m…

a) The content of the <running> _configuration_ datastore may be
   eventually made persistent according to how NETCONF works today.

b) The <running> configuration datastore has editing primitives that
   trigger specific YANG validation rules that, as far as I
   understand, do not match I2RS requirements.

c) I2RS specifically requires that I2RS data can reference state data,
   which is not allowed for config true data in configuration datastores.

There may be more but this is likely already a good start.

'Ephemeral datastore' is a term we should get rid of as soon as
possible. A datastore may be ephemeral or persistent and this is I
think a _property_ of a datastore but no the main reason for the
existance of a datastore. We are talking about an 'ephemeral
datastore' in the context of I2RS simply since never nailed it down /
found agreement on what kind of datastore this really is. I would call
this thing a <control-plane> datastore or a <routing> datastore or
even an <i2rs> datastore or even a <foo> datastore.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 12 Jul 2016 21:23:53 +0000

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Tuesday, July 12, 2016 12:25 PM
> To: Eric Voit (evoit)
> Cc: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco); [email-masked]
> Subject: Re: [netmod] Comparison between two opstate datastore drafts
> 
> > Robert: thanks for this comparison.  Certainly the Event and Datastore
> Subscription drafts would be users of whatever results from your and Juergen’s
> efforts.
> >
> > A question on the representation of the Ephemeral Datastore.  Why not
> consider Ephemeral Config as part of the running datastore?  Having Ephemeral
> part of running should match better to people’s mental models of what Running
> actually means.   Also if there is no Ephemeral Config on a device, this shouldn’t
> present backwards compatibility issues.
> >
> 

Yes, I can see where there might or might not need to be validation based on where an assertion is coming from.

>    which is not allowed for config true data in configuration datastores.

Yes, makes sense.
 
> 'Ephemeral datastore' is a term we should get rid of as soon as possible. A
> datastore may be ephemeral or persistent and this is I think a _property_ of a
> datastore but no the main reason for the existance of a datastore. We are
> talking about an 'ephemeral datastore' in the context of I2RS simply since never
> nailed it down / found agreement on what kind of datastore this really is. I
> would call this thing a <control-plane> datastore or a <routing> datastore or

Some in I2RS are thinking Routes when they talk about Ephemeral information.   I think of things like dynamic/ephemeral config for mobile 802.11 sessions in a hotel/airport where a user is temporarily redirected to a Web Portal.  Successful log-in results in a Change-of-Authorization coming into the Edge Router.  Another example might be an 802.1x log-on.  Based on the credentials provided, certain ACLs or templates might be applied to an interface.  

Both of these are examples of configuration which would not survive reboot, and would likely be in your <operational-state> datastore.  I don't have a firm opinion yet on whether this type of intended config needs to be exposed as intended config.  But I suspect it will.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 14:48:39 -0700

On Tue, Jul 12, 2016 at 2:23 PM, Eric Voit (evoit) <[email-masked]> wrote:

> possible. A
> Some in I2RS are thinking Routes when they talk about Ephemeral
> information.   I think of things like dynamic/ephemeral config for mobile
> 802.11 sessions in a hotel/airport where a user is temporarily redirected
> to a Web Portal.  Successful log-in results in a Change-of-Authorization
> coming into the Edge Router.  Another example might be an 802.1x log-on.
> Based on the credentials provided, certain ACLs or templates might be
> applied to an interface.
>
> Both of these are examples of configuration which would not survive
> reboot, and would likely be in your <operational-state> datastore.  I don't
> have a firm opinion yet on whether this type of intended config needs to be
> exposed as intended config.  But I suspect it will.
>
>

I agree with Juergen that I2RS should have its own datastore.
It makes it much easier to write and understand the validation rules
and the protocol interaction model.  I also agree that the "MUST NOT
NV-store"
aspect of I2RS is far less interesting than "MUST override running config ".

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 12 Jul 2016 22:14:09 +0000

From: Andy Bierman, July 12, 2016 5:49 PM

On Tue, Jul 12, 2016 at 2:23 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Juergen Schoenwaelder [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco); [email-masked]<mailto:[email-masked]>

Yes, makes sense.

I agree with Juergen that I2RS should have its own datastore.
It makes it much easier to write and understand the validation rules
and the protocol interaction model.  I also agree that the "MUST NOT NV-store"
aspect of I2RS is far less interesting than "MUST override running config ".

<eric2>  I have no issue with having another datastore.  We should not frame this being a protocol specific datastore though.   Otherwise other transient/ephemeral config (such as the two examples above) will request their own datastores as well.

Eric

Eric

Andy

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 18:35:18 -0700

On Tue, Jul 12, 2016 at 3:14 PM, Eric Voit (evoit) <[email-masked]> wrote:

> *From:* Andy Bierman, July 12, 2016 5:49 PM
>
> <eric2>  I have no issue with having another datastore.  We should not
> frame this being a protocol specific datastore though.   Otherwise other
> transient/ephemeral config (such as the two examples above) will request
> their own datastores as well.
>
>
>
OK but in the end, the datastore is just an API abstraction, and I2RS has a
lot of
requirements and metadata to implement. Each protocol has its own
interaction model.
I agree the ephemeral datastore should not be coupled to the I2RS protocol.
(e.g., client priority is part of I2RS not the datastore)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jul 2016 11:12:50 +0200

> Both of these are examples of configuration which would not survive reboot, and would likely be in your <operational-state> datastore.  I don't have a firm opinion yet on whether this type of inten…

Be careful about the word 'configuration' since people different
opinions what this word means. For some people, dynamically
established control plane state is not configuration for others it
apparently is. This is part of the reason why we have gone in circles
in this whole debate here. We have to be very careful and sensitive
with terminology.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 13 Jul 2016 11:24:19 +0000

> From: Juergen Schoenwaelder, July 13, 2016 5:13 AM
> 
> > Both of these are examples of configuration which would not survive reboot,
> and would likely be in your <operational-state> datastore.  I don't have a firm
> opinion yet on whether this type of intended config needs to be exposed as
> intended config.  But I suspect it will.
> >
> 
> Be careful about the word 'configuration' since people different opinions what
> this word means. For some people, dynamically established control plane state
> is not configuration for others it apparently is. This is part of the reason why we
> have gone in circles in this whole debate here. We have to be very careful and
> sensitive with terminology.

Completely agree.   The line between the two can get really narrow though.  Consider an ACL or routing table entry installed (perhaps automatically) during a DDoS attack.

Eric