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

[Kent Watsen <[e-mail]>]

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