[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

Internet Engineering Task Force                             J. Haas, Ed.
Internet-Draft                                          Juniper Networks
Intended status: Informational                        September 12, 2014
Expires: March 16, 2015

                  I2RS requirements for netmod/netconf


   This document covers requests to the netmod and netconf Working
   Groups for functionality to support requirements to implement the
   I2RS architecture.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 16, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Haas                     Expires March 16, 2015                 [Page 1]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  I2RS Requirements . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Data Store Requirements . . . . . . . . . . . . . . . . .   3
       2.1.1.  A Separate Ephemeral Datastore  . . . . . . . . . . .   4
       2.1.2.  Tagged Ephemeral Modules in the Running Datastore . .   4
       2.1.3.  Permitting Existing Configuration State to be Made
               Optionally Ephemeral  . . . . . . . . . . . . . . . .   4
     2.2.  Mutual Authentication Requirements  . . . . . . . . . . .   5
       2.2.1.  NETCONF over SSH  . . . . . . . . . . . . . . . . . .   5
       2.2.2.  NETCONF/RESTCONF over TLS . . . . . . . . . . . . . .   5
     2.3.  Identity, Secondary-Identity Requirements; Priority
           Requirements; Implications  . . . . . . . . . . . . . . .   5
       2.3.1.  Identity Requirements . . . . . . . . . . . . . . . .   5
       2.3.2.  Priority Requirements . . . . . . . . . . . . . . . .   6
       2.3.3.  Implications of Idenities and Priorities on Internal
               State . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Access Control Model Requirements . . . . . . . . . . . .   6
       2.4.1.  Data Store Implications . . . . . . . . . . . . . . .   6
       2.4.2.  I2RS Priority . . . . . . . . . . . . . . . . . . . .   6
     2.5.  Connectivity Requirements . . . . . . . . . . . . . . . .   6
     2.6.  Notification and Subscription Requirements  . . . . . . .   7
       2.6.1.  Persistence of Subscriptions  . . . . . . . . . . . .   7
       2.6.2.  Filtering Considerations  . . . . . . . . . . . . . .   7  Expressivity of Existing Filtering Mechanisms . .   7  Filtering Workload  . . . . . . . . . . . . . . .   8
     2.7.  Transaction Requirements  . . . . . . . . . . . . . . . .   8
     2.8.  Object Relationship Requirements  . . . . . . . . . . . .   9
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The Interface to the Routing System (I2RS) Working Group is chartered
   with providing architecture and mechanisms to inject into and
   retrieve information from the routing system.  The I2RS Architecture
   document [I-D.ietf-i2rs-architecture] abstractly documents a number
   of requirements for implementing the I2RS requirements.

   The I2RS Working Group has chosen to use the YANG data modeling
   language [RFC6020] as the basis to implement its mechanisms.

Haas                     Expires March 16, 2015                 [Page 2]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

   Additionally, the I2RS Working group has chosen to use the NETCONF
   [RFC6241] and its similar but lighter-weight relative RESTCONF
   [I-D.bierman-netconf-restconf] as the protocols for carrying I2RS.

   While YANG, NETCONF and RESTCONF are a good starting basis for I2RS,
   there are some things needed from each of them in order for I2RS to
   be implemented.

   Note that this draft does not attempt to address specific
   implementation of I2RS requirements that the existing YANG, RESTCONF
   and NETCONF mechanisms are expected to cover.  A separate draft will
   be issued for the consumption of the I2RS Working Group for such

2.  I2RS Requirements

2.1.  Data Store Requirements

   One of the key mechanisms in I2RS is the ability to inject
   configuration state into a network element on an ephemeral basis.
   While at first glance this may seem equivalent to the writable-
   running datastore in NETCONF, running-config can be copied to a
   persistant data store, like startup config.  The author wishes to
   prevent any action that would lead to preserving any configuration
   state entered via the I2RS agent across reboots.  If state has to be
   restored, it should be solely by replay actions from I2RS client via
   I2RS agent.

   A few options for implementing such ephemeral configuration suggest
   themselves, as do some possible problems with such an implementation:

   1.  A separate ephemeral datastore.  The semantics of this datastore
       is that all configuration state is known ahead of time to not
       survive reboot and is not to be copied into persistent storage.
       Such a datastore could be referenced by NETCONF and RESTCONF
       using existing semantics, such as "target" and "source".

   2.  Configuration state in the existing running datastore where the
       module is "tagged ephemeral".

   3.  Permitting existing configuration to be optionally configured as
       ephemeral.  As an example, the NETCONF server advertises in its
       <hello> message if it supports the specified YANG module
       persistently and/or ephemerally.

Haas                     Expires March 16, 2015                 [Page 3]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

2.1.1.  A Separate Ephemeral Datastore

   The primary advantage of a fully separate datastore is that the
   semantics of its contents are always clearly ephemeral.  It also
   provides strong segregation of I2RS configuration and operational
   state from the rest of the system within the network element.

   The most obvious disadvantage of such a fully separate datastore is
   that interaction with the network element's operational or
   configuration state becomes significantly more difficult.  As an
   example, a BGP I2RS use case would be the dynamic instantiation of a
   BGP peer.  While it is readily possible to re-use any defined
   groupings from an IETF-standardized BGP module in such an I2RS
   ephemeral datastore's modules, one cannot currently reference state
   from one datastore to another.

   For example, XPath queries are done in the context document of the
   datastore in question and thus it is impossible for an I2RS model to
   fulfil a "must" or "when" requirement in the BGP module in the
   standard data stores.  To implement such a mechanism would require
   appropriate semantics for XPath.

2.1.2.  Tagged Ephemeral Modules in the Running Datastore

   Presume a YANG keyword that flagged an entire module as being
   ephemeral.  In such a case, entire modules could be crafted for I2RS
   (and other) purposes wherein the configuration state in the module
   had ephemeral properties.  The primary property is that copy
   operations would not be able to cause the I2RS state to persist.

   An obvious issue with this is the muddying of the semantics of
   existing NETCONF/RESTCONF operations.  For example, get-config is
   expected to return the configuration state for the network element,
   but the knowledge that the configuration state may not persist is
   important.  This may require alterations to get-config (and similar
   commands) along with the ambiguity of copy-config not picking up the
   ephemeral modules.

   Providing additional parameters to the various configuration related
   operations in NETCONF/RESTCONF would likely be required.

2.1.3.  Permitting Existing Configuration State to be Made Optionally

   In YANG, configuration state is distinguished from operational state
   using "config true" vs. "config false".  One way to implement I2RS
   state would be to introduce a third option, "config ephemeral", to

Haas                     Expires March 16, 2015                 [Page 4]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

   A form of this option was previously discussed in
   [I-D.rfernando-i2rs-yang-mods].  The suggestion of "config ephemeral"
   is made instead due to potential non-I2RS interest in this feature at
   the microphone during the IETF-90 session of netmod in Toronto,

2.2.  Mutual Authentication Requirements

      "Mutual authentication between the I2RS Client and I2RS Agent is
      required.  An I2RS Client must be able to trust that the I2RS
      Agent is attached to the relevant Routing Element so that write/
      modify operations are correctly applied and so that information
      received from the I2RS Agent can be trusted by the I2RS Client."

   Implementing the mutual authentication requirements for I2RS in each
   of the underlying protocols and their transports have some
   implications to be discussed.

2.2.1.  NETCONF over SSH

   The SSH transport does not mandate authentication be done; it is an
   optional feature.  In an I2RS context, authentication is mandatory.
   Authentication of the client to the agent is carried out using any
   method besides "none".  Authentication of the agent to the client
   requires that the server's public key be recognized.


   Agent validation of the I2RS client is mandated over TLS in an I2RS
   context.  The client shall also validate the Agent using its server

2.3.  Identity, Secondary-Identity Requirements; Priority Requirements;

2.3.1.  Identity Requirements

   I2RS requires clients to have an identity.  This identity will be
   used by the Agent authentication mechanism over the appropriate

   I2RS also permits clients to have a secondary identity which may be
   used for troubleshooting.

Haas                     Expires March 16, 2015                 [Page 5]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

2.3.2.  Priority Requirements

   To support Multi-Headed Control, I2RS requires that there be a
   decidable means of arbitrating the correct state of data when
   multiple clients attempt to manipulate the same piece of data.  This
   is done via a priority mechanism with the highest priority winning.
   This priority may vary on a per-node or subtree basis based for a
   given identity.

2.3.3.  Implications of Idenities and Priorities on Internal State

   Given the requirements for I2RS identities and priority arbitration,
   I2RS configured state must have "meta-data" that includes the
   identity that caused it to come into being.  Agents must also be able
   to map priority on a particular piece of configuration state vs. the
   identity provisioning it for arbitration purposes.  Such mapping
   might be represented as part of the "meta-data" or potentially a
   distinct mapping database of identity vs.  priority vs. configuration
   state.  Such a mapping may be implemented using an extension to the
   NETCONF Access Control Model [RFC6536].

2.4.  Access Control Model Requirements

2.4.1.  Data Store Implications

   As noted above, one of the possible options for implementing the I2RS
   ephemeral behavior is a separate data store.  However, this clashes
   with Section 3.2 of [RFC6536] which limits itself to the well- known
   data stores.

2.4.2.  I2RS Priority

   A likely implementation of priority arbitration would be to extend
   the NACM model to also contain criteria for I2RS priority.

2.5.  Connectivity Requirements

   I2RS does not require clients to maintain active communication
   channels with their agents.  Agents thus require the ability to open
   communication channels back to clients to satisfy previously
   requested information.

   [I-D.ietf-netconf-call-home] describes a mechanism by which NETCONF
   may "phone home" using SSH and TLS.

   While NETCONF notifications currently permit a different client to
   establish a session to an agent specifically for notification
   purposes, the I2RS use case typically expects that provisioning of

Haas                     Expires March 16, 2015                 [Page 6]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

   notifications is centrally managed and that systems receiving the
   notifications should not need to be individually to be provisioned.

2.6.  Notification and Subscription Requirements

2.6.1.  Persistence of Subscriptions

   NETCONF Event Notifications [RFC5277] provides a mechanism by which
   subscriptions may be created.  In that RFC, subscriptions are
   terminated when the underlying transport session ends.

   As noted in the prior section, I2RS does not require its clients to
   maintain a connection to its agents.  Thus, a mechanism by which
   subscriptions may be created and persist through the termination of
   the transport session is required.

   Management of these subscriptions implies the ability to:

   o  Create a "headless" subscription and determine what its endpoint

   o  Specify the type and various parameters for the endpoint session.
      For example, the need for confidentiality may not be required for
      some notifications or a highly efficient transport may be
      required.  Experience over the years has shown that very light-
      weight transports, for example UDP for SNMP NOTIFICATIONs/TRAPs,
      enables low-end components to participate in notification in a
      distributed fashion.  A long-term implication may be that
      additional lighter-weight transports may be needed for I2RS
      notification channels.

   o  Delete such "headless" subscriptions.

   o  Enumerate the set of those subscriptions on the network element.

   o  Apply Access Control to the above abilities.

2.6.2.  Filtering Considerations  Expressivity of Existing Filtering Mechanisms

   XPath is provided as the mechanism in [RFC6241] for extended
   filtering.  While XPath is a highly expressive language, it tends to
   be best suited for string and simple math-based filtering.

   I2RS, being an interface to network elements, will typically have as
   common types IPv4 and IPv6 addresses, prefixes for the same and may
   require network mask interactions for firewalling.  These and other

Haas                     Expires March 16, 2015                 [Page 7]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

   examples suggest that long term extensions appropriate for efficient
   filtering of I2RS types may be required.

   As an example, a regular expression filter that can match addresses
   covered by "" would need to match on the string
   "192.0.2." as a prefix and all final octets with the string
   representations of the values greater than or equal to 128.  While
   methodologies for building such regular expressions are well known
   within the networking world, it typically results in poor
   performance.  Filtering Workload

   Filtering, additionally, is implied to be a mechanism of the "central
   event processor".  I2RS subscriptions may be implemented on data
   objects wherein a small, filtered portion of a subtree is being
   monitored, but the magnitude of events being generated is

   Given this filtering workload, implementations are suggested to
   "push" the filtering to relevant system components to "pre-filter"
   events when possible.

2.7.  Transaction Requirements

   Each transaction should be treated as atomic and providing full
   functionality.  If the configuration change is not functionally
   complete, then the transaction should fail and be rolled back (
   rollback 0).  Example, I2RS agents wants to configure BGP:

               routing-options {
                   autonomous-system autonomous-system;
               protocols {
                   bgp {
                       group group-name {
                           peer-as autonomous-system;
                           type type;
                           neighbor address;

   If a statement like neighbor address is missing or is missformated,
   like 300.127.5.23, configuration is not functional, transaction
   should fail and rollback 0 should be performed by the I2RS agent on
   the ephemeral config store.  If the neighbor address is in the
   transaction, but the address is not reachable or similar, transaction

Haas                     Expires March 16, 2015                 [Page 8]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

   is accepted, but notification will be sent that BGP peering can't be

2.8.  Object Relationship Requirements

   XXX JMH - I've largely convinced myself that the "instance-
   identifier" and "require-instance" YANG keywords satisfy the
   properties required by I2RS.  If you don't, please supply an example.

3.  IANA Considerations

   This document introduces no new considerations to IANA.

4.  Security Considerations


5.  Acknowledgements

   This document is an attempt to distill length conversations on the
   I2RS mailing list for an architecture that was for a long period of
   time a moving target.  Some individuals in particular warrant
   speicfic mention for their extensive help in providing the basis for
   this document:

   o  Alia Atlas

   o  Andy Bierman

   o  Martin Bjorklund

   o  Dean Bogdanavich

   o  Rex Fernando

   o  Joel Halpern

   o  Susan Hares

   o  Thomas Nadeau

   o  Juergen Schoenwaelder

   o  Kent Watsen

Haas                     Expires March 16, 2015                 [Page 9]

Internet-Draft     I2RS requirements on NETMOD/NETCONF    September 2014

6.  Normative References

              Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
              "RESTCONF Protocol", draft-bierman-netconf-restconf-04
              (work in progress), February 2014.

              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-ietf-i2rs-architecture-05 (work in
              progress), July 2014.

              Watsen, K., "NETCONF Call Home", draft-ietf-netconf-call-
              home-00 (work in progress), September 2014.

              Fernando, R., pals, p., Madhayyan, M., and A. Clemm, "YANG
              modifications for I2RS", draft-rfernando-i2rs-yang-mods-00
              (work in progress), February 2013.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, July 2008.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March

Author's Address

   Jeffrey Haas (editor)
   Juniper Networks
   1194 N. Mathida Ave.
   Sunnyvale, CA  94089

   Email: jhaas@juniper.net

Haas                     Expires March 16, 2015                [Page 10]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/