Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt- 2 week WG LC (6/21 to 7/5/2016)

"Susan Hares" <shares@ndzh.com> Fri, 01 July 2016 12:59 UTC

Return-Path: <shares@ndzh.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 B580412D094 for <i2rs@ietfa.amsl.com>; Fri, 1 Jul 2016 05:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.748
X-Spam-Level: *
X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=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 HzlO3SlBSxhs for <i2rs@ietfa.amsl.com>; Fri, 1 Jul 2016 05:59:57 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB14F12B03A for <i2rs@ietf.org>; Fri, 1 Jul 2016 05:59:56 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.165.235;
From: Susan Hares <shares@ndzh.com>
To: 'Martin Bjorklund' <mbj@tail-f.com>
References: <004901d1cbf1$85b87430$91295c90$@ndzh.com> <20160629.124946.1123239025236388287.mbj@tail-f.com> <4a3b01d1d2e5$76dca350$6495e9f0$@ndzh.com> <20160701.124510.1016107013440022699.mbj@tail-f.com>
In-Reply-To: <20160701.124510.1016107013440022699.mbj@tail-f.com>
Date: Fri, 01 Jul 2016 08:59:17 -0400
Message-ID: <036101d1d398$60e5d5e0$22b181a0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEY5e8iHcIwDPPcBwyla1FJlV/FqgKm8o93ApFjhBMBN06EiqFB0Ung
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/coYKl5OMjQje2uIPREe8dataK54>
Cc: jhaas@pfrc.org, i2rs@ietf.org
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt- 2 week WG LC (6/21 to 7/5/2016)
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: Fri, 01 Jul 2016 13:00:00 -0000

Martin: 

Pulling up some response up-front to highlight them.  These response are
also in the text below. 

>> For the I2RS state which is ephemeral configuration state, the 
>> constraints may have all of 8.3 in yang 1.1 or part of the yang 1.1 
>> constraint.
>> The final definition of the ephemeral configuration state depends on 
>> the design of operational state modules.

>This explanation helps to understand this requirement.  You obviously have
some ideas what "constraint" means, and that it means different things for
config and state.  
> This should go into the document, but see below.

There are 4 classes of I2RS ephemeral configuration state checking we have
defined so far: 
  1) normal (r/w) of drafts (draft-ietf-i2rs-rib-data-model)  - check 8.3.1,
8.3.2, 8.3.3 + ephemeral requirements (1-15) 
  2) bulk (r/w) within rpcs (see draft-ietf-i2rs-rib-data-model) -
constraints check interfaces (real configuration) + checks on route overlay
(Ephemeral 7) + Ephemeral (-15)  
  3) bulk (r/w) with lots of data learned from other routing protocols
(draft-ietf-i2rs-l3-network-topology) + checks on static configured
protocols 
  4) bulk (r/w) with rpcs that are "high-speed" using only checks on 8.3.1 +
ephemeral requirements (1-15)   

The purpose was to allow the constraint checking to be tailored to the data
model.  The I2RS architecture (especially section 6 and 7) are accurate. 

> > For operational state listed in ephemeral constraints going quickly 
> from TRUE to FALSE, please note that an event notification will be sent to
the
> I2RS Client.   See the event-notification draft for specifics. 

New notification drafts: 
Draft-gonzalez-netconf-5277bis-02,
Draft-gonzalez-netconf-event-notifications,
draftvoit-netconf-restconf-notif-00.txt 

Changes queued for -13 based on this message: 

   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.

  Ephemeral-REQ-13: 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.
  The requirement to support multi-headed control is
  required for collisions and the priority resolution of collisions.

 Awaiting responses on:  Ephemeral-REQ-03, Ephemeral-REQ-04, 
Ephemeral-REQ-09, Ephemeral-REQ-10, Ephemeral-REQ-15. 

Thank you for spending time reviewing these 15 requirements. 

Sue 


