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

[Susan Hares]

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:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
Sent: Thursday, March 16, 2017 8:52 AM
To: sha...@ndzh.com
Cc: i2rs@ietf.org; kwat...@juniper.net; xufeng.liu.i...@gmail.com
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

"Susan Hares" <sha...@ndzh.com> 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


> 
> Sue
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin 
> Bjorklund
> Sent: Thursday, March 16, 2017 4:18 AM
> To: kwat...@juniper.net
> Cc: i2rs@ietf.org; xufeng.liu.i...@gmail.com
> 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 <kwat...@juniper.net> 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 , let's look-ahead and 
> > use the opstate  RPC (including the 'origin' attribute) now.
> > This way,  would return the configured value, while 
> >  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 , which is just like 
> > 
> > 
> > This option defines a new RPC called  that is 
> > fashioned directly after the  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  RPC.  The 
> >  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
> >

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

[Martin Bjorklund]

"Susan Hares" <sha...@ndzh.com> 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


> 
> Sue 
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
> Sent: Thursday, March 16, 2017 4:18 AM
> To: kwat...@juniper.net
> Cc: i2rs@ietf.org; xufeng.liu.i...@gmail.com
> 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 <kwat...@juniper.net> 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 , let's look-ahead and 
> > use the opstate  RPC (including the 'origin' attribute) now.  
> > This way,  would return the configured value, while 
> >  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 , which is just like 
> > 
> > 
> > This option defines a new RPC called  that is fashioned 
> > directly after the  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  RPC.  The 
> >  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

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

[Susan Hares]

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:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
Sent: Thursday, March 16, 2017 4:18 AM
To: kwat...@juniper.net
Cc: i2rs@ietf.org; xufeng.liu.i...@gmail.com
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 <kwat...@juniper.net> 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 , let's look-ahead and 
> use the opstate  RPC (including the 'origin' attribute) now.  
> This way,  would return the configured value, while 
>  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 , which is just like 
> 
> 
> This option defines a new RPC called  that is fashioned 
> directly after the  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  RPC.  The 
>  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
> >) to return data from the new operational-state datastore.
> >This is IMO better than adding opstate nodes to the reply to a 
> > 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  
> more than the planned , 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
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Martin Bjorklund]

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  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 , let's look-ahead and
> use the opstate  RPC (including the 'origin' attribute) 
> now.  This way,  would return the configured value, while
>  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 , which is just like 
> 
> 
> This option defines a new RPC called  that is fashioned
> directly after the  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  RPC.  The  
> 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
> >) to return data from the new operational-state datastore.
> >This is IMO better than adding opstate nodes to the reply to a
> > 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 
> more than the planned , 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
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Andy Bierman]

On Thu, Feb 16, 2017 at 1:19 PM, Martin Bjorklund <m...@tail-f.com> wrote:

> "Xufeng Liu" <xufeng.liu.i...@gmail.com> wrote:
> >
> >
> > > -Original Message-
> > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin
> Bjorklund
> > > Sent: Tuesday, February 14, 2017 11:41 AM
> > > To: kwat...@juniper.net
> > > Cc: i2rs@ietf.org
> > > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-
> topo
> > >
> > > Kent Watsen <kwat...@juniper.net> wrote:
> > > >
> > > >
> > > > [moving yang-doctors to BCC]
> > > >
> > > >
> > > > >> OPTION 1: separate /foo and /foo-state trees
> > > > >> 
> > > > >>
> > > > >> This option was/is described here:
> > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > > > >>
> > > > >> PROS:
> > > > >>   a) does NOT break legacy clients (how we got here)
> > > > >>   b) consistent with convention used in many IETF modules
> > > > >>   c) able to show if/how opstate may differ from configured values
> > > > >>
> > > > >> CONS:
> > > > >>   a) questionably valid YANG leafref usage
> > > > >
> > > > > What does this mean?
> > > >
> > > > I'm referring to how the description statement explains that the
> > > > server may look to operational state in order to resolve the leafref,
> > > > which is to result in behavior similar to pre-configuration in RFC
> > > > 7223.
> > >
> > > Ok, I didn't pay close attention to the proposal in the quoted email.
> > >
> > > I would design this a bit differently.  The config true leaf
> "dependency"
> > should
> > > have a leafref to the config false node name, with require-instance
> false.
> > The
> > > description should explain that the configuration item will be used by
> the
> > server
> > > if all dependencies exist.  When the configuration item is used, it
> shows
> > up in the
> > > config false list.
> > >
> > > This way, the leafref usage is valid and straight forward.
> > >
> > > > >>   b) complex server implementation (to handle require-instance
> > > > >> false)
> > > > >
> > > > >Can you elaborate on this one?
> > > >
> > > > This is primarily a reflection of the CON listed above, in that it
> > > > seems that a server would need to have special handling for when
> > > > dependencies transition from being present to not-present and vice
> > > > versa, much like the code to handle when a physical card is plugged
> in
> > > > or removed.
> > >
> > > Yes, but I think this is inherent to the problem at hand.  Even with
> the
> > config true
> > > solution defined in the current draft, it is not clear how things that
> > were created
> > > by the server would be deleted (if there were references to them).
> > >
> > > > Note: I should've listed this as a CON for OPTION 2 as well.
> > > >
> > > >
> > > >
> > > > >>   c) eventually the module would need to migrate to the long-term
> > > > >>  solution, which would result in needing to also rewrite all
> > > > >>  modules that have augmented it (e.g., ietf-te-topology).
> > > > >>   d) leafref path expressions really only work for configuration
> > data,
> > > > >>  though a clever server could have a special ability to peak
> at
> > > > >>  the opstate values when doing validations.  Of course, with
> > > > >>  require-instance is false, the value of leafref based
> validation
> > > > >>  checking is negated anyway, even for config true nodes, so
> this
> > > > >>  may not matter much.
> > > > >>
> > > > >>
> > > > >>
> > > > >> OPTION 2: explicit client-option to also return tagged opstate
> data
> > > > >> 
> ---
> > > > >>
> > > > >> This option takes a couple forms.  The first is module-specific

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

[Kent Watsen]

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 , let's look-ahead and
use the opstate  RPC (including the 'origin' attribute) 
now.  This way,  would return the configured value, while
 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 , which is just like 


This option defines a new RPC called  that is fashioned
directly after the  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  RPC.  The  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
>) to return data from the new operational-state datastore.
>This is IMO better than adding opstate nodes to the reply to a
> 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 
more than the planned , 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
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Susan Hares]

Xufeng and Alex: 

 
The WG will need to make the decision on the next steps (not the chair). My
questions (as chair) were simply to clarify the issues.  The AD (Alia) and I
have been asking for input on those who felt the 

If you want to create a proposal for the short term, please do.  

Just to let you know, the shortest time period I have been able to turn
around new proposal to RFC in a WG is 4 months (see IDR's large community
draft).  In this proposal, we had working code, a simple specification, and
operators who wanted the code.   If you feel the topology models  + rpc are
similar to this, please write-up the proposal.  We can hold virtual interims
before IETF in Chicago and after to speed the process. 

Thanks for working so hard on the topology models. 

Sue 
 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, February 16, 2017 4:17 PM
To: 'Susan Hares'; 'Martin Bjorklund'; kwat...@juniper.net
Cc: i2rs@ietf.org
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

Hi Sue,

I agree that the revised data stores solutions is the long term solution,
but it may take a year to complete because it covers a much broader scope.
Are we ok with delaying all these models for another year? This could be the
decision of the Chairs and ADs. Also, this approach seems to be a sub-set of
the long term solution, and they are compatible. If the details can be
worked out, it would be good to have such an interim solution immediately,
which does not need to solve all the problems, but hopefully can migrate to
the long term solution smoothly.

Thanks,
- Xufeng

> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, February 16, 2017 2:53 PM
> To: 'Xufeng Liu' <xufeng.liu.i...@gmail.com>; 'Martin Bjorklund'
<mbj@tail-
> f.com>; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: RE: [i2rs] modeling options for 
> draft-ietf-i2rs-yang-network-topo
> 
> Xufeng:
> 
> I suspect 2 rpcs will be needed, but Martin and Kent are the experts.   Do
> you think trying to accelerate the revised data stores solutions is a
better way to
> go?
> 
> Sue
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
> Sent: Thursday, February 16, 2017 2:48 PM
> To: 'Susan Hares'; 'Martin Bjorklund'; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for 
> draft-ietf-i2rs-yang-network-topo
> 
> Hi Sue,
> 
> > -Original Message-
> > From: Susan Hares [mailto:sha...@ndzh.com]
> > Sent: Thursday, February 16, 2017 2:02 PM
> > To: 'Xufeng Liu' <xufeng.liu.i...@gmail.com>; 'Martin Bjorklund'
> <mbj@tail-
> > f.com>; kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: RE: [i2rs] modeling options for 
> > draft-ietf-i2rs-yang-network-topo
> >
> > To Xufeng:
> >
> > Clarifying question - Are you asking about I2RS topology as a 
> > generic yang model for any configuration or are you asking about 
> > I2RS topology model as
> an
> > ephemeral topology model.
> 
> [Xufeng] I was talking about I2RS topology as a generic yang model for 
> any configuration, but I think that the same solution can be applied 
> to
ephemeral
> case, though a separate rpc might be needed.
> 
> Thanks,
> - Xufeng
> 
> >
> > To Martin:
> > Clarifying questions:
> >
> > 1)  Is your rpc suggest target toward the I2RS topology model as a 
> > generic topology model or an I2RS ephemeral state model or both?
> >
> > 2) Could we define rpcs now that operate as Alex desired for generic
> topology
> > models that could be replaced by more generic mechanisms later?
> > For example, the I2RS RIB has defined rpcs for all major functions
> (add/delete rib,
> > add/delete route, add/delete nexhop) plus notifications for changes.
> > Is
> this the
> > best approach here?
> >
> > Sue
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
> > Sent: Thursday, February 16, 2017 10:39 AM
> > To: 'Martin Bjorklund'; kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for 
> > draft-ietf-i2rs-yang-network-topo
> >
> >
> >
> > > -Original Message-
> > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin 
> > > Bjorklund
> > > Sent: Tuesday, February 14, 2017 11:41 AM
> > > To: kwat...@juniper.net
> > > Cc: i2rs@ietf.org
> > > Subject: Re: [i2rs] modeling options for 
> > > draft-ietf-i2rs-yang-network-topo
> > >
> > > Kent Wa

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

[Kent Watsen]

 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
>) to return data from the new operational-state datastore.
>This is IMO better than adding opstate nodes to the reply to a
> 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 
more than the planned , 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
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Martin Bjorklund]

