Subject: Re: [i2rs] [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Jun 2016 12:10:09 -0400

Lou: 

Thank you for your work on the two options.  I'd like to comment on the
following statement in your message statement, and reference a few things in
[4] and [5] regarding ephemeral state: 

You state: 
"  2) Model OpState using a revised logical datastore definition
       as introduced in [4] and also covered in [5]. There is
       also a variant of this that we believe doesn't significantly
       impact this choice.  
       With this approach, model definitions need no explicit
       changes to support applied configuration."

In [4], the author states: 

   "o  The model foresees ephemeral datastores that are by definition not
      part of the persistent configuration of a device.  These ephemeral
      datastores are considered to interact with the rest of the system
      like any other control-plane mechanisms (e.g., routing protocols,
      discovery protocols).  [XXX Note that this is different from what
      is described in some of the I2RS documents.  XXX]"

In [5], the author states: 

"5.5.  Ephemeral Configuration Datastore (Optional)
   This document does not intend to formally define an Ephemeral
   Configuration Datastore.  In particular, it must be noted that the
   ephemeral configuration datastore described here does not match that
   described in version -09 of draft-ietf-i2rs-ephemeral-state
   [I-D.ietf-i2rs-ephemeral-state].  Instead, it describes conceptually
   how such a datastore (restricted to configuration only) might fit
   into a conceptual refined datastore model."

Therefore, the result of I2RS WG spending 2 years writing requirements for
the ephemeral data store that both option 2 documents "do not  match" the
I2RS ephemeral requirements set.  [4] lumps ephemeral with operational
state.  [5] provides an ephemeral architecture closer to I2RS ephemeral
requirements, but does not understand that draft-ietf-i2rs-ephemeral-state
is a requirements document.    Your statement " With this approach, model
definitions need no explicit changes to support applied configuration"
cannot be true if you consider the I2RS data models (RIB, topology). 

How is option (2) a reasonable design for ephemeral state?  I have spent the
last week answering questions to Juergen [4] on the I2RS ephemeral state.
After our discussion, he did not have any specific suggestions to change
these requirements
(https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html).  

Can I have an option 2b that considers ephemeral state based on the
requirements listed by I2RS? 

 Sue Hares  
 I2RS WG-chair 

-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
Lou Berger
Sent: Wednesday, June 08, 2016 9:06 AM
To: [email-masked]
Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions:
update and request for WG input

FYI this decision is likely to have some impact on models under development,
including in the routing area. Comments on the message itself should go to
netmod.

Lou

--- Forwarded message ---
From: Lou Berger <[email-masked]>
Date: June 7, 2016 10:20:23 AM
Subject: [netmod] Opstate solutions discussions: update and request for WG
input
To: netmod WG <[email-masked]>
CC: [email-masked]

All,

We want to provide an update based on the off line discussions related to
OpState Solutions that we have been having and solicit input from the WG.

All authors of current solution drafts [1,2,3] together with those who
helped conduct the solutions analysis* were invited to the these discussions
-- with the objective of coming up with a single consolidated proposal to
bring to the WG. (I/Lou acted as facilitator as Kent and Juergen were and
are involved with the technical details.)

The discussions have yielded some results but, unfortunately, not a single
consolidated proposal as hoped, but rather two alternate directions -- and
clearly we need to choose one:

    1) Adopt the conventions for representing state/config
       based on Section 6 of [1].

       From a model definition perspective, these conventions
       impact every model and every model writer.

    2) Model OpState using a revised logical datastore definition
       as introduced in [4] and also covered in [5]. There is
       also a variant of this that we believe doesn't significantly
       impact this choice.

       With this approach, model definitions need no explicit
       changes to support applied configuration.

>From a technology/WG standpoint, we believe an approach
that doesn't impact every model written (i.e., #2) is superior.
The counterpoint to this is that the conventions based approach (i.e., #1)
is available today and being followed in OpenConfig defined models.

We would like to hear opinions on this from the WG before declaring one of
the following as the WG direction:

    A) models that wish to support applied configuration MUST
       follow conventions based on [1] -- and the WG needs to
       formalize these conventions.
or
    B) no explicit support is required for models to support
       applied configuration -- and that the WG needs to
       formalize an opstate solution based on the approach
       discussed in [4] and [5].

We intend to close on this choice before Berlin.

Thank you,
Lou (and co-chairs)

