Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

"Susan Hares" <> Wed, 20 July 2016 11:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C96CB12D5E7 for <>; Wed, 20 Jul 2016 04:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.739
X-Spam-Level: *
X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Yd-WJkA74-z for <>; Wed, 20 Jul 2016 04:27:53 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28ACD12D549 for <>; Wed, 20 Jul 2016 04:27:51 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'Andy Bierman' <>, 'Joe Clarke' <>
References: <> <016201d1e11b$6c0c3140$442493c0$> <> <009801d1e24d$3b92a340$b2b7e9c0$> <019b01d1e24e$8ea9bc70$abfd3550$> <> <009201d1e25a$35af9b10$a10ed130$> <> <> <> <>
In-Reply-To: <>
Date: Wed, 20 Jul 2016 07:27:12 -0400
Message-ID: <005e01d1e279$a9e6a400$fdb3ec00$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01D1E258.22D83850"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQIQ+p2C2ovBB8xVCOfYyAmnTkd9hgHTtsXcANrHzaYBEvJNdgLlyNRhALyE6U0BIYh7SwKoL/9dAf9W4RgCMNxa5wLfcbY1nxEK+KA=
Archived-At: <>
Cc: "'Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)'" <>,, 'Russ White' <>
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jul 2016 11:27:55 -0000



What we indicated is that because the client-id is linked to only one priority at a time, that the implementation could just keep the client id.   The basic principle is still the comparison of priority ideas.    In the code, you will need to a have a link between the element and the client id/priority. 


In my implementation of a I2RS RIB, I create a structure that store client-ID and opaque information (call it store-id (SID)).  


Route-entry à SID-#1.  

If SID changes, then you could change all the routes linked to SID.   I agree that one way to handle a change to the priority associated with a clients would be re-evaluate the routes associated with the SID.  The WG’s discussion 9 months ago, was to specify that if client priority changed that the implementation would not be required to process past.  (It could re-evaluate, but it was not required.). 


So.. your scenario is correct. 






From: Andy Bierman [] 
Sent: Wednesday, July 20, 2016 5:38 AM
To: Joe Clarke
Cc: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco); Susan Hares; Russ White;
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)




the text in REQ-07 does not say anything about client identity,

but Sue's comments in the NETCONF WG meeting indicate

that the client ID is saved, not the priority.


This does not seem to work if client priority can change.

If priority is changed, then it seems that all the overlays affected

need to be adjusted so the operational state reflects the new priority.


It seems to me that I2RS will require per-node storage of a

client ID and a priority to prevent this re-evaluation.

However, if the operator changes a client-ID priority they probably

want all the nodes re-evaluated.  This applies to ephemeral-only,

not just local config vs. ephemeral.






On Wed, Jul 20, 2016 at 2:18 AM, Joe Clarke <> wrote:

On 7/20/16 05:10, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) wrote:


Sorry, but I can't make the I2RS meeting because I'm presenting at the
end of NETCONF.

I've spoken to Sue and understand that the requirement isn't changing
here - just the text to describe it.

I think that I'm OK with this new text.

One suggestion: Possibly It might help if the text made it clear that
the priotiy resolution applies to the complete set of ephemeral config
vs the complete set of local config. I.e. the requirement is not asking
for priority resolution between the two config sets on a per datanode basis.

Yes, I had assumed that in my text, but I agree, this should be clear.


Functionally, in my head, I imagine local config to act like an I2RS client.  Clients don't have a per-data node priority.  They have an overall priority.

Is this consistent with what you're stating here?


But I strongly support getting the requirements draft completed, and
hence I suspect that whatever text that you agree in the 2nd I2RS
meeting will be fine.


Sent from my Xperia™ tablet

---- Joe Clarke (jclarke) wrote ----

On 7/20/16 03:42, Susan Hares wrote:

Yes - you are correct.  Can you help me state this requirement -07 better?

What about:

Ephemeral-REQ-07: Ephemeral configuration and local configuration MUST
each have a priority.  This priority will determine whether ephemeral
configuration or local configuration take precedence.  The I2RS protocol
MUST support this mechanism.

Is this clear and correct enough?



-----Original Message-----
From: Joe Clarke []
Sent: Wednesday, July 20, 2016 3:40 AM
To: Susan Hares; 'Russ White';
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.

On 7/20/16 02:18, Susan Hares wrote:

<WG hat off> <author hat on>

Here's text that might replace it:

Ephemeral-REQ-07: Ephemeral configuration state MUST be able to set a
priority on local configuration and ephemeral state.  Based on this
priority implementations MUST be able to provide a mechanism to choose
which takes precedence. The I2RS Protocol MUST be able to support this


Any thoughts?

I'm a bit confused by the first sentence.  I think what you're stating is
that both ephemeral and local configurations MUST have a priority.
This priority will determine whether ephemeral configuration or local
configuration take precedence.  The I2RS protocol MUST support this

Am I correct in my interpretation?



-----Original Message-----
From: Russ White []
Sent: Wednesday, July 20, 2016 2:09 AM
To: 'Joe Clarke'; 'Susan Hares';
Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.

(wg chair hat off) --

I think the idea of extending I2RS priority to local config operators

(e.g., CLI)

will still work.  Let's take knob 1.  Knob 1 is kind of like the

switch.  If I

don't want I2RS to have any effect on operational state, I'd have

off.  In

the I2RS priority case, by default my local config could will have


priority (let's say that's 255 to make it concrete).  In this case no


config can win.

I wanted to extend Joe's remarks a bit... On reflection, I actually
think having priority + "this wins" bits is rather confusing, and
opens the door to all sorts of strange behavior. Say I have two items
thus --

Local config item -- priority 100
I2RS config item -- priority 200, don't overwrite bit set

If the higher priority is supposed to win, then which item should the
operator find in the resulting running config? Should it be the I2RS
version, because the priority is higher, or the local config, because
the "don't overwrite" bit is set? There doesn't seem to be any clear
way to interpret such a situation.

It's better to have a single "thing" that determines which
configuration among many wins, rather than two.



i2rs mailing list

i2rs mailing list