One document matched: draft-kwatsen-conditional-enablement-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<rfc ipr="trust200902" docName="draft-kwatsen-conditional-enablement-00">
<front>
<title abbrev="Conditional Enablement of Config Nodes">Conditional Enablement of Configuration Nodes</title>
<author initials="K.W." surname="Watsen" fullname="Kent Watsen">
<organization>Juniper Networks</organization>
<address>
<email>kwatsen@juniper.net</email>
</address>
</author>
<date month="February" year="2013"/>
<area>Operations and Management Area</area>
<workgroup>Network Configuration Working Group</workgroup>
<keyword>conditional-enablement</keyword>
<abstract>
<t>This memo presents a cross-cutting technique whereby
a NETCONF server can support conditional enablement of
configuration nodes. That is, whether the node is active
or not depends on the evaluation of an expression.
Two expression types are defined herein, one for latent
configuration (present but not actualized) and another
for temporal configuration (actualized based on time).
This soluton presented is extensible so that additional
expression types may be added in the future.</t>
</abstract>
</front>
<middle>
<section title="Requirements Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 <xref target="RFC2119"/>.</t>
</section>
<section title="Introduction">
<t>This memo presents a cross-cutting technique whereby
a NETCONF server can support conditional enablement of
configuration nodes. That is, whether the node is active
or not depends on the evaluation of an expression.
Two expression types are defined herein, one for latent
configuration (present but not actualized) and another
for temporal configuration (actualized based on time).
This soluton presented is extensible so that additional
expression types may be added in the future.</t>
</section>
<section title="Motivation">
<section title="Explicit Nodes Defined in NETMOD Drafts">
<t>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.</t>
<figure anchor='enabled_example1'>
<preamble>Example of an "enabled" leaf from draft-ietf-netmod-routing-cfg-06.txt:</preamble>
<artwork>
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.";
}
</artwork>
</figure>
<figure anchor='enabled_example2'>
<preamble>Example of an "enabled" leaf from draft-ietf-netmod-system-mgmt-04.txt:</preamble>
<artwork>
leaf enabled {
type boolean;
default true;
description
"Indicates whether this server is enabled for use or not.";
}
</artwork>
</figure>
</section>
<section title="Precendent in Juniper's JUNOS-Based Products">
<t>Further, there is already a precendent for this strategy
in Juniper's JUNOS-based products, where any configuration
node can be flagged with an XML attribute stating that it is
inactive.</t>
<figure anchor='inactive_example'>
<preamble>Example of a JUNOS "inactive" statement:</preamble>
<artwork>
<interface inactive="inactive">...<interface>
</artwork>
</figure>
<t>Additionally, JUNOS also supports the notion of
a list of conditionals that must all be satisfied for an
associated configuration to be applied. JUNOS supports the
conditionals to be based on chassis type, model type, routing
engine, member, and time.</t>
<figure anchor='when_example'>
<preamble>Example of a JUNOS "when" statement (this is not YANG):</preamble>
<artwork>
groups {
my-group-g1 {
system {
hostname xyz;
}
when {
model tx1000;
routing-engine re0;
time 2am to 4am;
}
}
}
</artwork>
</figure>
</section>
<section title="Use-Cases Scoped By I2RS Working Group">
<t>Lastly, discusions with the I2RS Working Group have
revealed that they believe they have a need for a device
to autonomously switch configuration settings based on
time.</t>
</section>
</section>
<section title="Expression Types">
<section title="Overview">
<t>Conditional expressions are boolean expressions
that evaluate to either "true" or "false".</t>
<t>Expressions are contained inside an XML attribute
called "enabled". An expression that evaluates to
"true" enables the associated node, whereas an
expression that evaluates to "false" disables it.</t>
<t>A configuration node having no expression set is
equivalent to an expression evaluating to "true".
That is, all nodes are enabled by default.</t>
<figure>
<preamble>Example usage:</preamble>
<artwork><![CDATA[
<foobar enabled="<expression>"/>
]]></artwork>
</figure>
</section>
<section title="Simple Expressions">
<t>Simple expressions are the most trivial expressions
possible; they are simply either the constant value
"true" or "false".
<vspace blankLines="1"/>
expressions = "true" / "false";
</t>
<t>Simple expressions are useful to disable a
configuration node until it is explicitly reenabled.
Since this is such a common use-case, this draft
enables simple expressions to be supported without
having to implement support for complex expressions.</t>
<t>A device advertises support for simple expressions
using the feature "simple" in its capability string:
<vspace blankLines='1' />
<capability string>?features=simple
</t>
</section>
<section title="Complex Expressions">
<t>All expressions that are not "simple" are "complex".
These expressions require being able to compare values
and evaluate logical expressions; they do not need to
perform arithmetic, bitwise operations, or assignments.</t>
<t>The grammer is the same for all complex expresssions,
the only thing that varies is what variable assignments
the device supports (e.g. time, reference to a statistical
value, etc.).</t>
<t>A device does not explicitly advertise support for
complex expressions. Support for complex expressions
are implicit when any feature depending on complex
expressions (e.g. time) is advertized. For instance:
<vspace blankLines='1' />
<capability string>?features=time
</t>
<figure>
<preamble>Complex expressions use the following grammer:</preamble>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(expression.abnf)
]]></artwork>
</figure>
</section>
</section>
<section title="Feature Types">
<section title="Overview">
<t>The types of expressions a device supports is advertised
as a list of "features" in the capability identifier string.</t>
</section>
<section title="Simple">
<t>The "simple" feature defines support for constant boolean
values "true" and "false". Simple expressions are useful
to disable a node until it is explicitly reenabled.</t>
</section>
<section title="Time">
<t>The "time" feature defines support for complex expressions
using time-oriented values such as "dayofweek" and "hour".
Time expressions are useful to implement policies that depend
on time.</t>
</section>
</section>
<section title="Conditional Enablement Capability">
<section title="Overview">
<t>The :conditional-enablement capability advertises that the NETCONF
server supports the ability for nodes in its to be annotated
with metadata specifying conditions when it is enabled or
its values vary.</t>
</section>
<section title="Dependencies">
<t>None.</t>
</section>
<section title="Capability Identifier">
<t>The :conditional-enablement capability is identified by
the following capability string:
<vspace blankLines='1' />
urn:ietf:params:netconf:capability:conditional-enablement:1.0? \
features={name,...}
</t>
<t>The :conditional-enablement capability URI MUST contain a "features"
argument assigned a comma-separated list of names indicating
which expression-types the NETCONF peer supports. For example:
<vspace blankLines='1' />
urn:ietf:params:netconf:capability:conditional-enablement:1.0? \
features=simple,time
</t>
</section>
<section title="New Operations">
<t>None.</t>
</section>
<section title="Modifications to Existing Operations">
<t>The :conditional-enablement capability modifies any operation that
transmits configuration, including:
<list>
<t><get-config></t>
<t><edit-config></t>
<t><copy-config></t>
</list>
</t>
<t>A NETCONF server advertising the :conditional capability
indicates that any node in its configuration MAY contain
XML attributes defined in the "Overview" section of this
capability, even though those attributes were not explicitly
defined in its YANG module.</t>
</section>
<section title="Interactions with Other Capabilities">
<t>None.</t>
</section>
</section>
<section title="Security Considerations">
<t>There are no known security considerations at this time.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA directives.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials="S.B." surname="Bradner"
fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<!--
<reference anchor="RFC4741">
<front>
<title>NETCONF Configuration Protocol</title>
<author initials="R.E." surname="Enns"
fullname="Rob Enns" role="editor">
<organization>Juniper Networks</organization>
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name="RFC" value="4741" />
</reference>
<reference anchor="RFC6020">
<front>
<title>
YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)
</title>
<author initials="M.B." surname="Bjorklund"
fullname="Martin Bjorklund" role="editor">
<organization>Tail-f Systems</organization>
</author>
<date month="October" year="2010" />
</front>
<seriesInfo name="RFC" value="6020" />
</reference>
-->
</references>
<!--
<references title="Informative References">
</references>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 21:23:15 |