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

"Susan Hares" <> Wed, 20 July 2016 06:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8F0B12DA9B for <>; Tue, 19 Jul 2016 23:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LBe2oG5pfZpX for <>; Tue, 19 Jul 2016 23:19:17 -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 3D7A212DAB8 for <>; Tue, 19 Jul 2016 23:19:17 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'Russ White' <>, 'Joe Clarke' <>,
References: <> <016201d1e11b$6c0c3140$442493c0$> <> <009801d1e24d$3b92a340$b2b7e9c0$>
In-Reply-To: <009801d1e24d$3b92a340$b2b7e9c0$>
Date: Wed, 20 Jul 2016 02:18:38 -0400
Message-ID: <019b01d1e24e$8ea9bc70$abfd3550$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIQ+p2C2ovBB8xVCOfYyAmnTkd9hgHTtsXcANrHzaYBEvJNdp+Em7Yw
Content-Language: en-us
Archived-At: <>
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 06:19:19 -0000

<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 mechanisms.

Any thoughts? 


-----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 
> on/off
switch.  If I
> don't want I2RS to have any effect on operational state, I'd have this
off.  In
> the I2RS priority case, by default my local config could will have the
> 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.