-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: Friday, July 1, 2016 6:45 AM
To: shares@ndzh.com
Cc: i2rs@ietf.org; jhaas@pfrc.org
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt-
2 week WG LC (6/21 to 7/5/2016)

Hi,

Comments inline.


"Susan Hares" <shares@ndzh.com> wrote:
> Martin: 
> 
> Thank you for the comments.  Please see the responses inline. 
> 
> One bit of background may help in Ephemeral-REQ-11 through
Ephemeral-REQ-14.
> While NETCONF/RESTCONF is specified in this version the ephemeral 
> requirements, other protocols may be included in the future (PROTOBUF,
etc).
> At that point, this document would be expanded to include these other 
> protocols.
> 
> Summary:  Changes limited to /Yang/YANG/ change.  Other changes may 
> occur upon further details.
> 
> Sue
> 
> 
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin 
> Bjorklund
> Sent: Wednesday, June 29, 2016 6:50 AM
> To: i2rs@ietf.org
> Subject: Re: [i2rs] FW: I-D Action: 
> draft-ietf-i2rs-ephemeral-state-10.txt-
> 2 week WG LC (6/21 to 7/5/2016)
> 
> "Susan Hares" <shares@ndzh.com> wrote:
> > This begins a 2 WG LC last call on the text of 
> > draft-ietf-i2rs-ephemeral-state-10.txt.
> > 
> > Hi,
> > 
> > I have reviewed draft-ietf-i2rs-ephemeral-state-11, and here are my 
> > comments.
> > 
> > 
> > >o  Ephemeral-REQ-02
> > >
> > > I suggest you remove the text:
> > >
> >  >   it SHALL be considered a validation error if it does.
> > >
> >  > The requirement is clear as it is without this.  And maybe the
> > >   solution will make sure it is not even syntactially possible to
> >  >  define such constraints.
> > 
> >  Sue: Since the I2RS debate requested this be added for clarity and  
> >  you have stated the requirement is clear - it will be left in the 
> >  requirements.
> >  It would be wonderful if the solution prevented this syntax. 
> > 
> > Summary: No change here
> > 
> > >o  Ephemeral-REQ-03
> > >
> > > I think you need to define what you mean with "constraint".  For
> > > normal config, YANG has very detailed rules about when constraints  
> > > are checked and what a server MUST do when a constraint becomes
> > > false.
> > 
> > >   Since this requirement says that constraints can refer to fast  
> > > changing state, you need to say what should happen if such a
>  > constraint suddenly becomes false due.
> > 
> >   For the I2RS state which is ephemeral configuration state, the 
> > constraints may have all of 8.3 in yang 1.1 or part of the yang 1.1 
> > constraint.
> >  The final definition of the ephemeral configuration state depends on 
> > the design of operational state modules.

> This explanation helps to understand this requirement.  You obviously have
some ideas what "constraint" means, and that it means different things for
config and state.  
>  This should go into the document, but see below.

With respect, we have gone 4 rounds with different NETCONF experts.   Each
with a different suggestion to put in/take out. However, since you have
asked: 

There are 4 classes of I2RS ephemeral configuration state checking we have
defined so far: 
  1) normal (r/w) of drafts (draft-ietf-i2rs-rib-data-model)  - check 8.3.1,
8.3.2, 8.3.3 + ephemeral requirements (1-15) 
  2) bulk (r/w) within rpcs (see draft-ietf-i2rs-rib-data-model) -
constraints check interfaces (real configuration) + checks on route overlay
(Ephemeral 7) + Ephemeral (-15)  
  3) bulk (r/w) with lots of data learned from other routing protocols
(draft-ietf-i2rs-l3-network-topology) + checks on static configured
protocols 
  4) bulk (r/w) with rpcs that are "high-speed" using only checks on 8.3.1 +
ephemeral requirements (1-15)

We desire to be able to define additional data constraints per data model.
These additional constraints can go in rpcs. 
   
