Subject: [I2rs-proto-dt] Minutes for 10/2/2015 meeting

From: "Susan Hares" <[email-masked]>
Date: Fri, 2 Oct 2015 13:12:24 -0400

Hi all: 

This week we are trying to close off on an initial I2RS protocol strawman by
next Friday (10/9/2015) at our 10:00-11:30am meeting. 

We will conclude this phase with a protocol strawman document and a set of
slides to present at the I2RS interim on 10/14/2015.  At this point, we will
turn the work over to a small group of NETCONF/I2RS experts to refine and
check the details on the specification.   The I2RS chairs and NETCONF chairs
will select the 3-4 people in that small group

Please review the protocol strawman and send comments by Monday evening.  I
will send sending out on Monday evening: 

1)      2nd revision of the protocol strawman draft, 

2)      example draft with examples from I2RS RIB, I2RS FB-RIB, and I2RS
Topology updates (including link to TEAS draft),

3)      Slides for presentation on the 10/14/2015. 

4)      Proposed BGP I2RS RIB - as some of the questions indicate that BGP
may impact things. 

We'll work on revising this work this week.  

Sue

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Oct 2015 16:46:31 -0400

> will send sending out on Monday evening: 

There's an awful lot of TBD in there.  But given the ephemeral piece is the
critical and messy one, perhaps that's okay.

I can tell from looking at the slides that I've missed some of the
openconfig opstate discussions.  But from that, and prior context, it
appears that the "actual" configuration is being classified as "operational"
state and that the view that the devices receive comes from the logical
merge operation on that view plus the view through the panes of glass.

I sort of like the idea that a single client gets a single pane.  It
simplifies things, but potentially makes things a bit ugly for scaling if
you have too many clients.  This may be less of an issue if the models are
guaranteed some level of disjointness between various panes with regard to
their schemas.

I'm a bit confused by the writeable config false ephemeral true node.  Do we
really want to support that?

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Mon, 5 Oct 2015 15:06:18 -0700

> critical and messy one, perhaps that's okay.

I am curious about bulk-read and bulk-write

IMO we just need 1 GET or 1 PUT type of method.
Using YANG Patch with RESTCONF, multiple edits can be done at once.

> merge operation on that view plus the view through the panes of glass.
I think the terms are "intended config" and "applied config".

It is important to decouple the produce (sensor) from the consumer (applied
config)
The sensor still puts out its operational value but the
system (directed by I2RS edits) uses the injected value
as the applied config instead of the sensor value.

> guaranteed some level of disjointness between various panes with regard to

It is really just an implementation detail, but if N clients map
to 1 priority (like the default priority if the client is not configured)
then the client ID needs to be saved to decide first-1-wins in
any future edit collisions.

> really want to support that?

That is the most controversial part.

Are there YANG objects that are config=false used to model
the derived state?  Does that derived state ever need to
be altered by I2RS?   An alternative would be to have new YANG objects
that represent the I2RS-provided values.  But the config-stmt for
these nodes needs some value.  Clearly it is not true, since NETCONF
is not allowed to edit it.

Whether the derived state objects are edited directly,
or whether new objects that model the "I2RS-overrides"
are used, there still needs to be a way to indicate that
they are only editable in the ephemeral datastore.

   leaf desired-temp {
        type int32;
        config true;
        ephemeral true;
            units "degrees Celsius";
            description "The desired temperature";
            ephemeral true;
            }

     leaf actual-temp {
        type int32;
            config false;
            ephemeral false;
            units "degrees Celsius";
            description "The measured temperature";
            }

    leaf actual-temp-override {
        type int32;
            config false;
            ephemeral true;
            units "degrees Celsius";
            description "Override the actual temperature";
            }

With this design, the "plain" operational state objects are left as-is,
and clones or special overrides are in separate models.

> -- Jeff

Andy

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 Oct 2015 10:10:37 -0400

> Using YANG Patch with RESTCONF, multiple edits can be done at once.

That was my impression as well, but I had guessed that someone had brought
it up as a feature of some sort where I didn't have context.  

I suspect we can drop this section?

> as the applied config instead of the sensor value.

I can grok your use of terminology, but it seems a bit skewed to how I'd
interpret things.

I'd like to suggest you put together the taxonomy section for the start of
the doc.  Or, if you think that the openconfig opstate draft covers it, we
can refer to that one.

> any future edit collisions.

Agreed.  I liked the idea mostly because it avoids having to adjudicate the
collisions.