"Xufeng Liu" <xufeng.liu.i...@gmail.com> wrote:
> 
> 
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
> > Sent: Tuesday, February 14, 2017 11:41 AM
> > To: kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> > 
> > Kent Watsen <kwat...@juniper.net> wrote:
> > >
> > >
> > > [moving yang-doctors to BCC]
> > >
> > >
> > > >> OPTION 1: separate /foo and /foo-state trees
> > > >> 
> > > >>
> > > >> This option was/is described here:
> > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > > >>
> > > >> PROS:
> > > >>   a) does NOT break legacy clients (how we got here)
> > > >>   b) consistent with convention used in many IETF modules
> > > >>   c) able to show if/how opstate may differ from configured values
> > > >>
> > > >> CONS:
> > > >>   a) questionably valid YANG leafref usage
> > > >
> > > > What does this mean?
> > >
> > > I'm referring to how the description statement explains that the
> > > server may look to operational state in order to resolve the leafref,
> > > which is to result in behavior similar to pre-configuration in RFC
> > > 7223.
> > 
> > Ok, I didn't pay close attention to the proposal in the quoted email.
> > 
> > I would design this a bit differently.  The config true leaf "dependency"
> should
> > have a leafref to the config false node name, with require-instance false.
> The
> > description should explain that the configuration item will be used by the
> server
> > if all dependencies exist.  When the configuration item is used, it shows
> up in the
> > config false list.
> > 
> > This way, the leafref usage is valid and straight forward.
> > 
> > > >>   b) complex server implementation (to handle require-instance
> > > >> false)
> > > >
> > > >Can you elaborate on this one?
> > >
> > > This is primarily a reflection of the CON listed above, in that it
> > > seems that a server would need to have special handling for when
> > > dependencies transition from being present to not-present and vice
> > > versa, much like the code to handle when a physical card is plugged in
> > > or removed.
> > 
> > Yes, but I think this is inherent to the problem at hand.  Even with the
> config true
> > solution defined in the current draft, it is not clear how things that
> were created
> > by the server would be deleted (if there were references to them).
> > 
> > > Note: I should've listed this as a CON for OPTION 2 as well.
> > >
> > >
> > >
> > > >>   c) eventually the module would need to migrate to the long-term
> > > >>  solution, which would result in needing to also rewrite all
> > > >>  modules that have augmented it (e.g., ietf-te-topology).
> > > >>   d) leafref path expressions really only work for configuration
> data,
> > > >>  though a clever server could have a special ability to peak at
> > > >>  the opstate values when doing validations.  Of course, with
> > > >>  require-instance is false, the value of leafref based validation
> > > >>  checking is negated anyway, even for config true nodes, so this
> > > >>  may not matter much.
> > > >>
> > > >>
> > > >>
> > > >> OPTION 2: explicit client-option to also return tagged opstate data
> > > >> ---
> > > >>
> > > >> This option takes a couple forms.  The first is module-specific and
> > > >> the second is generic.  In both cases, the idea is modeled after
> > > >> the with-defaults solution (RFC6243), wherein the client passes a
> > > >> special flag into  causing the server to also return
> > > >> opstate data, having a special metadata flag set, intermingled with
> > > >> the configuration data.
> > > >>
> > > >>
> > > >> 2A: Module-specific version
> > > >>
> > > >>module foo {
> > > >>   import ie

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

[Xufeng Liu]

Hi Sue,

I agree that the revised data stores solutions is the long term solution,
but it may take a year to complete because it covers a much broader scope.
Are we ok with delaying all these models for another year? This could be
the decision of the Chairs and ADs. Also, this approach seems to be a
sub-set of the long term solution, and they are compatible. If the details
can be worked out, it would be good to have such an interim solution
immediately, which does not need to solve all the problems, but hopefully
can migrate to the long term solution smoothly.

> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, February 16, 2017 2:53 PM
> To: 'Xufeng Liu' <xufeng.liu.i...@gmail.com>; 'Martin Bjorklund'
<mbj@tail-
> f.com>; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: RE: [i2rs] modeling options for
draft-ietf-i2rs-yang-network-topo
> 
> Xufeng:
> 
> I suspect 2 rpcs will be needed, but Martin and Kent are the experts.
Do
> you think trying to accelerate the revised data stores solutions is a
better way to
> go?
> 
> Sue
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
> Sent: Thursday, February 16, 2017 2:48 PM
> To: 'Susan Hares'; 'Martin Bjorklund'; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for
draft-ietf-i2rs-yang-network-topo
> 
> Hi Sue,
> 
> > -Original Message-
> > From: Susan Hares [mailto:sha...@ndzh.com]
> > Sent: Thursday, February 16, 2017 2:02 PM
> > To: 'Xufeng Liu' <xufeng.liu.i...@gmail.com>; 'Martin Bjorklund'
> <mbj@tail-
> > f.com>; kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: RE: [i2rs] modeling options for
> > draft-ietf-i2rs-yang-network-topo
> >
> > To Xufeng:
> >
> > Clarifying question - Are you asking about I2RS topology as a generic
> > yang model for any configuration or are you asking about I2RS topology
> > model as
> an
> > ephemeral topology model.
> 
> [Xufeng] I was talking about I2RS topology as a generic yang model for
any
> configuration, but I think that the same solution can be applied to
ephemeral
> case, though a separate rpc might be needed.
> 
> Thanks,
> - Xufeng
> 
> >
> > To Martin:
> > Clarifying questions:
> >
> > 1)  Is your rpc suggest target toward the I2RS topology model as a
> > generic topology model or an I2RS ephemeral state model or both?
> >
> > 2) Could we define rpcs now that operate as Alex desired for generic
> topology
> > models that could be replaced by more generic mechanisms later?
> > For example, the I2RS RIB has defined rpcs for all major functions
> (add/delete rib,
> > add/delete route, add/delete nexhop) plus notifications for changes.
> > Is
> this the
> > best approach here?
> >
> > Sue
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
> > Sent: Thursday, February 16, 2017 10:39 AM
> > To: 'Martin Bjorklund'; kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for
> > draft-ietf-i2rs-yang-network-topo
> >
> >
> >
> > > -Original Message-
> > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin
> > > Bjorklund
> > > Sent: Tuesday, February 14, 2017 11:41 AM
> > > To: kwat...@juniper.net
> > > Cc: i2rs@ietf.org
> > > Subject: Re: [i2rs] modeling options for
> > > draft-ietf-i2rs-yang-network-topo
> > >
> > > Kent Watsen <kwat...@juniper.net> wrote:
> > > >
> > > >
> > > > [moving yang-doctors to BCC]
> > > >
> > > >
> > > > >> OPTION 1: separate /foo and /foo-state trees
> > > > >> 
> > > > >>
> > > > >> This option was/is described here:
> > > > >>
https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > > > >>
> > > > >> PROS:
> > > > >>   a) does NOT break legacy clients (how we got here)
> > > > >>   b) consistent with convention used in many IETF modules
> > > > >>   c) able to show if/how opstate may differ from configured
> > > > >> values
> > > > >>
> > > > >> CONS:
> > > > >>   a) questionably valid YANG leafref usage
> > > > >
> > > > > What does this mean?
> > > >
> > > > I'm

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

[Xufeng Liu]

Hi Sue,

I agree that the revised data stores solutions is the long term solution,
but it may take a year to complete because it covers a much broader scope.
Are we ok with delaying all these models for another year? This could be the
decision of the Chairs and ADs. Also, this approach seems to be a sub-set of
the long term solution, and they are compatible. If the details can be
worked out, it would be good to have such an interim solution immediately,
which does not need to solve all the problems, but hopefully can migrate to
the long term solution smoothly.

Thanks,
- Xufeng

> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, February 16, 2017 2:53 PM
> To: 'Xufeng Liu' <xufeng.liu.i...@gmail.com>; 'Martin Bjorklund'
<mbj@tail-
> f.com>; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: RE: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> Xufeng:
> 
> I suspect 2 rpcs will be needed, but Martin and Kent are the experts.   Do
> you think trying to accelerate the revised data stores solutions is a
better way to
> go?
> 
> Sue
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
> Sent: Thursday, February 16, 2017 2:48 PM
> To: 'Susan Hares'; 'Martin Bjorklund'; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> Hi Sue,
> 
> > -Original Message-
> > From: Susan Hares [mailto:sha...@ndzh.com]
> > Sent: Thursday, February 16, 2017 2:02 PM
> > To: 'Xufeng Liu' <xufeng.liu.i...@gmail.com>; 'Martin Bjorklund'
> <mbj@tail-
> > f.com>; kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: RE: [i2rs] modeling options for
> > draft-ietf-i2rs-yang-network-topo
> >
> > To Xufeng:
> >
> > Clarifying question - Are you asking about I2RS topology as a generic
> > yang model for any configuration or are you asking about I2RS topology
> > model as
> an
> > ephemeral topology model.
> 
> [Xufeng] I was talking about I2RS topology as a generic yang model for any
> configuration, but I think that the same solution can be applied to
ephemeral
> case, though a separate rpc might be needed.
> 
> Thanks,
> - Xufeng
> 
> >
> > To Martin:
> > Clarifying questions:
> >
> > 1)  Is your rpc suggest target toward the I2RS topology model as a
> > generic topology model or an I2RS ephemeral state model or both?
> >
> > 2) Could we define rpcs now that operate as Alex desired for generic
> topology
> > models that could be replaced by more generic mechanisms later?
> > For example, the I2RS RIB has defined rpcs for all major functions
> (add/delete rib,
> > add/delete route, add/delete nexhop) plus notifications for changes.
> > Is
> this the
> > best approach here?
> >
> > Sue
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
> > Sent: Thursday, February 16, 2017 10:39 AM
> > To: 'Martin Bjorklund'; kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for
> > draft-ietf-i2rs-yang-network-topo
> >
> >
> >
> > > -Original Message-
> > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin
> > > Bjorklund
> > > Sent: Tuesday, February 14, 2017 11:41 AM
> > > To: kwat...@juniper.net
> > > Cc: i2rs@ietf.org
> > > Subject: Re: [i2rs] modeling options for
> > > draft-ietf-i2rs-yang-network-topo
> > >
> > > Kent Watsen <kwat...@juniper.net> wrote:
> > > >
> > > >
> > > > [moving yang-doctors to BCC]
> > > >
> > > >
> > > > >> OPTION 1: separate /foo and /foo-state trees
> > > > >> 
> > > > >>
> > > > >> This option was/is described here:
> > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > > > >>
> > > > >> PROS:
> > > > >>   a) does NOT break legacy clients (how we got here)
> > > > >>   b) consistent with convention used in many IETF modules
> > > > >>   c) able to show if/how opstate may differ from configured
> > > > >> values
> > > > >>
> > > > >> CONS:
> > > > >>   a) questionably valid YANG leafref usage
> > > > >
> > > > > What does this mean?
> > > >
> >

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

[Martin Bjorklund]

