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

Andy Bierman <andy@yumaworks.com> Wed, 20 July 2016 09:38 UTC

Return-Path: <andy@yumaworks.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 493FF12D158 for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 02:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 8ZMfnHaDkg06 for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 02:37:53 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED4912D0EC for <i2rs@ietf.org>; Wed, 20 Jul 2016 02:37:53 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id x130so61504548vkc.0 for <i2rs@ietf.org>; Wed, 20 Jul 2016 02:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rnrd3xWFtt4drmWtrDVVebbHwqd9zHGcrIj0r7dMlh8=; b=MXi4/h9T9XPX05MHjedTotW9rVP3RhJZX9r6BY+GOJ52FV9DZLqV6eMszE5trOGFxh FipFwWR045JOwFeYSzjQetmU7Y+gYgv9Wx490WNrl4ut0SZwV5ZjcQ4lvf/HHPkDIXuy TWQzsizjcH2CpO1i9DiCdMMl1C4ZMNbV+p2hw3PDLJA8lN8V5bQ+2ZFuF2JdK3KpF6rb KViaIo2dVaclChgBYQDhz4u/iZy+YDyX7MaiWcW5B83qZuATumC66zLK9pR/c6hDKeyH cR4mnarslrZGYSyfOQQHp3Je8TIXLL9Ci28PXQfjx7gzWreb0cjSStWaWETLMrnS/QJl qALA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rnrd3xWFtt4drmWtrDVVebbHwqd9zHGcrIj0r7dMlh8=; b=AgdHzGXOVJExwPq9pwJZUozuHuJURxfyzGCkIMOaIbiSCBRZAy/m77DWoeESlUd+Oq Ty6+Rra0MEQXn9Z7cUgGEAM0btWqAwSvHxtwCRnDvnZQRHk+OR0ZO32abxIo/awp98Oq ixd7/KLIxO4jgSa474GdWsDSfK4IjkYyRNQc98TjKoFEYjr21U/FUYgdCH8ByYXhlUUA MdFt0hiOkNumHYEpstiay/CIOgem7AGgptj3SG8wHE0ChDm0H+FdYVUC+8ZAHKakVFCG PP/oE0g5keWjnuE3Ue//7zOKuSBevLjVMRFPi9kkZorEtl0yZBRwBU9RLkTzxfHD6CDj 4IBA==
X-Gm-Message-State: ALyK8tKsmSXLbjk6FrbH5SSKDjzILKxXTZMZ9QL76OmT/abO2OWy3HRWE79MqJQuMIsIdZM0lFtnJSlV9KOfZw==
X-Received: by 10.159.40.74 with SMTP id c68mr22940111uac.9.1469007472466; Wed, 20 Jul 2016 02:37:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.20.2 with HTTP; Wed, 20 Jul 2016 02:37:51 -0700 (PDT)
In-Reply-To: <1d3b708a-f8f3-b1e1-cf1d-bc09a87dba4f@cisco.com>
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: Andy Bierman <andy@yumaworks.com>
Date: Wed, 20 Jul 2016 02:37:51 -0700
Message-ID: <CABCOCHRA1_ZGChup9UT=NamPX2gPd88e6MtW8MBXB9_1Bw915A@mail.gmail.com>
To: Joe Clarke <jclarke@cisco.com>
Content-Type: multipart/alternative; boundary="94eb2c04486a91b5fc05380df423"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/cAtlXGfMQfeI4If4ghHMceeK2WU>
Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, "i2rs@ietf.org" <i2rs@ietf.org>, Russ White <7riw77@gmail.com>, Susan Hares <shares@ndzh.com>
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:38:01 -0000

Hi,

the text in REQ-07 does not say anything about client identity,
but Sue's comments in the NETCONF WG meeting indicate
that the client ID is saved, not the priority.

This does not seem to work if client priority can change.
If priority is changed, then it seems that all the overlays affected
need to be adjusted so the operational state reflects the new priority.

It seems to me that I2RS will require per-node storage of a
client ID and a priority to prevent this re-evaluation.
However, if the operator changes a client-ID priority they probably
want all the nodes re-evaluated.  This applies to ephemeral-only,
not just local config vs. ephemeral.


Andy


On Wed, Jul 20, 2016 at 2:18 AM, Joe Clarke <jclarke@cisco.com> 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.
> i,
>


> 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?
>
> 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
>>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>