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

From: Lou Berger <[email-masked]>
Date: Wed, 1 Feb 2017 13:52:25 -0500

Juergen,

    What precludes treating such dependencies in the same way
per-provisioning is handled by RFC7223?

Lou

On 1/25/2017 10:18 AM, Juergen Schoenwaelder wrote:
> On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote:
>> So - if one has models - such as a writable topology - where there
>> can be dependencies on dynamic data, then those models can't be in
>> the configuration data-store as currently defined.
>>
> Yes.
>
> /js
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Feb 2017 20:32:38 +0100

> per-provisioning is handled by RFC7223?

This is fine. But having direct dependencies, e.g., leafrefs from
config true leafs to config false leafs, is not.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Lou Berger <[email-masked]>
Date: Wed, 1 Feb 2017 15:56:49 -0500

> config true leafs to config false leafs, is not.

Okay, then we're on the same page -- I think some may have missed the
possibility of handling references to dynamic topology information in
config using a 'pre-provisioning' approach.

Thanks,
Lou

---

From: Alia Atlas <[email-masked]>
Date: Wed, 1 Feb 2017 16:13:42 -0500

> config using a 'pre-provisioning' approach.

I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this
would
look like and how it would work for the base topology model, so that the WG
can
consider all potentially viable options.  I'm not certain how it would
function for the
recursive nature and it does presume the separate /config and /oper-state
trees in
the data-model that were a concern (though certainly the current
recommended
approach for YANG models).

Regards,
Alia

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 1 Feb 2017 22:03:59 +0000

We are working this separately and will articulate the different options and their respective issues.

The fundamental issue is still the fact that you may have dependencies in overlay topologies on underlay topologies that are discovered and represent “state”, and that in fact your underlay may be either.

RFC 7223, as far as I can tell, sidesteps this issue.  It does define a type “interface-ref” with a path to reference a configured interface, and it does define a type  “interface-state-ref” to reference an operationally present interface.  However, interface-state-ref is used only in read-only objects, whereas (to put the analogy) it is needed for configurable objects as well.  Likewise, there are two types; really we need a union which would allow either (or a leafref with alternate paths, which is not supported).  While there are some analogies with a preprovisioning scenario, there are also differences.

Anyway, Xufeng, Kent, Pavan and I are having offline discussions and will come back with further elaboration on this.

--- Alex

From: i2rs [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, February 01, 2017 1:14 PM
To: Lou Berger <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:

I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this would
look like and how it would work for the base topology model, so that the WG can
consider all potentially viable options.  I'm not certain how it would function for the
recursive nature and it does presume the separate /config and /oper-state trees in
the data-model that were a concern (though certainly the current recommended
approach for YANG models).

Regards,
Alia

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 Feb 2017 08:33:29 +0100 (CET)

Alexander Clemm <[email-masked]> wrote:
> The fundamental issue is still the fact that you may have dependencies
> in overlay topologies on underlay topologies that are discovered and
> represent “state”, and that in fact your underlay may be either.
> 
> RFC 7223, as far as I can tell, sidesteps this issue.  It does define
> a type “interface-ref” with a path to reference a configured
> interface, and it does define a type “interface-state-ref” to
> reference an operationally present interface.  However,
> interface-state-ref is used only in read-only objects, whereas (to put
> the analogy) it is needed for configurable objects as well.  Likewise,
> there are two types; really we need a union which would allow either
> (or a leafref with alternate paths, which is not supported).  While
> there are some analogies with a preprovisioning scenario, there are
> also differences.

When people refer to the "pre-provisioning approach" in RFC 7223, it
is not the "interface-ref" or "interface-state-ref" they refer to.

The pre-provisioning mechanism in RFC 7223 says that when the device
initializes a detected interface, it will check the configuration to
see if there is config available for an interface with the same name
as the newly detected one.  If so, that config is used.

I think the idea was to use something similar here.  E.g., allow a
configured overlay to refer to a discovered underlay by name.  In YANG,
this can be done with a node with the same type; or possibly with a
leafref to the state data with "require-instance false".

This design allows an overlay to be configured for an existing
detected underlay.  Let's say the device reboots and starts to rebuild
its topologies.  During some period of time, the configured overlay
still exist in the config, but not in the state, since the underlay is
not yet available.  Once it becomes instantiated in the state, the
overlay is also instantiated in the state.  (This assumes that the
system-generated topology names do not change).

/martin

> 
> Anyway, Xufeng, Kent, Pavan and I are having offline discussions and
> will come back with further elaboration on this.
> 
> --- Alex
> 
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> 
> On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
>

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 2 Feb 2017 14:03:14 +0000

Hi Martin,

I know that this is a previously discussed solution, but I still have some issues with it:

1) In the case of the interfaces model, for each referenced interface-state, the operator needs to configure an interface object with the same interface name. However, in the case of the topology model, if we need to reference an underlay link-state, we will need to configure a topology (called network), a source node, a destination node, a source termination-point, a destination termination-point, which are five objects without including other consequent mandatory objects.