"Xufeng Liu" <xufeng.liu.i...@gmail.com> wrote:
> 
> 
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
> > Sent: Wednesday, February 15, 2017 1:41 PM
> > To: alexander.cl...@huawei.com
> > Cc: i2rs@ietf.org; kwat...@juniper.net
> > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> > 
> > Alexander Clemm <alexander.cl...@huawei.com> wrote:
> > > Hello Martin,
> > > Thank you.  Your first explanation is clear.  Regarding the expression
> > > of constraints, see inline, below (thread is pruned for clarity)
> > > --- Alex
> > >
> > > -Original Message-
> > > From: Martin Bjorklund [mailto:m...@tail-f.com]
> > > Sent: Wednesday, February 15, 2017 12:12 AM
> > > To: Alexander Clemm <alexander.cl...@huawei.com>
> > > Cc: kwat...@juniper.net; i2rs@ietf.org
> > > Subject: Re: [i2rs] modeling options for
> > > draft-ietf-i2rs-yang-network-topo
> > >
> > >
> > > 
> > > .
> > > I mean that the server will consider a configured item, and decide if
> > > it can be used or not.  If the configured item has a reference to
> > > something that doesn't (yet) exist (weak reference; require-instance
> > > false), the server leaves the item in the config, and moves on.  At
> > > some later time, suppose the weak reference is fulfilled; at this
> > > point the server decides that the configured item can be used, and it
> > > instantiates the item in the /-state list.  Once it is there, maybe
> > > some other configured item has a reference to this one, and it can
> > > also be instantiated etc.
> > >
> > > And it goes the other way as well; suppose a server provided item is
> > > removed by the server; at this point the server would also remove
> > > items in the state list that originated in the configuration - however
> > > they are not removed from the config, just the state.
> > > (Server provided items would only show up in the state in this
> > > solution).
> > >
> > > The state subtree works exactly like the operational-state datastore
> > > in draft-ietf-netmod-revised-datastores.
> > >
> > > 
> > > Thank you, this clarifies the earlier statement 
> > >
> > > > One of the issues that we are facing is that a configured topology
> > > > might refer to a configured topology or a server-provided topology,
> > > > and we would like to avoid making a case distinction as to which
> > > > category we are referring to.
> > >
> > > I believe my proposed solution handles this.
> > >
> > > > At the same time, we are making use of leafrefs to express a number
> > > > of integrity constraints which are part of the model: as a node is
> > > > part of a topology, and a topology has an underlay topology, we make
> > > > sure that the underlay node is part of the underlay topology (and
> > > > not just any arbitrary node).
> > >
> > > Can you point me to the place in the model where this is specified?
> > >
> > > Or did you mean that today you have to mention this in plain text, but
> > > it would be nice if it could be captured formally in the model?
> > >
> > >   It is covered in the model today. E.g.:
> > 
> > Ok.  Here the model uses require-instance false, so if these ponts to the
> state
> > tree instead, you'd get the same effect.
> > 
> 
> [Xufeng] Does the leafref point to the "state tree" only? If we do so, we
> will miss the other half - the possible dependency to the config tree. If we
> let the leafref point to both, we will get the unmanageable complications.

The idea was that the leafref would point to state only.  You will not
really miss the dependency to the config tree; see my description
above.


/martin





> 
> > 
> > /martin
> > 
> > 
> > >
> > > In networks/network/node/supporting-node
> > >  leaf network-ref {
> > >type leafref {
> > >  path "../../../supporting-network/network-ref";
> > >require-instance false;
> > >}
> > > (supporting node is contained in supporting network)
> > >
> > > Supporting link:
> > >   +--rw supporting-link* [network-ref link-ref]
> > >  +--rw network-ref->
> ../..

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

[Susan Hares]

Xufeng: 

I suspect 2 rpcs will be needed, but Martin and Kent are the experts.   Do
you think trying to accelerate the revised data stores solutions is a better
way to go? 

Sue  

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, February 16, 2017 2:48 PM
To: 'Susan Hares'; 'Martin Bjorklund'; kwat...@juniper.net
Cc: i2rs@ietf.org
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

Hi Sue,

> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, February 16, 2017 2:02 PM
> To: 'Xufeng Liu' <xufeng.liu.i...@gmail.com>; 'Martin Bjorklund'
<mbj@tail-
> f.com>; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: RE: [i2rs] modeling options for 
> draft-ietf-i2rs-yang-network-topo
> 
> To Xufeng:
> 
> Clarifying question - Are you asking about I2RS topology as a generic 
> yang model for any configuration or are you asking about I2RS topology 
> model as
an
> ephemeral topology model.

[Xufeng] I was talking about I2RS topology as a generic yang model for any
configuration, but I think that the same solution can be applied to
ephemeral case, though a separate rpc might be needed.

Thanks,
- Xufeng

> 
> To Martin:
> Clarifying questions:
> 
> 1)  Is your rpc suggest target toward the I2RS topology model as a 
> generic topology model or an I2RS ephemeral state model or both?
> 
> 2) Could we define rpcs now that operate as Alex desired for generic
topology
> models that could be replaced by more generic mechanisms later?
> For example, the I2RS RIB has defined rpcs for all major functions
(add/delete rib,
> add/delete route, add/delete nexhop) plus notifications for changes.  
> Is
this the
> best approach here?
> 
> Sue
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
> Sent: Thursday, February 16, 2017 10:39 AM
> To: 'Martin Bjorklund'; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for 
> draft-ietf-i2rs-yang-network-topo
> 
> 
> 
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin 
> > Bjorklund
> > Sent: Tuesday, February 14, 2017 11:41 AM
> > To: kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for 
> > draft-ietf-i2rs-yang-network-topo
> >
> > Kent Watsen <kwat...@juniper.net> wrote:
> > >
> > >
> > > [moving yang-doctors to BCC]
> > >
> > >
> > > >> OPTION 1: separate /foo and /foo-state trees
> > > >> 
> > > >>
> > > >> This option was/is described here:
> > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > > >>
> > > >> PROS:
> > > >>   a) does NOT break legacy clients (how we got here)
> > > >>   b) consistent with convention used in many IETF modules
> > > >>   c) able to show if/how opstate may differ from configured 
> > > >> values
> > > >>
> > > >> CONS:
> > > >>   a) questionably valid YANG leafref usage
> > > >
> > > > What does this mean?
> > >
> > > I'm referring to how the description statement explains that the 
> > > server may look to operational state in order to resolve the 
> > > leafref, which is to result in behavior similar to 
> > > pre-configuration in RFC 7223.
> >
> > Ok, I didn't pay close attention to the proposal in the quoted email.
> >
> > I would design this a bit differently.  The config true leaf
"dependency"
> should
> > have a leafref to the config false node name, with require-instance
false.
> The
> > description should explain that the configuration item will be used 
> > by the
> server
> > if all dependencies exist.  When the configuration item is used, it 
> > shows
> up in the
> > config false list.
> >
> > This way, the leafref usage is valid and straight forward.
> >
> > > >>   b) complex server implementation (to handle require-instance
> > > >> false)
> > > >
> > > >Can you elaborate on this one?
> > >
> > > This is primarily a reflection of the CON listed above, in that it 
> > > seems that a server would need to have special handling for when 
> > > dependencies transition from being present to not-present and vice 
> > > versa, much like the code to handle when a physical card is 
> > >

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

[Xufeng Liu]

Hi Sue,

> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, February 16, 2017 2:02 PM
> To: 'Xufeng Liu' <xufeng.liu.i...@gmail.com>; 'Martin Bjorklund'
<mbj@tail-
> f.com>; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: RE: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> To Xufeng:
> 
> Clarifying question - Are you asking about I2RS topology as a generic yang
> model for any configuration or are you asking about I2RS topology model as
an
> ephemeral topology model.

[Xufeng] I was talking about I2RS topology as a generic yang model for any
configuration, but I think that the same solution can be applied to
ephemeral case, though a separate rpc might be needed.

Thanks,
- Xufeng

> 
> To Martin:
> Clarifying questions:
> 
> 1)  Is your rpc suggest target toward the I2RS topology model as a generic
> topology model or an I2RS ephemeral state model or both?
> 
> 2) Could we define rpcs now that operate as Alex desired for generic
topology
> models that could be replaced by more generic mechanisms later?
> For example, the I2RS RIB has defined rpcs for all major functions
(add/delete rib,
> add/delete route, add/delete nexhop) plus notifications for changes.  Is
this the
> best approach here?
> 
> Sue
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
> Sent: Thursday, February 16, 2017 10:39 AM
> To: 'Martin Bjorklund'; kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> 
> 
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin
> > Bjorklund
> > Sent: Tuesday, February 14, 2017 11:41 AM
> > To: kwat...@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for
> > draft-ietf-i2rs-yang-network-topo
> >
> > Kent Watsen <kwat...@juniper.net> wrote:
> > >
> > >
> > > [moving yang-doctors to BCC]
> > >
> > >
> > > >> OPTION 1: separate /foo and /foo-state trees
> > > >> 
> > > >>
> > > >> This option was/is described here:
> > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > > >>
> > > >> PROS:
> > > >>   a) does NOT break legacy clients (how we got here)
> > > >>   b) consistent with convention used in many IETF modules
> > > >>   c) able to show if/how opstate may differ from configured
> > > >> values
> > > >>
> > > >> CONS:
> > > >>   a) questionably valid YANG leafref usage
> > > >
> > > > What does this mean?
> > >
> > > I'm referring to how the description statement explains that the
> > > server may look to operational state in order to resolve the
> > > leafref, which is to result in behavior similar to pre-configuration
> > > in RFC 7223.
> >
> > Ok, I didn't pay close attention to the proposal in the quoted email.
> >
> > I would design this a bit differently.  The config true leaf
"dependency"
> should
> > have a leafref to the config false node name, with require-instance
false.
> The
> > description should explain that the configuration item will be used by
> > the
> server
> > if all dependencies exist.  When the configuration item is used, it
> > shows
> up in the
> > config false list.
> >
> > This way, the leafref usage is valid and straight forward.
> >
> > > >>   b) complex server implementation (to handle require-instance
> > > >> false)
> > > >
> > > >Can you elaborate on this one?
> > >
> > > This is primarily a reflection of the CON listed above, in that it
> > > seems that a server would need to have special handling for when
> > > dependencies transition from being present to not-present and vice
> > > versa, much like the code to handle when a physical card is plugged
> > > in or removed.
> >
> > Yes, but I think this is inherent to the problem at hand.  Even with
> > the
> config true
> > solution defined in the current draft, it is not clear how things that
> were created
> > by the server would be deleted (if there were references to them).
> >
> > > Note: I should've listed this as a CON for OPTION 2 as well.
>

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

[Susan Hares]

To Xufeng: 

Clarifying question - Are you asking about I2RS topology as a generic yang
model for any configuration or are you asking about I2RS topology model as
an ephemeral topology model. 

To Martin: 
Clarifying questions: 

1)  Is your rpc suggest target toward the I2RS topology model as a generic
topology model or an I2RS ephemeral state model or both? 

2) Could we define rpcs now that operate as Alex desired for generic
topology models that could be replaced by more generic mechanisms later?
For example, the I2RS RIB has defined rpcs for all major functions
(add/delete rib, add/delete route, add/delete nexhop) plus notifications for
changes.  Is this the best approach here? 

