Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Mar 2013 06:15:36 -0800

Hi,

The example does not make it clear that it is a client who is sending
<foo enabled="custom-expression" /> and that the set of variables (e.g.
'enabled')
and their semantics are completely unspecified and  undiscoverable by the
clients.

Ditto for the variables used in the RHS of the expression.  It is also
unclear how multiple
independent client applications manage the same server.  It seems they have
to
retrieve and parse these expressions and make sure no other client has
changed
the expression, added or deleted expressions, etc.

I think all protocol content needs a schema definition in order to be
workable as a standard. Conditional activation outside the schema,
plus conditional instances defined inside the schema seems broken to me.

Andy

On Tue, Feb 26, 2013 at 4:38 PM, Kent Watsen <[email-masked]> wrote:

>
>  Hi Andy,
>
>  Thanks for your comments and biting first  ;)
>
>  I think the with YANG's when-statement is that it applies to the schema
> as a whole, whereas this solution works on distinct data elements.  For
> instance, envision a list of interfaces, we may want some (but not all)
>  interfaces to enabled conditionally, and then, perhaps with different
> policies.
>
>  Thanks,
> Kent
>
>
>   From: Andy Bierman <[email-masked]>
> Date: Tuesday, February 26, 2013 5:43 PM
> To: Kent Watsen <[email-masked]>
> Cc: NetConf <[email-masked]>
> Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00
>
>  Hi Kent,
>
>  I'll bite first ;-)
>
>  YANG can already do this with when-stmt and XPath.
> I know when-stmt for config=true can only point to other config=true,
> but I look at the "platform config" an an access control issue, and
> it is just more config that is only set by a privileged system user.
>
>       groups {
>            my-group-g1 {
>                system {
>                    hostname xyz;
>                }
>            when {
>                model tx1000;
>                routing-engine re0;
>                time 2am to 4am;
>            }
>          }
>        }
>
>
>
> If the 'model', routine-engine', and range begin/end variables were YANG leafs
> then when-stmt can be used to describe the condition.
>
> IMO, inventing a new expression syntax when we already have 1 is not needed.
>
>
> Andy
>
>
> On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen <[email-masked]> wrote:
>
>>  NETCONF WG,
>>
>>  The following draft has been submitted for your consideration:
>>
>>      http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00
>>
>>  Thanks,
>> Kent
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 Mar 2013 06:51:43 -0800

Hi

After reading the motivation section again I have another comment...

3.1 <http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00#section-3.1>.
 Explicit Nodes Defined in NETMOD Drafts

   Two separate drafts presented during the NETMOD meeting and IETF 85
   had data-models with explicit "enabled" leaves (see examples below).
   One of the questions asked during the sessions was if cross-cutting
   concerns, such as if a node were enabled, wouldn't be better
   supported via meta-data, to which there was general agreement.

   Example of an "enabled" leaf from
   draft-ietf-netmod-routing-cfg-06.txt
<http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06.txt>:

       leaf enabled {
           type boolean;
           default "true";
           description
               "Enable/disable the router instance.

               If this parameter is false, the parent router instance is
               disabled, despite any other configuration that might be
               present.";
       }

The problem is not that this is done with a YANG leaf, but rather that
this is ad-hoc and no 2 'enabled' leafs will be the same.  Moving the
mechanism to meta-data does not fix the problem if it is even more ad-hoc
than YANG leafs.

We have a simple solution in YANG called groupings -- just create 1 standard
"enabled" leaf in a grouping (new module) and put uses-stmts in the 2
modules that are defining their own leafs.  A simple boolean is good enough.
These enabled flags need to be available to must/when statements and
XPath select in get operations.

Andy

On Fri, Mar 1, 2013 at 6:15 AM, Andy Bierman <[email-masked]> wrote:

> independent client applications manage the same server.  It seems they
> have to

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 Mar 2013 11:32:04 +0100

> IMO, inventing a new expression syntax when we already have 1 is not needed.

Indeed, XPath should be suitable for this purpose - unlike YANG's when statement, in fact. 
This could also include the time-based enablement via current-time in ietf-system, but this would require at least an XPath expression function for comparing time values.

Also, the draft uses features in a way that is not directly supported by RFC 6020. We had this discussion before in another context and I don't rememeber whether there was any conclusion.

Lada

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

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 Mar 2013 20:16:03 +0000

[responding to all comments in this email]