>> Every effort we have made to tie this down has resulted in cycles of 
>> unproductive discussion.  Therefore, this portion will not be re-opened.

>If you specify a requirement, isn't it fair to expect that the requirement
is clear and well-understood?  
>Since the requirement is there, you obvsiously have some *behavior* in mind
(I am not talking about a solution).  
>Just stating that "ephemeral state may have constraints" w/o a definition
of what 'constraint' means doesn't help much.

 The I2RS architecture and these I2rs ephemeral requirements have been
around for 2 years. 
>From the I2RS perspective, these constraints have not changed. We have added
data models. 
However, every time we try to put in constraints - it hits some
netconf/netmod experts idea of operational versus
Ephemeral configuration state.  We have tried enlisting friendly editing,
only to find 
Some other netconf/netmod expert objects to it. Perhaps after the
netconf/netmod experts agree on 
Operational state we can make some significant forward progress.  

>> For operational state listed in ephemeral constraints going quickly 
>> from TRUE to FALSE, please note that an event notification will be sent
to the
>> I2RS Client.   See the event-notification draft for specifics. 

> Which draft do you mean?
Draft-gonzalez-netconf-event-notifications.


> > o  Ephemeral-REQ-04
> >  The requirement says that ephemeral state can refer to 
> > non-ephemeral state in constraints.  Does the term "non-ephemeral 
> > state" include configuration?  If so, does this mean that if an 
> > operator tries to delete some config, the existance of some  
> > ephemeral state may reject the config change request?
>> 
>> Sue: Please refer to the sentence in the top of this section: 
>>   In requirements Ephemeral-REQ-01 to Ephemeral-05, Ephemeral state is
>>    defined as potentially including both ephemeral configured state and
>>    operational state.

> I am well aware of this definition.

> > Non-ephemeral state can be configuration or operational state (e.g. 
> > MPLS LSP-ID
> > or BGP RIB).    

> I suggest this is made explicit in the document; it is not clear from the
current defintion.
I suspect you mean definition. 

How about: 
   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. 
   

>> If the operator deletes some "local configuration" (in I2RS terms), 
>> and the I2RS Ephemeral state depends on the local configuration - the 
>> I2RS agent will Provide a notification that the ephemeral 
>> configuration state or the Operational state defined in an ephemeral 
>> model is no longer valid.
>> The I2RS client must handle this one. 

> Again, this explanation really helps!  It should go into the document.
OR, if this is explained in another document, a pointer to that text would
be great.
See section 6.3 of RFC7921.   We put these references in, and Juergen asked
for their removal as TMI (too much information).   
Please check with other netconf/netmod experts before we put-in/take-out
again.   

>Clarifacation question: does this mean that the ephemeral state in question
is removed and a notification is sent, or that the ephemeral state is still
present, but not used, and a notification is sent?
Clarification question:   It is possible any time the ephemeral state goes
from active to inactive (see draft-ietf-i2rs-rib-data-model), or if state is
removed (see draft-ietf-i2rs-rib-data-model)   

>> Summary: No change
Summary:   
  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. 
   
 
> 
> o  Ephemeral-REQ-07
> 
>  >This requirement says:
> >
> >    "Implementations MUST provide a mechanism..."
> >
> >  Does this mean that this mechanism should not be standardized; 
> > rather implementations are required to invent some vendor-specific 
> > mechanism?
> 
> Sue:  Previous netconf/netmod reviewers have cautioned the I2RS WG on 
> defining a solutions.  If the NETCONF/NETMOD does not define a 
> solution - then the implementation should provide a solution.
> Of course, a standardized solution would be preferred. 

>I agree that this document shouldn't specify a solution.  This document's
role is to define requirements for a solution (not for implementations).
Maybe simply:
>
>OLD:

 > Implementations MUST provide a mechanism to choose which takes
  > precedence.

>NEW:

 > It MUST be possible to choose which takes precedence.

