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

Joe Clarke <jclarke@cisco.com> Wed, 20 July 2016 12:52 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 C60D912D5C5 for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 05:52:55 -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 avTCFJLmAfEF for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 05:52:53 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6090812D0B1 for <i2rs@ietf.org>; Wed, 20 Jul 2016 05:52:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8092; q=dns/txt; s=iport; t=1469019173; x=1470228773; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=GOSVEOlhhrbOrGUJL+ltH5wHrjThFgfYvLPLl9ORImQ=; b=EL3UqvA4asI5AWLV9BMQF6tbcJUq7UCxuvO9lBds203l5iDbkeqhuaT1 MmCVR+N5W6k1PcYJT+k795anHuLbXtfD3p0aG93L7ks57uCAuLDOLiflf XrNgvwGzbKLPFxHsAiyCfkBsP0+78PDgOUsHLI/+DZ4PUbmmCbvh/aJMu I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CyAgCMc49X/5ldJa1aA4M/VipSrDyMG4F6IoV4AoEvOBQBAQEBAQEBZSeEXAEBBQEBMAEFLwcXAgILEAEDAQEBAScHGwYGHwkIBgEMBgIBARqHeAMXDrkkDYQIAQEBAQEBAQEBAQEBAQEBAQEBAQEBHAWGJYF4CIJNgkOCHiaFFAEEhlYJkhM0hhOGMYIegWyEWYMNhWeIJYd7HjaEDyAyh3ABAQE
X-IronPort-AV: E=Sophos;i="5.28,394,1464652800"; d="scan'208";a="125820362"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 12:52:52 +0000
Received: from [10.82.238.162] (rtp-vpn5-1692.cisco.com [10.82.238.162]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6KCqo5Z007530; Wed, 20 Jul 2016 12:52:51 GMT
To: "jmh.direct" <jmh.direct@joelhalpern.com>, Susan Hares <shares@ndzh.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Russ White' <7riw77@gmail.com>, i2rs@ietf.org
References: <3b4hc19ywdtjui9gp6yu90i7.1469014886778@email.android.com> <20160720115932.GA52435@elstar.local>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
Message-ID: <599d04d1-fdf7-6777-3f61-55cfcba57f89@cisco.com>
Date: Wed, 20 Jul 2016 08:52:50 -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: <20160720115932.GA52435@elstar.local>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/RL6jKzQ40Ojp0uO_dYU-A7Pc5ao>
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 12:52:57 -0000

On 7/20/16 07:59, Juergen Schoenwaelder wrote:
> The text I comment to says "individual ephemeral configuration
> changes" - I was not able to infer from this that it was supposed to
> imply "individual I2RS clients".

I agree with both you and Joel.  "Individual" should apply to clients, 
but we need to have something that ties priority to local config.

What about:

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

Joe

>
> /js
>
> On Wed, Jul 20, 2016 at 01:41:26PM +0200, jmh.direct wrote:
>>
>> The reason I referred to individual I2RS clients is that different clients have different priorities.  The previous text referred to "ephemeral priority" which needed clarification.
>> I referred to changes because the only time priority is relevant is when something changes.
>> And the proposed new text loses the emphasis on associating a priority with local config.
>> Yours,Joel
>>
>> Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
>> -------- Original message --------From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Date: 7/20/16  1:19 PM  (GMT+01:00) To: Susan Hares <shares@ndzh.com> Cc: "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Joe Clarke' <jclarke@cisco.com>, 'Russ White' <7riw77@gmail.com>, 	i2rs@ietf.org Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
>> What is the purpose of the word 'individual' in the sentence? Why does
>> it talk about 'changes'? Isn't it simply the data that takes
>> precedence? Or is the idea to have this linked to changes of data,
>> i.e., how a change was carried out?
>>
>> I actually find the text related to this in RFC 7921 more helpful
>> since RFC 7921 provides more insight that priority is associated
>> with an I2RS client. Perhaps Req-07 should just say:
>>
>>   Req-07: The I2RS protocol MUST support a priority mechanism to
>>   resolve any possible conflicts with local configuration as described
>>   in RFC 7921.
>>
>> This way we avoid having multiple definitions that may interact in
>> weird ways. (This might also apply to other requirements where perhaps
>> a simple pointer to RFC 7921 would be easier and safer than attempts
>> to reformulate things.)
>>
>> /js
>>
>> PS: I do not want to further complicate things so please feel free
>>     to ignore this.
>>
>> On Wed, Jul 20, 2016 at 06:49:27AM -0400, Susan Hares wrote:
>>> I'm fine with this revision.  Anyone else wish to change this version?
>>>
>>> Sue
>>>
>>> -----Original Message-----
>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern
>>> Sent: Wednesday, July 20, 2016 5:25 AM
>>> To: Joe Clarke; Susan Hares; 'Russ White'; i2rs@ietf.org
>>> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
>>> ephemeral)
>>>
>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>
>