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

"Russ White" <> Wed, 20 July 2016 06:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9F0912DAA6 for <>; Tue, 19 Jul 2016 23:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I50k3Vp_MaCf for <>; Tue, 19 Jul 2016 23:09:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04F2412DA9B for <>; Tue, 19 Jul 2016 23:09:16 -0700 (PDT)
Received: by with SMTP id u25so21278132qtb.1 for <>; Tue, 19 Jul 2016 23:09:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=OajlcIYUfoYhk5sJPQ0s6wbLrOTxwlJRWRWLdUDsDQY=; b=g4EGxFTkYdrLgMYMNH4JhBdkmvC0+QNBXZg4ibiWzABcHjMIP9ySMDHi7WW25AId66 D9WyhNOq7xUguwTTzEe6pi2itLJcYpcbz16DZJwFCUtxGZ3sV9PzciHLRfNClljIpsue DzpP9MS3YsLLC6PHOZmA/Zee8xlg1sXk9YKuRY/jnZnfMxGiSK0oKpglZTB97bQPOHMO Q0fbEzeBSKdYLjMGd76cbUcJwFkLqUbGRcGhkCnGKte3PIWZVClKaZcRrP/vY23GaTOl 0pvfr6vvRmneIQfMHdzaOcEr/K5N8kS8jNWevF7CwK3JmwBaXHUSjs2DjdRAuxOwbB+R ZUPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=OajlcIYUfoYhk5sJPQ0s6wbLrOTxwlJRWRWLdUDsDQY=; b=nFK5Kg/te7Kymn9H/SGh1l+hSagdNHqROXW4zz3Kaqqg35mbVzDbrC/Rt8t5GOBnIq HBZZfAfswoglOCr2+uqAAz2+JMXUVr3unz5fdthXOumTYPvcPqg8BeHR881GZhc2e328 PzMiXFh6UQvPw0e1rzySJV4JaYCAmPCYh8iDo4LMdC0mtzuj6UqwQEmcaoMN9gR2KGGD D0oOnhm9WszMH1cm/v/2oHzmOWu+Wy14PUP521UKCEwQsrzlyK0aVEy9eRzQaZHBCtG4 XRzYDGAxYAH0PEG3+eidT1y8Jq3Cbj2tFXwgqr5XTo4J1j+qGHFsAKRkbrlMOiCAtNUK tokg==
X-Gm-Message-State: ALyK8tJlgAjHLvMExCNZoZdvRJDWtDJGWNe8L7kyGTJ3KwddWqUvTAKTOdEYAQ+zD8qTHg==
X-Received: by with SMTP id q40mr67579930qta.34.1468994955124; Tue, 19 Jul 2016 23:09:15 -0700 (PDT)
Received: from Russ ([2001:67c:370:136:a5:c0e4:9464:b50f]) by with ESMTPSA id v19sm615301qkl.22.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 23:09:14 -0700 (PDT)
From: Russ White <>
To: 'Joe Clarke' <>, 'Susan Hares' <>,
References: <> <016201d1e11b$6c0c3140$442493c0$> <>
In-Reply-To: <>
Date: Wed, 20 Jul 2016 02:09:08 -0400
Message-ID: <009801d1e24d$3b92a340$b2b7e9c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIQ+p2C2ovBB8xVCOfYyAmnTkd9hgHTtsXcANrHzaafjS/YMA==
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:09:18 -0000

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