Sue:  This was part of an earlier version, but people felt we must indicate
what chooses. 
Summary: No change 


>>  >o  Ephemeral-REQ-08
>>  >
> > > I understand "ephemeral" and "read/write".  But what does  > 
>>  "status/configuration" mean in this context?  Can I have  >  
> > "ephemeral, read-only, configuration"?  Can I have  > "ephemeral, 
> > write, status"?
> >
> > > 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.
> 
> > Here we are indicating that Ephemeral state may be Ephemeral 
> > configuration state or Operational state.

> I understand that.

> > Every time we have not used "ephemeral", "read/write", 
> > "status/configuration"  - we have bumped into someone's operational 
> >  data model.
> > Unless the netmod group has a finalized version of operational state, 
> > it will Remain this way.

> This doesn't make any sense to me.  This is a requirement to YANG, and I
do not understand how to interpret this requirement.  

Martin - I apologize, but I keep getting request to change to different
answers based on different "yang experts" opinion.  
I respect your expertise and your questions 

> My questions were simple:
> Can I have "ephemeral, read-only, configuration"? 
You are missing a key point.  Different I2RS agents have different
permissions. 
For I2RS agent 1, you can have ephemeral, read-only configuration because
Agent 1 does not have permission to write this section of the data models.
For I2RS agent 2 (who has permission to read this portion of the data
model), the data will be ephemera, configuration, read/write.    

This is part of the normal case of the I2RS client-I2RS agent. 

>  Can I have "ephemeral, write, status"?
It is possible if you allow a remote client permission to clear counters
prior to sending. 
This is possible if the I2RS data model allows read and clear.  

> If we don't understand the requirement, it will be difficult to propose a
solution.  All I'm asking for is clarification of the requirement.
I am glad to walk through this section with you.  

Summary: Still waiting on answers to determine if change is needed. 

> > o  Ephemeral-REQ-09
> > 
> > >   This requirement is fine, but why is it labeled *changes* to 
> > > NETCONF?  NETCONF already supports this requirement.
> >  
> > Do you really support the following: 
> > 
> >   1.  Support for communication mechanisms to enable an I2RS client to
>  >       determine that an I2RS agent supports the mechanisms needed for
>  >  I2RS operation.

> > Sure, by using std YANG features and/or protocol capabilities.

Ok.  How easy is it for the I2RS client to request this of the NETCONF
server or 
RESTCONF server?  This requirement underscores that it must not only be
possible, but 
Easy for the client to query. 

>>    2.  The ephemeral state must support notification of write conflicts
>>       using the priority requirements defined in section 7 below in
> >      requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).

> > NETCONF the protocol supports notifications; it is not involved in the
semantics for when/how these notifications are generated.
> > I think this requirement probably should not be directed to NETCONF.

People woho have been working in netconf are actively supporting changes to
event notifications for netconf  (draft-gonzalez-netconf-4277bis-02,
draft-gonzalez-netconf-evnet-notifications-00) or restconf
(draft-voit-netconf-restconf-notif-00).  Where else would you suggest the
write conflict is provided?  Early reports to I2RS during protocol selection
claimed this was the place to work.  

>> This is not what other netconf/netmod people have indicated. 

> If I'm not mistaken, Andy said the same thing re capabilities.
Andy did same the same thing on #1.  However, the emphasis is going from
"possible" to "easy".  

> Summary: Need response on -09 and -10 before changing.

Summary:  Awaiting confirmation on "write-conflict" prior to any change. 

> > >o  Ephemeral-REQ-10
> > >
> > >   This requirement is fine, but why is it labeled *changes* to 
> > > RESTCONF?  RESTCONF already supports this requirement.
> > 
> > Are you really sure you support priority requirements as specified in 
> > items Ephemeral-REQ-11 through Ephemeral-REQ-14?
> > Not what other people have said.  Does not hurt if you do? 
> > 
> Summary: Need response on -09 and -10 before changing. 

