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
>
> .
>