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

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Mar 2017 09:17:50 +0100 (CET)

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
> 
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Mar 2017 08:36:03 -0400

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:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Thursday, March 16, 2017 4:18 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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 <[email-masked]> wrote:
> regarding OPTION-2 came up, and I mentioned again my concerns for CON 
> 'c':
> 
> use the opstate <get-data> RPC (including the 'origin' attribute) now.  
> This way, <get-config> would return the configured value, while 
> 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.
> >>> 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.
> >
> Going back your earlier "better to define a new rpc" comment, I fail 
> to see how this proposal is significantly different than RFC 6243.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Mar 2017 13:52:21 +0100 (CET)

>From the authors' pow, we believe we have addressed all technical
issues.  The document needs to be split into protocol documents and a
pure architecture document; this will happen after Chicago, if the WGs
(NETCONF and NETMOD) agree.  Of course, in the end the fate of the
document is up to the WG to decide about...

/martin

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Mar 2017 13:41:18 -0400

Martin: 

As always - you provide just the right information.  I2RS will meet after
the NETCONF meeting and the 1st NETMOD meeting, so we'll be able to adapt to
WGs actions.   Thank your (you and your co-authors) excellent work on
draft-ietf-netmod-revised-datastores. 

Sue 

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

"Susan Hares" <[email-masked]> wrote:
> 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?

>From the authors' pow, we believe we have addressed all technical
issues.  The document needs to be split into protocol documents and a pure
architecture document; this will happen after Chicago, if the WGs (NETCONF
and NETMOD) agree.  Of course, in the end the fate of the document is up to
the WG to decide about...

/martin

> draft and (ii) is guaranteed to be compatible with the solution in that
draft.
> > CON
> > This option defines a new RPC called <get-topo-data> that is 
> > fashioned directly after the <get-data> RPC from the revised-datastores
draft.
> > >>>> 2) It doesn't say anything about how the opstate data is stored 
> > >>>> on
> the
> > >>> modifying the semantics of an existing one.  I don't think this 
> > >>> is a good idea; it is better to define a new rpc.
> > >> 
> > 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'
> > 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
> > 
> > 
> > 
> > 
> >