2) This approach stretches the definition of "system generated" non-configurable objects. The system generated objects mentioned in 1) are designed to be not configurable. Configuring them may result un-desirable consequences.

3) In general, this approach will not work if the referenced schema leaf is marked as "config false". In such a case, we cannot configure such a referenced leaf since it is not configurable.

Thanks,

- Xufeng

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Thursday, February 2, 2017 2:33 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-i2rs-yang-l3-
> [email-masked]; [email-masked]; [email-masked]
> When people refer to the "pre-provisioning approach" in RFC 7223, it is not the
> "interface-ref" or "interface-state-ref" they refer to.
> 
> initializes a detected interface, it will check the configuration to see if there is
> config available for an interface with the same name as the newly detected one.
> If so, that config is used.
> 
> I think the idea was to use something similar here.  E.g., allow a configured
> overlay to refer to a discovered underlay by name.  In YANG, this can be done
> with a node with the same type; or possibly with a leafref to the state data with
> "require-instance false".
> 
> This design allows an overlay to be configured for an existing detected underlay.
> Let's say the device reboots and starts to rebuild its topologies.  During some
> period of time, the configured overlay still exist in the config, but not in the state,
> since the underlay is not yet available.  Once it becomes instantiated in the state,
> the overlay is also instantiated in the state.  (This assumes that the system-
> generated topology names do not change).
> 
> 
> /martin
> 
> 
> 
> >
> > I would be happy to see Alex, Xufeng, Kent & Pavan articulate what
> > this would look like and how it would work for the base topology
> > model, so that the WG can consider all potentially viable options.
> > I'm not certain how it would function for the recursive nature and it
> > does presume the separate /config and /oper-state trees in the
> > data-model that were a concern (though certainly the current
> > recommended approach for YANG models).
> >
> > Regards,
> > Alia

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 2 Feb 2017 09:48:26 -0500

Lou and Juergen: 

Just to make sure I understand the pre-provisioning comment.  What you are referring to is the “when” statements in the clause below. 

     augment "/if:interfaces/if:interface" {

       when "if:type = 'ianaift:ethernetCsmacd'";

   // operational state parameters for Ethernet interfaces
     augment "/if:interfaces-state/if:interface" {
       when "if:type = 'ianaift:ethernetCsmacd'";

Thank you, 

Sue Hares 

From: i2rs [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, February 1, 2017 4:14 PM
To: Lou Berger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Regards,

Alia

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Feb 2017 16:14:54 +0100

I do not understand your question, but the answer is likely 'no'.

See Martin's email, perhaps that one helps.

In RFC 7223, you can configure an interface that is not currently
present. An interface is identified by a name and the interface
configuration sits in the configuration datastore. When an interface
starts to exist (e.g., a line card is inserted) that has a matching
name, then the interface configuration with the same name is applied
to it. This is RFC 7223 style pre-provisioning.

/js

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 Feb 2017 17:17:32 +0100 (CET)

Hi,

Xufeng Liu <[email-masked]> wrote:
> 1) In the case of the interfaces model, for each referenced
> interface-state, the operator needs to configure an interface object
> with the same interface name. However, in the case of the topology
> model, if we need to reference an underlay link-state, we will need to
> configure a topology (called network), a source node, a destination
> node, a source termination-point, a destination termination-point,
> which are five objects without including other consequent mandatory
> objects.

You don't have to configure a "dummy" object if you are not using
leafrefs to config.  And the number of nodes that you need for unique
identification should be totally independent.

> 2) This approach stretches the definition of "system generated"
> non-configurable objects. The system generated objects mentioned in 1)
> are designed to be not configurable. Configuring them may result
> un-desirable consequences.

