Subject: [I2rs-proto-dt] couple YANG details

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Oct 2015 14:45:56 -0700

Hi,

I would like to simplify the draft a bit further.

1) module-level "ephemeral" flag
Since the data node flag applies to the entire subtree,
it should be simple enough to just require each top-level
data node to declare 'ephemeral true' if needed.
There are usually 1 - 2 top-level data nodes per module so
this is not a burden.  Checking 2 places is too complicated
and they can conflict.

2) groupings wrt/ edit overlap

YANG already has a way to say what sub-nodes must
be present (mandatory=true, min-elements>0).
Is this good enough for I2RS?  Can the requirements
for the ephemeral version be different than the
persistent version, wrt/ mandatory & min-elements?

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Oct 2015 14:49:12 -0700

Hi,

We need to figure out for each YANG constraint:
 1) does it apply at all?
 2) is it MUST, SHOULD, or MAY enforce?
 3) Does the constraint apply the same in running vs. ephemeral?
 4) Does the constraint apply to the combined panes of glass or
     each pane independently?

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Oct 2015 11:17:56 -0400

> this is not a burden.  Checking 2 places is too complicated

As long as we permit ephemeral true in nodes other than the top one, I think
that's good.  We want to permit data models to be published that have
non-ephemeral components with some ephemeral without requiring an ephemeral
augmentation module just for the ephemeral properties.

> persistent version, wrt/ mandatory & min-elements?

If I'm parsing this correctly, I think that's fine.  We want to avoid
introducing additional constraints in ephemeral modules, but shouldn't
perturb the requirements for persistent config state.  Since ephemeral state
can only go underneath the persistent stuff when they mix, min-elements
should be tied to requirements for the persistent nodes; the ephemeral nodes
may contribute, but shouldn't count against the min, ideally.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Oct 2015 11:19:45 -0400

Andy,

>  4) Does the constraint apply to the combined panes of glass or

I'm going to avoid answering your question to let you decide what this
functional requirement means:
Ephemeral nodes SHOULD NOT introduce their own constraints.  
The presence of ephemeral nodes does not trump validation or constraints for
persistent state.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2015 08:29:25 -0700

> The presence of ephemeral nodes does not trump validation or constraints
So if the YANG list has "max-elements 5",
and the config has 5 entries.  What happens when
5 or 10 entries are added in the ephemeral datastore?

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Oct 2015 11:47:57 -0400

Andy,

> 5 or 10 entries are added in the ephemeral datastore?

I'd go for Principle of Least Astonishment and assume it works as you'd
expect through the union of all of the data stores.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2015 09:07:34 -0700

> expect through the union of all of the data stores.
So that means constraint enforcement is on the combined intended config.
OK.  Let's say config-list[1] through [5] exist in config. An I2RS client
adds
config-list[6] in ephemeral data. This should not be rejected because
I2RS is supposed to be better priority than regular config. (T or F?)
So which config-list entry in the running config is disabled?
(Implementation-specific?)
How does the NETCONF client know an entry got disabled (opstate solution?)

-- Jeff

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 23 Oct 2015 16:36:03 -0400

Andy: 

Sorry for the delay in responding. 

Declaring module-level “ephemeral” by declaring the top-node as ephemeral is fine.  However,   do you think people will want to query by the module library whether a module is ephemeral. 

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, October 21, 2015 5:46 PM
To: Susan Hares; [email-masked]
Subject: [I2rs-proto-dt] couple YANG details

Hi,

and they can conflict.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 23 Oct 2015 16:36:47 -0400

Andy: 

Can you define Yang constraint for me?  I’m glad to work through these issues for all constraints. 

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, October 21, 2015 5:49 PM
To: Susan Hares; [email-masked]
Subject: Re: [I2rs-proto-dt] couple YANG details

Hi,

 1) does it apply at all?

     each pane independently?

Andy

Hi,

and they can conflict.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 23 Oct 2015 16:41:29 -0400

Jeff and Andy: 

I agree with Jeff.  I2RS should not create new constraints for anything
under a configuration data tree.   (Jeff see the BGP suggestions below). 

What about the I2RS protocol data modules?  I think these data modules have
their own constraints.  Is this true. 

Sue 

Examples from BGP: 

1) if you create an ephemeral BGP peer, then it should have the same
constraints and other peers. 
b) If you create a BGP cost community, then it should have the same
constraints as other cost communities. 

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Friday, October 23, 2015 11:18 AM
To: Andy Bierman
Cc: Susan Hares; [email-masked]
Subject: Re: [I2rs-proto-dt] couple YANG details

