Subject: [netmod] Mandatory and optional ranges

From: "William Lupton (wilupton)" <[email-masked]>
Date: Thu, 2 Oct 2014 10:05:59 +0000

All,

Someone asked me whether a YANG definition can distinguish the parts of a
range that are mandatory and the parts that are optional, e.g an int leaf
XXX might be required to support 1..10 but 11..20 might be optional.  It
seems that being able to associate 11..20 with a feature would be a nice
solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on
enums)?  But I don't think that range "1..10|11..20" can be split into
multiple range statements, so this would not be trivial?

A use case from the DSL world (I can't be too specific) is where the valid
values for two leaf nodes are coupled.  If leaf WWW = 1 then XXX = 1..10
but if leaf WWW = 2 then XXX = 11..20.  A future module version might add
WWW = 3 and tie it to XXX = 21..30.

I suppose that a "must" statement could be used (?) but I quite like the
feature approach, especially given the analogy with YANG 1.1 Y11.

Comments?

Thanks,
William Lupton

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Oct 2014 16:11:53 +0200

Hello William,

> feature approach, especially given the analogy with YANG 1.1 Y11.

This could be solved by defining a choice with one case for each
variant. A must or when statement can then indeed be used for making
sure that each case only applies when WWW has the corresponding value.

Something like

choice XXX {
  leaf XXX1 {
    must "../WWW = 1";
    type uint8 {
        range "1..10";
    }
  }
  leaf XXX2 {
    must "../WWW = 2";
    type uint8 {
        range "11..20";
    }
  }
}

Also, you can make a case conditional by using if-feature.

Hope this helps,

Lada

>
> Comments?
>
> Thanks,
> William Lupton
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "William Lupton (wilupton)" <[email-masked]>
Date: Fri, 17 Oct 2014 08:02:48 +0000

Thanks.  Would there be any appetite for permitting the feature approach
(it would need to be understood that multiple "range" statements are ORd)?

leaf WWW {
  type uint8 {
    range "1..1" {
      if-feature A;
    }
    range "2..2" {
      if-feature B;
    }
  }
}

leaf XXX {
  type uint8 {
    range "1..10" {
      if-feature A;
    }
    range "11..20" {
      if-feature B;
    }
  }
}

Compare the above with
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, which
also mentions "choice" as an option, and includes this example:

type enumeration {
  enum tcp;
  enum ssh {
    if-feature ssh;
  }
  enum tls {
    if-feature tls;
  }
}

Cheers,
William

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Oct 2014 08:21:23 -0400

Yes, but perhaps taking this a little further would help too but I am not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were just discussing a similar requirement for a provisioning use case over in ODL. What you propose would definitely help, but would not necessarily be the comoplete solution. The use case is simple: an operational domain that wishes to constrain an operational store to values that make sense in that operational domain. So using your example, the second range statement would actually be useful in that domain. Its not exactly an "if-feature" though; its an "if-in-this-domain" or something.   Also, these values need to be a combination of run-time variables much like ultimately would be considered a "policy statement". So today, in our object classes for we have two stages of commit checks on an object: the first enforces what is found in the Yang module's type/range statements, but the second is essentially a manual augmentation to that which can further narrow the statement, or as I said above, validate it against other operation state. For example, if we had a definition for a VpnRoute leaf (forget about the details for a moment), but you wanted to say, "in addition to the syntactic constraints, only allow CurrentVpnRouteCount <= MaxVpnRoutesAllowedOnThisRouter to be created."

	So using what you suggest below, but being able to augment that at run-time would be ideal and making the statement more robust somehow.

	--Tom

---

From: "William Lupton (wilupton)" <[email-masked]>
Date: Fri, 17 Oct 2014 15:49:17 +0000

Thanks.  When you say "run-time", does that refer to a "must" statement,
or to something different and yet to be defined?  Presumably such run-time
checks would be relevant in general and not just in this case?  So for
example they would also be relevant to the YANG 1.1 issue #11 bits / enum
/ identity case?  W.

On 17/10/2014 13:21, "Thomas D. Nadeau" <[email-masked]> wrote:

>	Yes, but perhaps taking this a little further would help too but I am
>not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were just
>discussing a similar requirement for a provisioning use case over in ODL.
>What you propose would definitely help, but would not necessarily be the
>comoplete solution. The use case is simple: an operational domain that
>wishes to constrain an operational store to values that make sense in
>that operational domain. So using your example, the second range
>statement would actually be useful in that domain. Its not exactly an
>"if-feature" though; its an "if-in-this-domain" or something.   Also,
>these values need to be a combination of run-time variables much like
>ultimately would be considered a "policy statement". So today, in our
>object classes for we have two stages of commit checks on an object: the
>first enforces what is found in the Yang module's type/range statements,
>but the second is essentially a manual augmentation to that which can
>further narrow the statement, or as I said above, validate it against
>other operation state. For example, if we had a definition for a VpnRoute
>leaf (forget about the details for a moment), but you wanted to say, "in
>addition to the syntactic constraints, only allow CurrentVpnRouteCount <=
>MaxVpnRoutesAllowedOnThisRouter to be created."
>
>	So using what you suggest below, but being able to augment that at
>run-time would be ideal and making the statement more robust somehow.
>
>	--Tom
>
>>>> Someone asked me whether a YANG definition can distinguish the parts
>>>>of
>>>> a

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Oct 2014 09:15:20 -0700

Hi,

I am concerned about overloading the YANG feature-stmt.
Not only are the conformance mechanisms weak, but they are
passed in the module advertisement.  Not every type of classification
should be a global YANG feature or advertised in the <hello> message.

IMO static YANG schema definitions cannot express all run-time decisions
that determine what values are valid for a given leaf at the moment.
YANG 1.1 will allow complex if-feature statements, and allow if-feature
in more places.  This may help automation if used correctly.  It might
be easy to make mistakes with complex existence conditions on values.

Another solution approach is described in the new YANG Conformance draft.
Just ask the server what it supports for certain leafs.

http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt

The <get-allowed-identities> and <get-allowed-leafrefs> operations return
the
supported values for a given leaf instance. Consider a large open-ended
identityref
like interface-type.  If would be quite difficult to markup all the
identities with
YANG if-feature-stmts (or if-whatever-stmts) so a client knows what a
server will
accept for a given "create" edit operation.

Andy

On Fri, Oct 17, 2014 at 5:21 AM, Thomas D. Nadeau <[email-masked]>
wrote:

>
>         Yes, but perhaps taking this a little further would help too but I
> am not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were
> just discussing a similar requirement for a provisioning use case over in
> ODL. What you propose would definitely help, but would not necessarily be
> the comoplete solution. The use case is simple: an operational domain that
> wishes to constrain an operational store to values that make sense in that
> operational domain. So using your example, the second range statement would
> actually be useful in that domain. Its not exactly an "if-feature" though;
> its an "if-in-this-domain" or something.   Also, these values need to be a
> combination of run-time variables much like ultimately would be considered
> a "policy statement". So today, in our object classes for we have two
> stages of commit checks on an object: the first enforces what is found in
> the Yang module's type/range statements, but the second is essentially a
> manual augmentation to that which can further narrow the statement, or as I
> said above, validate it against other operation state. For example, if we
> had a definition for a VpnRoute leaf (forget about the details for a
> moment), but you wanted to say, "in addition to the syntactic constraints,
> only allow CurrentVpnRouteCount <= MaxVpnRoutesAllowedOnThisRouter to be
> created."
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Oct 2014 18:57:57 +0200

Hi,

I am confused since you talk about 'operation state' and 'operational
store'. If we are talking about operational state, then what does
validate mean? The operational state should document the real state of
the device and there is no concept of rejecting or validating it - if
the state is there, it is real operational state. You can reject a
config change if the change leads to invalid config. I am not sure how
to reject an operational state. Perhaps you are thinking about
identifying undesirable operational states. But for me, this would not
be the same thing as validation of config. And what is desirable or
undesirable likely depends on deployment specifics and thus it is
application and deployment domain specific and not generic.

If the idea is, however, to express that the number of configured
vpnRoutes (e.g. list entries) is smaller than some leaf value (say
maxVpnRoutes) for a config to be valid, I think this is expressable
using must constraints.

/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: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Oct 2014 13:31:22 -0400

On Oct 17, 2014:11:49 AM, at 11:49 AM, William Lupton (wilupton) <[email-masked]> wrote:

> or to something different and yet to be defined?  

	It refers to the running state, and is defined per-domain, so its not something you can just define in a standard model because its different per domain. The example I gave is illustrative of that. For instance, one operator might care about MaxVRFs when configuring service X, but then another might care about MaxVRFs + <insert something else>.

> Presumably such run-time
> checks would be relevant in general and not just in this case?  

	Right! That was my point. *)  This is perhaps a general thing for Yang 2.0 whereby a model's constraints are augmented at run-time.  Its unclear if this is an "implementation detail", a Yang 2.0 thing, or some combination of both. 

