[i2rs] Review of draft-ietf-i2rs-ephemeral-state-11
Robert Wilton <rwilton@cisco.com> Mon, 27 June 2016 15:33 UTC
Return-Path: <rwilton@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 A165912D77E for <i2rs@ietfa.amsl.com>; Mon, 27 Jun 2016 08:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, 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 i3A-0Pp9zwPa for <i2rs@ietfa.amsl.com>; Mon, 27 Jun 2016 08:33:18 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2C412D779 for <i2rs@ietf.org>; Mon, 27 Jun 2016 08:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30374; q=dns/txt; s=iport; t=1467041406; x=1468251006; h=from:subject:to:message-id:date:mime-version; bh=4Z5pxLSBlXAwfMVhpCj+8EbOOnIsJRoQPPlMNUYmt9Y=; b=Xaol40fsMpvaOM3ZjmyX5BZ2ZXv32axMtWfPi7jKKsuDIWcZzdDrPiJt JNXyNSKwSnuu0xfHsd5K5TyoOCFsaPETFG2+wOA9KvfKoClGt5AgQXj5K f6N0yAbXKuxxMY5MCmG0uXQtWLsRoFvJ3ntSlHaxb2X7JhIaC6yR9K39M c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DRAQBfRXFX/xbLJq1bgnCBT7p9gXuIARQBAQEBAQEBZSeEdoEDExMBCQJLIQgBAReIFaINj2KQQYYogXeCVodBgloFmQGBMY0GgWmHX4VchlSJKx42g3E7iikBAQE
X-IronPort-AV: E=Sophos;i="5.26,537,1459814400"; d="scan'208,217";a="677952336"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 15:30:03 +0000
Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5RFU3I4015055 for <i2rs@ietf.org>; Mon, 27 Jun 2016 15:30:03 GMT
From: Robert Wilton <rwilton@cisco.com>
To: i2rs@ietf.org
Message-ID: <4f70e94d-f73b-73a7-c41b-9ab5ffeeda6f@cisco.com>
Date: Mon, 27 Jun 2016 16:30:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------2DDBCBF0E88477DF8E12FDA9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/bLIo7tDqs6fx4aZElszMgVsmL-w>
Subject: [i2rs] Review of draft-ietf-i2rs-ephemeral-state-11
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: Mon, 27 Jun 2016 15:33:21 -0000
Hi, I've reviewed draft-ietf-i2rs-ephemeral-state-11 and given a few minor comments below. Generally I think that I understand the requirements stated in this document. Minors comments: 1) Ephemeral-REQ-01 (page 5): Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does not persist across reboots. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent. The architecture document indicates that the ephemeral state would (or is that may) also be lost on other circumstances such as process restart of the I2RS agent. Does this need to be clarified in the requirement? E.g. Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that MUST NOT persist across reboots of the device or I2RS Agent subsystem. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent. 2) Hierarchy: (page 5) Based on the previous description, I would possibly split Ephemeral-REQ-06 up into the following requirements: Old (from ephemeral-state:10): Ephemeral-REQ-06: The ability to augment an object with appropriate YANG structures that have the property of being ephemeral. An object defined as any one of the following: yang module, submodule or components of submodule, or schema node. Old (from ephemeral-state-11): Ephemeral-REQ-06: The ability to augment Yang schema nodes with additional Yang Schema nodes that have the property of being ephemeral. Proposed: Ephemeral-REQ-06: 1. The ability to define a YANG module or submodule schema that only contains data nodes with the property of being ephemeral. 2. The ability to augment a YANG data model with additional YANG schema nodes that have the property of being ephemeral. 3) Ephemeral-REQ-07: (page 6): Ephemeral-REQ-07: Ephemeral configuration state could override overlapping local configuration state, or vice-versa. Implementations MUST provide a mechanism to choose which takes precedence. This mechanism MUST include local configuration (policy) and MAY be provided via the I2RS protocol mechanisms. I note that this requirement doesn't specify the scope of whether the override mechanism should operate globally or on a per data node basis. I'm not sure whether this needs to be clarified - since the text in the architecture document makes it pretty clear that a global level resolution is sufficient. 4) Ephemeral-REQ-08: (page 6): Similar to Juergen's comments, I'm concerned about the writable/non-writable requirement. Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model that schema nodes have the following properties: ephemeral, writable/ not-writable, and status/configuration. I'm somewhat adverse to writable operational state, and hence I would prefer if this requirement was watered down to something like: Ephemeral-REQ-08: In addition to config true/false, there MUST be a way to indicate that YANG schema nodes represent ephemeral state. It is desirable to allow for, and have to way to indicate, config false YANG schema nodes that are writable operational state. 5) Ephemeral-Req-12, page 7: Presumably the requirement is that the notification must indicate the node that we involved in the collision? I.e. it isn't sufficient to just signal to the client that there has been a collision with some of their configuration? Ephemeral-REQ-12: When a collision occurs as two clients are trying to write the same data node, this collision is considered an error and priorities were created to give a deterministic result. When there is a collision, a notification MUST BE sent to the original client to give the original client a chance to deal with the issues surrounding the collision. The original client may need to fix their state. Should this be made explicit? E.g. perhaps: Ephemeral-REQ-12: When a collision occurs as two clients are trying to write the same data node, this collision is considered an error and priorities were created to give a deterministic result. When there is a collision, a notification (indicating which data node the collision occurred on) MUST BE sent to the original client to give the original client a chance to deal with the issues surrounding the collision. The original client may need to fix their state. 6) Ephemeral-REQ-14, page 7: I would suggest potentially rewording this to make the requirement and leeway on the solution more explicit. Ephemeral-REQ-14: If two clients have the same priority, the architecture says the first one wins. The I2RS protocol has this requirement to prevent oscillations between clients. If one uses the last wins scenario, you may oscillate. That was our opinion, but a design which prevents oscillation is the key point. Proposed alternative text: Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST be provided to handle the error scenario that two clients, with the same priority, update the same configuration data node. The I2RS architecture gives one way that this could be achieved, by specifying that the first update wins. Other solutions, that prevent oscillation of the config data node, are also acceptable. Cosmetic comments: 7) Section 1. Introduction. The requirements are no longer version specific, hence perhaps update the following text from: 1. select features from YANG, NETCONF, and RESTCONF per version of the I2RS protocol (See sections 4, 5, and 6) 2. propose additions to YANG, NETCONF, and RESTCONF per version of the I2RS protocol for key functions (ephemeral state, protocol security, publication/subscription service, traceability), to: 1. select features from YANG, NETCONF, and RESTCONF for the initial I2RS protocol version (See sections 4, 5, and 6). 2. propose additions to YANG, NETCONF, and RESTCONF for the initial I2RS protocol version for key functions (ephemeral state, protocol security, publication/subscription service, traceability). 8) Section 1. introduction. I'm not sure that this 3rd bullet is relevant, and possibly could be removed, although equally it doesn't seem to do any harm: 3. suggest protocol strawman as ideas for the NETCONF, RESTCONF, and YANG changes. 9) The document uses a mix of "Yang" and "YANG", probably should just use "YANG". 10) Section 3. Ephemeral State Requirements: The document refers to "ephemeral configured state" here, but elsewhere (e.g. 3.4) "ephemeral configuration" or "ephemeral configuration state" is used. It might be helpful for use of these terms to be consistent, I would suggest "ephemeral configuration" is sufficient. 11) Ephemeral-REQ-13, page 7: Minor omission in the last sentence. Ephemeral-REQ-13: The requirement to support multi-headed control is required for collisions and the priority resolution of collisions. Multi-headed control is not tied to ephemeral state. I2RS is not mandating how AAA supports priority. Mechanisms which prevent collisions of two clients trying the same node of data are the focus. Proposed: Ephemeral-REQ-13: The requirement to support multi-headed control is required for collisions and the priority resolution of collisions. Multi-headed control is not tied to ephemeral state. I2RS is not mandating how AAA supports priority. Mechanisms which prevent collisions of two clients trying to modify the same node of data are the focus. 12) Ephemeral-REQ-15, page 7: I would suggest that it might be better to refer to "Ephemeral state" rather than the I2RS ephemeral data-store. Ephemeral-REQ-15: Section 7.9 of the [I-D.ietf-i2rs-architecture] states the I2RS architecture does not include multi-message atomicity and roll-back mechanisms. I2RS notes multiple operations in one or more messages handling can handle errors within the set of operations in many ways. No multi-message commands SHOULD cause errors to be inserted into the I2RS ephemeral data-store. Proposed: Ephemeral-REQ-15: Section 7.9 of the [I-D.ietf-i2rs-architecture] states the I2RS architecture does not include multi-message atomicity and roll-back mechanisms. I2RS notes multiple operations in one or more messages handling can handle errors within the set of operations in many ways. No multi-message commands SHOULD cause errors to be inserted into the ephemeral state. Thanks, Rob
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Robert Wilton
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Susan Hares
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Martin Bjorklund
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Eric Voit (evoit)
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Susan Hares
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Eric Voit (evoit)
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Eric Voit (evoit)
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Susan Hares
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Robert Wilton
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Susan Hares
- [i2rs] Review of draft-ietf-i2rs-ephemeral-state-… Robert Wilton
- Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-st… Susan Hares