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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 20 July 2016 09:32 UTC

Return-Path: <jmh@joelhalpern.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 7E05412D110 for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 02:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 KpuQFNUWvAuE for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 02:32:48 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A23312D096 for <i2rs@ietf.org>; Wed, 20 Jul 2016 02:24:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45B161C05AE; Wed, 20 Jul 2016 02:24:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1469006698; bh=S0kvi+u+JnngRf/SXroZ58WhRV4e8k19xgqgs8EgxQk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ORmt8+/sxSo+OiVv4p0M7XwBmpPzPGZkCgUJqMS41WsLyHkqDI3gMvidapDNKslL3 7Z5/TA9NAmx7g5qKpHGzpRaccPCVcKU0fOe20qbMJ7vyeLc6wAxpowiKUDvHgmNfVK mDFYqnkH/vpPcbLtx/2oh15JcmQQlcXatCpEJpGc=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from surfer-172-29-110-137-hotspot.internet-for-guests.com (unknown [62.214.2.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4A8FF1C02FB; Wed, 20 Jul 2016 02:24:57 -0700 (PDT)
To: Joe Clarke <jclarke@cisco.com>, 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> <99078e75-8c89-ee08-9ea3-a5d2c0840671@cisco.com> <009201d1e25a$35af9b10$a10ed130$@ndzh.com> <c2f0dbb8-c558-b738-6241-40fc1cd61349@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <be18c19b-6b54-fa7c-a6a2-a1d3af8c107d@joelhalpern.com>
Date: Wed, 20 Jul 2016 05:24:50 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <c2f0dbb8-c558-b738-6241-40fc1cd61349@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/CQ-P3lboBdS3vLldTXGzSXT3dto>
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 09:32:49 -0000

That wording may well lead readers to think that Ephemeral 
configuration, considered as a whole, has a priority.  Since that is not 
true, I would like to further refine this.  How about:

Req-07: Local configuration MUST have a priority that is comparable with 
the I2RS Agent priority for making changes.  This priority will 
determine whether local configuration changes or individual ephemeral 
configuration changes take precedence.  The I2RS protocol MUST support 
his mechanism.

Yours,
Joel

On 7/20/16 4:05 AM, Joe Clarke wrote:
> On 7/20/16 03:42, Susan Hares wrote:
>> Joe:
>> Yes - you are correct.  Can you help me state this requirement -07
>> better?
>
> What about:
>
> Ephemeral-REQ-07: Ephemeral configuration and local configuration MUST
> each have a priority.  This priority will determine whether ephemeral
> configuration or local configuration take precedence.  The I2RS protocol
> MUST support this mechanism.
>
> Is this clear and correct enough?
>
> Joe
>
>>
>> Sue
>>
>> -----Original Message-----
>> From: Joe Clarke [mailto:jclarke@cisco.com]
>> Sent: Wednesday, July 20, 2016 3:40 AM
>> To: Susan Hares; 'Russ White'; i2rs@ietf.org
>> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
>> ephemeral)
>>
>> 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
>>>
>>>
>>
>>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>