Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT)
Benoit Claise <bclaise@cisco.com> Thu, 27 October 2016 12:09 UTC
Return-Path: <bclaise@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 10B91129A8E; Thu, 27 Oct 2016 05:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.953
X-Spam-Level:
X-Spam-Status: No, score=-14.953 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, 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 uGZ104tnVyin; Thu, 27 Oct 2016 05:09:27 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D42129A89; Thu, 27 Oct 2016 05:09:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12822; q=dns/txt; s=iport; t=1477570166; x=1478779766; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Yh16f8l7Yty4gHN4/Bq8aFEAW9XlZQ4DOu03hUZE+Og=; b=hWfx/7pndsVkdE2Iflo9PD0naLB3KVSaaSrHGxQ5MSHePAxaIOwYz1VR HmSLXKmc1eVMvnPeuUSB7f+tu0b8pJt2m13Ho1AlmcS5P1NrmbGgJYAxG nh7XAYVRe6KMyVfSyrsxq3abEQhO12BP2WCI5DjS+ineSFJIey3VcaZIa w=;
X-IronPort-AV: E=Sophos;i="5.31,404,1473120000"; d="scan'208";a="647688714"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2016 12:09:24 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9RC9NY2008394; Thu, 27 Oct 2016 12:09:24 GMT
To: Susan Hares <shares@ndzh.com>, 'The IESG' <iesg@ietf.org>
References: <147756978661.24643.15919752806670541040.idtracker@ietfa.amsl.com> <327101d2304a$0f7bf220$2e73d660$@ndzh.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <195afd1c-5ca3-6ec3-3927-fe0aaf65bdd7@cisco.com>
Date: Thu, 27 Oct 2016 14:09:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <327101d2304a$0f7bf220$2e73d660$@ndzh.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/A-IFSG97H4g-xjgK3MsPdwBNEyU>
Cc: i2rs@ietf.org, lionel.morand@orange.com, jclarke@cisco.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-ephemeral-state@ietf.org, Benoit Claise <bclaise@cisco.com>
Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT)
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, 27 Oct 2016 12:09:31 -0000
Understood Sue. Nobody is asking the impossible. Also, let's not forget that a DISCUSS should serve as discussion points. Regards, Benoit > Benoit: > > I will be glad to address these comments. It is a little difficult when > they come at 7:44am on Thursday morning. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Thursday, October 27, 2016 8:03 AM > To: The IESG > Cc: lionel.morand@orange.com; jclarke@cisco.com; > draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; > i2rs@ietf.org > Subject: [i2rs] Benoit Claise's Discuss on > draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) > > Benoit Claise has entered the following ballot position for > draft-ietf-i2rs-ephemeral-state-20: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > - > The I2RS Working Group has chosen to use the YANG data modeling > language [RFC6020] as the basis to implement its mechanisms. > > I guess you mean RFC 7950. > RFC7950 should be a normative reference. > > > - > I read the abstract and title: clearly this is about ephemeral state. > > I2RS Ephemeral State Requirements > draft-ietf-i2rs-ephemeral-state-19.txt > > Abstract > > The I2RS (interface to the routing system) Architecture document > (RFC7921) abstractly describes a number of requirements for ephemeral > state (in terms of capabilities and behaviors) which any protocol > suite attempting to meet the needs of I2RS has to provide. This > document describes, in detail, requirements for ephemeral state for > those implementing the I2RS protocol. > > And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's > DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client. > Why (re-hashing) requirements not related to ephemeral? > What the goal of this section 2? > It seems more like adding confusing that being helpful. Too many > requirements from different documents in I2RS: "distilling" them between > documents is looking for troubles. > note: section 9 title " > Pub/Sub Requirements Expanded for Ephemeral State" and content area clear > > > > > - I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? > > Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints > that refer to operational state, this includes potentially fast > changing or short lived operational state nodes, > > > Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- > ephemeral state as a constraint. Non-ephemeral state can be > configuration state or operational state. > > I should be missing something. Examples would help me. > > - Clarification: > Ephemeral-REQ-12: When a collision occurs as two clients are trying > to write the same data node > > I2RS clients with the I2RS protocol, or NETCONF/RESTCONF clients? > Note: multiple instances of "clients" (as opposed to I2RS clients) in the > doc. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Editorial: > - Section 5 versus 6 > For NETCONF: > 2. The ephemeral state MUST support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > For RESTCONF: > 2. The ephemeral state must support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > > must versus MUST. If there are some language subtleties here, I didn't grasp > them. > > - "To support Multi-Headed Control," > Multi-Headed Control? I guess I know what you mean, but expressed like this > (capitalized), I'm looking for a well-known, well-defined term. > Later on, I see "Multi-headed control" > > - s/yang/YANG > > - > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol > > remove one "I2RS protocol" instance > > - > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order > to support I2RS client identity and priority: > > I would remove: "(e.g. NETCONF/RESTCONF + yang)" > > > - "MUST BE" = MUST Belgium :-) > > Pretty good feedback from Lionel Morand's OPS DIR review: > > 1. Introduction > > The I2RS Working Group has chosen to use the YANG data modeling > language [RFC6020] as the basis to implement its mechanisms. > > Additionally, the I2RS Working group has chosen to re-use two > existing protocols, NETCONF [RFC6241] and its similar but lighter- > weight relative RESTCONF [I-D.ietf-netconf-restconf], as the > protocols for carrying I2RS. > > What does re-use of a protocol mean? Re-use means that while YANG, > NETCONF and RESTCONF are a good starting basis for the I2RS protocol, > the creation of the I2RS protocol implementations requires that the > I2RS requirements > > 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), > > The purpose of these requirements is to ensure clarity during I2RS > protocol creation. > > [LM] The aim of the document is not so clear. The working assumption is : > re-use but with "addition". > What does addition mean? Who is in charge to check that the proposed > "additions" can be supported by YANG/NETCONF/RESTCONF without protocol > updates? Where is the need to first derive specific requirements from > RFC7921 and then check if they can be fulfilled by the model and the > protocols, instead of doing both in the same document? > > 2. Review of Requirements from I2RS architecture document > > The I2RS architecture defines important high-level requirements for > the I2RS protocol. The following are requirements distilled from > [RFC7921] that provide context for the ephemeral data state > requirements given in sections 3-8: > > [LM] What is the meaning of "distilled" here? Are these requirements > explicitly part of the RFC7921 or the requirements listed in this draft may > be "relative" or even complementary requirements compared to the RFC7921? > > 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous > interface, with real-time guarantees on getting data from an I2RS > agent by an I2RS client. > > [LM] Is it a requirement related to the I2RS protocol or to the transport > protocol? > > 2. I2RS agent MUST record the client identity when a node is created > or modified. The I2RS agent SHOULD to be able to read the client > identity of a node and use the client identity's associated > priority to resolve conflicts. The secondary identity is useful > for traceability and may also be recorded. > > [LM] I think that the first sentence is not so related to the I2RS protocol > but rather to the mechanism to provision the I2RS agent with this info (e.g. > AAA). > > 3. An I2RS Client identity MUST have only one priority for the > client's identifier. A collision on writes is considered an > error, but the priority associated with each client identifier is > utilized to compare requests from two different clients in order > to modify an existing node entry. Only an entry from a client > which is higher priority can modify an existing entry (First > entry wins). Priority only has meaning at the time of use > > [LM] If I'm correct, "First entry wins" is for clients associated with the > same priority, right? If it is, it is not only about 'higher' > priority. > > 4. I2RS Client's secondary identity data is read-only meta-data that > is recorded by the I2RS agent associated with a data model's node > is written. Just like the primary client identity, the secondary > identity SHOULD only be recorded when the data node is written. > > [LM] Not sure of the relevance of this requirement in the context of the > I2RS protocol design if this info is opaque for the agent. > > 5. I2RS agent MAY have a lower priority I2RS client attempting to > modify a higher priority client's entry in a data model. The > filtering out of lower priority clients attempting to write or > modify a higher priority client's entry in a data model SHOULD be > effectively handled and not put an undue strain on the I2RS > agent. > > [LM] This requirement seems to imply that the priority associated with the > client ID is transitively associated with the client's entry in the I2RS > agent. If it is, this requirement should be clarified along with Req > 3 or just after. > > 3.1. Persistence > > 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. > > [LM] this one is related to Req 8 and is about a "MUST" regarding the YANG > model. As defined in RFC7950 (recently published), there are only two > flavors of data managed with YANG: configuration data and state data, > differentiated by the "config" statement with the argument the string "true" > or "false". This requirement seems to imply a new "flavor" i.e. > ephemeral state, which seems not compatible with the existing model that > cannot be accommodated using a Boolean value. Does it mean that a new > version of the YANG model would be required to fulfil this requirement? > > [LM] Most of the other requirements are derived from and/or dependent on the > req 1. > > [LM] Other specific comments: > > 5. NETCONF Features for Ephemeral State > > 2. The ephemeral state MUST support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > > [LM] I wonder how this impacts the recommendation on the use of > configuration lock mechanism when it is known that multiple instances may > update the same configuration data as per RFC6241. Here, it seems that the > priority is able to override the lock in place, which is not allowed in > NETCONF. > > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order > to support I2RS client identity and priority: > > o the data nodes MAY store I2RS client identity and not the > effective priority at the time the data node is stored. > > [LM] This requirement seems to be in contradiction with the one given in > section 2 i.e. "I2RS agent MUST record the client identity when a node is > created or modified.". If I'm correct, the "MAY" applies only to the > "effective priority" and not to the I2RS Id storage. > > o The priority MAY be dynamically changed by AAA, but the exact > actions are part of the protocol definition as long as collisions > are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, > and Ephemeral-REQ-14. > > [LM] there are several references to the use of AAA-based solutions for > priority handling. Does it require any action in RADEXT or Dime to support > these requirements, at least as a default standard mechanism for I2RS? > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > . >
- [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs… Benoit Claise
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Susan Hares
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Benoit Claise
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Susan Hares