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

"Susan Hares" <> Wed, 28 October 2015 13:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 343FA1B551B for <>; Wed, 28 Oct 2015 06:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.054
X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s_ex4upnp58m for <>; Wed, 28 Oct 2015 06:02:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 091781B5518 for <>; Wed, 28 Oct 2015 06:02:40 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Andy Bierman'" <>
References: <> <> <> <> <033a01d10dd4$0e25ef50$2a71cdf0$> <>
In-Reply-To: <>
Date: Wed, 28 Oct 2015 09:02:35 -0400
Message-ID: <01f601d11180$eb2372b0$c16a5810$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F7_01D1115F.64166690"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKMEsdjPzkqeQIW8vtZ5c+9e7UOnAHIfNVjAlWBtF4CQfRF0wKVc7koAjYgq26csX+yYA==
Content-Language: en-us
Archived-At: <>
Cc: 'Jeffrey Haas' <>,
Subject: Re: [I2rs-proto-dt] couple YANG details
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: I2RS protocol design team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Oct 2015 13:02:43 -0000



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? 




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




On Fri, Oct 23, 2015 at 1:47 PM, Susan Hares <>; wrote:



Two options: 

1)      Ephemeral obeys the overall configuration, 

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.








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




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




On Fri, Oct 23, 2015 at 8:19 AM, Jeffrey Haas <>; wrote:


On Wed, Oct 21, 2015 at 02:49:12PM -0700, Andy Bierman wrote:
> 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?

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.


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?



-- Jeff