> is not allowed to edit it.

My thoughts on this depend on the idea of datastores and schema.

Nodes are editable or not.  Whether the node has schema presence in
ephemeral or not is controlled by the ephemeral keyword in the yang.

It *may* be possible that a node is present in both config and in ephemeral
both. Examples are where we want to override things.

The question is how can we signal presence in both?  Do we want to simplify
and say that config datastore is always permitted when ephemeral is?

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 6 Oct 2015 14:18:40 -0400

Andy and Jeff: 

I need a little bit of feedback on the posts you made in order to provide a revision.   I’m really confused by the config=false discussion.  I suggest it might be ok for LSP-ID to have another definition.  Unfortunately, I do not see how it will work for the BGP draft. 

Here’s my changes: 

1)      Fix the terms to "intended config" and "applied config".

2)      Create a usage with RESTCONF PATCH for the single change and for the bulk change 

3)      Look at RPC notes from Kent Watsen. 

On the examples, I need the following examples: 

1)      RIB single route 

2)      RIB bulk 

3)      Topology single route 

4)      Topology bulk

5)      FB-RIB single filter 

6)      FB-FIB bulk filter

I will try to get another draft today. 

Sue 

From: I2rs-proto-dt [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Monday, October 05, 2015 6:06 PM
To: Jeffrey Haas
Cc: [email-masked]; Susan Hares
Subject: Re: [I2rs-proto-dt] Minutes for 10/2/2015 meeting

>> critical and messy one, perhaps that's okay

> Using YANG Patch with RESTCONF, multiple edits can be done at once.

Andy: I had in my notes to create an RPC plus a GET/PUT method. 

           I will start with the Yang Patch and then 

>I think the terms are "intended config" and "applied config".

Andy: I will utilize the new terms in the next revision. 

>It is important to decouple the produce (sensor) from the consumer (applied config)

 

 

 

 

>>is not allowed to edit it.

For operationally created a config=false node and derived state,

LSPs,  BGP Received AdjRIB-In,  BGP received community, BGP received AS Paths.  

 

   leaf desired-temp {

        type int32;

        config true;

        ephemeral true;

            units "degrees Celsius";

            ephemeral true;

            }

     leaf actual-temp {

        type int32;

            config false;

            ephemeral false;

            units "degrees Celsius";

            }

        type int32;

            config false;

            ephemeral true;

            units "degrees Celsius";

            }

The LSP-ID can work in this way, but the BGP AdjRibIn, Communities, and AS Paths would be problematic. 

-- Jeff

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Oct 2015 09:02:45 -0700

Hi,

While I am still thinking about the details...
I think we agreed to a lot of changes:

  1) no need to edit config=false nodes
      - remove "HoldTemp" example and use-case

  2) stop-on-error is not defined for NETCONF (as-is) but
      continue-on-error and all-or-none is well-defined.
      Issue is that the server does not know how to prune unapplied
      or error edits -- up to the client to provide disjoint edits
  2a) NETCONF + YANG Patch would provide ordered edits

   3) no caching at all, so pane of glass per client can be removed
       just 2 panes (ephemeral over running)

  4) need to resolve client-id to priority mapping.  It can be derived
       from AAA, but requirements draft also says NACM group will
      be extended with a priority leaf.  What if both are provided?
      Is this an issue or just an implementation detail?

  5) need to determine how I2RS conformance is determined.
      Unless agent expected to allow ephemeral editing of all
      config=true nodes, then subset needs to be identified.
  5a) client needs to discover what the agent supports
      (for all I2RS options, not just data models)

Andy

On Tue, Oct 6, 2015 at 11:18 AM, Susan Hares <[email-masked]> wrote:

> Andy and Jeff:
>
>
>
> I need a little bit of feedback on the posts you made in order to provide
> a revision.   I’m really confused by the config=false discussion.  I
> suggest it might be ok for LSP-ID to have another definition.
> Unfortunately, I do not see how it will work for the BGP draft.
>
>
>
> Here’s my changes:
>
>
>
> *From:* I2rs-proto-dt [mailto:[email-masked]] *On Behalf
> Of *Andy Bierman
> *Sent:* Monday, October 05, 2015 6:06 PM
> *To:* Jeffrey Haas
> *Cc:* [email-masked]; Susan Hares
> *Subject:* Re: [I2rs-proto-dt] Minutes for 10/2/2015 meeting
>
>
>
>
>
>
>