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

Joe Clarke <jclarke@cisco.com> Wed, 20 July 2016 07:40 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D48F12B02A for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 00:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJzJI8ooMb39 for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 00:40:20 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F2C12D0DE for <i2rs@ietf.org>; Wed, 20 Jul 2016 00:40:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2338; q=dns/txt; s=iport; t=1469000420; x=1470210020; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=uKA+4sO9s82MPeyFch9+7+yPLa1lLqnrQOzbg3YLfKg=; b=Zv1i5TaMM6BnSgqoFg8EIY5EJGNfY9uBw+AmvPs4vC70ieLRTXnHYvSK QrGEBbK2WyEwF4nQy1WYAws3YtkerYLWsTiIYUUxGJs90l5tHt+4XK3YB LyxDs1EMYXrg5qiI/bCfJ3nbZ3txYvC2lk7gDGN13LQa9KL/pmAVcKBdz A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CQBgAyKo9X/4gNJK1dgz+BAFKsVYwagXqGGgKBMzgUAQEBAQEBAWUnhFwBAQQBOE0ECw4DBAEBAR0KByElCQgGAQwGAgEBGod4Aw8IuTINhAgBAQEBAQEBAQEBAQEBAQEBAQEBHoYqgXiCVYJDh1gBBJhyNIxEgh6JUYVniCWHex42hA8gModwAQEB
X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="299272386"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 07:40:19 +0000
Received: from [10.82.252.95] (rtp-vpn6-1115.cisco.com [10.82.252.95]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6K7eHJS002652; Wed, 20 Jul 2016 07:40:18 GMT
To: Susan Hares <shares@ndzh.com>, 'Russ White' <7riw77@gmail.com>, i2rs@ietf.org
References: <fc5d171b-82da-0041-3248-8a01d31e9202@cisco.com> <016201d1e11b$6c0c3140$442493c0$@ndzh.com> <5a2feb3c-9f9b-8d4a-91f2-db337d1ceecf@cisco.com> <009801d1e24d$3b92a340$b2b7e9c0$@gmail.com> <019b01d1e24e$8ea9bc70$abfd3550$@ndzh.com>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
Message-ID: <99078e75-8c89-ee08-9ea3-a5d2c0840671@cisco.com>
Date: Wed, 20 Jul 2016 03:40:17 -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: <019b01d1e24e$8ea9bc70$abfd3550$@ndzh.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/_xQuOsZf_FMfSVtbWqtWzylKHwU>
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2016 07:40:22 -0000

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

Am I correct in my interpretation?

Joe

>
> Sue
>
> -----Original Message-----
> From: Russ White [mailto:7riw77@gmail.com]
> Sent: Wednesday, July 20, 2016 2:09 AM
> To: 'Joe Clarke'; 'Susan Hares'; i2rs@ietf.org
> Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
> ephemeral)
>
>
> (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
> highest
>> priority (let's say that's 255 to make it concrete).  In this case no
> ephemeral
>> 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.
>
> -r
>
>