See above.

> 3) In general, this approach will not work if the referenced schema
> leaf is marked as "config false". In such a case, we cannot configure
> such a referenced leaf since it is not configurable.

I don't understand this comment.

BTW, maybe further discussion about a new solution should be on the
i2rs ML only?

/martin

> > is not the
> > see if there is
> > configured
> > detected underlay.

---

From: Lou Berger <[email-masked]>
Date: Thu, 2 Feb 2017 11:53:45 -0500

Hi Sue,

    I think Juergen's comment covers what I was referring to. Does this
answer your question / make sense?

Cheers,

Lou

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 2 Feb 2017 17:13:36 +0000

Hi Martin,

> Sent: Thursday, February 2, 2017 11:18 AM
> To: Xufeng Liu <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> You don't have to configure a "dummy" object if you are not using leafrefs to
> config.  And the number of nodes that you need for unique identification should
> be totally independent.

[Xufeng] We have to do them in this case, because a link connects two termination-points, with each of them are in a node, which can only exists within the context of a topology. Without defining these objects, I cannot configure a valid link.
 
> > un-desirable consequences.
[Xufeng] We don't want to configure a node or link just because we need to reference it. Configuring a node means that the system will need to perform a series of tasks and may change the node to have different behaviors from previous "system generated" non-configurable node.

> I don't understand this comment.
[Xufeng] Assume the following model:

+--rw nodes
   +--rw node [id]
      +--rw id   string
      +--rw under-lay-attribute-a ???
+---ro nodes-state
   +--ro node [id]
      +--ro id   string
      +--ro attribute-a string

I cannot define the under-lay-attribute-a to reference attribute-a as:
               type leafref {
                 path "../node/attribute-a"'
               }

