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  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 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
> >> 

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