Sue 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Xufeng Liu
Sent: Thursday, February 16, 2017 10:39 AM
To: 'Martin Bjorklund'; kwat...@juniper.net
Cc: i2rs@ietf.org
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo



> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin 
> Bjorklund
> Sent: Tuesday, February 14, 2017 11:41 AM
> To: kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for 
> draft-ietf-i2rs-yang-network-topo
> 
> Kent Watsen <kwat...@juniper.net> wrote:
> >
> >
> > [moving yang-doctors to BCC]
> >
> >
> > >> OPTION 1: separate /foo and /foo-state trees
> > >> 
> > >>
> > >> This option was/is described here:
> > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > >>
> > >> PROS:
> > >>   a) does NOT break legacy clients (how we got here)
> > >>   b) consistent with convention used in many IETF modules
> > >>   c) able to show if/how opstate may differ from configured 
> > >> values
> > >>
> > >> CONS:
> > >>   a) questionably valid YANG leafref usage
> > >
> > > What does this mean?
> >
> > I'm referring to how the description statement explains that the 
> > server may look to operational state in order to resolve the 
> > leafref, which is to result in behavior similar to pre-configuration 
> > in RFC 7223.
> 
> Ok, I didn't pay close attention to the proposal in the quoted email.
> 
> I would design this a bit differently.  The config true leaf "dependency"
should
> have a leafref to the config false node name, with require-instance false.
The
> description should explain that the configuration item will be used by 
> the
server
> if all dependencies exist.  When the configuration item is used, it 
> shows
up in the
> config false list.
> 
> This way, the leafref usage is valid and straight forward.
> 
> > >>   b) complex server implementation (to handle require-instance
> > >> false)
> > >
> > >Can you elaborate on this one?
> >
> > This is primarily a reflection of the CON listed above, in that it 
> > seems that a server would need to have special handling for when 
> > dependencies transition from being present to not-present and vice 
> > versa, much like the code to handle when a physical card is plugged 
> > in or removed.
> 
> Yes, but I think this is inherent to the problem at hand.  Even with 
> the
config true
> solution defined in the current draft, it is not clear how things that
were created
> by the server would be deleted (if there were references to them).
> 
> > Note: I should've listed this as a CON for OPTION 2 as well.
> >
> >
> >
> > >>   c) eventually the module would need to migrate to the long-term
> > >>  solution, which would result in needing to also rewrite all
> > >>  modules that have augmented it (e.g., ietf-te-topology).
> > >>   d) leafref path expressions really only work for configuration
data,
> > >>  though a clever server could have a special ability to peak at
> > >>  the opstate values when doing validations.  Of course, with
> > >>  require-instance is false, the value of leafref based validation
> > >>  checking is negated anyway, even for config true nodes, so this
> > >>  may not matter much.
> > >>
> > >>
> > >>
> > >> OPTION 2: explicit client-option to also return tagged opstate 
> > >> data
> > >> -
> > >> --
> > >>
> > >> This option takes a couple forms.  The first is module-specific 
> > >> and the second

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

[Susan Hares]

Kent, Alex, and Martin: 

 

These are clarifying question regarding the future when revised data stores
is deployed:  

 

1)  If I2RS topology model and L3 Topology models are generic model in
the configuration data store,  . 

a.   is disabling validation using the require-instance false path in
configuration is the best mechanism you can obtain for the configuration not
being there?  

b.  Is get-state the appropriate information to determine what is the
applied data store? 

c.   Can notifications operate on changes in operational state in the
applied data store?  That is, if the server-supplied information is updated
can notifications provide the signaling of the topology node being added to
the operational state? 

 

2)  If I2RS topology model and L3 Topology model are models in the
ephemeral data store? 

a.   Can the long-term solution Kent proposed in
https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html

  be supported by the basic get-data
,  write-data  (or your
equivalent) 

 get-state  and notification services?  

 

Sue Hares 

 

 

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Wednesday, February 15, 2017 2:28 PM
To: Alexander Clemm; Martin Bjorklund
Cc: i2rs@ietf.org
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

 

 

> So, the suggested solution would be to not have validation of 

> information, but simply have misconfigured stuff that violates 

> integrity constraints never show up in the state tree.

 

A leafref with require-instance false, even if pointing to a path in the
configuration, effectively disables validation.  Still, I think a leafref is
better than just a description statement.

 

> Perhaps this is the best that YANG can support today, although I still 

> find this not very satisfying.  At a minimum, it would be good if the 

> framework would support an indication whether the configured topology 

> information went into effect or not.

 

The revised-datastore solution is intended to provide a way to show this.
See draft-ietf-netmod-opstate-reqs.

 

> The implication is that a client will need to achieve this now by 

> retrieving the corresponding state tree after each configuration 

> operation (and if the configuration would not show correspondingly in 

> the state tree, troubleshoot to see

> what's wrong).   So, if this is taken as design pattern, it

> would be good to introduce operations to support that.

 

See draft-ietf-netmod-opstate-reqs.

 

> Likewise, it would be good to have a "diffing" operation in which 

> state tree and configuration tree are checked for differences and 

> discrepancies are reported (e.g. config not in state, and possibly 

> vice versa).

 

See opstate-reqs, requirement 2-C.

 

> These should probably

> be added as requirements for I2Rs and the next revision of 

> the overall YANG+associated protocols framework.

 

Sure, but I don't think this is needed, as we already have the opstate-reqs
draft.

 

 

Kent

 

 

___

i2rs mailing list

 <mailto:i2rs@ietf.org> i2rs@ietf.org

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Xufeng Liu]

> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
> Sent: Tuesday, February 14, 2017 11:41 AM
> To: kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> Kent Watsen <kwat...@juniper.net> wrote:
> >
> >
> > [moving yang-doctors to BCC]
> >
> >
> > >> OPTION 1: separate /foo and /foo-state trees
> > >> 
> > >>
> > >> This option was/is described here:
> > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > >>
> > >> PROS:
> > >>   a) does NOT break legacy clients (how we got here)
> > >>   b) consistent with convention used in many IETF modules
> > >>   c) able to show if/how opstate may differ from configured values
> > >>
> > >> CONS:
> > >>   a) questionably valid YANG leafref usage
> > >
> > > What does this mean?
> >
> > I'm referring to how the description statement explains that the
> > server may look to operational state in order to resolve the leafref,
> > which is to result in behavior similar to pre-configuration in RFC
> > 7223.
> 
> Ok, I didn't pay close attention to the proposal in the quoted email.
> 
> I would design this a bit differently.  The config true leaf "dependency"
should
> have a leafref to the config false node name, with require-instance false.
The
> description should explain that the configuration item will be used by the
server
> if all dependencies exist.  When the configuration item is used, it shows
up in the
> config false list.
> 
> This way, the leafref usage is valid and straight forward.
> 
> > >>   b) complex server implementation (to handle require-instance
> > >> false)
> > >
> > >Can you elaborate on this one?
> >
> > This is primarily a reflection of the CON listed above, in that it
> > seems that a server would need to have special handling for when
> > dependencies transition from being present to not-present and vice
> > versa, much like the code to handle when a physical card is plugged in
> > or removed.
> 
> Yes, but I think this is inherent to the problem at hand.  Even with the
config true
> solution defined in the current draft, it is not clear how things that
were created
> by the server would be deleted (if there were references to them).
> 
> > Note: I should've listed this as a CON for OPTION 2 as well.
> >
> >
> >
> > >>   c) eventually the module would need to migrate to the long-term
> > >>  solution, which would result in needing to also rewrite all
> > >>  modules that have augmented it (e.g., ietf-te-topology).
> > >>   d) leafref path expressions really only work for configuration
data,
> > >>  though a clever server could have a special ability to peak at
> > >>  the opstate values when doing validations.  Of course, with
> > >>  require-instance is false, the value of leafref based validation
> > >>  checking is negated anyway, even for config true nodes, so this
> > >>  may not matter much.
> > >>
> > >>
> > >>
> > >> OPTION 2: explicit client-option to also return tagged opstate data
> > >> ---
> > >>
> > >> This option takes a couple forms.  The first is module-specific and
> > >> the second is generic.  In both cases, the idea is modeled after
> > >> the with-defaults solution (RFC6243), wherein the client passes a
> > >> special flag into  causing the server to also return
> > >> opstate data, having a special metadata flag set, intermingled with
> > >> the configuration data.
> > >>
> > >>
> > >> 2A: Module-specific version
> > >>
> > >>module foo {
> > >>   import ietf-netconf { prefix nc; }
> > >>   import ietf-yang-metadata { prefix md; }
> > >>   md:annotation server-provided {
> > >>  type boolean;
> > >>   }
> > >>   container nodes {
> > >>  config true;
> > >>  list node {
> > >> key "name";
> > >> leaf name { type string; }
> > >> leaf dependency {
> > >>type

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

[Xufeng Liu]

> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
> Sent: Wednesday, February 15, 2017 1:41 PM
> To: alexander.cl...@huawei.com
> Cc: i2rs@ietf.org; kwat...@juniper.net
> Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo
> 
> Alexander Clemm <alexander.cl...@huawei.com> wrote:
> > Hello Martin,
> > Thank you.  Your first explanation is clear.  Regarding the expression
> > of constraints, see inline, below (thread is pruned for clarity)
> > --- Alex
> >
> > -Original Message-
> > From: Martin Bjorklund [mailto:m...@tail-f.com]
> > Sent: Wednesday, February 15, 2017 12:12 AM
> > To: Alexander Clemm <alexander.cl...@huawei.com>
> > Cc: kwat...@juniper.net; i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for
> > draft-ietf-i2rs-yang-network-topo
> >
> >
> > 
> > .
> > I mean that the server will consider a configured item, and decide if
> > it can be used or not.  If the configured item has a reference to
> > something that doesn't (yet) exist (weak reference; require-instance
> > false), the server leaves the item in the config, and moves on.  At
> > some later time, suppose the weak reference is fulfilled; at this
> > point the server decides that the configured item can be used, and it
> > instantiates the item in the /-state list.  Once it is there, maybe
> > some other configured item has a reference to this one, and it can
> > also be instantiated etc.
> >
> > And it goes the other way as well; suppose a server provided item is
> > removed by the server; at this point the server would also remove
> > items in the state list that originated in the configuration - however
> > they are not removed from the config, just the state.
> > (Server provided items would only show up in the state in this
> > solution).
> >
> > The state subtree works exactly like the operational-state datastore
> > in draft-ietf-netmod-revised-datastores.
> >
> > 
> > Thank you, this clarifies the earlier statement 
> >
> > > One of the issues that we are facing is that a configured topology
> > > might refer to a configured topology or a server-provided topology,
> > > and we would like to avoid making a case distinction as to which
> > > category we are referring to.
> >
> > I believe my proposed solution handles this.
> >
> > > At the same time, we are making use of leafrefs to express a number
> > > of integrity constraints which are part of the model: as a node is
> > > part of a topology, and a topology has an underlay topology, we make
> > > sure that the underlay node is part of the underlay topology (and
> > > not just any arbitrary node).
> >
> > Can you point me to the place in the model where this is specified?
> >
> > Or did you mean that today you have to mention this in plain text, but
> > it would be nice if it could be captured formally in the model?
> >
> >   It is covered in the model today. E.g.:
> 
> Ok.  Here the model uses require-instance false, so if these ponts to the
state
> tree instead, you'd get the same effect.
> 

[Xufeng] Does the leafref point to the "state tree" only? If we do so, we
will miss the other half - the possible dependency to the config tree. If we
let the leafref point to both, we will get the unmanageable complications.

> 
> /martin
> 
> 
> >
> > In networks/network/node/supporting-node
> >  leaf network-ref {
> >type leafref {
> >  path "../../../supporting-network/network-ref";
> >require-instance false;
> >}
> > (supporting node is contained in supporting network)
> >
> > Supporting link:
> >   +--rw supporting-link* [network-ref link-ref]
> >  +--rw network-ref->
../../../nd:supporting-network/network-ref
> >  +--rw link-ref ->
> >
> > /nd:networks/network[nd:network-id=current()/../network-ref]/link/link
> > -id
> >
> > (supporting link is a link contained in the supporting network)
> >
> > Supporting termination point:
> >   +--rw supporting-termination-point* [network-ref node-ref tp-ref]
> >  +--rw network-ref-> ../../../nd:supporting-node/network-ref
> >  +--rw node-ref   -> ../../../nd:supporting-node/node-ref
> >  +--rw tp-ref ->
> >
> > /nd:networks/network[nd:network-id=current()/../network-ref]/node[nd:n
> > ode-id=current()/../node-ref]/termination-point/tp-id
> >
> > (supporting termination point is contained in supporting network and
> > supporting node)
> >
> > It is those leafrefs whose transposition in the split subtree model
> > (where we encounter alternative paths) I am concerned will be
> > problematic.
> >
> > 
> >
> >
> 
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Martin Bjorklund]

Alexander Clemm <alexander.cl...@huawei.com> wrote:
> So, the suggested solution would be to not have validation of
> information, but simply have misconfigured stuff that violates
> integrity constraints never show up in the state tree.

If I'm not mistaken, this is how the solution in the current draft
works.

And it seems to me that it more or less follows from the requirement
that the server can create/modify/delete any server-provided data at
any time.

> Perhaps this is the best that YANG can support today, although I still
> find this not very satisfying.  At a minimum, it would be good if the
> framework would support an indication whether the configured topology
> information went into effect or not.

I'm not sure how useful that information would be, given that the
server-provided data might disappear at any time after such an
indication.


/martin


> The implication is that a client
> will need to achieve this now by retrieving the corresponding state
> tree after each configuration operation (and if the configuration
> would not show correspondingly in the state tree, troubleshoot to see
> what's wrong).  So, if this is taken as design pattern, it would be
> good to introduce operations to support that.  Likewise, it would be
> good to have a "diffing" operation in which state tree and
> configuration tree are checked for differences and discrepancies are
> reported (e.g. config not in state, and possibly vice versa).  These
> should probably be added as requirements for I2Rs and the next
> revision of the overall YANG+associated protocols framework.
> 
> --- Alex
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com] 
> Sent: Wednesday, February 15, 2017 10:41 AM
> To: Alexander Clemm <alexander.cl...@huawei.com>
> Cc: kwat...@juniper.net; i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for
> draft-ietf-i2rs-yang-network-topo
> 
> Alexander Clemm <alexander.cl...@huawei.com> wrote:
> > Hello Martin,
> > Thank you.  Your first explanation is clear.  Regarding the expression
> > of constraints, see inline, below (thread is pruned for clarity)
> > --- Alex
> > 
> > -Original Message-
> > From: Martin Bjorklund [mailto:m...@tail-f.com]
> > Sent: Wednesday, February 15, 2017 12:12 AM
> > To: Alexander Clemm <alexander.cl...@huawei.com>
> > Cc: kwat...@juniper.net; i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for 
> > draft-ietf-i2rs-yang-network-topo
> > 
> > 
> > 
> > .
> > I mean that the server will consider a configured item, and decide if 
> > it can be used or not.  If the configured item has a reference to 
> > something that doesn't (yet) exist (weak reference; require-instance 
> > false), the server leaves the item in the config, and moves on.  At 
> > some later time, suppose the weak reference is fulfilled; at this 
> > point the server decides that the configured item can be used, and it 
> > instantiates the item in the /-state list.  Once it is there, maybe 
> > some other configured item has a reference to this one, and it can 
> > also be instantiated etc.
> > 
> > And it goes the other way as well; suppose a server provided item is 
> > removed by the server; at this point the server would also remove 
> > items in the state list that originated in the configuration - however
> > they are not removed from the config, just the state.
> > (Server provided items would only show up in the state in this 
> > solution).
> > 
> > The state subtree works exactly like the operational-state datastore 
> > in draft-ietf-netmod-revised-datastores.
> > 
> > 
> > Thank you, this clarifies the earlier statement 
> > 
> > > One of the issues that we are facing is that a configured topology 
> > > might refer to a configured topology or a server-provided topology, 
> > > and we would like to avoid making a case distinction as to which 
> > > category we are referring to.
> > 
> > I believe my proposed solution handles this.
> > 
> > > At the same time, we are making use of leafrefs to express a number 
> > > of integrity constraints which are part of the model: as a node is 
> > > part of a topology, and a topology has an underlay topology, we make 
> > > sure that the underlay node is part of the underlay topology (and 
> > > not just any arbitrary node).
> > 
> > Can you point me to the place in the model where this is specified?
> > 
> > Or did you mean that today you have to mention this in plain text, but
> > it would 

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

[Kent Watsen]

> So, the suggested solution would be to not have validation
> of information, but simply have misconfigured stuff that
> violates integrity constraints never show up in the state tree.  

A leafref with require-instance false, even if pointing to a path
in the configuration, effectively disables validation.  Still, I
think a leafref is better than just a description statement.

> Perhaps this is the best that YANG can support today, although
> I still find this not very satisfying.  At a minimum, it would
> be good if the framework would support an indication whether
> the configured topology information went into effect or not.

The revised-datastore solution is intended to provide a way to
show this.  See draft-ietf-netmod-opstate-reqs.

> The implication is that a client will need to achieve this now
> by retrieving the corresponding state tree after each
> configuration operation (and if the configuration would not
> show correspondingly in the state tree, troubleshoot to see
> what's wrong).   So, if this is taken as design pattern, it
> would be good to introduce operations to support that.

See draft-ietf-netmod-opstate-reqs.

> Likewise, it would be good to have a "diffing" operation 
> in which state tree and configuration tree are checked for
> differences and discrepancies are reported (e.g. config not
> in state, and possibly vice versa).

See opstate-reqs, requirement 2-C.

> These should probably
> be added as requirements for I2Rs and the next revision of 
> the overall YANG+associated protocols framework.

Sure, but I don't think this is needed, as we already have the
opstate-reqs draft.


Kent


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Alexander Clemm]

So, the suggested solution would be to not have validation of information, but 
simply have misconfigured stuff that violates integrity constraints never show 
up in the state tree.  

Perhaps this is the best that YANG can support today, although I still find 
this not very satisfying.  At a minimum, it would be good if the framework 
would support an indication whether the configured topology information went 
into effect or not.  The implication is that a client will need to achieve this 
now by retrieving the corresponding state tree after each configuration 
operation (and if the configuration would not show correspondingly in the state 
tree, troubleshoot to see what's wrong).   So, if this is taken as design 
pattern, it would be good to introduce operations to support that.  Likewise, 
it would be good to have a "diffing" operation in which state tree and 
configuration tree are checked for differences and discrepancies are reported 
(e.g. config not in state, and possibly vice versa).  These should probably be 
added as requirements for I2Rs and the next revision of the overall 
YANG+associated protocols framework.

--- Alex

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Wednesday, February 15, 2017 10:41 AM
To: Alexander Clemm <alexander.cl...@huawei.com>
Cc: kwat...@juniper.net; i2rs@ietf.org
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

Alexander Clemm <alexander.cl...@huawei.com> wrote:
> Hello Martin,
> Thank you.  Your first explanation is clear.  Regarding the expression 
> of constraints, see inline, below (thread is pruned for clarity)
> --- Alex
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: Wednesday, February 15, 2017 12:12 AM
> To: Alexander Clemm <alexander.cl...@huawei.com>
> Cc: kwat...@juniper.net; i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for 
> draft-ietf-i2rs-yang-network-topo
> 
> 
> 
> .
> I mean that the server will consider a configured item, and decide if 
> it can be used or not.  If the configured item has a reference to 
> something that doesn't (yet) exist (weak reference; require-instance 
> false), the server leaves the item in the config, and moves on.  At 
> some later time, suppose the weak reference is fulfilled; at this 
> point the server decides that the configured item can be used, and it 
> instantiates the item in the /-state list.  Once it is there, maybe 
> some other configured item has a reference to this one, and it can 
> also be instantiated etc.
> 
> And it goes the other way as well; suppose a server provided item is 
> removed by the server; at this point the server would also remove 
> items in the state list that originated in the configuration - however 
> they are not removed from the config, just the state.
> (Server provided items would only show up in the state in this 
> solution).
> 
> The state subtree works exactly like the operational-state datastore 
> in draft-ietf-netmod-revised-datastores.
> 
> 
> Thank you, this clarifies the earlier statement 
> 
> > One of the issues that we are facing is that a configured topology 
> > might refer to a configured topology or a server-provided topology, 
> > and we would like to avoid making a case distinction as to which 
> > category we are referring to.
> 
> I believe my proposed solution handles this.
> 
> > At the same time, we are making use of leafrefs to express a number 
> > of integrity constraints which are part of the model: as a node is 
> > part of a topology, and a topology has an underlay topology, we make 
> > sure that the underlay node is part of the underlay topology (and 
> > not just any arbitrary node).
> 
> Can you point me to the place in the model where this is specified?
> 
> Or did you mean that today you have to mention this in plain text, but 
> it would be nice if it could be captured formally in the model?
> 
>   It is covered in the model today. E.g.:

Ok.  Here the model uses require-instance false, so if these ponts to the state 
tree instead, you'd get the same effect.


/martin


> 
> In networks/network/node/supporting-node 
>  leaf network-ref {
>type leafref {
>  path "../../../supporting-network/network-ref";
>require-instance false;
>}
> (supporting node is contained in supporting network)
> 
> Supporting link:
>   +--rw supporting-link* [network-ref link-ref]
>  +--rw network-ref-> ../../../nd:supporting-network/network-ref
>  +--rw link-ref ->
>  
> /nd:networks/network[nd:network-id=current()/../network-ref]/link

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

[Martin Bjorklund]

Alexander Clemm <alexander.cl...@huawei.com> wrote:
> Hello Martin,  
> Thank you.  Your first explanation is clear.  Regarding the expression
> of constraints, see inline, below (thread is pruned for clarity)
> --- Alex
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com] 
> Sent: Wednesday, February 15, 2017 12:12 AM
> To: Alexander Clemm <alexander.cl...@huawei.com>
> Cc: kwat...@juniper.net; i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for
> draft-ietf-i2rs-yang-network-topo
> 
> 
> 
> .
> I mean that the server will consider a configured item, and decide if
> it can be used or not.  If the configured item has a reference to
> something that doesn't (yet) exist (weak reference; require-instance
> false), the server leaves the item in the config, and moves on.  At
> some later time, suppose the weak reference is fulfilled; at this
> point the server decides that the configured item can be used, and it
> instantiates the item in the /-state list.  Once it is there, maybe
> some other configured item has a reference to this one, and it can
> also be instantiated etc.
> 
> And it goes the other way as well; suppose a server provided item is
> removed by the server; at this point the server would also remove
> items in the state list that originated in the configuration - however
> they are not removed from the config, just the state.
> (Server provided items would only show up in the state in this
> solution).
> 
> The state subtree works exactly like the operational-state datastore
> in draft-ietf-netmod-revised-datastores.
> 
> 
> Thank you, this clarifies the earlier statement
> 
> 
> > One of the issues that we are facing is that a configured topology 
> > might refer to a configured topology or a server-provided topology, 
> > and we would like to avoid making a case distinction as to which 
> > category we are referring to.
> 
> I believe my proposed solution handles this.
> 
> > At the same time, we are making use of leafrefs to express a number of
> > integrity constraints which are part of the model: as a node is part 
> > of a topology, and a topology has an underlay topology, we make sure 
> > that the underlay node is part of the underlay topology (and not just 
> > any arbitrary node).
> 
> Can you point me to the place in the model where this is specified?
> 
> Or did you mean that today you have to mention this in plain text, but
> it would be nice if it could be captured formally in the model?
> 
>   It is covered in the model today. E.g.:

Ok.  Here the model uses require-instance false, so if these ponts to
the state tree instead, you'd get the same effect.


/martin


> 
> In networks/network/node/supporting-node 
>  leaf network-ref {
>type leafref {
>  path "../../../supporting-network/network-ref";
>require-instance false;
>}
> (supporting node is contained in supporting network)
> 
> Supporting link:
>   +--rw supporting-link* [network-ref link-ref]
>  +--rw network-ref-> ../../../nd:supporting-network/network-ref
>  +--rw link-ref ->
>  
> /nd:networks/network[nd:network-id=current()/../network-ref]/link/link-id
> 
> (supporting link is a link contained in the supporting network)
> 
> Supporting termination point:
>   +--rw supporting-termination-point* [network-ref node-ref tp-ref]
>  +--rw network-ref-> ../../../nd:supporting-node/network-ref
>  +--rw node-ref   -> ../../../nd:supporting-node/node-ref
>  +--rw tp-ref ->
>  
> /nd:networks/network[nd:network-id=current()/../network-ref]/node[nd:node-id=current()/../node-ref]/termination-point/tp-id
> 
> (supporting termination point is contained in supporting network and
> supporting node)
> 
> It is those leafrefs whose transposition in the split subtree model
> (where we encounter alternative paths) I am concerned will be
> problematic.
> 
> 
>  
> 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Alexander Clemm]

Hello Martin,  
Thank you.  Your first explanation is clear.  Regarding the expression of 
constraints, see inline, below (thread is pruned for clarity)
--- Alex

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Wednesday, February 15, 2017 12:12 AM
To: Alexander Clemm <alexander.cl...@huawei.com>
Cc: kwat...@juniper.net; i2rs@ietf.org
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo



.
I mean that the server will consider a configured item, and decide if it can be 
used or not.  If the configured item has a reference to something that doesn't 
(yet) exist (weak reference; require-instance false), the server leaves the 
item in the config, and moves on.  At some later time, suppose the weak 
reference is fulfilled; at this point the server decides that the configured 
item can be used, and it instantiates the item in the /-state list.  Once it is 
there, maybe some other configured item has a reference to this one, and it can 
also be instantiated etc.

And it goes the other way as well; suppose a server provided item is removed by 
the server; at this point the server would also remove items in the state list 
that originated in the configuration - however they are not removed from the 
config, just the state.
(Server provided items would only show up in the state in this solution).

The state subtree works exactly like the operational-state datastore in 
draft-ietf-netmod-revised-datastores.


Thank you, this clarifies the earlier statement


> One of the issues that we are facing is that a configured topology 
> might refer to a configured topology or a server-provided topology, 
> and we would like to avoid making a case distinction as to which 
> category we are referring to.

I believe my proposed solution handles this.

> At the same time, we are making use of leafrefs to express a number of 
> integrity constraints which are part of the model: as a node is part 
> of a topology, and a topology has an underlay topology, we make sure 
> that the underlay node is part of the underlay topology (and not just 
> any arbitrary node).

Can you point me to the place in the model where this is specified?

Or did you mean that today you have to mention this in plain text, but it would 
be nice if it could be captured formally in the model?

  It is covered in the model today. E.g.:

In networks/network/node/supporting-node 
 leaf network-ref {
   type leafref {
 path "../../../supporting-network/network-ref";
   require-instance false;
   }
(supporting node is contained in supporting network)

Supporting link:
  +--rw supporting-link* [network-ref link-ref]
 +--rw network-ref-> ../../../nd:supporting-network/network-ref
 +--rw link-ref   -> 
/nd:networks/network[nd:network-id=current()/../network-ref]/link/link-id

(supporting link is a link contained in the supporting network)

Supporting termination point:
  +--rw supporting-termination-point* [network-ref node-ref tp-ref]
 +--rw network-ref-> ../../../nd:supporting-node/network-ref
 +--rw node-ref   -> ../../../nd:supporting-node/node-ref
 +--rw tp-ref -> 
/nd:networks/network[nd:network-id=current()/../network-ref]/node[nd:node-id=current()/../node-ref]/termination-point/tp-id

(supporting termination point is contained in supporting network and supporting 
node)

It is those leafrefs whose transposition in the split subtree model (where we 
encounter alternative paths) I am concerned will be problematic.  


 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Martin Bjorklund]

Hi,

Alexander Clemm <alexander.cl...@huawei.com> wrote:
> Hi, 
> 
> One comment inline re: option 1, 
> 
> Thanks
> --- Alex
> 
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Tuesday, February 14, 2017 8:41 AM
> To: kwat...@juniper.net
> Cc: i2rs@ietf.org
> Subject: Re: [i2rs] modeling options for
> draft-ietf-i2rs-yang-network-topo
> 
> Kent Watsen <kwat...@juniper.net> wrote:
> > 
> > 
> > [moving yang-doctors to BCC]
> > 
> > 
> > >> OPTION 1: separate /foo and /foo-state trees
> > >> 
> > >> 
> > >> This option was/is described here:
> > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > >> 
> > >> PROS:
> > >>   a) does NOT break legacy clients (how we got here)
> > >>   b) consistent with convention used in many IETF modules
> > >>   c) able to show if/how opstate may differ from configured values
> > >> 
> > >> CONS:
> > >>   a) questionably valid YANG leafref usage
> > >
> > > What does this mean?
> > 
> > I'm referring to how the description statement explains that the 
> > server may look to operational state in order to resolve the leafref, 
> > which is to result in behavior similar to pre-configuration in RFC 
> > 7223.
> 
> Ok, I didn't pay close attention to the proposal in the quoted email.
> 
> I would design this a bit differently.  The config true leaf
> "dependency" should have a leafref to the config false node name, with
> require-instance false.  The description should explain that the
> configuration item will be used by the server if all dependencies
> exist.  When the configuration item is used, it shows up in the config
> false list.
> 
> This way, the leafref usage is valid and straight forward.
> 
>  
> Hi Martin,
>  
> I don't understand one statement you are making "When the
> configuration item is used, it shows up in the config false list" -
> can you please elaborate?