> So for example they would also be relevant to the YANG 1.1 issue #11 bits / enum
> / identity case?  W.

	Yes. So my point was that *some* of what I am describing above can be handled in Yang 1.1 issues, but perhaps others elsewhere.

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Oct 2014 13:34:52 -0400

> be easy to make mistakes with complex existence conditions on values.

	That is fair. My questions is whether or not we need to augment Yang... for this?

> The <get-allowed-identities> and <get-allowed-leafrefs> operations return the
> supported values for a given leaf instance. Consider a large open-ended identityref
> like interface-type.  If would be quite difficult to markup all the identities with
> YANG if-feature-stmts (or if-whatever-stmts) so a client knows what a server will

	Ah I'd forgotten about that.  Yes, this is perhaps a place to tackle this. I agree too that we don't want to augment models with if-feature... in a particular Yang module; but instead, have a method by which an agent can be programmed dynamically with perhaps a supplemental yang module.  What I am talking about is perhaps writing the conformance at run time and plugging it in.

	--Tom

> 
> Andy
> 
> 
> 
> 
> On Fri, Oct 17, 2014 at 5:21 AM, Thomas D. Nadeau <[email-masked]> wrote:
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Oct 2014 13:39:16 -0400

On Oct 17, 2014:12:57 PM, at 12:57 PM, Juergen Schoenwaelder <[email-masked]> wrote:

