<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,               
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.             
    There has to be one entity for each item to be referenced.                    
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2697 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2697.xml">
<!ENTITY RFC2698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2698.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
]>
<rfc category="std" docName="draft-zheng-netconf-inline-action-capability-02"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Inline Action Capability">Inline Action Capability for
    NETCONF</title>

    <author fullname="Walker Zheng" initials="W." surname="Zheng">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>zhengguangying@huawei.com</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <date year="2018"/>

    <area>OPS Area</area>

    <workgroup>NETCONF Working Group</workgroup>

    <abstract>
      <t>NETCONF provides mechanism to install configuration of network
      devices. In many cases, it is required that the same configuration
      repeats on many interfaces. In the absence of protocol semantics for
      performing operations with group-specific scope, this results in either
      a significant amount of signaling traffic and configuration template
      applying on a periodic basis or large packet size between a given
      network management system and a network devices. This document defines
      optimizations to the NETCONF protocol operations for performing
      operations with group-specific scope with the use of a group
      identifier.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>NETCONF provides mechanism to install configuration of network
      devices. In many cases, it is required that the same configuration
      repeats on many interfaces, e.g., configure multiple VLAN ranges on the
      same Trunk interface. In the absence of protocol semantics for
      performing operations with group-specific scope, using configuration
      template to replicate multiple copies on the same interface result in
      either a significant amount of signaling traffic(e.g, multiple data
      retrieval for vlan tag configuration on the interface) on a periodic
      basis or large packet size (e.g,edit-config operation related to
      protocol message) between a given network management system and a
      network devices.</t>

      <t>This document defines optimizations to the NETCONF protocol
      operation(i.e., inline action operation) for performing bulk operations
      with group-specific scope with the use of a group identifier and allows
      NETCONF protocol operation work together with inline action operation
      that apply to different conceptual node in the underlying data model in
      one transaction.</t>

      <section title="Terminology">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 [RFC2119] [RFC8174] when, and only when, they appear in all
        capitals, as shown here.</t>
      </section>
    </section>

    <!-- intro -->

    <!-- summary -->

    <section anchor="extension" title="Inline-Action Capability">
      <section title="Description">
        <t>The :inline-action capability indicates that the device supports
        Inline-action operation within protocol operation on specific
        datastore. In other words, the device supports &lt;record-merge&gt;
        operation which is included in existing protocol operations.</t>

        <t/>
      </section>

      <section title="Dependencies">
        <t>None.</t>
      </section>

      <section title="Capability Identifier">
        <t>The :inline-action capability is identified by the following
        capability string: <figure>
            <artwork>urn:ietf:params:netconf:capability:inline-action:1.1</artwork>
          </figure></t>
      </section>

      <section title="New Operations">
        <t>None.</t>
      </section>

      <section title="Modifications to Existing Operations">
        <t>The :inline-action:1.1 capability modifies the protocol operation
        to accept &lt;record-merge&gt; attribute value within operation
        attribute.</t>

        <t>As described in [RFC6241], "operation" attribute is defined in a
        element within &lt;config&gt; subtree and identify the point in the
        configuration to perform the operation and MAY appear on multiple
        elements throughout the &lt;config&gt; subtree. In this document, two
        new "operation" attribute values are added as follows: <list
            style="hanging">
            <t hangText="record-split: ">The range constrait of the
            configuration data identified by the element containing this
            attribute is split at the corresponding level in the configuration
            datastore identified by the &lt;target&gt; parameter.</t>

            <t hangText="record-merge: ">The range constrait of the
            configuration data identified by the element containing this
            attribute is merged at the corresponding level in the
            configuration datastore identified by the &lt;target&gt;
            parameter.</t>
          </list></t>

        <t>In addition, the record-merge and record-split operation attributes
        and other "operation" attributes MUST apply to the different
        conceptual nodes In the underlying data model.</t>

        <t>As described in [RFC6241], the config subtree is expressed as a
        hierarchy of configuration data as defined by one of the device's data
        models. The contents MUST follow the constraints of that data model,
        as defined by its capability definition. If inline action capability
        is supported, the config subtree may contain a schema node with the
        name "input" and a schema node with the name "output" connected to a
        specific container or list data node containing recrod-merge element
        in a datastore.</t>

        <figure>
          <artwork>Excample:
