[i2rs] inteirm 10/7/20

"Susan Hares" <shares@ndzh.com> Fri, 09 October 2015 20:13 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2C21A1BC9; Fri, 9 Oct 2015 13:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.045
X-Spam-Level:
X-Spam-Status: No, score=-93.045 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, MANGLED_LIPS=2.3, T_HTML_ATTACH=0.01, USER_IN_WHITELIST=-100] autolearn=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 WqM5n61VWSht; Fri, 9 Oct 2015 13:13:11 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 4A8A01B2CE9; Fri, 9 Oct 2015 13:13:10 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=184.157.84.146;
From: Susan Hares <shares@ndzh.com>
To: i2rs@ietf.org
Date: Fri, 09 Oct 2015 16:13:03 -0400
Message-ID: <05c801d102ce$eb398930$c1ac9b90$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_05C9_01D102AD.642D4060"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdECzbLPf/jBR8T3RumWqwNQi5I6fw==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/54K9xgNWFerDf2RtxvjpSDj1qa0>
Cc: i2rs-proto-dt@ietf.org
Subject: [i2rs] inteirm 10/7/20
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 09 Oct 2015 20:13:18 -0000

The 10/7/2015 interim discussed the ephemeral portion of the protocol 

 

1)      Ephemeral state is not unique to zI2RS 

2)      The ephemeral datastore is a datastore holds 

configuration that is intended to not survive a reboot.

 

3)      The ephemeral datastore is never locked.

4)      I2RS is using a 2 panes of glass mechanisms

Pane 1: normal configuration 

Pane 2:  ephemeral state 

 

                The I2RS agent and configuration software on 

              the node  must handle this complexity.

 

5)      The key word "ephemeral" can be used to identify 

Identities which are ephemeral in data models.

 

Does anyone have any concerns with adding this to 

Yang? 

 

6)       Each client has a priority.  

a.       Multiple clients may share a priority, 

b.      AAA or other external mechanisms 

provides the client ID and priority 

c.       An authorized I2RS client must have both

A client Id and a priority, 

d.      System administrators set up the number 

of client IDs and priorities within a system. 

 

7)      I2RS has defined 3 ways of handling errors  in order

To be efficient in the processing. 

a.       "all-or-nothing", 

b.      "stop-on-error", 

c.       "continue on error"

 

.         If these three are supported, it is the agent which must support
the complexity to support all three.

.         The WG must consider whether for the initial release we limit the
agent by doing "all or nothing". 

 

.         One issues with this is grouping changes into a related group. 

.         The failure in one part of a related  group could cause errors in
the related 

.         "continue on error" were only meant for variables which are
orthogonal or independent. 

 

8)      There is no caching in the I2RS agents. 

 

.         Andy - noted a concern that without caching some of updates may
have too much latency. 

 

Please review the whole minutes for all the details. 

 

Sue Hares