> validate mean?

	It means checking the running state of the system in addition to static syntactic constraints.

> The operational state should document the real state of
> the state is there, it is real operational state.

	Right - and that is my point. Operationally there is a need to do this from some of my customers.

> You can reject a
> config change if the change leads to invalid config.

	That is what I am asking for - to augment what "valid" means.  Right now its only based on some relatively static constraints.

> I am not sure how

	I think it is the same as validating a config request; its just making the constraints more complex.  This is actually done today within implementations, but its hidden from the Netconf server. For example, if the Max configured VRFs on a system is 20, and you try to configure a (syntactically correct VRF), but the config fails.  That is a very simplistic example. You can imagine an entire operationally policy attached to the constraints validation phase.

> maxVpnRoutes) for a config to be valid, I think this is expressable

	I think it is fair to limit the constraints to things that can be expressed in a Yang module.

	--Tom

---

From: "William Lupton (wilupton)" <[email-masked]>
Date: Fri, 17 Oct 2014 17:45:39 +0000

So, setting aside the more recent discussion, is there some agreement that
my original suggestion, which can be seen as extending YANG 1.1 issue #11
to apply not only to {bits, enum, identity} but also to range, has some
merit?  W.

On 17/10/2014 18:39, "Thomas D. Nadeau" <[email-masked]> wrote:

>
>On Oct 17, 2014:12:57 PM, at 12:57 PM, Juergen Schoenwaelder
><[email-masked]> wrote:
>
>> Hi,
>> 
>	That is what I am asking for - to augment what "valid" means.  Right now
>its only based on some relatively static constraints.
>
>> I am not sure how
>	I think it is the same as validating a config request; its just making
>the constraints more complex.  This is actually done today within
>implementations, but its hidden from the Netconf server. For example, if
>the Max configured VRFs on a system is 20, and you try to configure a
>(syntactically correct VRF), but the config fails.  That is a very
>simplistic example. You can imagine an entire operationally policy
>attached to the constraints validation phase.
>
>>>not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were
>>>just discussing a similar requirement for a provisioning use case over
>>>in ODL. What you propose would definitely help, but would not
>>>necessarily be the comoplete solution. The use case is simple: an
>>>operational domain that wishes to constrain an operational store to
>>>values that make sense in that operational domain. So using your
>>>example, the second range statement would actually be useful in that
>>>domain. Its not exactly an "if-feature" though; its an
>>>"if-in-this-domain" or something.   Also, these values need to be a
>>>combination of run-time variables much like ultimately would be
>>>considered a "policy statement". So today, in our object classes for we
>>>have two stages of commit checks on an object: the first enforces what
>>>is found in the Yang module's type/range statements, but the second is
>>>essentially a manual augmentation to that which can further narrow the
>>>statement, or as I said above, validate it against other operation
>>>state. For example, if we had a definition for a VpnRoute leaf (forget
>>>about the details for a moment), but you wanted to say, "in addition to
>>>the syntactic constraints, only allow CurrentVpnRouteCount <=
>>>>>> Someone asked me whether a YANG definition can distinguish the
>>>>>>parts of
>>>>>> a
>>>>>> but if leaf WWW = 2 then XXX = 11..20.  A future module version
>>>>>>might
>>>>>> add

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 17 Oct 2014 19:45:51 +0200 (CEST)

Hi,

"Thomas D. Nadeau" <[email-masked]> wrote:
> 	It refers to the running state, and is defined per-domain, so its not
> 	something you can just define in a standard model because its different
> 	per domain. The example I gave is illustrative of that. For instance,
> 	one operator might care about MaxVRFs when configuring service X, but
> 	then another might care about MaxVRFs + <insert something else>.

We have something we call configuration policies for this.  Here's the
description from the module:

  description
    "This module defines configuration policies.  A configuration policy
     enforces custom validation rules on the configuration data.
     These rules assert that the user-defined conditions are always
     true in committed data.  If a configuration change is done such
     that a policy rule would evaluate to false, the configuration
     change is rejected by the system.";

