Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Hi, just one comment, I think the example is a bit oversimplified.  

Specifically, the leafref just indicates that you should point to another node.  In the full model, there is a requirement that you cannot point just to any other node, but a node that is part of the actual underlay.  Likewise, in the case of a TP, the supporting TP cannot just be any other TP, but a TP in the underlay, itself contained in a supporting node.  

In the case of the opstate solution, you would need to distinguish different paths based on whether the supporting is opstate or not, and you would likewise have to reflect the same in the constraints to make sure that the supporting is part of the underlay and not a "random" resource, but one that makes sense (e.g. supporting TP part of a supporting node, etc).  There are 3 cases:  opstate on opstate, configured on configured, and configured on opstate.  

The resulting conditions make the model considerable more complex.  More complex means harder to use and extend.  The alternative is to not model those constraints but put them into the description, thus punting the problem from the framework to the user.  This would strike me as SMIv2-ish, which is a route that I think with a YANG model is better to avoid.  

--- Alex

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Friday, February 03, 2017 10:12 AM
To: Xufeng Liu <Xufeng_Liu@jabil.com>; Martin Bjorklund <mbj@tail-f.com>
Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Xufeng] Right. If we do so, the approach will be different from RFC7223, and requires the capability that a "config true" leafref references a "config false" leaf.

I think my proposal was misunderstood, so here's a more complete example:

Assume the following schema is used by client/servers that implement the long-term opstate solution presented in the revised-datastores draft:

   module foo {
      container nodes {
         config true;
         list node {
            key "name";
            leaf name { type string; }
            leaf dependency {
               type leafref {
                 path "../node/name"
                 require-instance false;
                 description
                   "In the case when a configured node (i.e. in the running DS)
                    has a dependency on a node that is not configured, the system
                    may try to resolve the dependency as operational state data
                    (i.e. in the operational-state DS).  As operational state 
                    data may have a lifecycle independent of configuration, there
                    is no guarantee that the opstate data will exist.  Therefore,
                    application of the configuration node is conditional, resulting
                    in an effect much like pre-provisioning interfaces in RFC 7223.";
               }
            }
         }
     }
   }

Specifically, note that the leafref is from one config true node to another config true node.  I understand that the semantics are almost as if it were like a config true node were pointing to a config false node, but I believe that this should be okay, that is, that we should specifically define this convention as okay.

Assuming that we're okay with the above, we proposal for a near-term solution, that does NOT utilize the opstate solution, follows:

   module foo {
      container nodes {
         config true;
         list node {
            key "name";
            leaf name { type string; }
            leaf dependency {
               type leafref {
                 path "../node/name"
                 require-instance false;
                 description
                   "In the case when a configured node (i.e. in the running DS)
                    has a dependency on a node that is not configured, the system
                    may try to resolve the dependency as operational state data
                    (i.e. under the /nodes-state tree).  As operational state 
                    data may have a lifecycle independent of configuration, there
                    is no guarantee that the opstate data will exist.  Therefore,
                    application of the configuration node is conditional, resulting
                    in an effect much like pre-provisioning interfaces in RFC 7223.";
               }
            }
         }
      }
      container nodes-state {
         config false;
         list node {
            key "name";
            leaf name { type string; }
            leaf dependency {
               type leafref {
                 path "../node/name"
                 require-instance false;
               }
            }
         }
      }
   }

This module is semantically identical to the first, but now, in additional to the leafref potentially hopping datastores, it also needs to hop paths (i.e. s/nodes/nodes-state/). Note the minute change in the first sentence of the description statement.  Yes, it's a hack, but since the hopping is implemented internally anyway, maybe it's okay as a stop-gap short-term solution?

Kent

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