0) Yes, this draft is about config (not schema).  For instance, the I2RS
folks talk about "temporal config" (their term) so instead of this:

   Every M-F @ 9am:

       Controller                             Router
           |          <edit-config>             |
           |----------------------------------->|
           |       (turns on "foobar")          |

   Every M-F @ 5pm:

       Controller                             Router
           |          <edit-config>             |
           |----------------------------------->|
           |       (turns off "foobar")         |

   Where the <edit-config> could be:
      <foobar/>                       // a "presence" node
   Or:
      <foobar enabled="true/false"/>  // if we agreed on the "simple"
expression

They can have:

   When the policy is decided:

       Controller                             Router
           |          <edit-config>             |
           |----------------------------------->|
           |   (set "foobar" with schedule)     |

   Where the <edit-config> contains something like:

      <foobar enabled="(dayofweek >= "Monday" && dayofweek <= "Friday") \
                        && (hour >= 9:00 && hour <= 17:00)"/>

1) I didn't define a YANG module because YANG is unable to model
attributes.  I view this as a shortcoming in YANG.  Ideally we first
address this issue in YANG and then update this draft with a YANG module.
Any thoughts about this?

2) I'm not concerned about expression syntax, but I worry a lot about
implementation complexity.   The primary reason why the draft didn't
specify XPath is because I thought it would be helpful if implementations
could incrementally support parts they care about.  For instance, if only
wanting to support "simple" expressions, having to implement full-XPath
could be more than a team wants to take on.  YANG doesn't require XPath to
be fully-implemented, since the vendor controls both the expression and
its evaluation.  In this case, clients could pass any expression, which
then requires a full-xpath implementation on the device.  Additionally,
NMS's would need a XPath-parser so as to present pretty UI, which sounds
complex...

3) Regarding an XPath expression function for comparing time values, this
StackOverflow posting shows how it could be done in both XPath 1.0 and
XPath 2.0:  
http://stackoverflow.com/questions/475923/xpath-query-and-time.   Just
looking at the solutions, I'm struck by how unintuitive they are.   In the
same way that we choose YANG over XSD because we felt a domain-specific
syntax could be better and simpler, maybe the same is true here?   [ps:
searching the path 2.0 spec, I didn't see a way to extract day-of-weekŠ]

Lastly, something that isn't a based on a comment from Andy or Lada, but
you should know, I had planned to also submit a companion draft entitled
"Conditional Assignment for Configuration Nodes".  The idea is the similar
except instead of an expression evaluating to a boolean, it instead
evaluates to a value.  That is, instead of:

   Every M-F @ 9am:

       Controller                             Router
           |          <edit-config>             |
           |----------------------------------->|
           |     (sets "foobar" to 1024)        |

   Every M-F @ 5pm:

       Controller                             Router
           |          <edit-config>             |
           |----------------------------------->|
           |     (sets "foobar" to 2048)        |

   Where the <edit-config> contains something like:
      <foobar>1024</foobar>
   Or
      <foobar>2048</foobar>

It could be:

   When the policy is decided:

       Controller                             Router
           |          <edit-config>             |
           |----------------------------------->|
           |   (set "foobar" with schedule)     |

   Where the <edit-config> might look something like:

      <foobar value="M-F 9am-5pm ? 1024 : 2048">-1</foobar>

   But this is where it gets tricky because:

      1) there may be a need to handle multiple "if" cases
      2) the "value" may be a subtree (not just a scalar)

I stopped working on this solution because I ran out of time, but it
should be considered along with "conditional-enablement" ...

Thanks,
Kent

On 3/4/13 5:32 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>This could also include the time-based enablement via current-time in
>ietf-system, but this would require at least an XPath expression function
>for comparing time values.
>
>Also, the draft uses features in a way that is not directly supported by
>RFC 6020. We had this discussion before in another context and I don't
>rememeber whether there was any conclusion.
>
>Lada
>
>--

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Mar 2013 12:31:01 -0800

Hi,

This helps me understand what you are trying to do.  Thanks.
Maybe I'm biased (as co-author of NACM and original proponent
of a standard ACM for NETCONF), but I would much rather see policy configured
with a YANG module that extends NACM, or at least coexists with NACM.

IMO it is much easier and more efficient to use ordered rules like in
NACM to describe the policy,
rather than send <edit-config>s with the policy embedded in XML
attributes in every
data node that needs to have a policy applied to it.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Mar 2013 02:09:11 +0000

I like rulebase processing - I've used it effectively on other modeling
projects.