> 
> BTW, maybe further discussion about a new solution should be on the i2rs ML
> only?
> 
> 
> /martin
> 
> 
> >
> > Thanks,
> >
> > - Xufeng
> >
> > > > The fundamental issue is still the fact that you may have
> > > > dependencies in overlay topologies on underlay topologies that are
> > > > discovered and represent “state”, and that in fact your underlay may be
> either.
> > > >
> > > > RFC 7223, as far as I can tell, sidesteps this issue.  It does
> > > > define a type “interface-ref” with a path to reference a
> > > > configured interface, and it does define a type
> > > > “interface-state-ref” to reference an operationally present
> > > > interface.  However, interface-state-ref is used only in read-only
> > > > objects, whereas (to put the analogy) it is needed for
> > > > configurable objects as well.  Likewise, there are two types;
> > > > really we need a union which would allow either (or a leafref with
> > > > alternate paths, which is not supported).  While there are some
> > > > analogies with a preprovisioning scenario, there are also differences.
> > >
> > > configured overlay to refer to a discovered underlay by name.  In
> > > YANG, this can be done with a node with the same type; or possibly
> > > with a leafref to the state data with "require-instance false".
> > >
> > > period of time, the configured overlay still exist in the config,
> > > but not in the state, since the underlay is not yet available.  Once
> > > it becomes instantiated in the state, the overlay is also
> > > instantiated in the state.  (This assumes that the
> > > system-
> > > > Anyway, Xufeng, Kent, Pavan and I are having offline discussions
> > > > and will come back with further elaboration on this.
> > > >
> > > > --- Alex
> > > >
> > > > > This is fine. But having direct dependencies, e.g., leafrefs
> > > > > from config true leafs to config false leafs, is not.
> > > > >
> > > > > /js
> > > > >
> > > >
> > > > Okay, then we're on the same page -- I think some may have missed
> > > > the possibility of handling references to dynamic topology
> > > > information in config using a 'pre-provisioning' approach.
> > > >
> > > > I'm not certain how it would function for the recursive nature and
> > > > it does presume the separate /config and /oper-state trees in the

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 2 Feb 2017 13:00:59 -0500

<chair hat on>

Martin is right.   It should take off IESG and just be I2RS.  The document has been sent back to WG by Alia. 

Sue 
<chair hat off> 

Can add TEAS if Lou or Xufeng desires... 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Thursday, February 2, 2017 11:18 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

Hi,

> which are five objects without including other consequent mandatory 

You don't have to configure a "dummy" object if you are not using leafrefs to config.  And the number of nodes that you need for unique identification should be totally independent.

See above.

BTW, maybe further discussion about a new solution should be on the i2rs ML only?

/martin

> > > discovered and represent “state”, and that in fact your underlay may be either.
> > >

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 2 Feb 2017 13:06:28 -0500

Lou: 

In concept Martin's answer makes sense, but I would just like to see an example.  I could not find an example of the YANG to go with the NETCONF.  If you could either point me to a section in RFC7223 or provide an example - it would be helpful.  What I think I understand from Martin's message is that the YANG configuration does not have any "must" or "when" statements in the leaf clause.   Is this true?

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, February 2, 2017 11:54 AM
To: Susan Hares; 'Alia Atlas'; [email-masked]; [email-masked]
Subject: [i2rs] What is RFC 7223 style pre-provisioning (was Re: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT))

Hi Sue,

    I think Juergen's comment covers what I was referring to. Does this answer your question / make sense?

Cheers,

Lou

On 2/2/2017 10:14 AM, Juergen Schoenwaelder wrote:
>> this would

---

From: Lou Berger <[email-masked]>
Date: Thu, 2 Feb 2017 13:09:59 -0500

Sue,

I think the discussion can take place on one list for now, i.e, I2Rs,
and then the results can be brought back to TEAS.  I of course defer to
my co-chair if he disagrees...

Lou
As TEAS co-chair.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 3 Feb 2017 01:38:33 +0000

[reducing distribution]

Hi Xufeng,

> Assume the following model:
>
> +--rw nodes
>   +--rw node [id]
>      +--rw id   string

True, but maybe it could be:

   type leafref {
      path "../node/attribute-a"
      require-instance false;
      description
        "In the case when the referenced instance is not a configured
         object, the system may resolve it by looking for it under the
         /nodes-state node.  As the referenced operational state data
         may have a lifecycle independent of configuration, this results
         in an effect much like pre-provisioning interfaces in RFC 7223.";
   }

This would be cleaner in a revised-datastores oriented model, as then
it would be obvious that the list's key space spanned across both
datastores.

Kent

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 3 Feb 2017 14:28:28 +0000

Hi Kent,

> From: Kent Watsen [mailto:[email-masked]]
> Sent: Thursday, February 2, 2017 8:39 PM
> Cc: [email-masked]; [email-masked]
[Xufeng] I think that "require-instance false" does not help here. The validation for path "../node/attribute-a" still fails because "attribute-a" does not exist under /nodes/node/. 

> 
> This would be cleaner in a revised-datastores oriented model, as then it would
> be obvious that the list's key space spanned across both datastores.
> 
> 
> Kent
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 03 Feb 2017 16:32:16 +0100 (CET)

Hi,

Xufeng Liu <[email-masked]> wrote:
> [Xufeng] I think that "require-instance false" does not help here. The
> validation for path "../node/attribute-a" still fails because
> "attribute-a" does not exist under /nodes/node/.

No, "require-instance false" essentially turns off validation.  Section
9.9.3 in RFC 7950 says:

   If "require-instance" is "false", it means that the instance being
   referred to MAY exist in valid data.

/martin

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 3 Feb 2017 15:50:57 +0000

