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

Robert Wilton <rwilton@cisco.com> Thu, 21 July 2016 08:47 UTC

Return-Path: <rwilton@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 8FF9512DC16 for <i2rs@ietfa.amsl.com>; Thu, 21 Jul 2016 01:47:56 -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_H4=-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 qSJrItCFLWIv for <i2rs@ietfa.amsl.com>; Thu, 21 Jul 2016 01:47:54 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0EF512DC10 for <i2rs@ietf.org>; Thu, 21 Jul 2016 01:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5336; q=dns/txt; s=iport; t=1469090865; x=1470300465; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=eOqcbyBm5GgRlnJw1NWf3nhS7o7Slp1B2+mUA80WshI=; b=fXs2o583cUal+DzXnRm9+zWqegf0KU6GkN7sqH7kzLVMXUIJ5dmivceF YENV9kThN0OcCvdWinkyIQYIRr1Zww2/gsl3mhuauOMF9yZW2kW7ouzFA sBm8sWFcge5wXBGKsWbJpVuJ4hMZ3GoeNhwJS397JgIOle6Y/iMUImjc1 E=;
X-IronPort-AV: E=Sophos;i="5.28,398,1464652800"; d="scan'208";a="635914011"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 08:47:44 +0000
Received: from [10.61.86.58] (ams3-vpn-dhcp5691.cisco.com [10.61.86.58]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6L8lhoY020289; Thu, 21 Jul 2016 08:47:44 GMT
To: Joe Clarke <jclarke@cisco.com>, Susan Hares <shares@ndzh.com>, "'Russ White'" <7riw77@gmail.com>, "i2rs@ietf.org" <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> <eniiljkadm7ncjq8p2nkjn9d.1469003679596@email.android.com> <1d3b708a-f8f3-b1e1-cf1d-bc09a87dba4f@cisco.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <eb0ef258-7bcf-52ef-88ef-75e1c2f5cfe7@cisco.com>
Date: Thu, 21 Jul 2016 10:47:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <1d3b708a-f8f3-b1e1-cf1d-bc09a87dba4f@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/DjV7G2KbB0MSmtChvs2EUm-Zxg4>
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: Thu, 21 Jul 2016 08:47:56 -0000


On 20/07/2016 11:18, Joe Clarke wrote:
> On 7/20/16 05:10, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
> wrote:
>> Hi,
>>
>> Sorry, but I can't make the I2RS meeting because I'm presenting at the
>> end of NETCONF.
>>
>> I've spoken to Sue and understand that the requirement isn't changing
>> here - just the text to describe it.
>>
>> I think that I'm OK with this new text.
>>
>> One suggestion: Possibly It might help if the text made it clear that
>> the priotiy resolution applies to the complete set of ephemeral config
>> vs the complete set of local config. I.e. the requirement is not asking
>> for priority resolution between the two config sets on a per datanode 
>> basis.
>
> Yes, I had assumed that in my text, but I agree, this should be clear.
>
> Functionally, in my head, I imagine local config to act like an I2RS 
> client.  Clients don't have a per-data node priority.  They have an 
> overall priority.
>
> Is this consistent with what you're stating here?
It wasn't.  In fact, even after speaking with Sue I was misunderstanding 
the requirement.

I previously thought that the requirement was either:
    "all local config" is higher priority than "all ephemeral config" or 
vice versa.

But I now understand that the requirement is on a per client basis. E.g. 
some clients may override the local config whereas others do not.

Now I understand the actual requirement, the recent text that you posted 
to the I2RS alias looks good to me.

Thanks,
Rob

>
> Joe
>
>>
>> But I strongly support getting the requirements draft completed, and
>> hence I suspect that whatever text that you agree in the 2nd I2RS
>> meeting will be fine.
>>
>> Thanks,
>> Rob
>>
>>
>> Sent from my Xperia™ tablet
>>
>> ---- Joe Clarke (jclarke) 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
>
> .
>