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

"Susan Hares" <> Mon, 18 July 2016 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6F8212DB36 for <>; Mon, 18 Jul 2016 10:40:47 -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 Bzcky6wRoaUU for <>; Mon, 18 Jul 2016 10:40:46 -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 18F6212DB1D for <>; Mon, 18 Jul 2016 10:40:42 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'Joe Clarke' <>,
References: <>
In-Reply-To: <>
Date: Mon, 18 Jul 2016 13:39:49 -0400
Message-ID: <016201d1e11b$6c0c3140$442493c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIQ+p2C2ovBB8xVCOfYyAmnTkd9hp+gHAFA
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: Mon, 18 Jul 2016 17:40:48 -0000


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. 

Your point is the last remaining point. 


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
                       ===================     ==================
   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 

-----Original Message-----
From: i2rs [] On Behalf Of Joe Clarke
Sent: Monday, July 18, 2016 10:08 AM
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

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

Hopefully I've described this well so that it makes sense.


i2rs mailing list