> See above.
See answers above as well. 

> >o  Ephemeral-REQ-13
> >
>  >  I do not understand what this requirement means.
> >
> >   (BTW, the text should be rephrased; it now says "the requirement 
> > ... is required ...")
> 
>    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.
> 
> I believe this text refines the requirement to support multi-headed 
> control to only be required for collisions and priority resolution of
collisions.

Ok, this makes it clearer.  Maybe you can do:

OLD:

  The requirement to support multi-headed control is
  required for collisions and the priority resolution of collisions.

NEW:

 Multi-headed control is required for collisions and the priority
resolution of collisions.

> Perhaps you understood the English in a different manner. 
> 
> This text is terse, and assumes you understand the I2RS architecture. 
> Rather than repeat that text here, perhaps you will review it and see 
> if you then understand this text.
> We have been terse based on feedback from netconf/netmod reviewers. 

Terse is fine, as long as it is clear.  Pointers to other documents are also
fine, they help the readers to understand what you had in mind.

Summary: 
Will change to: 
/Multi-headed control is required for collisions and the priority
resolution of collisions./ 


> >o  Ephemeral-REQ-14
> >
> > If this is not a new requirement, does it need to be part of this  
> > document?
> > If the answer is yes, are there other things from the architecture 
> > document that should be listed here, e.g., details about priority  
> > interaction w/ local config?
> 
> Again, we were cautioned in our early discussions not to define the 
> solution or to assume a solution in I2RS requirements.
> 
> Summary: No change

> Actually, you *did* change this in -12, to the better!

Yes.  I'm glad you liked it. 

> >o  Ephemeral-REQ-15
> > > I do not understand what this requirement means.
>> 
> >  Example: 
> > 
> > I2RS client                I2RS Agent 
> >  ===========          =============
> >  Message 0 [query to see if eth0 is up] 
> >                                 [response eth0 is up ] Message 1 
> > [install I2RS Static route associated with eth0 ] Message 2 [install 
> >  BGP I2RS route dependent on I2RS static route]
>  >                               [Message 1-reply success]
>  >                                [Message 2-reply success]
>  > 
> > Message 1 and Message 2 are individual actions but linked.  However, 
> >  Message 2 will not work if the I2RS static route has not be installed.
> > 
> > I2RS does not include roll-back or atomicity of Message 1 and Message 2.

> > It requires that the I2RS client know the status of each action. 
> > 
> > None of these multiple message sequences should allow the I2RS agent 
> > to insert errors into the Ephemeral Configuration state or Ephemeral 
> >  operational state.
> >
> > Does this example help? 

> Well, I think that this follows from the requirements on 'constraints', so
this requirement is at best redundant.
Perhaps this is true, however this text is the result of 4 weeks of debate.
The compromise for all participants was to place this requirement.  If you
feel it is redundant, you are aligning with some of the people in the
debate. 

> The text is also not very clear.  For example it talks about "not insert
errors".  What is an "error" that could be inserted?  What you probably mean
is that all constraints MUST be true.

No - we mean that multiple messages MUST not insert an error.  Andy Bierman
states if we allow less than the current constraints (8.3.1, 8.3.2, 8.3.3 in
netconf) and the current netconf constraints we could have a error in the
ephemeral configuration data store.   We simply state this MUST not happen. 

For some models using the high-speed update with minimal checking, the I2RS
is willing to provide self-checks of the data.   If you mix this type (type
4 above) and the normal type, perhaps you could get an error.  The
self-checking would then detect it, invalidate all the "invalid" data and
send a notification to the I2RS client that the data has been invalidated.
This is not what we are focusing on here. 


> /martin




> 
> Summary: No changes
> 
> o  general
> 
>    s/Yang/YANG/g
> 
> Thank you - I will change this after other revisions have been suggested. 
> 
> 
> /martin
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>