On Wed, Oct 21, 2015 at 02:45:56PM -0700, Andy Bierman wrote:
> Since the data node flag applies to the entire subtree, it should be 
> simple enough to just require each top-level data node to declare 
> 'ephemeral true' if needed.
> There are usually 1 - 2 top-level data nodes per module so this is not 
> a burden.  Checking 2 places is too complicated and they can conflict.

> YANG already has a way to say what sub-nodes must be present 
> (mandatory=true, min-elements>0).
> Is this good enough for I2RS?  Can the requirements for the ephemeral 
> version be different than the persistent version, wrt/ mandatory & 
> min-elements?

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 23 Oct 2015 16:47:38 -0400

Andy: 

Two options: 

1)      Ephemeral obeys the overall configuration, 

2)      Ephemeral sets its own ephemeral limit. 

If you do #2, then are you suggesting we put a limit in the original data model. 

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, October 23, 2015 11:29 AM
To: Jeffrey Haas
Cc: [email-masked]; Susan Hares
Subject: Re: [I2rs-proto-dt] couple YANG details

Andy,

 

-- Jeff

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2015 13:55:28 -0700

On Fri, Oct 23, 2015 at 1:36 PM, Susan Hares <[email-masked]> wrote:

> Declaring module-level “ephemeral” by declaring the top-node as ephemeral
> is fine.  However,   do you think people will want to query by the module
> library whether a module is ephemeral.
>

no - YANG does not need to make rules about what subset of statements
exist in a module. e.g., deviation-stmt is put in a regular YANG module.

Andy

> *From:* I2rs-proto-dt [mailto:[email-masked]] *On Behalf
> Of *Andy Bierman
> *Sent:* Wednesday, October 21, 2015 5:46 PM
> *To:* Susan Hares; [email-masked]
> *Subject:* [I2rs-proto-dt] couple YANG details
>
>
>
> Hi,
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2015 13:58:38 -0700

> issues for all constraints.

https://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-08.txt
sec. 8 + various statement definitions before that.

  must, when, unique, min-elements, max-elements, mandatory

Andy

> *Sent:* Wednesday, October 21, 2015 5:49 PM
> *Subject:* Re: [I2rs-proto-dt] couple YANG details
>
>
>
> Hi,
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Oct 2015 14:04:48 -0700

> their own constraints.  Is this true.

No -- currently there is no way to tell that the constraints apply to I2RS.

So the YANG constraints apply to the running datastore.
The config=true nodes make up the running datastore.
The ephemeral datastore contents and the ephemeral-stmt
values are ignored for this validation.

There is no YANG constraint enforcement in the ephemeral datastore at all.
Only the YANG "type" statement is enforced, and even then,
leafrefs with "require-instance true" are treated as if they were
"require-instance false".

All servers should do validation the same way or the client will not know
what to expect.

> constraints as other cost communities.

But the YANG statements only apply to the running datastore.
What does "same constraints" mean here?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Oct 2015 13:18:00 -0700

> 2)      Ephemeral sets its own ephemeral limit.

It is not that clear what it means for both (1) and (2) to be true.

I am ready to give up on panes of glass.
Nobody is clear on the details of client-facing integration of running
and ephemeral datastores.

Instead, I think the ephemeral datastore should be completely separate
from the running datastore.  At boot-time, it is completely empty.

To override "next-hop",  the I2RS client has to provide all the ancestors,
and (at least) ancestor key leafs.  These data nodes will not be created
automatically
or mirror running config automatically, or do anything at all automatically,
wrt/ the running datastore.

The router is responsible for reconciling the running and ephemeral
datastores
to produce the current intended config.

A collision can only occur in the ephemeral datastore between the proposed
edit
and the existing ephemeral datastore contents.

Running datastore validation and operation is completely untouched
and unaffected by the ephemeral datastore.

Ephemeral datastore validation and operation is completely untouched
and unaffected by the running datastore.

The client will not be able to derive the intended configuration by
retrieving
both datastores and combining them. A special operation is probably
needed for that.

Validation on the ephemeral datastore is not really required, although
any deviation from the running datastore (especially pick and choose
statements)
is likely to cause user astonishment.

IMO it is least astonishing to say the ephemeral datastore is not validated
at all, but the intended configuration in use by the agent SHOULD be valid
at all times.

Andy

