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

Joe Clarke <> Mon, 18 July 2016 21:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30C5E12DA8E for <>; Mon, 18 Jul 2016 14:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JHZ9-W8RGG9i for <>; Mon, 18 Jul 2016 14:57:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BE2012DA2C for <>; Mon, 18 Jul 2016 14:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4197; q=dns/txt; s=iport; t=1468879061; x=1470088661; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=N3JhLu/lOMvxolg5uYUW0UXVMORFCskQJgm1lIBlEF0=; b=M/6IjupHWdL2Pv6abRisif55j6YtlVPJPAMSPAjcBIKRbRHz66djlWwf 8FrlJuaCgbQY8adR22rIMO2pf/sAGUR9/jQbcaSQ9LNor4ldQDnPXiRfX yfrowOd1S7zc1tWWWcfVOSM5VdGP412lwWidZ9hwjpeROY9GngzwCdgbV E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.28,386,1464652800"; d="scan'208";a="297471062"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 21:57:40 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id u6ILvcDH021230; Mon, 18 Jul 2016 21:57:39 GMT
To: Susan Hares <>,
References: <> <016201d1e11b$6c0c3140$442493c0$>
From: Joe Clarke <>
Organization: Cisco Systems, Inc.
Message-ID: <>
Date: Mon, 18 Jul 2016 17:57:38 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <016201d1e11b$6c0c3140$442493c0$>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Mon, 18 Jul 2016 21:57:43 -0000

On 7/18/16 13:39, Susan Hares wrote:
> Joe:
> We discussed  "treating "local config" (e.g., CLI changes) as an I2RS client
> with its own I2RS priority" in order so that priority concept can resolve
> conflict.  REQ-07 is a bit broader because we tagged this to the two "Knobs"
> that section 6.3.1 described.  (see below) in the IETF architecture
> document.   If you think the priority concept can provide the support for
> the two switches and use case below, could you describe it on the list.

The architecture uses the term "overwrite," but I think at least in some 
cases we mean, "overlay."  Anyway, I'll explain using the architecture 

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 highest priority (let's say 
that's 255 to make it concrete).  In this case no ephemeral config can win.

When I turn I2RS "on", the priority of local config drops to the lowest 
priority (let's say 1, again to be concrete).

Okay, that's knob 1.

Now in the case of knob 2, I want to allow local config to win 
sometimes.  In the example in the architecture, I may want to overwrite 
ephemeral config every night at 11 pm.  In this case, I can increase the 
priority of local config to be higher than the last ephemeral I2RS 
client write, thus overwriting that change.

Again, this allows local config to behave like an I2RS client respective 
to the priority.


> Your point is the last remaining point.
> Sue
> ===============================
> Section 6.3.1
> =============
>    The policy settings in the architecture is:
> Knob 1: Ephemeral configuration overwrites Local Configuration.
> Knob 2: Update of Local Configuration value supersedes and
>       overwrites the ephemeral configuration.
>                            Existence                              Updates
>                           Policy Knob 1                       Policy Knob 2
> Situation
>                        ===================     ==================
>    Router A     ephemeral has                     ephemeral  has
> Ephemeral  is active
>                          priority                                 priority .
>    Router B    Local Configuration            Local Configuration
> Ephemeral is recorded in Agent,
>                        has priority                           has priority
> but not used.  Can be turned on by
> turning knob 1 to "ephemeral has priority".
>    Router C    ephemeral has priority      Local Configuration
> Nightly configuration overwrite
> Ephemeral.
> -----Original Message-----
> From: i2rs [] On Behalf Of Joe Clarke
> Sent: Monday, July 18, 2016 10:08 AM
> To:
> Subject: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
> As I stated at the mic today, I think the way REQ-07 is written is a bit
> broad.  This was evidently the intent, but I have a proposal.
> Can we not treat "local config" (e.g., CLI changes) as an I2RS client with
> its own I2RS priority?  If all players (I2RS and local config) play with the
> same priority concept, then one can easily control what gets precedence.
> For example, if I want to temporarily overlay ephemeral-provided changes
> with local config, I could increase the local config priority.  When I'm
> done with that, I set the priority back.  By default, the local config
> priority would be the lowest value to allow for ephemeral changes to take
> precedence.
> I do not think this will have a negative impact on topology as I have read
> it, but if this doesn't make sense in some use cases, the priority could be
> ignored.
> Hopefully I've described this well so that it makes sense.
> Joe
> _______________________________________________
> i2rs mailing list