[1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
[2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
[3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
[4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
[5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
* - Chris H. and Acee L.

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
Rtg-yang-coord mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Jun 2016 12:23:23 -0400

Sue,

I think you're looking a step beyond the scope of decision we're
considering now. This is a fine thing, and certainly the right thing to
be thinking about from the I2RS (or any other WG working on YANG models
that is considering operational state for that matter) perspective.

The decision at hand is to choose between directions A and B.  I think
you are saying you that you like direction B but that the details aren't
sufficient for your (WG's) needs.  Is this correct?

If so, then I think you're point is that [4] and [5] need work.  We
agree with this statement and we believe consistent with the statement in B:

    -- and that the WG needs to
       formalize an opstate solution based on the approach
       discussed in [4] and [5].

So, once the WG closes on direction B (before Berlin), the WG can then
start discussing details of the WG's version of [4] and [5] -- and
issues on ephemeral support makes sense to discuss then if they still
haven't been addressed.   Of course discussion on the individual drafts
don't need to wait for the decision on basic direction.

Make sense?

Lou

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Jun 2016 12:52:33 -0400

Lou: 

My email message was to express my concerns as I2RS co-chair.  
<WG co-chair hat on> 
  [A] does not even consider ephemeral.  [B] at least considers it, but does
not match I2RS requirements.  As I2RS WG Chair, both [A] and [B] have
problems.  
<WG co-chair hat off> 

<individual contributor hat on> 
 Either [A] or [B] work as long as ephemeral state gets handed.  On B, at
least [4] and [5] at least give some ideas on handling ephemeral state. I
will work with authors [1][2][3][4][5] to suggest ephemeral improvements.
Will getting support [A] or [B] to work as individual contributor. 
<individual contributor hat off> 
Sue Hares 

========= 

 .   [A] does not even consider ephemeral.  [B] at least considers it, but
does not match it.  As I2RS WG Chair, [A] and [B] both has problems.  
<WG chair hat off> 
<individual contributor> 
[A] - will not cause me to re-write data models.  All data models (BGP,
I2RS) have split between operational data and configuration data. 
[B] As individual contributor, I appreciate that [4] and [5] at trying to
work through the details of ephemeral.  [5] has a really good diagram in
section 4 that would work for I2RS Ephemeral Configuration State.  [5] uses
the term "ephemeral configuration datastore" and correctly understands what
a get of the ephemeral datastore should result in.  It also allows multiple
layers.  However, [5] has not considered the multi-headed issues in the I2RS
ephemeral requirements.  
</individual contributor off> 
-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
Lou Berger
Sent: Wednesday, June 08, 2016 12:23 PM
To: Susan Hares; [email-masked]
Cc: 'Benoit Claise'; [email-masked]; 'Alia Atlas'
Subject: Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions:
update and request for WG input

Sue,

I think you're looking a step beyond the scope of decision we're considering
now. This is a fine thing, and certainly the right thing to be thinking
about from the I2RS (or any other WG working on YANG models that is
considering operational state for that matter) perspective.

The decision at hand is to choose between directions A and B.  I think you
are saying you that you like direction B but that the details aren't
sufficient for your (WG's) needs.  Is this correct?

If so, then I think you're point is that [4] and [5] need work.  We agree
with this statement and we believe consistent with the statement in B:

So, once the WG closes on direction B (before Berlin), the WG can then start
discussing details of the WG's version of [4] and [5] -- and issues on
ephemeral support makes sense to discuss then if they still
haven't been addressed.   Of course discussion on the individual drafts
don't need to wait for the decision on basic direction.

Make sense?

Lou

On 6/8/2016 12:10 PM, Susan Hares wrote:
> Lou: 
>
> Thank you for your work on the two options.  I'd like to comment on 
> the following statement in your message statement, and reference a few 
> things in [4] and [5] regarding ephemeral state:
>
> You state: 
> Therefore, the result of I2RS WG spending 2 years writing requirements 
> for the ephemeral data store that both option 2 documents "do not  
> match" the I2RS ephemeral requirements set.  [4] lumps ephemeral with 
> operational state.  [5] provides an ephemeral architecture closer to 
> I2RS ephemeral requirements, but does not understand that
draft-ietf-i2rs-ephemeral-state
> How is option (2) a reasonable design for ephemeral state?  I have 
> spent the last week answering questions to Juergen [4] on the I2RS
ephemeral state.
> After our discussion, he did not have any specific suggestions to 
> change these requirements 
> From: Rtg-yang-coord [mailto:[email-masked]] On 
> Behalf Of Lou Berger
> FYI this decision is likely to have some impact on models under 
> development, including in the routing area. Comments on the message 
> itself should go to netmod.
>
> Lou
>
>
> Subject: [netmod] Opstate solutions discussions: update and request 
> for WG input
> We want to provide an update based on the off line discussions related 
> to OpState Solutions that we have been having and solicit input from the
WG.
> -- with the objective of coming up with a single consolidated proposal 
> to bring to the WG. (I/Lou acted as facilitator as Kent and Juergen 
> were and are involved with the technical details.)
>
> The discussions have yielded some results but, unfortunately, not a 
> single consolidated proposal as hoped, but rather two alternate 
> directions -- and clearly we need to choose one:
>
> The counterpoint to this is that the conventions based approach (i.e., 
> #1) is available today and being followed in OpenConfig defined models.
>
> We would like to hear opinions on this from the WG before declaring 
> one of the following as the WG direction:
>
> [4] 
> https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
> [5] 
> https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
> * - Chris H. and Acee L.
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 8 Jun 2016 10:39:09 -0700

Hi Lou,

I would say 2 steps ahead.
Step 1 seems to be to reconfirm the meeting room consensus from Yokohama
(model-based vs. protocol-based)

Step 2 is usually picking a starting point for a solution draft.

Step 3 is when people can start detailed solution reviews.

IMO [4] is a good starting point but there are many open issues that need
to be resolved,
possibly addressed in the other drafts.

Andy

On Wed, Jun 8, 2016 at 9:23 AM, Lou Berger <[email-masked]> wrote:

> for
> development,
> single
> #1)

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Jun 2016 19:40:28 +0200 (CEST)

Hi Sue,

>       is described in some of the I2RS documents.  XXX]"

[...]

> state.

I don't think this last sentence is correct.  Admittedly, the details
about ephemeral in [4] are not worked out (by design).  But the idea
was not to "lump ephemeral and operational state".  The idea was
rather that the content of ephemeral datastore(s) would interact with
the applied config to produce the resulting operational state.

If the WG agrees that B is the right way to go, we'll need to work out
all the details about how the ephemeral datastore(s) work.

The main point is that [4] (and [5]) provides an architecture into
which ephemeral datastores can fit.

/martin

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Jun 2016 15:27:07 -0400

Andy, (Sue)

    Valid point -- either way the WG will get to Ephemeral *after* the
direction question is settled.

Lou

On 6/8/2016 1:39 PM, Andy Bierman wrote:
> IMO [4] is a good starting point but there are many open issues that
> need to be resolved,
> On Wed, Jun 8, 2016 at 9:23 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Sue,
>
>     > From: Rtg-yang-coord [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of
>     > Lou Berger
>     > To: [email-masked] <mailto:[email-masked]>
>     > From: Lou Berger <[email-masked] <mailto:[email-masked]>>
>     > To: netmod WG <[email-masked] <mailto:[email-masked]>>
>     > CC: [email-masked] <mailto:[email-masked]>
>     >
>     > All,
>     >
>     > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jun 2016 09:37:06 +0200

> I2RS ephemeral requirements set.  [4] lumps ephemeral with operational

I tried to bring [4] to the attention of I2RS; nobody ever claimed
that [4] is a final solution. I did ask concrete questions on the I2RS
list concerning I2RS requirements and what the various terms used in
the description of I2RS requirements actually mean. The outcome were
some changes (I think) but there are also requirements I still find
unclear (but where we keep going in circles). That said, I do not
think '[4] lumps ephemeral with operational state' is a fair statement
either.

Anyway, as Lou explained, the subject of this thread is to decide on
the general direction and once we have agreement on the direction, I
am sure there will be further work on the details of the architectural
solutions on the table. And yes, this is then the time to settle what
an I2RS ephemeral datastore is and how it integrates conceptually and
architecturally with the rest.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 9 Jun 2016 09:42:42 -0400

Juergen: 

I'm sorry you felt "lumps in with operational state" [4] was pejorative, it
was not intended to be.    100% agree - pick between option A and B, and
then come back to ephemeral.   If you have specific changes to the text, we
still welcome your comments on the ephemeral requirements document. 

Considering your questions on how constraints work in section 8.3 of
draft-ietf-netmod-6020bis-12 has led me to reconsider how these constraints
apply to ephemeral state. 

Sue 

-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Thursday, June 09, 2016 3:37 AM
To: Susan Hares
Cc: [email-masked]; 'Benoit Claise'; 'Lou Berger'; 'Alia Atlas';
[email-masked]
Subject: Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions:
update and request for WG input

On Wed, Jun 08, 2016 at 12:10:09PM -0400, Susan Hares wrote:
> operational state.

I tried to bring [4] to the attention of I2RS; nobody ever claimed that [4]
is a final solution. I did ask concrete questions on the I2RS list
concerning I2RS requirements and what the various terms used in the
description of I2RS requirements actually mean. The outcome were some
changes (I think) but there are also requirements I still find unclear (but
where we keep going in circles). That said, I do not think '[4] lumps
ephemeral with operational state' is a fair statement either.

Anyway, as Lou explained, the subject of this thread is to decide on the
general direction and once we have agreement on the direction, I am sure
there will be further work on the details of the architectural solutions on
the table. And yes, this is then the time to settle what an I2RS ephemeral
datastore is and how it integrates conceptually and architecturally with the
rest.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 9 Jun 2016 09:48:56 -0400

Martin: 

I agree [4] and [5] provide possible architectures that ephemeral could fit
into as part of choice [B].  

Sue 
-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Wednesday, June 08, 2016 1:40 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] [Rtg-yang-coord] Fwd: [netmod] Opstate solutions
discussions: update and request for WG input

Hi Sue,

[...]

> match" the I2RS ephemeral requirements set.  [4] lumps ephemeral with 

I don't think this last sentence is correct.  Admittedly, the details about
ephemeral in [4] are not worked out (by design).  But the idea was not to
"lump ephemeral and operational state".  The idea was rather that the
content of ephemeral datastore(s) would interact with the applied config to
produce the resulting operational state.

If the WG agrees that B is the right way to go, we'll need to work out all
the details about how the ephemeral datastore(s) work.

The main point is that [4] (and [5]) provides an architecture into which
ephemeral datastores can fit.

/martin

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs