Subject: [netmod] Yang 1.1 support for long-running commands

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Tue, 6 May 2014 21:58:45 +0000

Issue:

Currently, we cannot find a "clean" way to mode a long-running command (e.g. "ping", "traceroute") in Yang. This class of command requires the following:

-    A request to be made to trigger the command starting (e.g. an RPC).

-    Notifications to be returned (for a period) as partial results become available.

-    A request to be made to cancel the operation if required.

-    An indication that the operation has completed and no further results are pending.

So in Yang 1.0 this could be modelled as follows:

rpc ping {

  input {

    leaf dest     { type yang:ip-address; mandatory true; }

    leaf timeout  { type uint32; units "ms"; default 1000; }

    leaf interval { type uint32; units "ms"; default 0; }

    leaf count    { type uint32; description "Default: infinite"; }

  }

  output {

    leaf operation-id {

      type uint64;

      description "Correlates the request to 'ping-cancel' and 'ping-results'"

  }

}

rpc ping-cancel {

  input {

    leaf operation-id {

      type uint64;

      description "The ID for the operation to cancel, as returned by the ping request";

    }

  }

}

notification ping-results {

  leaf operation-id {

    type uint64;

    mandatory true;

    description "The ID for the request for which results are being returned";

  leaf result {

    type enumeration {

      enum success;

      enum timeout;

      enum unreachable;

    }

  }

  leaf operation-completed {

    type empty;

    description "Indicates that no further results are to be returned";

  }

}

However, it would be preferable to have an abbreviated form for this usage pattern, which would also allow for it to be implemented differently depending on the protocol.

Solution:

This could be done various ways, but one suggestion would be to define a "partial-output" RPC result, such that whenever it is used, the type of operation is as above.

rpc ping {

  input {

    leaf dest     { type yang:ip-address; mandatory true; }

    leaf timeout  { type uint32; units "ms"; default 1000; }

    leaf interval { type uint32; units "ms"; default 0; }

    leaf count    { type uint32; description "Default: infinite"; }

  }

  partial-output {

    leaf result {

      mandatory true;

      type enumeration {

        enum success;

        enum failed;

        enum unreachable;

      }

    }

  }

}

Depending on the protocol, this could be implicitly expanded to the above Yang 1.0 form (with the "cancel", operation-id and "operation-completed" being implicit based on a standard pattern), so all the extraneous parts that are common to this pattern are abstracted from the user.

[Note: If an "output" is also specified, that would be expected to be returned immediately in response to the input, in line with the existing RPC semantics.]

Alternative solution:

It would be possible to implement this as an extension, though that would require a fifth type of operation to be defined as part of the extension.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 May 2014 09:27:12 +0200 (CEST)

Hi,

Added as Y51.

/martin