container interfaces {
    list trunk-interface {
            key "name";
             config true;
             leaf name {
               type string;
             }
          container vlan-id-ranges{
            list vlan-id-range{
             key "group-id";
             leaf group-id {
                type string;
                description
             "Specified VLAN group ID.";
             }
          leaf lower-vlan-id {
           type uint32 {
             range "1..4094";
           }
           mandatory true;
           description
             "Start outer VLAN ID.";
         }
         leaf upper-vlan-id {
           type uint16 {
             range "1..4094";
           }
           description
             "End outer VLAN ID.";
           }
           action range-merge {
               input {
             leaf lower-vlan-id {
               type uint32 {
               range "1..4094";
            }
           mandatory true;
           description
             "Start outer VLAN ID.";
         }
         leaf upper-vlan-id {
           type uint16 {
             range "1..4094";
           }
           description
             "End outer VLAN ID.";
           }
         }
        }
       }
     }
  }
}</artwork>
        </figure>

        <t>Suppose we configure trunk interface with multiple discrete vlan
        tag ranges from the running configuration and without inline action
        capability, edit-config with configuration template will be used to
        merge them as one record with extra computation in the client app.</t>

        <figure>
          <artwork>&lt;rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"&gt;
           &lt;edit-config&gt;
             &lt;target&gt;
               &lt;running/&gt;
             &lt;/target&gt;
             &lt;default-operation&gt;none&lt;/default-operation&gt;
             &lt;config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.1"&gt;
               &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
                &lt;interfaces&gt;
                 &lt;interface&gt;
                   &lt;name&gt;Ethernet0/0&lt;/name&gt;
                   &lt;vlan-id-ranges&gt;
                     &lt;vlan-id-range xc:operation="delete"&gt;
                        &lt;group-id&gt;0&lt;/group-id&gt;
                        &lt;lower-vlan-id&gt;1&lt;/lower-vlan-id&gt;
                        &lt;upper-vlan-id&gt;3&lt;/upper-vlan-id&gt;
                      &lt;/vlan-id-range&gt;
                      &lt;vlan-id-range xc:operation="delete"&gt;
                        &lt;group-id&gt;2&lt;/group-id&gt;
                        &lt;lower-vlan-id&gt;5&lt;/lower-vlan-id&gt;
                        &lt;upper-vlan-id&gt;6&lt;/upper-vlan-id&gt;
                      &lt;/vlan-id-range&gt;
                      &lt;vlan-id-range xc:operation="delete"&gt;
                        &lt;group-id&gt;3&lt;/group-id&gt;
                        &lt;lower-vlan-id&gt;7&lt;/lower-vlan-id&gt;
                        &lt;upper-vlan-id&gt;8&lt;/upper-vlan-id&gt;
                      &lt;/vlan-id-range&gt;
                      &lt;vlan-id-range xc:operation="delete"&gt;
                        &lt;group-id&gt;4&lt;/group-id&gt;
                        &lt;lower-vlan-id&gt;9&lt;/lower-vlan-id&gt;
                        &lt;upper-vlan-id&gt;10&lt;/upper-vlan-id&gt;
                      &lt;/vlan-id-range&gt;
                      &lt;vlan-id-range xc:operation="create"&gt;
                        &lt;group-id&gt;0&lt;/group-id&gt;
                        &lt;lower-vlan-id&gt;1&lt;/lower-vlan-id&gt;
                        &lt;upper-vlan-id&gt;10&lt;/upper-vlan-id&gt;
                      &lt;/vlan-id-range&gt;
                   &lt;/vlan-id-ranges&gt;
                 &lt;/interface&gt;                
           &lt;/interfaces&gt;
         &lt;/top&gt;
      &lt;/config&gt;
    &lt;/edit-config&gt;
