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

["Susan Hares" <[e-mail]>]

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:[e-mail]] On Behalf Of Andy Bierman
Sent: Monday, October 05, 2015 6:06 PM
To: Jeffrey Haas
Cc: [e-mail]; Susan Hares
Subject: Re: [I2rs-proto-dt] Minutes for 10/2/2015 meeting

 

 

 

On Mon, Oct 5, 2015 at 1:46 PM, Jeffrey Haas <[e-mail]> wrote:

On Fri, Oct 02, 2015 at 01:12:24PM -0400, Susan Hares wrote:
> > Please review the protocol strawman and send comments by Monday evening.  I
> > 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 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.

 

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

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

 

 

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

 

 

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

 

 


>>I'm a bit confused by the writeable config false ephemeral true node.  Do we
>>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.

 

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

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

 

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

 

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

 


-- Jeff

 

Andy

 


_______________________________________________
I2rs-proto-dt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs-proto-dt