I mean that the server will consider a configured item, and decide if
it can be used or not.  If the configured item has a reference to
something that doesn't (yet) exist (weak reference; require-instance
false), the server leaves the item in the config, and moves on.  At
some later time, suppose the weak reference is fulfilled; at this
point the server decides that the configured item can be used, and it
instantiates the item in the /-state list.  Once it is there, maybe
some other configured item has a reference to this one, and it can
also be instantiated etc.

And it goes the other way as well; suppose a server provided item is
removed by the server; at this point the server would also remove
items in the state list that originated in the configuration - however
they are not removed from the config, just the state.
(Server provided items would only show up in the state in this
solution).

The state subtree works exactly like the operational-state datastore
in draft-ietf-netmod-revised-datastores.

> One of the issues that we are facing is that a configured topology
> might refer to a configured topology or a server-provided topology,
> and we would like to avoid making a case distinction as to which
> category we are referring to.

I believe my proposed solution handles this.

> At the same time, we are making use of leafrefs to express a number of
> integrity constraints which are part of the model: as a node is part
> of a topology, and a topology has an underlay topology, we make sure
> that the underlay node is part of the underlay topology (and not just
> any arbitrary node).

Can you point me to the place in the model where this is specified?

Or did you mean that today you have to mention this in plain text, but
it would be nice if it could be captured formally in the model?

> Likewise for termination points and links (with
> some additional constraints, such as a TP's supporting TP be contained
> in the TP's containing node's supporting node, with supporting links
> of a link being terminated by supporting TPs of the link's TP, etc) It
> would be really nice to capture these without resorting to description
> statements, and without overly complex path expressions (particularly
> as leafrefs refer to a single path, not a choice of alternative paths)
> 
> What you describe above does not seem to address this entirely.  You
> describe having a leafref to a config false node.  We need to have a
> leafref that can effectively be pointed at a config false, or a config
> true node.  How can we achieve that when both nodes are in separat

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

[Alexander Clemm]

Hi, 

One comment inline re: option 1, 

Thanks
--- Alex

-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin Bjorklund
Sent: Tuesday, February 14, 2017 8:41 AM
To: kwat...@juniper.net
Cc: i2rs@ietf.org
Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

Kent Watsen <kwat...@juniper.net> wrote:
> 
> 
> [moving yang-doctors to BCC]
> 
> 
> >> OPTION 1: separate /foo and /foo-state trees
> >> 
> >> 
> >> This option was/is described here:
> >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> >> 
> >> PROS:
> >>   a) does NOT break legacy clients (how we got here)
> >>   b) consistent with convention used in many IETF modules
> >>   c) able to show if/how opstate may differ from configured values
> >> 
> >> CONS:
> >>   a) questionably valid YANG leafref usage
> >
> > What does this mean?
> 
> I'm referring to how the description statement explains that the 
> server may look to operational state in order to resolve the leafref, 
> which is to result in behavior similar to pre-configuration in RFC 
> 7223.