> *Sent:* Friday, October 23, 2015 11:29 AM
> *To:* Jeffrey Haas
> *Cc:* [email-masked]; Susan Hares

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 26 Oct 2015 16:36:53 -0400

Ephemeral should obey the overall configuration.

To go forward with Andy’s example, ‘max-elements 5’, question is what is this limit: physical or logical?

If it is physical limitation, like number of queues, then there is really no sense to increase that value.

If it is logical, number of VRFs, then increasing this value might be possible. But how can this be known by the client? So IMO, ephemeral should obey overall configuration. Ephemeral can always overlay existing configuration with its values, if it has admin rights to it.

Dean

> On Oct 26, 2015, at 4:18 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Fri, Oct 23, 2015 at 1:47 PM, Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
> Andy:
> 
>  
> 
> Two options:
> 
> and (at least) ancestor key leafs.  These data nodes will not be created automatically
> The router is responsible for reconciling the running and ephemeral datastores
> A collision can only occur in the ephemeral datastore between the proposed edit
> The client will not be able to derive the intended configuration by retrieving
> any deviation from the running datastore (especially pick and choose statements)
> From: I2rs-proto-dt [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Andy Bierman
> Cc: [email-masked] <mailto:[email-masked]>; Susan Hares
> On Fri, Oct 23, 2015 at 8:19 AM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Andy,
> 
> _______________________________________________
> I2rs-proto-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Oct 2015 13:45:04 -0700

> Ephemeral should obey the overall configuration.

What does this mean?
Does this mean all the YANG constraints MUST be valid in the ephemeral
datastore.  Your terminology is not precise enough to apply to RFC6020bis.

YANG tools need specific deterministic rules that are derived from YANG
statements
other than the description and reference statements.  The agent is not
going to read
description-stmts and decide if the resource represented by the YANG data
is real, virtual, or some combination of the two.

Andy

> If it is logical, number of VRFs, then increasing this value might be
> possible. But how can this be known by the client? So IMO, ephemeral should
> obey overall configuration. Ephemeral can always overlay existing
> configuration with its values, if it has admin rights to it.
>
> Dean
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 28 Oct 2015 07:12:39 -0400

Andy: 

I’m not sure I answered #2 – is the mandatory good enough for I2RS?  The answer is yes. 

Sue 

Hi,

and they can conflict.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 28 Oct 2015 09:02:35 -0400

Andy: 

The two options were a choice – not both.  I’m not sure how to take the document toward this major change. I think I need in person time at IETF to talk about this. 

When do you arrive at Yokohama? 

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Monday, October 26, 2015 4:18 PM
To: Susan Hares
Cc: Jeffrey Haas; [email-masked]
Subject: Re: [I2rs-proto-dt] couple YANG details

Andy: 

Two options: 

 

needed for that.

at all times.

Andy

 

Sue 

 

Andy,

 

-- Jeff

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Oct 2015 09:21:09 -0700

Hi,

I will be there Sat. night, so anytime from Sunday to Friday is OK
(except WG meetings I have to attend).

The YANG validation should fall out for free if the architecture
is good enough.  Something as simple as YANG "max-entries"
should be obvious, but that does not seem to be the case.

There was a slide from Jeff way back that had "running" and
"ephemeral" as "sibling datastores".  The intended config
was derived by the I2RS agent somehow.   This is how Phil described
the Junos implementation to me.  The router picks data from the
dynamic datastore to activate.  It is not a direct API to operational state.

Understanding the differences between panes of glass and sibling datastores
might be useful. Something to talk about next week.

Andy

On Wed, Oct 28, 2015 at 6:02 AM, Susan Hares <[email-masked]> wrote:

> Andy:
>
>
>
> The two options were a choice – not both.  I’m not sure how to take the
> document toward this major change. I think I need in person time at IETF to
> talk about this.
>
>
>
> *Sent:* Monday, October 26, 2015 4:18 PM
> *To:* Susan Hares
> *Cc:* Jeffrey Haas; [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 29 Oct 2015 14:49:01 -0400

Andy:  

I’d also like to understand the concepts of panes of glass versus sibling databases. 

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, October 28, 2015 12:21 PM
To: Susan Hares
Cc: Jeffrey Haas; [email-masked]
Subject: Re: [I2rs-proto-dt] couple YANG details

Hi,

 

Andy

Andy: 

Sue 

 

Andy: 

Two options: 

 

needed for that.

at all times.

Andy

 

Sue 

 

Andy,

 

-- Jeff

Andy