Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

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

Martin: 

Thank you for reviewing this option.  In your opinion, how long do you think
the generic solution based on the draft-ietf-netmod-revised-datastores will
take to complete? 

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Martin Bjorklund
Sent: Thursday, March 16, 2017 4:18 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

Hi,

So this new option 3 tries to fast-track what's being done in
draft-ietf-netmod-revised-datastores.  It has to solve many of the issues
that we face in that draft.  It is not clear to me that this will produce a
result that (i) is completed much faster than that draft and (ii) is
guaranteed to be compatible with the solution in that draft.

So I still think that option 1 is the best way forward (unless this draft
can wait for the generic solution in draft-ietf-netmod-revised-datastores).


/martin


Kent Watsen <[e-mail]> wrote:
> Hi Martin,
> 
> Speaking with the authors offline late last week, this discussion 
> regarding OPTION-2 came up, and I mentioned again my concerns for CON 
> 'c':
> 
>   c) unable to return the opstate value for any configured node
>  
> ...to which the Xufeng suggested we take your idea to heart.
> Specifically, rather than augment <get-config>, let's look-ahead and 
> use the opstate <get-data> RPC (including the 'origin' attribute) now.  
> This way, <get-config> would return the configured value, while 
> <get-data> could return the applied value, as well as the system 
> generated/learned topology.  So, as in previous fashion, I formally 
> submit OPTION 3:
> 
> 
> 
> OPTION 3: use new RPC <get-topo-data>, which is just like <get-data>
> --------------------------------------------------------------------
> 
> This option defines a new RPC called <get-topo-data> that is fashioned 
> directly after the <get-data> RPC from the revised-datastores draft.
> The RPC is renamed for fear of conflicting with any possible future 
> changes that may occur to the planned <get-data> RPC.  The 
> <get-topo-data> RPC would take an optional 'with-origin-data' selector to
return the 'origin' attribute.
> 
> PROS:
>   a) does NOT break legacy clients (how we got here).
>   b) ability to return the opstate value for any configured node.
>   c) minimal rewrite of the module for revised-datastores solution.
> 
> CONS:
>   a) seems like a shady thing for an IETF module to do.
>   b) would need to resolve other issues (e.g., how to support with
>      RESTCONF), which makes the draft quite a bit more than just
>      a module draft.
>   c) requires server to support metadata, which is a relatively
>      new concept and maybe not well supported by servers.
> 
> 
> Thanks,
> Kent
> 
> 
> 
> -------ORIGINAL MESSAGE-------
> >>>> 2) It doesn't say anything about how the opstate data is stored on
the
> >>>>    server.  The opstate data is not modeled at all.  This approach
> >>>>    only defines a presentation-layer format for how opstate data can
> >>>>    be returned via an RPC.  The server is free to persist the opstate
> >>>>    data anyway it wants, perhaps in an internal datastore called
> >>>>    'operational-state' or in an uber-datastore with the opstate data
> >>>>    flagged with a datastore='oper-state' attribute.  Regardless, it's
> >>>>    an implementation detail, and the conceptual datastore model is
> >>>>    preserved.
> >>> 
> >>> You are essentially defining a new operation, but do it by 
> >>> modifying the semantics of an existing one.  I don't think this is 
> >>> a good idea; it is better to define a new rpc.
> >> 
> >> [Xufeng] Is using a new rpc is acceptable? If so, this could be a 
> >> viable option.
> >
> >The draft-ietf-netmod-revised-datastores proposes a new rpc (maybe
> ><get-data>) to return data from the new operational-state datastore.
> >This is IMO better than adding opstate nodes to the reply to a 
> ><get-config> request.
> 
> 
> Martin,
> 
> Going back your earlier "better to define a new rpc" comment, I fail 
> to see how this proposal is significantly different than RFC 6243.
> 
> If not this, then the new RPC would be something like <get-config-ex> 
> more than the planned <get-data>, as the goal is to return 'running'
> + "some opstate" (not just opstate).
> 
> Still, in looking the the pros/cons, Option 1 appears stronger - only 
> the authors don't like the idea of having to rewrite their models 
> later...
> 
> Kent
> 
> 
> 
> 
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> 

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