Ok, I didn't pay close attention to the proposal in the quoted email.

I would design this a bit differently.  The config true leaf "dependency" 
should have a leafref to the config false node name, with require-instance 
false.  The description should explain that the configuration item will be used 
by the server if all dependencies exist.  When the configuration item is used, 
it shows up in the config false list.

This way, the leafref usage is valid and straight forward.

 
Hi Martin,
 
I don't understand one statement you are making "When the configuration item is 
used, it shows up in the config false list" - can you please elaborate? 

One of the issues that we are facing is that a configured topology might refer 
to a configured topology or a server-provided topology, and we would like to 
avoid making a case distinction as to which category we are referring to.  

At the same time, we are making use of leafrefs to express a number of 
integrity constraints which are part of the model:  as a node is part of a 
topology, and a topology has an underlay topology, we make sure that the 
underlay node is part of the underlay topology (and not just any arbitrary 
node).  Likewise for termination points and links (with some additional 
constraints, such as a TP's supporting TP be contained in the TP's containing 
node's supporting node, with supporting links of a link being terminated by 
supporting TPs of the link's TP, etc)  It would be really nice to capture these 
without resorting to description statements, and without overly complex path 
expressions (particularly as leafrefs refer to a single path, not a choice of 
alternative paths) 

What you describe above does not seem to address this entirely.  You describe 
having a leafref to a config false node.  We need to have a leafref that can 
effectively be pointed at a config false, or a config true node.  How can we 
achieve that when both nodes are in separate subtrees?

We could consider a solution in which we have two dependencies - one leafref to 
point to config false, another leafref to point to config true.  But this 
solution seems a bit awkward, as it requires different handling by applications 
of each case.  Perhaps use a union of two leafrefs with different paths.  This 
might be a solution, but the question regarding how to capture the 
overlay/underlay layering constraints remains.  

--- Alex



> >>   b) complex server implementation (to handle require-instance 
> >> false)
> >
> >Can you elaborate on this one?
> 
> This is primarily a reflection of the CON listed above, in that it 
> seems that a server would need to have special handling for when 
> dependencies transition from being present to not-present and vice 
> versa, much like the code to handle when a physical card is plugged in 
> or removed.

Yes, but I think this is inherent to the problem at hand.  Even with the config 
true solution defined in the current draft, it is not clear how things that 
were created by the server would be deleted (if there were references to them).

> Note: I should've listed this as a CON for OPTION 2 as well.
> 
> 
> 
> >>   c) eventually the module would need to migrate to the long-term 
> >>  solution, which would result in needing to also rewrite all
> >>  modules that have augmented it (e.g., ietf-te-topology).
> >>   d) leafref path expressions really only work for configuration data,
> >>  though a clever server could have a special ability to peak at
> >>  the opstate values when doing va

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

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> 
> [moving yang-doctors to BCC]
> 
> 
> >> OPTION 1: separate /foo and /foo-state trees
> >> 
> >> 
> >> This option was/is described here:
> >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> >> 
> >> PROS:
> >>   a) does NOT break legacy clients (how we got here)
> >>   b) consistent with convention used in many IETF modules
> >>   c) able to show if/how opstate may differ from configured values
> >> 
> >> CONS:
> >>   a) questionably valid YANG leafref usage
> >
> > What does this mean?
> 
> I'm referring to how the description statement explains that
> the server may look to operational state in order to resolve
> the leafref, which is to result in behavior similar to 
> pre-configuration in RFC 7223.

Ok, I didn't pay close attention to the proposal in the quoted email.

I would design this a bit differently.  The config true leaf
"dependency" should have a leafref to the config false node name, with
require-instance false.  The description should explain that the
configuration item will be used by the server if all dependencies
exist.  When the configuration item is used, it shows up in the config
false list.

This way, the leafref usage is valid and straight forward.

> >>   b) complex server implementation (to handle require-instance false)
> >
> >Can you elaborate on this one?
> 
> This is primarily a reflection of the CON listed above, in that
> it seems that a server would need to have special handling for 
> when dependencies transition from being present to not-present
> and vice versa, much like the code to handle when a physical
> card is plugged in or removed.

Yes, but I think this is inherent to the problem at hand.  Even with
the config true solution defined in the current draft, it is not clear
how things that were created by the server would be deleted (if there
were references to them).

> Note: I should've listed this as a CON for OPTION 2 as well.
> 
> 
> 
> >>   c) eventually the module would need to migrate to the long-term 
> >>  solution, which would result in needing to also rewrite all
> >>  modules that have augmented it (e.g., ietf-te-topology).
> >>   d) leafref path expressions really only work for configuration data,
> >>  though a clever server could have a special ability to peak at
> >>  the opstate values when doing validations.  Of course, with 
> >>  require-instance is false, the value of leafref based validation
> >>  checking is negated anyway, even for config true nodes, so this
> >>  may not matter much.
> >> 
> >> 
> >> 
> >> OPTION 2: explicit client-option to also return tagged opstate data
> >> ---
> >> 
> >> This option takes a couple forms.  The first is module-specific and
> >> the second is generic.  In both cases, the idea is modeled after the
> >> with-defaults solution (RFC6243), wherein the client passes a special
> >> flag into  causing the server to also return opstate data,
> >> having a special metadata flag set, intermingled with the
> >> configuration
> >> data.
> >> 
> >> 
> >> 2A: Module-specific version
> >> 
> >>module foo {
> >>   import ietf-netconf { prefix nc; }
> >>   import ietf-yang-metadata { prefix md; }
> >>   md:annotation server-provided {
> >>  type boolean;
> >>   }
> >>   container nodes {
> >>  config true;
> >>  list node {
> >> key "name";
> >> leaf name { type string; }
> >> leaf dependency {
> >>type leafref {
> >>  path "../node/name"
> >>  require-instance false;
> >>}
> >> }
> >>  }
> >>   }
> >>   augment /nc:get-config/nc:input {
> >>  leaf with-server-provided {
> >> type boolean;
> >>  }
> >>   }
> >>}
> >
> > I don't think this solution is substantially different from the
> > solution in draft-ietf-i2rs-yang-network-topo-10.  You have just moved
> > a config false leaf to a meta-data annotation.  This solution suffers
> > from the same problems as the solution in
> > draft-ietf-i2rs-yang-network-topo-10.
> 
> There are two primary differences:
> 
> 1) It doesn't break legacy clients

The solution in the draft doesn't break legacy clients either -
there's a config false leaf among the config true.  No problem.

>, because it requires the client to
>explicitly pass a 'with-server-provided' flag in the 
>request in order to get back the extended response.  Likewise, it
>doesn't break backup/restore workflows, as the server can discard
>any 'server-provided' nodes passed in an  operation.

Huh?  This goes against the defined behavior of 6241 + 7950.  This is
the main problem with the solution in the current draft.

If a client sends a  for data in running, the server
cannot send back data 

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

[Robert Wilton]

Hi Kent,

I think that the answer depends on when this module needs to be published:

If it needs to be published now, then I think that it should follow the 
standard IETF config/state module conventions and use separate /foo and 
/foo-state trees.  This should make the module most widely usable.  
Would it help if the model defined two "require-instance false" 
dependency leaf refs, one to the potential underlay node in the config 
tree, and a second to the potential underlay node in the state tree?


Otherwise, if this model can be delayed until the revised datastores and 
I2RS work progresses then it could use a single combined config/state 
tree.  It seems that the revised datastore solution would allow for a 
simpler model to be constructed to represent network topologies.


Rob


On 14/02/2017 13:55, Kent Watsen wrote:


[moving yang-doctors to BCC]



OPTION 1: separate /foo and /foo-state trees


This option was/is described here:
https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.

PROS:
   a) does NOT break legacy clients (how we got here)
   b) consistent with convention used in many IETF modules
   c) able to show if/how opstate may differ from configured values

CONS:
   a) questionably valid YANG leafref usage

What does this mean?

I'm referring to how the description statement explains that
the server may look to operational state in order to resolve
the leafref, which is to result in behavior similar to
pre-configuration in RFC 7223.




   b) complex server implementation (to handle require-instance false)

Can you elaborate on this one?

This is primarily a reflection of the CON listed above, in that
it seems that a server would need to have special handling for
when dependencies transition from being present to not-present
and vice versa, much like the code to handle when a physical
card is plugged in or removed.

Note: I should've listed this as a CON for OPTION 2 as well.




   c) eventually the module would need to migrate to the long-term
  solution, which would result in needing to also rewrite all
  modules that have augmented it (e.g., ietf-te-topology).
   d) leafref path expressions really only work for configuration data,
  though a clever server could have a special ability to peak at
  the opstate values when doing validations.  Of course, with
  require-instance is false, the value of leafref based validation
  checking is negated anyway, even for config true nodes, so this
  may not matter much.



OPTION 2: explicit client-option to also return tagged opstate data
---

This option takes a couple forms.  The first is module-specific and
the second is generic.  In both cases, the idea is modeled after the
with-defaults solution (RFC6243), wherein the client passes a special
flag into  causing the server to also return opstate data,
having a special metadata flag set, intermingled with the
configuration
data.


2A: Module-specific version

module foo {
   import ietf-netconf { prefix nc; }
   import ietf-yang-metadata { prefix md; }
   md:annotation server-provided {
  type boolean;
   }
   container nodes {
  config true;
  list node {
 key "name";
 leaf name { type string; }
 leaf dependency {
type leafref {
  path "../node/name"
  require-instance false;
}
 }
  }
   }
   augment /nc:get-config/nc:input {
  leaf with-server-provided {
 type boolean;
  }
   }
}

I don't think this solution is substantially different from the
solution in draft-ietf-i2rs-yang-network-topo-10.  You have just moved
a config false leaf to a meta-data annotation.  This solution suffers
from the same problems as the solution in
draft-ietf-i2rs-yang-network-topo-10.

There are two primary differences:

1) It doesn't break legacy clients, because it requires the client to
explicitly pass a 'with-server-provided' flag in the 
request in order to get back the extended response.  Likewise, it
doesn't break backup/restore workflows, as the server can discard
any 'server-provided' nodes passed in an  operation.
Lastly, it doesn't break /, as there is no comingling
of opstate data in the 'running' datastore.

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 

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

[Kent Watsen]

[moving yang-doctors to BCC]


>> OPTION 1: separate /foo and /foo-state trees
>> 
>> 
>> This option was/is described here:
>> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
>> 
>> PROS:
>>   a) does NOT break legacy clients (how we got here)
>>   b) consistent with convention used in many IETF modules
>>   c) able to show if/how opstate may differ from configured values
>> 
>> CONS:
>>   a) questionably valid YANG leafref usage
>
> What does this mean?

I'm referring to how the description statement explains that
the server may look to operational state in order to resolve
the leafref, which is to result in behavior similar to 
pre-configuration in RFC 7223.



>>   b) complex server implementation (to handle require-instance false)
>
>Can you elaborate on this one?