The one thing I don't like about the approach here (or any other I've
thought of in the last couple weeks), is that they change to structure of
the config such that it is no longer just an annotation of its original
self.  At least somehow, in my mind, putting XML attributes on existing
config nodes is less intrusiveŠ

Consider the data model:

    container foo {
        leaf bar {
            type integer;
        }
    }

Which has config:

    <foo>
        <bar>1024</bar>
    </foo>

Using XML attributes, conditional-enablement might looks like:

    <foo>
        <bar enabled="false">1024</bar>
    </foo>

Or:

    <foo>
        <bar enabled="M-F 9am-5pm">1024</bar>
    </foo>

Whereas a rulebase approach might be:

    <foo>
        <rule-list>
            <rule>
                <type>time</type>
                <expression>M-F 9am-5pm</expression>
                <action>
                    <bar>1024</bar>
                </action>
            </rule>
            <rule>
                <!-- this is a catch-all rule -->
                <action>
                </action>
            </rule>
        </rule-list>
    </foo>

Don't focus on the syntax, we can massage that into something better
later, but what about the fact that the "config" hardly resembles the
original YANG definition?   Does it matter?   I'm sure it would look
better with namespaces clearly indicating which parts came from the
"conditional-enablement" module, but still, it seems heavy - what do you
think?

Back to conditional *assignments*, there may be no other option - bottom
line is that if/else expressions (or case statements) containing multiple
conditions, there is no easy way to express them without taking up a lot
of space.  For instance:

    <foo>
        <rule-list>
            <rule>
                <!-- 1024 inside business hours -->
                <type>time</type>
                <expression>M-F 9am-5pm</expression>
                <action>
                    <bar>1024</bar>
                </action>
            </rule>
            <rule>
                <!-- 2048 outside business hours -->
                <action>
                    <bar>2048</bar>
                </action>
            </rule>
        </rule-list>
    </foo>

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Mar 2013 18:39:12 -0800

> "conditional-enablement" module, but still, it seems heavy - what do you

I think a rule-based approach scales much better and also works better
if there are multiple manager apps setting config, but maybe not all apps
have access to the policy config or know how to set the right policy.

I would much rather be able to update the policy for 100,000 interfaces
all at once, without requiring a massive <edit-config> to do that.
Also there will be a lot of redundant verbose monitoring info with
these attributes.

>                 <!-- 2048 outside business hours -->

I think this is better than sending 100,000 'enabled' attributes to the server,
especially since changing policy rules happens much less often than
changing config.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 05 Mar 2013 14:05:36 +0100

Kent Watsen <[email-masked]> writes:

...
> address this issue in YANG and then update this draft with a YANG module.

I think it is actually a feature of YANG that it doesn't model XML attributes. A few global attributes, such as "enabled" can be easily defined using XSD or RELAX NG.
 
> could be more than a team wants to take on.  YANG doesn't require XPath to

There can still be two different capabilities: simple (true/false) and complex (XPath).

> NMS's would need a XPath-parser so as to present pretty UI, which sounds

The NMS can present a simple UI, e.g. a calendar widget, and just construct corresponding XPath expressions.

> searching the path 2.0 spec, I didn't see a way to extract day-of-week]

Nobody wants to repeatedly write such awkward expressions. What I had in mind was a function that extends XPath, something like

    "yang:time-before(/sys:system/sys:clock/sys:current-datetime,
                      '2013-03-05T14:02:45+01:00')"

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 05 Mar 2013 14:26:29 +0100

...

>                 <!-- 2048 outside business hours -->

IMO, one option would be to have the candidate config represented not as a clone of running with modifications but rather as a sequence of patches. Then various rules/conditions could be specified as attributes of each patch - when it should be applied etc. At commit, all unconditional patches would be immediately applied and the conditional/termporal ones put on hold.

BTW, this would also solve the problem of access rights - it can be easily checked whether the user submitting each patch is entitled to perform the changes.

Lada

---

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Mar 2013 21:26:39 +0000

HI Andy,

I don't fully understand some of your comments...

>I think a rule-based approach scales much better

Scale better on which axis?   All the solutions I can think of seem nearly
equal from a scaling perspective...

> and also works better

I don't understand - whatever syntax we choose would have to be understood
by all clients, if the device-advertizes support for this ability.  How
would using rulebases make this any easier?

>Also there will be a lot of redundant verbose monitoring info with

