Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am -? Topic: Ephemeral State Requirements

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 02 June 2016 15:14 UTC

Return-Path: <jmh@joelhalpern.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 342A412D1B2 for <i2rs@ietfa.amsl.com>; Thu, 2 Jun 2016 08:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 Mga0ytci6kSP for <i2rs@ietfa.amsl.com>; Thu, 2 Jun 2016 08:14:37 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF5C12D108 for <i2rs@ietf.org>; Thu, 2 Jun 2016 08:14:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E7E67240828; Thu, 2 Jun 2016 08:14:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464880476; bh=/NxqnEU+gpDrhoofXjRH89poIc2chrkLKmTPdCNWfKw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PPUVZrvEhhox0cfgFFvDJ8SI5innP3USseYHhlR8uNOYkfawh3IgD6N5UNN62JxHA RwOugcPYvLNPeLgyRrQQNyzjMcdBC7AgrwvCL/fh3+t6LGElEvgXsm6CHOpSaHkf0B lCV255zGx18f0Q3mVANYEeLew0qQR7B44rxHp77o=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4F8282406B3; Thu, 2 Jun 2016 08:14:36 -0700 (PDT)
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, i2rs@ietf.org, 'Benoit Claise' <bclaise@cisco.com>
References: <6qtqondee9e8m6od11bh1ilt.1464783874424@email.android.com> <20160601123117.GB24741@elstar.local> <014801d1bc06$98eed670$cacc8350$@ndzh.com> <20160602103621.GA26659@elstar.local> <016c01d1bcbd$10aa6ba0$31ff42e0$@ndzh.com> <20160602110449.GC26659@elstar.local> <017101d1bcc0$1b3a18b0$51ae4a10$@ndzh.com> <20160602115004.GF26659@elstar.local>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <e8545a72-7671-c0ce-4997-97cbabf82671@joelhalpern.com>
Date: Thu, 02 Jun 2016 11:14:29 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160602115004.GF26659@elstar.local>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/rEzyn81aBQnTVQW3YAbHjEWE-yY>
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am -? Topic: Ephemeral State Requirements
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, 02 Jun 2016 15:14:39 -0000

 From where I sit, there is no such thing as "ephemeral operational 
state".  There is "operational state" that reflects the effect of 
"ephemeral configuration", but as far as I can tell, it is still just 
"operational state".

Putting aside the operational state aspects, we do need to work out the 
diagramming / positioning of the ephemeral configuration and its 
relationship to the other components in the base diagram.

Yours,
Joel

On 6/2/16 7:50 AM, Juergen Schoenwaelder wrote:
> I might be able to answer the picture question once I know what is
> really meant by 'ephemeral operational state'.
>
> /js
>
> On Thu, Jun 02, 2016 at 07:15:34AM -0400, Susan Hares wrote:
>> Juergen:
>>
>>
>>
>> On first sentence, ... restated
>>
>> Do you believe the "ephemeral operational state" belongs in the ephemeral
>> requirements? If so, we can add it.  Perhaps we should also add a definition
>> for ephemeral configuration.
>>
>>
>>
>> On picture -- here is your picture:
>>
>>
>>
>>    +-------------+                  +-----------+
>>
>>    | <candidate> |                  | <startup> |
>>
>>    |  (ct, rw)   |<---+        +--->| (ct, rw)  |
>>
>>    +-------------+    |        |    +-----------+
>>
>>           |           |        |           |
>>
>>           |         +------------+         |
>>
>>           +-------->| <running>  |<--------+
>>
>>                     | (ct, rw)   |
>>
>>                     +------------+
>>
>>                           |         // e.g., removal of 'inactive' nodes
>>
>>                           v
>>
>>                     +------------+
>>
>>                     | <intended> |  // subject to validation
>>
>>                     | (ct, ro)   |
>>
>>                     +------------+
>>
>>                           |         // e.g., missing resources or delays
>>
>>                           v
>>
>>                     +------------+
>>
>>                     | <applied>  |
>>
>>                     | (ct, ro)   |
>>
>>                     +------------+
>>
>>                           |         // e.g., autodiscovery of values
>>
>>                           v
>>
>>           +--------------------------------+
>>
>>           | <operational-state>            |<-- control plane and
>>
>>           | (ct + cf, ro)                  |    ephemeral datastores
>>
>>           +--------------------------------+
>>
>>
>>
>> Is this part of the picture
>>
>>
>>
>>           +--------------------------------+
>>
>>           | <operational-state>            |<-- control plane and
>>
>>           | (ct + cf, ro)                  |    ephemeral datastores
>>
>>           +--------------------------------+
>>
>>
>>
>> Really
>>
>>   +--------------------+    +--------------------------+
>> +-----------------------+
>>
>>  |    opstate         |    | ephemeral config  |   | applied  config    |
>>
>>  | (cf, ro)               |    |   (ct, ro, ephemeral|  | (ct, ro)
>> |
>>
>>  +--------------------+    +---------------------------+
>> +-------------------------+
>>
>>
>>
>> Or just
>>
>>   +--------------------+    +--------------------------+
>>
>>   |    opstate         |    | ephemeral config  |
>>
>>   | (cf, ro)               |    |   (ct, ro, ephemeral
>>
>>   +--------------------+    +---------------------------+
>>
>>
>>
>>
>>
>> Sue
>>
>>
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
>> Sent: Thursday, June 02, 2016 7:05 AM
>> To: Susan Hares
>> Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Benoit Claise'; 'Alia Atlas'
>> Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am
>> -? Topic: Ephemeral State Requirements
>>
>>
>>
>> On Thu, Jun 02, 2016 at 06:53:42AM -0400, Susan Hares wrote:
>>
>>> Juergen:
>>
>>>
>>
>>> Do you think this definition belongs in the ephemeral requirements?  If
>> so,
>>
>>> we can add it.   But perhaps we should define both ephemeral configuration
>>
>>> and ephemeral operational state.  Joel point out at the I2RS interim
>>
>>> that ephemeral operational state is just like all other operational state
>> - it
>>
>>> disappears upon reboot.   It is ephemeral configuration which is different
>>
>>> than normal configuration - since it disappears upon reboot where
>>
>>> normal configuration does not.
>>
>>>
>>
>>> Is this diagram close to your existing model where opstate and
>>
>>> ephemeral configuration are parallel?
>>
>>>
>>
>>> +--------------------+    +--------------------------+
>>
>>> |    opstate         |    | ephemeral config  |
>>
>>> +--------------------+    +--------------------------+
>>
>>>
>>
>>
>>
>> I see two boxes, I am unsure what you think these boxes drawn this way mean.
>> What is 'this definition' in your first sentence? I really have problems to
>> follow what is going on.
>>
>>
>>
>> /js
>>
>>
>>
>> --
>>
>> 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/>
>> http://www.jacobs-university.de/>
>>
>>
>>
>> _______________________________________________
>>
>> i2rs mailing list
>>
>>  <mailto:i2rs@ietf.org> i2rs@ietf.org
>>
>>  <https://www.ietf.org/mailman/listinfo/i2rs>
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>