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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 20 July 2016 09:37 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 8EDC4128E18 for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 02:37:46 -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 6gg5qPGC2oF1 for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 02:37:45 -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 514EF12DA60 for <i2rs@ietf.org>; Wed, 20 Jul 2016 02:31:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3B94B1C05AE; Wed, 20 Jul 2016 02:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1469007111; bh=+k0BiOr/keK8zRRxTPWKMjArd4ulHXzmYUlth2ag47w=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nOrqIeJBeu4cRigzZHTVL62gzy5a7xLBk3sXlmkSqkfUwEUtNEX2CM9UPkS4uku1N x7BaY3RR32U9Ct/VTkUo1bI1Pvy5dO/0qk84nE8XeoUENFFPoOGuf/rAG0RiIvElhs NogKmlQP5UHZ0XJvuPE8Lr0WgOhD2E2TbkQOt0cA=
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 409421C02FB; Wed, 20 Jul 2016 02:31:50 -0700 (PDT)
To: Joe Clarke <jclarke@cisco.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> <be18c19b-6b54-fa7c-a6a2-a1d3af8c107d@joelhalpern.com> <d26fe3ea-003c-6f1f-99df-59ff41d1b8d6@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <a3dba62f-e9e5-84fd-5781-e8f9de28a72f@joelhalpern.com>
Date: Wed, 20 Jul 2016 05:31:43 -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: <d26fe3ea-003c-6f1f-99df-59ff41d1b8d6@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/Vl5EyBpF0snTYAnpTEyglFFhtuM>
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:37:47 -0000

Thanks Joe.  Yes, I meant I2RS CLIENT priority, not agent priority.
Yours,
Joel

On 7/20/16 5:30 AM, Joe Clarke wrote:
> On 7/20/16 05:24, Joel M. Halpern wrote:
>> 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.
>
> I think you mean I2RS client priority?  But otherwise, I like the text.
>
> Joe
>
>>
>> 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
>>>
>