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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 20 July 2016 11:59 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 96AAB12B059 for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 04:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 BVc_zBiGrDRa for <i2rs@ietfa.amsl.com>; Wed, 20 Jul 2016 04:59:41 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B374412D1CB for <i2rs@ietf.org>; Wed, 20 Jul 2016 04:59:40 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7C5F1FD4; Wed, 20 Jul 2016 13:59:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Uf3Qf799QOVw; Wed, 20 Jul 2016 13:59:34 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 20 Jul 2016 13:59:36 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7C1020075; Wed, 20 Jul 2016 13:59:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Y4a09mXi5BcP; Wed, 20 Jul 2016 13:59:34 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB0B220078; Wed, 20 Jul 2016 13:59:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C2D873BDC3D6; Wed, 20 Jul 2016 13:59:32 +0200 (CEST)
Date: Wed, 20 Jul 2016 13:59:32 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "jmh.direct" <jmh.direct@joelhalpern.com>
Message-ID: <20160720115932.GA52435@elstar.local>
Mail-Followup-To: "jmh.direct" <jmh.direct@joelhalpern.com>, Susan Hares <shares@ndzh.com>, 'Joe Clarke' <jclarke@cisco.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Russ White' <7riw77@gmail.com>, i2rs@ietf.org
References: <3b4hc19ywdtjui9gp6yu90i7.1469014886778@email.android.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <3b4hc19ywdtjui9gp6yu90i7.1469014886778@email.android.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/8xgdjO0UQnqD4h8uURGEcqSQ1lg>
Cc: i2rs@ietf.org, 'Joe Clarke' <jclarke@cisco.com>, 'Russ White' <7riw77@gmail.com>, Susan Hares <shares@ndzh.com>, "'Joel M. Halpern'" <jmh@joelhalpern.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
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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 11:59:43 -0000

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".

/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


-- 
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/>