&lt;/rpc&gt;</artwork>
        </figure>

        <t>If inline-action capability supported, bulk operation in one
        protocol message will be used to merge multiple records with different
        vlan tag range will into one record:</t>

        <figure>
          <artwork>&lt;rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"&gt;
           &lt;edit-config&gt;
             &lt;target&gt;
               &lt;running/&gt;
             &lt;/target&gt;
             &lt;default-operation&gt;none&lt;/default-operation&gt;
             &lt;config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.1"&gt;
               &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
                &lt;interfaces&gt;
                 &lt;interface xc:operation="record-merge"&gt;
                   &lt;name&gt;Ethernet0/0&lt;/name&gt;
                   &lt;vlan-id-ranges&gt;
                     &lt;vlan-id-range&gt;
                     &lt;action xmlns="http://example.com/schema/1.2/config"&gt;
                       &lt;range-merge&gt;
                         &lt;input&gt;
                           &lt;lower-vlan-id&gt;1&lt;/lower-vlan-id&gt;
                           &lt;upper-vlan-id&gt;10&lt;/upper-vlan-id&gt;
                         &lt;/input&gt;
                       &lt;/range-merge&gt;
                      &lt;/action&gt;
                     &lt;/vlan-id-range&gt;
                    &lt;vlan-id-ranges&gt;
                    &lt;/interface&gt;
                 &lt;/interfaces&gt;
               &lt;/top&gt;
           &lt;/config&gt;
    &lt;/edit-config&gt;
 &lt;/rpc&gt;    </artwork>
        </figure>

        <t>Suppose we have a trunk interface with vlan tag range [1,10], we
        delete one vlan tag from this trunk interface,without inline action
        capability, edit-config with configuration template will be used to
        split valn tag range into multiple records with extra computation in
        the client app.</t>

        <figure>
          <artwork>&lt;rpc message-id="102"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"&gt;
           &lt;edit-config&gt;
             &lt;target&gt;
               &lt;running/&gt;
             &lt;/target&gt;
             &lt;default-operation&gt;none&lt;/default-operation&gt;
             &lt;config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.1"&gt;
               &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
                &lt;interfaces&gt;
                 &lt;interface&gt;
                   &lt;name&gt;Ethernet0/0&lt;/name&gt;
                   &lt;vlan-id-ranges&gt;
                     &lt;vlan-id-range xc:operation="delete"&gt;
                        &lt;group-id&gt;0&lt;/group-id&gt;
                        &lt;lower-vlan-id&gt;4&lt;/lower-vlan-id&gt;
                        &lt;upper-vlan-id&gt;4&lt;/upper-vlan-id&gt;
                      &lt;/vlan-id-range&gt;
                      &lt;vlan-id-range xc:operation="create"&gt;
                        &lt;group-id&gt;0&lt;/group-id&gt;
                        &lt;lower-vlan-id&gt;1&lt;/lower-vlan-id&gt;
                        &lt;upper-vlan-id&gt;3&lt;/upper-vlan-id&gt;
                      &lt;/vlan-id-range&gt;
                      &lt;vlan-id-range xc:operation="create"&gt;
                        &lt;group-id&gt;1&lt;/group-id&gt;
                        &lt;lower-vlan-id&gt;4&lt;/lower-vlan-id&gt;
                        &lt;upper-vlan-id&gt;10&lt;/upper-vlan-id&gt;
                      &lt;/vlan-id-range&gt;
                   &lt;/vlan-id-ranges&gt;
                 &lt;/interface&gt;                
           &lt;/interfaces&gt;
         &lt;/top&gt;
      &lt;/config&gt;
    &lt;/edit-config&gt;
&lt;/rpc&gt;</artwork>
        </figure>

        <t>If inline-action capability supported, bulk operation in one
        protocol message will be used to split one record with vlan tag range
        into two records:</t>

        <figure>
          <artwork>&lt;rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"&gt;
           &lt;edit-config&gt;
             &lt;target&gt;
               &lt;running/&gt;
             &lt;/target&gt;
             &lt;default-operation&gt;none&lt;/default-operation&gt;
             &lt;config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.1"&gt;
               &lt;top xmlns="http://example.com/schema/1.2/config"&gt;
                &lt;interfaces&gt;
                 &lt;interface xc:operation="record-merge"&gt;
                   &lt;name&gt;Ethernet0/0&lt;/name&gt;
                   &lt;vlan-id-ranges&gt;
                     &lt;vlan-id-range&gt;
                         &lt;lower-vlan-id&gt;1&lt;/lower-vlan-id&gt;
                         &lt;upper-vlan-id&gt;10&lt;/upper-vlan-id&gt;
                         &lt;action xmlns="http://example.com/schema/1.2/config"&gt;
                         &lt;range-split&gt;
                         &lt;input&gt;
                          &lt;lower-vlan-id&gt;4&lt;/lower-vlan-id&gt;
                          &lt;upper-vlan-id&gt;4&lt;/upper-vlan-id&gt;
                         &lt;/input&gt;
                       &lt;/range-split&gt;
                      &lt;/action&gt;
                     &lt;/vlan-id-range&gt;
                    &lt;vlan-id-ranges&gt;
                    &lt;/interface&gt;
                 &lt;/interfaces&gt;
               &lt;/top&gt;
           &lt;/config&gt;
    &lt;/edit-config&gt;
 &lt;/rpc&gt;</artwork>
        </figure>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document does not introduce any security vulnerability besides
      on defined in [RFC6241].</t>
    </section>

    <section title="IANA Considerations">
      <section title="NETCONF Capability URN">
        <t>IANA has created and now maintains a registry "Network
        Configuration Protocol (NETCONF) Capability URNs" that allocates
        NETCONF capability identifiers. Additions to the registry require IETF
        Standards Action.</t>

        <t>IANA has added the following capabilities to the registry:<figure>
            <artwork>      Index
         Capability Identifier
      ------------------------
      :inline-action:1.1
         urn:ietf:params:netconf:capability:inline-action:1.1</artwork>
          </figure></t>
      </section>
    </section>

    <!---->
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>

      <?rfc include="reference.RFC.6020.xml"?>

      <?rfc include="reference.RFC.6021.xml"?>

      <?rfc include="reference.RFC.6241.xml"?>

      <?rfc include="reference.RFC.6242.xml"?>

      <?rfc include="reference.RFC.6470.xml"?>

      <?rfc include='reference.I-D.ietf-netconf-nmda-netconf'?>
    </references>
  </back>
</rfc>
