Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10
"Susan Hares" <shares@ndzh.com> Thu, 23 June 2016 16:20 UTC
Return-Path: <shares@ndzh.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 0C16912D0A5 for <i2rs@ietfa.amsl.com>; Thu, 23 Jun 2016 09:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 Rs5yLABqNLmt for <i2rs@ietfa.amsl.com>; Thu, 23 Jun 2016 09:20:28 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 73B6012B00F for <i2rs@ietf.org>; Thu, 23 Jun 2016 09:20:28 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.195.80;
From: Susan Hares <shares@ndzh.com>
To: 'Robert Wilton' <rwilton@cisco.com>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
References: <20160623120251.GA46183@elstar.local> <085cf0e5-414d-7bfc-203e-b98e75a1337a@cisco.com> <20160623154138.GA46519@elstar.local> <013f01d1cd66$89680930$9c381b90$@ndzh.com> <cbd8985a-d1b8-bf57-d607-362013e4cd04@cisco.com>
In-Reply-To: <cbd8985a-d1b8-bf57-d607-362013e4cd04@cisco.com>
Date: Thu, 23 Jun 2016 12:19:57 -0400
Message-ID: <029401d1cd6b$15b12260$41136720$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHCSRbpWb0yJVb4kgFT1yEyebZopAEPuBwXAwKJxXQCTxCG+wILhFN4n9LbBAA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/gRW-FzBJvc7IMSDjmSODn3MbuO4>
Cc: i2rs@ietf.org
Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10
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, 23 Jun 2016 16:20:31 -0000
Robert: I changed Ephemeral-REQ-03 to: Ephemeral-REQ-03: Ephemeral state may have constraints that refer to operational state, this includes potentially fast changing or short lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB. Is this OK? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Robert Wilton Sent: Thursday, June 23, 2016 12:00 PM To: Susan Hares; 'Juergen Schoenwaelder' Cc: i2rs@ietf.org Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10 Hi, On 23/06/2016 16:47, Susan Hares wrote: > Juergen and Robert: > > I will use the following for Ephemeral-REQ-03. > > Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary > operational state (e.g. MPLS LSP-ID or a BGP IN-RIB) as a > constraints. That is the original text. Am I correct in assuming that you meant this text instead?: Ephemeral-REQ-03: Ephemeral state must be able to utilize operational state (e.g. MPLS LSP-ID or BGP In-RIB) as a constraint. If so, this proposed text is OK with me. > > On Ephemeral-REQ-04, > >> Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state >> for purposes of implementing constraints. > Non-ephemeral state is both configuration state (config true), and > operational state (config false). > > I believe these are two different requirements. Yes. Given that REQ-03 covers using operational state as a constraint, then would it be sufficient to word REQ-04 as: Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral configuration for purposes of implementing constraints. Or perhaps to relate it more closely to REQ-03, as: Ephemeral-REQ-03: Ephemeral state must be able to utilize non-ephemeral configuration as a constraint. Or is this missing something out? Thanks, Rob > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, June 23, 2016 11:42 AM > To: Robert Wilton > Cc: i2rs@ietf.org > Subject: Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10 > > On Thu, Jun 23, 2016 at 03:12:50PM +0100, Robert Wilton wrote: >> Hi, >> >> On 23/06/2016 13:02, Juergen Schoenwaelder wrote: >>> Hi, >>> >>> here are few comments on the latest version. >>> >>> Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary >>> operational state (e.g. MPLS LSP-ID or a BGP IN-RIB) as a >>> constraints. >>> >>> I am not sure what 'must be able to utilized temporary operational >>> state as constraints' means. The text in the parenthesis does not >>> help me understand this better. Did you want to say something like: >>> 'Ephemeral configuration state may have constraints that refer to >>> operational state'? I am using 'ephemeral configuration state' since >>> this is used in other places (although sometimes worded slightly >>> different). >> I asked a similar question in the I2RS interim meeting yesterday, I >> think that Sue's spoken explanation of the requirement was effectively: >> >> Ephemeral-REQ-03: Ephemeral state may have constraints that refer >> to operational state, this includes potentially fast changing or >> short lived operational state nodes, such as MPLS LSP-ID or a BGP > IN-RIB. >> Perhaps this wording is more clear? > Yes, this is clearer. One question of course is what is expected to > happen if constraints are becoming false due to (fast) operational > state changes, that is, what the expected consequence of this is. > >>> Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state >>> for purposes of implementing constraints. >>> >>> Hm, now I wonder whether this is just a special case of >>> Ephemeral-REQ-03 and if so it is not clear why we need this as a >>> separate requirement. If this is not the case but something >>> different, then likely my interpretation of Ephemeral-REQ-03 is wrong. >> I think that ephemeral state could also use configuration nodes as a >> constraint, so it isn't just operational state covered by REQ-3. > Well, the Ephemeral-REQ-04 text says 'non-ephemeral state' - if your > interpretation is correct than this phrase is wrong or possibly misleading. > > /js > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Robert Wilton
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Susan Hares
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Susan Hares
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Susan Hares
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Robert Wilton
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Susan Hares
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Susan Hares
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Juergen Schoenwaelder
- Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-… Robert Wilton
- [i2rs] comments on draft-ietf-i2rs-ephemeral-stat… Juergen Schoenwaelder