Hi,

> Sent: Friday, February 3, 2017 10:32 AM
> Cc: [email-masked]; [email-masked];
> [email-masked]
[Xufeng] My understanding is that this section talks about instance "data" validation, but I was talking about schema validation. The path statement is pointing to a non-existing schema node. At least, pyang, yangdump, and yangvalidator all fail on this currently.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 03 Feb 2017 17:08:00 +0100 (CET)

Xufeng Liu <[email-masked]> wrote:
> [Xufeng] My understanding is that this section talks about instance
> "data" validation, but I was talking about schema validation. The path
> statement is pointing to a non-existing schema node.

Aha, ok.  Yes, the path needs to refer to a valid schema node.  So the
path would be /nodes-state/node/attribute-a.

> At least, pyang,
> yangdump, and yangvalidator all fail on this currently.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Feb 2017 17:11:00 +0100

> [Xufeng] My understanding is that this section talks about instance "data" validation, but I was talking about schema validation. The path statement is pointing to a non-existing schema node. At le…

Yes, the example is confusing. If the idea was that the path would be

../node/under-lay-attribute-a

then I find the description questionable since the leafref is
restricted to ../node/under-lay-attribute-a but the description says
go look elsewhere. Perhaps I need an even simpler example. ;-)

/js

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 3 Feb 2017 16:16:43 +0000

> Sent: Friday, February 3, 2017 11:08 AM
> > > > [Xufeng] I think that "require-instance false" does not help here.
> > > > The validation for path "../node/attribute-a" still fails because
> Aha, ok.  Yes, the path needs to refer to a valid schema node.  So the path would
> be /nodes-state/node/attribute-a.
> 
[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.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 03 Feb 2017 18:43:42 +0100 (CET)

Xufeng Liu <[email-masked]> wrote:
> [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.

You don't need any additional capability for this; if you tag the
leafref with "require-instance false", it can reference config false
(from config true).

/martin

---

From: Kent Watsen <[email-masked]>
Date: Fri, 3 Feb 2017 18:11:30 +0000

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

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Feb 2017 13:14:49 -0500

Kent,

>From the 5000 foot view, this looks to me like the description changing the
behavior
of what a system should do.

What am I missing?

Thanks,
Alia

On Fri, Feb 3, 2017 at 1:11 PM, Kent Watsen <[email-masked]> wrote:

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 3 Feb 2017 20:38:04 +0000

> From the 5000 foot view, this looks to me like the description changing
> the behavior of what a system should do.

Correct.

> What am I missing?

I think you are asking, how is this different than the current draft's approach, right?   The primary
distinction is that this approach doesn't break legacy clients.   All existing operations (backup/restore)
continue to work.

The issue was never that new semantics were being added; we do that all the time (e.g., opstate).  The
issue was that the new semantics were being added without a strong mechanism to prevent legacy
clients from doing something bad (i.e. a description statement alone isn't sufficient).

By example, note that YANG extensions, which includes metadata per RFC 7952, also are used to
introduce new semantics, but they cannot do so is a non backwards compatible manner.  RFC 7950
Section 6.3.1 says:

   The processing of extensions depends on whether support for those
   extensions is claimed for a given YANG parser or the tool set in
   which it is embedded.  An unsupported extension appearing in a YANG
   module as an unknown-statement (see Section 14) MAY be ignored in its
   entirety.

and also:

   Care must be taken when defining extensions so that modules that use
   the extensions are meaningful also for applications that do not
   support the extensions.

So, for instance, if we wanted to have a "server-provided" metadata annotation, we'd have to
introduce it along with an explicit client request, somewhat like the <with-defaults> parameter
added by RFC 6243.   We could go that route here if needed, but I first want to see if the idea
posted early is sufficient...

Kent

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 10 Feb 2017 21:05:02 +0000

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:[email-masked]] On Behalf Of Kent Watsen
Sent: Friday, February 03, 2017 10:12 AM
To: Xufeng Liu <[email-masked]>; Martin Bjorklund <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

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

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

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