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

[Andy Bierman <[e-mail]>]

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 <[e-mail]> 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:
>
>
>
> 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
>
>
>