This is primarily a reflection of the CON listed above, in that
it seems that a server would need to have special handling for 
when dependencies transition from being present to not-present
and vice versa, much like the code to handle when a physical
card is plugged in or removed.

Note: I should've listed this as a CON for OPTION 2 as well.



>>   c) eventually the module would need to migrate to the long-term 
>>  solution, which would result in needing to also rewrite all
>>  modules that have augmented it (e.g., ietf-te-topology).
>>   d) leafref path expressions really only work for configuration data,
>>  though a clever server could have a special ability to peak at
>>  the opstate values when doing validations.  Of course, with 
>>  require-instance is false, the value of leafref based validation
>>  checking is negated anyway, even for config true nodes, so this
>>  may not matter much.
>> 
>> 
>> 
>> OPTION 2: explicit client-option to also return tagged opstate data
>> ---
>> 
>> This option takes a couple forms.  The first is module-specific and
>> the second is generic.  In both cases, the idea is modeled after the
>> with-defaults solution (RFC6243), wherein the client passes a special
>> flag into  causing the server to also return opstate data,
>> having a special metadata flag set, intermingled with the
>> configuration
>> data.
>> 
>> 
>> 2A: Module-specific version
>> 
>>module foo {
>>   import ietf-netconf { prefix nc; }
>>   import ietf-yang-metadata { prefix md; }
>>   md:annotation server-provided {
>>  type boolean;
>>   }
>>   container nodes {
>>  config true;
>>  list node {
>> key "name";
>> leaf name { type string; }
>> leaf dependency {
>>type leafref {
>>  path "../node/name"
>>  require-instance false;
>>}
>> }
>>  }
>>   }
>>   augment /nc:get-config/nc:input {
>>  leaf with-server-provided {
>> type boolean;
>>  }
>>   }
>>}
>
> I don't think this solution is substantially different from the
> solution in draft-ietf-i2rs-yang-network-topo-10.  You have just moved
> a config false leaf to a meta-data annotation.  This solution suffers
> from the same problems as the solution in
> draft-ietf-i2rs-yang-network-topo-10.

There are two primary differences:

1) It doesn't break legacy clients, because it requires the client to
   explicitly pass a 'with-server-provided' flag in the 
   request in order to get back the extended response.  Likewise, it
   doesn't break backup/restore workflows, as the server can discard
   any 'server-provided' nodes passed in an  operation.
   Lastly, it doesn't break /, as there is no comingling
   of opstate data in the 'running' datastore.

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.



> /martin

Kent




>> 
>> For instance:
>> 
>>   
>> 
>>   
>> 
>> 
>>
>> 
>>
>>  
>>
>>  overlay-node
>>  underlay-node
>>
>>
>>  underlay-node
>>
>>  
>>
>> 
>> PROS:
>>   a) does NOT break legacy clients (how we got here)
>>   b) having all data in one merged tree is simpler to process 
>>  than two separate queries.
>>   c) module doesn't have to be rewritten for revised-datastores;
>>  the 'with-server-provided' switch would just not be passed
>>  by new opstate-aware clients.
>> 
>> CONS:
>>   a) inconsistent 

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

[Martin Bjorklund]

Hi,

Kent Watsen  wrote:
> Hi All,
> 
> It's been quiet on the list as a small group of us (Alex, Xufeng,
> Pavan, and myself) went offline to discuss for a bit before bringing
> back to the group, which I'm doing now.
> 
> Regarding resolving the modeling the issue, we went through nearly a
> dozen ideas that we've narrowed down to two.  We discussed the
> pros/cons, but since we each emphasize different values, we were
> unable to reach a consensus amongst ourselves.  We're hoping that
> bringing the discussion here will bring more perspectives and resolve
> this issue.
> 
> 
> OPTION 1: separate /foo and /foo-state trees
> 
> 
> This option was/is described here:
> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> 
> PROS:
>   a) does NOT break legacy clients (how we got here)
>   b) consistent with convention used in many IETF modules
>   c) able to show if/how opstate may differ from configured values
> 
> CONS:
>   a) questionably valid YANG leafref usage

What does this mean?

>   b) complex server implementation (to handle require-instance false)

Can you elaborate on this one?

>   c) eventually the module would need to migrate to the long-term 
>  solution, which would result in needing to also rewrite all
>  modules that have augmented it (e.g., ietf-te-topology).
>   d) leafref path expressions really only work for configuration data,
>  though a clever server could have a special ability to peak at
>  the opstate values when doing validations.  Of course, with 
>  require-instance is false, the value of leafref based validation
>  checking is negated anyway, even for config true nodes, so this
>  may not matter much.
> 
> 
> 
> OPTION 2: explicit client-option to also return tagged opstate data
> ---
> 
> This option takes a couple forms.  The first is module-specific and
> the second is generic.  In both cases, the idea is modeled after the
> with-defaults solution (RFC6243), wherein the client passes a special
> flag into  causing the server to also return opstate data,
> having a special metadata flag set, intermingled with the
> configuration
> data.
> 
> 
> 2A: Module-specific version
> 
>module foo {
>   import ietf-netconf { prefix nc; }
>   import ietf-yang-metadata { prefix md; }
>   md:annotation server-provided {
>  type boolean;
>   }
>   container nodes {
>  config true;
>  list node {
> key "name";
> leaf name { type string; }
> leaf dependency {
>type leafref {
>  path "../node/name"
>  require-instance false;
>}
> }
>  }
>   }
>   augment /nc:get-config/nc:input {
>  leaf with-server-provided {
> type boolean;
>  }
>   }
>}

I don't think this solution is substantially different from the
solution in draft-ietf-i2rs-yang-network-topo-10.  You have just moved
a config false leaf to a meta-data annotation.  This solution suffers
from the same problems as the solution in
draft-ietf-i2rs-yang-network-topo-10.



/martin




> 
> For instance:
> 
>   
> 
>   
> 
> 
>
> 
>
>  
>
>  overlay-node
>  underlay-node
>
>
>  underlay-node
>
>  
>
> 
> PROS:
>   a) does NOT break legacy clients (how we got here)
>   b) having all data in one merged tree is simpler to process 
>  than two separate queries.
>   c) module doesn't have to be rewritten for revised-datastores;
>  the 'with-server-provided' switch would just not be passed
>  by new opstate-aware clients.
> 
> CONS:
>   a) inconsistent with convention used in many IETF modules
>   b) unclear how to model 'with-server-provided' for RESTCONF
>  (just use a description statement to define a query param?)
>   c) unable to return the opstate value for any configured node
>  (is it needed here?)
>   d) requires server to support metadata, which is a relatively
>  new concept and maybe not well supported by servers.
>   e) only changes presentation-layer (doesn't change the fact 
>  that 'server-provided' data is not configuration), thus the
>  leafref path expressions still don't work quite the way as
>  desired, though a clever server could have a special ability
>  to peak at the opstate values when doing validations. Of 
>  course, with require-instance is false, the value of leafref
>  based validation checking is negated anyway, even for config
>  true nodes, so this may not matter much.
> 
> 
> 
> 
> 2B: Generic version
> 
> The generic version is much the same, but rather than letting the
> solution be limited to this one module, the idea is to generalize
> it so it could be a server-level feature.  Having a 

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

[Kent Watsen]

Hi All,

It's been quiet on the list as a small group of us (Alex, Xufeng, Pavan, and 
myself) went offline to discuss for a bit before bringing back to the group, 
which I'm doing now.

Regarding resolving the modeling the issue, we went through nearly a dozen 
ideas that we've narrowed down to two.  We discussed the pros/cons, but since 
we each emphasize different values, we were unable to reach a consensus amongst 
ourselves.  We're hoping that bringing the discussion here will bring more 
perspectives and resolve this issue.


OPTION 1: separate /foo and /foo-state trees


This option was/is described here:  
https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.

PROS:
  a) does NOT break legacy clients (how we got here)
  b) consistent with convention used in many IETF modules
  c) able to show if/how opstate may differ from configured values

CONS:
  a) questionably valid YANG leafref usage
  b) complex server implementation (to handle require-instance false)
  c) eventually the module would need to migrate to the long-term 
 solution, which would result in needing to also rewrite all
 modules that have augmented it (e.g., ietf-te-topology).
  d) leafref path expressions really only work for configuration data,
 though a clever server could have a special ability to peak at
 the opstate values when doing validations.  Of course, with 
 require-instance is false, the value of leafref based validation
 checking is negated anyway, even for config true nodes, so this
 may not matter much.



OPTION 2: explicit client-option to also return tagged opstate data
---

This option takes a couple forms.  The first is module-specific and
the second is generic.  In both cases, the idea is modeled after the
with-defaults solution (RFC6243), wherein the client passes a special
flag into  causing the server to also return opstate data,
having a special metadata flag set, intermingled with the configuration
data.


2A: Module-specific version

   module foo {
  import ietf-netconf { prefix nc; }
  import ietf-yang-metadata { prefix md; }
  md:annotation server-provided {
 type boolean;
  }
  container nodes {
 config true;
 list node {
key "name";
leaf name { type string; }
leaf dependency {
   type leafref {
 path "../node/name"
 require-instance false;
   }
}
 }
  }
  augment /nc:get-config/nc:input {
 leaf with-server-provided {
type boolean;
 }
  }
   }

For instance:

  

  


   

   
 
   
 overlay-node
 underlay-node
   
   
 underlay-node
   
 
   

PROS:
  a) does NOT break legacy clients (how we got here)
  b) having all data in one merged tree is simpler to process 
 than two separate queries.
  c) module doesn't have to be rewritten for revised-datastores;
 the 'with-server-provided' switch would just not be passed
 by new opstate-aware clients.

CONS:
  a) inconsistent with convention used in many IETF modules
  b) unclear how to model 'with-server-provided' for RESTCONF
 (just use a description statement to define a query param?)
  c) unable to return the opstate value for any configured node
 (is it needed here?)
  d) requires server to support metadata, which is a relatively
 new concept and maybe not well supported by servers.
  e) only changes presentation-layer (doesn't change the fact 
 that 'server-provided' data is not configuration), thus the
 leafref path expressions still don't work quite the way as
 desired, though a clever server could have a special ability
 to peak at the opstate values when doing validations. Of 
 course, with require-instance is false, the value of leafref
 based validation checking is negated anyway, even for config
 true nodes, so this may not matter much.




2B: Generic version

The generic version is much the same, but rather than letting the
solution be limited to this one module, the idea is to generalize
it so it could be a server-level feature.  Having a generic RPC to
return data from more than one DS at a time was something that was
discussed ~1.5 years ago when we were kicking off the opstate effort.

The PROS and CONS are similar, but there are additional CONS in the
generic case.  The main ones being 1) how to simultaneously return 
both the config and opstate values for a node (split at the leaves)
and 2) how to handle some YANG statements such as presence containers
and choice nodes.  For this reason, (2B) is NOT considered a viable
solution and is only here so that it's clear that it was discussed.



If there are any other options people want to suggest, please do so now!

Thanks,
Kent