Do you mean that you rather a client set a temporal-policy on each of a
100,000 interfaces once, than having the client set/unset the settings
remotely?   In other words, you like the idea of temporal config?

><SNIP>my rulebase example</SNIP>

Agreed, sending temporal-config is less chatty (and more reflective of
what the client really wants) than having the client flipping settings
themselves.   

I think that your 'enabled' comment above regards only using what the
draft referred to as "simple" expressions (i.e. enabled="true" or
enabled="false").  The draft also described temporal-expressions, in which
case they'd be comparable to the rulebase example I gave.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Mar 2013 21:58:26 +0000

>I think it is actually a feature of YANG that it doesn't model XML
>attributes. A few global attributes, such as "enabled" can be easily
>defined using XSD or RELAX NG.
> 

Fair enough.

>There can still be two different capabilities: simple (true/false) and

True again, though I'd rather one capability with features...

>The NMS can present a simple UI, e.g. a calendar widget, and just
>construct corresponding XPath expressions.

Yes, if the NMS is only exporting config to the device, but I was actually
thinking about the NMS trying to import some config *another* client set,
and then trying to parse the XPath so that it could present it in the UI -
that seems hard...

>Nobody wants to repeatedly write such awkward expressions. What I had in
>mind was a function that extends XPath, something like
>

I see, but can you try to make an XPath mimic the "M-F 9-5" example with
custom-functions to help make it usable?

I'm not sure, but would we first capture a couple variables:

  dow=yang:day-of-week(/sys:system/sys:clock/sys:current-datetime)
  tod=yang:time-of-day(/sys:system/sys:clock/sys:current-datetime)

And then construct a boolean expressions?

  ("Monday"<=$doy and $dow<="Friday") and (9:00<=$tod and $tod<=17:00)

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Mar 2013 14:12:46 -0800

> equal from a scaling perspective...

I don't agree.
The amount of network and server processing needed to
handle policy embedded in each data node is relative to the number of nodes.
A pattern or XPath expression can match a potentially unlimited
number of nodes with the same 1 line expression.

A rule-based approach moves the application of policy to the database
to be a server implementation issue, allowing more flexibility
which might produce better performance.

> would using rulebases make this any easier?

Access to the rule-base that controls the enable property for object X
is different than access to object X directly.  IMO separating them
allows for more deployment scenarios.

> remotely?   In other words, you like the idea of temporal config?

Wildcards can match N instances with 1 XPath expression.
I would rather provide 1 rule that allowed the server to apply
the policy internally however it wants to implement it.

I don't know if I like moving temporal config to the server
at the object level. Perhaps named sub-tree patches
(e.g. business-hours-cfg and after-hours-cfg) might be
more user-friendly.

> case they'd be comparable to the rulebase example I gave.

I saw that -- I don't want a copy of a rule in every leaf.
I want XPath expressions that can describe an arbitrarily large node-set.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Mar 2013 23:38:22 +0000

>IMO, one option would be to have the candidate config represented not as
>a clone of running with modifications but rather as a sequence of
>patches. Then various rules/conditions could be specified as attributes
>of each patch - when it should be applied etc. At commit, all
>unconditional patches would be immediately applied and the
>conditional/termporal ones put on hold.

If I understand you correctly, you mean that the "running datastore" would
always contain the evaluated temporal-config?  So, for instance, if
something is set "M-F 9-5", it would show up in running config only during
those times and not otherwise?

This is an interesting approach, as it enables the "running" datastore to
be validated by its YANG module without the YANG-validator needing to
process any expressions, but I wonder if it's a good idea, since the
running config wouldn't represent the full/persisted config anymore -
thoughts?

Thanks again,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Mar 2013 08:48:52 +0100

> those times and not otherwise?

Simply put, the conditions would be a property of an edit-config, not of a data node in the datastore. Such an edit-config would be similar to a cron job. Your "M-F 9-5" example could be implemented as two edits: one that enables the item on workdays at 9am and another that disables it at 5pm.

In fact, this by itself doesn't require any changes to candidate, it could be an independent facility.
  
> running config wouldn't represent the full/persisted config anymore -

I think the running config would still show exactly the current configuration, and the client could also view the "cron table".

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Mar 2013 09:06:39 +0100

...
> and then trying to parse the XPath so that it could present it in the UI -

Yes, I see.

>   ("Monday"<=$doy and $dow<="Friday") and (9:00<=$tod and $tod<=17:00)

This is pretty much impossible with XPath 1.

Lada