This works somewhat like "must" statements, but are defined by the
operator.  Is this what you had in mind?

Note that this is a normal YANG module with no additional YANG
extensions; works fine w/ YANG 1.0.

/martin

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Oct 2014 13:49:22 -0400

I personally think so.

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Oct 2014 13:51:14 -0400

> operator.  Is this what you had in mind?

	The issue is that these need to be augmented, perhaps at run-time (versus inside of say a standard yang module).  We need to combine/override/refine existing constraints. Its my understanding that you cannot do this with the must statement.

	--Tom

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Oct 2014 20:05:13 +0200

> 	I think it is the same as validating a config request; its just making the constraints more complex.  This is actually done today within implementations, but its hidden from the Netconf server. Fo…

But operational state changes dynamically. So your config becomes
invalid because say some I2RS client or a routing protocol injects
some additional state?  What does it mean to now have invalid config?
There is no config change transaction to reject in this case. So what
should the box do? Reboot or shutdown? Or is the idea that all config
changes from now on fail until they bring the box back again into a
valid config state?

/js

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Oct 2014 14:09:14 -0400

On Oct 17, 2014:2:05 PM, at 2:05 PM, Juergen Schoenwaelder <[email-masked]> wrote:

> some additional state?

	Yep. That is my point. The static definition doesn't necessarily work.
Its also problematic because one static def doesn't apply across different 
operational domains.

>  What does it mean to now have invalid config?

	If the box is out of (configured) space for say VRFs, then it simply rejects the config request.  This is the same as any Policy operation.

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Oct 2014 11:12:24 -0700

On Fri, Oct 17, 2014 at 11:05 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> >       I think it is the same as validating a config request; its just
> making the constraints more complex.  This is actually done today within
> simplistic example. You can imagine an entire operationally policy attached
> to the constraints validation phase.
> >
>

Validating a config request is not the same as expressing constraints on
non-config data.
The server is checking an internal resource constraint.  That is not
operational state.

YANG is quite clear about this detail. Datastore validation is only based
on config=true data nodes.
Any YANG constraints on config=false data nodes refer to what can possibly
returned
as a valid <rpc-reply> for a <get> request.

Andy

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Oct 2014 14:16:03 -0400

On Oct 17, 2014:2:12 PM, at 2:12 PM, Andy Bierman <[email-masked]> wrote:

> 
> 
> On Fri, Oct 17, 2014 at 11:05 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> Validating a config request is not the same as expressing constraints on non-config data.

	Right. But its cool if you can express the same constraints using Yang.

> The server is checking an internal resource constraint.  That is not operational state.

	The value of a counter containing the number of configured Xs surely is operational state, for example.
That is not something I pre-configure in a Yang model, necessarily.

> YANG is quite clear about this detail. Datastore validation is only based on config=true data nodes.
> Any YANG constraints on config=false data nodes refer to what can possibly returned

	The existing Yang does. That is my point in there being parts of this that might belong in Yang 2.0.

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Oct 2014 14:19:48 -0700

> Right. But its cool if you can express the same constraints using Yang.

There is a fundamental design assumption in NETCONF, based on RFC 3535
requirements.
A <get-config> (issued by a client with full read access) will return a
complete representation
of the configuration, such that the YANG validation rules could be applied
to this data.
This data could also be used to completely restore a configuration via
<copy-config>.

> That is not something I pre-configure in a Yang model, necessarily.

The value of an counter is a representation of internal state data.
The config validation can check this internal state as part of deciding
between <ok> and "resource-denied".

--Tom

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Oct 2014 13:18:12 +0200

> (it would need to be understood that multiple "range" statements are ORd)?

This is different from the enum case below. Features A and B needn't be
mutually exclusive, and if both are active the data model would be
ambiguous. For enums it is not the case because they are additive. The
same is true for bits and identities.

So I don't think your proposal is a simple extension of issue #11. Do
you think a choice won't work for your use case?

Lada

---

From: "William Lupton (wilupton)" <[email-masked]>
Date: Mon, 20 Oct 2014 11:25:39 +0000

I didn't assume that features A and B were mutually exclusive.  I also
don't see that there would be a problem even if the ranges overlapped.
The actual supported range would simply be the union of the per-feature
ranges.  What is the ambiguity?  Thanks, W.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Oct 2014 13:47:29 +0200

> ranges.  What is the ambiguity?  Thanks, W.

Currently the “range” statement can appear only once, and sec. 9.2.4 in RFC 6020 contains several restrictions - the ranges separated by | must be disjoint and appear in ascending order.

Maybe these restrictions are in the spec only to make parsing easier but accepting your proposal would essentially mean to get rid of these restrictions in the first place.

Lada