[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-netmod-routing-cfg

NETMOD                                                         L. Lhotka
Internet-Draft                                                    CESNET
Intended status: Standards Track                          March 03, 2011
Expires: September 4, 2011


              A YANG Data Model for Routing Configuration
                   draft-lhotka-netmod-routing-cfg-00

Abstract

   This document contains a specification of a core YANG data model for
   IP routing configuration.  It is expected that this module will serve
   as a basis for further development of data models for individual
   routing protocols and other related functions.  The present data
   model defines the building blocks for such configurations - routes
   and routing tables, routing protocol instances, route filters and
   route pipes.

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 September 4, 2011.

Copyright Notice

   Copyright (c) 2011 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



Lhotka                  Expires September 4, 2011               [Page 1]


Internet-Draft         YANG Routing Configuration             March 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Notation . . . . . . . . . . . . . . . . . . .  4
   3.  Objectives . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Design of the Routing Data Model . . . . . . . . . . . . . . .  7
     4.1.  Route  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Routing Tables . . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Routing Protocol Instances . . . . . . . . . . . . . . . .  9
       4.3.1.  Defining New Routing Protocols . . . . . . . . . . . . 10
     4.4.  Route Pipes  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.5.  Route Filters  . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Core Routing YANG Module . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25
   Appendix A.  Example Module for Routing Information Protocol . . . 26
     A.1.  Example YANG Module for Routing Information Protocol . . . 26
     A.2.  Sample Reply to the NETCONF <get> Message  . . . . . . . . 27
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
























Lhotka                  Expires September 4, 2011               [Page 2]


Internet-Draft         YANG Routing Configuration             March 2011


1.  Introduction

   The NETCONF Data Modeling Language (NETMOD) Working Group has
   completed the essential specifications for the YANG data modeling
   language [RFC6020], common data types [RFC6021], and the
   corresponding data modeling environment and tools [RFC6087],
   [RFC6110].  The new NETMOD WG charter puts emphasis on the
   development of a set of core YANG data models for the following
   subsystems:

   1.  core system data model,

   2.  core interface data model,

   3.  core routing data model.

   The initial version of the core interface data model (item 2) was
   already published [YANG-IF].

   This document contains an initial specification for item 3, namely
   the "ietf-routing" YANG module representing the core routing data
   model.  While the module can be directly used for simple devices with
   static routing, its main purpose is to provide basic building blocks
   for more complicated setups involving multiple routing protocols and
   advanced functions, such as route filtering and policy routing.  To
   this end, it is expected that this module will be augmented by
   numerous modules developed by other IETF working groups.
























Lhotka                  Expires September 4, 2011               [Page 3]


Internet-Draft         YANG Routing Configuration             March 2011


2.  Terminology and Notation

   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 [RFC2119].

   The following terms are defined in [RFC4741]:

   o  client

   o  datastore

   o  message

   o  operation

   o  server

   The following terms are defined in [RFC6020]:

   o  augment

   o  configuration data

   o  container

   o  data model

   o  data node

   o  data tree

   o  data type

   o  feature

   o  grouping

   o  identity

   o  instance identifier

   o  leaf-list

   o  list

   o  mandatory node




Lhotka                  Expires September 4, 2011               [Page 4]


Internet-Draft         YANG Routing Configuration             March 2011


   o  module

   o  operational state data

   o  RPC operation

   o  submodule

   The following terms are defined in [XML-INFOSET]:

   o  attribute

   o  document

   o  document element

   o  element

   o  information set

   o  namespace






























Lhotka                  Expires September 4, 2011               [Page 5]


Internet-Draft         YANG Routing Configuration             March 2011


3.  Objectives

   The initial design of the core routing data model was driven by the
   following main objectives:

   o  The data model should be suitable for the common address families,
      in particular IPv4 and IPv6.

   o  Simple routing setups, such as static routing, should be
      configurable in a simple way, ideally without any need to define
      additional YANG modules.

   o  On the other hand, the framework defined by the module must allow
      for complicated setups involving multiple routing tables and
      multiple routing protocols, as well as controlled redistributions
      of routing information.

   o  Device vendors will want to map the data models built on this
      generic framework to their proprietary data models and
      configuration interfaces.  Therefore, the framework should be
      flexible enough to facilitate such a mapping and accommodate data
      models with different logic.





























Lhotka                  Expires September 4, 2011               [Page 6]


Internet-Draft         YANG Routing Configuration             March 2011


4.  Design of the Routing Data Model

   The "ietf-routing" YANG module presented in Section 5 defines a data
   modeling framework with several essential components: routes, routing
   tables, routing protocol instances, route filters and route pipes.
   By combining these components in various ways, and filling them with
   appropriate content models defined in other modules, a broad range of
   routing setups can be covered.

                           +------------+
                           | kernel FIB |
                           +------------+
                              ^      |
                              |      v
                            +---+  +---+
                            | F |  | F |
                            +---+  +---+
                              ^      |
                              |      v
                          +--------------+    +---+    +--------------+
   +--------+             |              |<---| F |<---|              |
   | static |    +---+    |    main      |    +---+    |  additional  |
   | routes |--->| F |--->|   routing    |             |   routing    |
   +--------+    +---+    |    table     |    +---+    |    table     |
                          |              |--->| F |--->|              |
                          +--------------+    +---+    +--------------+
                              ^      |                     ^      |
                              |      v                     |      v
                            +---+  +---+                 +---+  +---+
                            | F |  | F |                 | F |  | F |
                            +---+  +---+                 +---+  +---+
                              ^      |                     ^      |
                              |      v                     |      v
                            +----------+                 +----------+
                            | routing  |                 | routing  |
                            | protocol |                 | protocol |
                            +----------+                 +----------+

             Figure 1: Example setup of the routing subsystem

   Figure 1 shows an example of a more complicated setup:

   o  Along with the main routing table, which must always be present,
      an additional routing table is defined.

   o  Each routing protocol instance, including the static pseudo-
      protocol instance, is connected to exactly one routing table with
      which it can exchange routes (in both directions, except for the



Lhotka                  Expires September 4, 2011               [Page 7]


Internet-Draft         YANG Routing Configuration             March 2011


      static pseudo-protocol).

   o  Routing tables may also be connected to each other through route
      pipes and exchange routes in one or both directions.

   o  The main routing table exchanges routes with the forwarding
      information base (FIB) in the operating system kernel as follows:
      active routes from the main routing table are installed in the FIB
      and used for packet forwarding, and automatic routes set up by the
      kernel (for example, direct routes to connected networks) are
      passed to the main routing table.

   o  Route exchanges along all connections may be controlled by means
      of route filters denoted by "F" in the figure.

   All configuration and operational state data defined by the "ietf-
   routing" module apear inside the "routing" container.  The following
   subsections describe the individual components of the core routing
   framework.

4.1.  Route

   Routes are basic units of information in a routing system.  The
   "ietf-routing" module defines only the following essential route
   parameters:

   o  route-type - permitted values are "unicast" (default), "multicast"
      and "anycast".

   o  destination-prefix - IP prefix specifying the set of destination
      addresses for which the route may be used.  This parameter is
      mandatory.

   o  next-hop - IP address of the adjacent router or host to which
      packets with destination addresses belonging to destination-prefix
      should be sent.

   o  outgoing-interface - network interface that should be used for
      sending packets with destination addresses belonging to
      destination-prefix.

   The above list of route parameters is sufficient for a simple static
   route configuration.  It is expected that future modules defining
   routing protocols will add other route attributes such as metrics or
   preferences.

   Routes are used in both configuration data, for example as manually
   configured static routes, as well as in operational state data, for



Lhotka                  Expires September 4, 2011               [Page 8]


Internet-Draft         YANG Routing Configuration             March 2011


   example as entries in routing tables.

4.2.  Routing Tables

   Routing tables are lists of routes complemented with administrative
   data, namely:

   o  source-protocol - name of the routing protocol from which the
      route arrived.

   o  last-modified - date and time of last modification, or
      installation, of the route.

   In the core routing data model, routing tables are represented as
   operational state data.  Routing protocol operations result in route
   additions, removals and modifications.  This also includes
   manipulations via the "static" pseudo-protocol.

   The data model also defines an RPC operation, "delete-route" which
   allows the client to immediately delete a specified route from a
   routing table.

   Every compliant implementation MUST automatically configure the main
   routing table.  Additional routing tables MAY be configured by adding
   their unique names to the "configured-routing-tables" leaf-list.

4.3.  Routing Protocol Instances

   The "ietf-routing" module provides an open-ended framework for
   defining multiple routing protocol instances.  Each of them is
   identified by a unique name and MUST be assigned a type from a
   selection which includes all routing protocol types supported by the
   server, such as RIP, OSPF or BGP.

   Each routing protocol instance is connected to exactly one routing
   table.  By default, every routing protocol instance is connected to
   the main routing table, but any routing protocol instance can be
   configured to use a different routing table, provided such an extra
   table is configured.

   Routes learned from the network by a routing protocol instance are
   passed to the connected routing table and vice versa - routes
   appearing in a routing table may be passed to any routing protocol
   connected to the table and advertised by that protocol to the
   network.

   Two independent route filters (see Section 4.5) may be defined for a
   routing protocol instance to control the exchange of routes in both



Lhotka                  Expires September 4, 2011               [Page 9]


Internet-Draft         YANG Routing Configuration             March 2011


   directions between the routing protocol instance and the connected
   routing table:

   o  import filter controls which routes are passed from a routing
      protocol instance to the routing table,

   o  export filter controls which routes the routing protocol instance
      may receive from the connected routing table.

   Note that, for historical reasons, the terms import and export are
   used from the viewpoint of a routing table.

   The "ietf-routing" module defines two special routing protocols -
   "direct" and "static".  Both are in fact pseudo-protocols, which
   means that they are confined to the local server and do not exchange
   any routing information with neighboring routers.  Routes from both
   "direct" and "static" protocol instances are passed to the connected
   routing table (subject to route filters, if any), but an exchange in
   the opposite direction is not allowed.

   The "direct" pseudo-protocol MUST exist in exactly one instance in
   any server implementation.  It is the source for routes to directly
   connected networks (so-called direct routes).  Such routes are
   supplied by the operating system kernel based on the detected and
   configured network interfaces, and they usually appear in the main
   routing table.  However, using the framework defined in this
   document, the target routing table for direct routes can be changed
   by connecting the "direct" protocol instance to a non-default routing
   table, and the direct routes can also be filtered before they appear
   in the routing table.

   The "static" routing pseudo-protocol allows for specifying routes
   manually.  It can be configured in zero or more instances, although
   typically one instance suffices.

4.3.1.  Defining New Routing Protocols

   It is expected that other YANG modules will create data models for
   additional routing protocol types.  In order to do so, the new module
   has to define the protocol-specific information and fit it to the
   core routing framework in the following way:

   o  A new identity MUST be defined for the routing protocol and its
      base identity set to "routing-protocol", or to an identity derived
      from "routing-protocol".

   o  Additional route attributes MAY be defined.  Their definitions
      have to be inserted as operational state data by augmenting the



Lhotka                  Expires September 4, 2011              [Page 10]


Internet-Draft         YANG Routing Configuration             March 2011


      definition of "route" under "routing-table".  Naturally, routes
      (including the extra attributes) may be used in configuration
      data, too, as demonstrated by the "static" pseudo-protocol.

   o  The recommended way of defining configuration data specific to the
      new protocol is to augment the "routing-protocol-instance" list
      entry with a container that encapsulates the configuration
      hierarchy of the new protocol.  The 'augment' statement SHOULD be
      made conditional by using a 'when' substatement requiring that the
      new nodes be used only if the "type" leaf node is equal to the new
      protocol's identity.

   The above steps are implemented by the example YANG module for the
   RIP routing protocol in Appendix A.  In particular, the module first
   defines a new identity for the RIP protocol:

   identity rip {
     base rt:routing-protocol;
     description "Identity for the RIP routing protocol.";
   }

   RIP-specific configuration data are then integrated into the
   "routing-protocol-instance" node by using the following 'augment'
   statement, which applies only for routing protocol instances whose
   type is "rip":

   augment "/rt:routing/rt:routing-protocol-instances/" +
           "rt:routing-protocol-instance" {
     container rip-configuration {
       when "../rt:type='rip'";
       ...
     }
   }

4.4.  Route Pipes

   Route pipes are unidirectional links connecting pairs of routing
   tables that allow for passing routes from one routing table to
   another.  Each route pipe is identified by a unique name and has two
   mandatory parameters, "origin" and "recipient", that specify the two
   routing tables that are being connected.

   The transport of routes from the "origin" table to the "recipient"
   table may be controlled by means of a route filter (see Section 4.5).
   If no filter is defined, all routes present in the "origin" table
   MUST also appear in the "recipient" table.





Lhotka                  Expires September 4, 2011              [Page 11]


Internet-Draft         YANG Routing Configuration             March 2011


4.5.  Route Filters

   The "ietf-routing" module provides a skeleton for defining route
   filters that can be used to restrict the set of routes being
   exchanged between a routing protocol instance and a routing table, or
   between two routing tables connected through a route pipe.  Route
   filters may also manipulate routes, i.e., add, delete, or modify
   their properties.

   By itself, the route filtering framework defined in the "ietf-
   routing" module allows to establish only the two extreme routing
   policies in which either all routes are allowed or all routes are
   denied.  It is expected that a real route filtering framework (or
   several alternative frameworks) will be developed separately.

   Each route filter is identified by a unique name.  Its type may be
   specified by the "type" identity reference - this opens the space for
   multiple route filtering framework implementations.  The only route
   filter type defined in the "ietf-routing" module carries the default
   "route-filter" identity, and represents the "deny all" route
   filtering policy.






























Lhotka                  Expires September 4, 2011              [Page 12]


Internet-Draft         YANG Routing Configuration             March 2011


5.  Core Routing YANG Module
<CODE BEGINS> file "ietf-routing@2011-03-03.yang"

module ietf-routing {
  namespace "urn:ietf:params:xml:ns:yang:ietf-routing";
  prefix rt;

  import ietf-yang-types {
    prefix yang;
  }
  import ietf-inet-types {
    prefix inet;
  }
  import ietf-interfaces {
    prefix if;
  }

  organization
    "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/netmod/>
     WG List:  <mailto:netmod@ietf.org>

     WG Chair: David Kessens
               <mailto:david.kessens@nsn.com>

     WG Chair: Juergen Schoenwaelder
               <mailto:j.schoenwaelder@jacobs-university.de>

     Editor:   Ladislav Lhotka
               <mailto:lhotka@cesnet.cz>";

  description
    "This module contains YANG definitions for basic
     configuration of IP routing.

     It is immediately usable for a device that needs just a single
     routing table populated with static routes.

     On the other hand, the framework is designed to handle arbitrarily
     complex configurations with any number of routing tables and
     various routing protocols (in multiple instances).

     Every compliant implementation MUST support IPv4 unicast routing
     and implement at least one (main) routing table, which is
     connected to the OS kernel forwarding information base.";




Lhotka                  Expires September 4, 2011              [Page 13]


Internet-Draft         YANG Routing Configuration             March 2011


  revision 2011-03-03;

  /* Features */

  feature ipv6-routing {
    description
      "This feature MUST be advertised by devices supporting IPv6
       routing. Such a device MUST implement at least one extra routing
       table to which all IPv6 unicast routing protocols are connected
       by default.";
  }

  feature ipv4-multicast-routing {
    description
      "This feature MUST be set by devices supporting IPv4
       multicast routing.  Such a device MUST implement at least one
       extra routing table to which all IPv6 multicast routing
       protocols are connected by default.";
  }

  feature ipv6-multicast-routing {
    description
      "This feature MUST be set by devices supporting IPv6
       multicast routing.  Such a device MUST implement at least one
       extra routing table to which all IPv6 multicast routing
       protocols are connected by default.";
  }

  /* Identities */

  identity address-family {
    description
      "Base identity from which address family identities are
       derived.";
  }

  identity af-ipv4 {
    base address-family;
    description
      "IPv4 address family.";
  }

  identity af-ipv6 {
    base address-family;
    description
      "IPv6 address family.";
  }




Lhotka                  Expires September 4, 2011              [Page 14]


Internet-Draft         YANG Routing Configuration             March 2011


  identity routing-protocol {
    description
      "Base identity from which routing protocol identities are
       derived.";
  }

  identity direct {
    base routing-protocol;
    description
      "Identity for the pseudo-protocol providing routes to
       directly connected networks. An implementation MUST preconfigure
       an instance of this pseudo-protocol.";
  }

  identity static {
    base routing-protocol;
    description
      "Identity for static routing pseudo-protocol.";
  }

  identity route-filter {
    description
      "Base identity for route filters. It also represents the
       empty route filter that blocks everything.";
  }

  identity route-type {
    description
      "Base identity for route types.";
  }

  identity unicast {
    base route-type;
    description
      "Unicast route type.";
  }

  identity multicast {
    base route-type;
    description
      "Multicast route type.";
  }

  identity anycast {
    base route-type;
    description
      "Anycast route type.";
  }



Lhotka                  Expires September 4, 2011              [Page 15]


Internet-Draft         YANG Routing Configuration             March 2011


  /* Type definitions */

  typedef routing-table-ref {
    type leafref {
      path "/routing/configured-routing-tables/name";
    }
    description
      "This type represents a reference to a configured routing
       table.";
  }

  typedef routing-protocol-instance-ref {
    type leafref {
      path "/routing/routing-protocol-instances/" +
           "routing-protocol-instance/name";
    }
    description
      "This type represents a reference to a configured routing
       protocol instance.";
  }

  typedef route-filter-ref {
    type leafref {
      path "/routing/route-filters/route-filter/name";
    }
    description
      "This type represents a reference to a configured route
       filter.";
  }

  /* Groupings */

  grouping ip-route-content {
    description
      "Components of an IP route.";
    leaf type {
      type identityref {
        base route-type;
      }
      default "unicast";
    }
    leaf destination-prefix {
      type inet:ip-prefix;
      mandatory true;
      description
        "The set of destination addresses for which the route may
         be used.";
    }



Lhotka                  Expires September 4, 2011              [Page 16]


Internet-Draft         YANG Routing Configuration             March 2011


    leaf next-hop {
      type inet:ip-address;
      description
        "IP address of the host or router to which packets whose
         address matches 'destination-prefix' are to be forwarded.";
    }
    leaf outgoing-interface {
      type if:interface-ref;
      description
        "Name of the outgoing interface. This parameter is mainly
         used in direct routes.";
    }
  }

  rpc delete-route {
    description
      "This operation deletes a route with given parameters from
       a specified routing table. <ok> is returned by the server
       upon successful completion.";
    input {
      container route {
        description
          "All routes that match this parameter MUST be deleted
           from the target routing table.";
        uses ip-route-content;
      }
      leaf routing-table {
        type routing-table-ref;
        description
          "This parameter specifies the target routing
           table.";
      }
    }
  }

  /* Data tree */

  container routing {
    description
      "IP routing parameters.";
    container configured-routing-tables {
      description
        "Names of configured routing tables. Their contents are
         available as operational state data under 'routing-tables'. At
         least one (main) table MUST be configured for every supported
         address family. This default routing table is usually
         connected to the main kernel forwarding table.";
      leaf-list name {



Lhotka                  Expires September 4, 2011              [Page 17]


Internet-Draft         YANG Routing Configuration             March 2011


        type string;
        min-elements 1;
      }
    }
    container routing-protocol-instances {
      description
        "Container for configured routing protocol instances.

         Every implementation MUST preconfigure the 'direct'
         pseudo-protocol instance providing the routes to directly
         connected networks.";
      list routing-protocol-instance {
        key "name";
        container static-routes {
          when "../type='static'";
          description
            "Configuration of a 'static' pseudo-protocol instance
             consists of a list of routes.";
          list static-route {
            key "id";
            leaf id {
              type string;
            }
            leaf description {
              type string;
            }
            uses ip-route-content;
          }
        }
        leaf name {
          type string;
        }
        leaf description {
          type string;
        }
        leaf address-family {
          type identityref {
            base address-family;
          }
          default "af-ipv4";
          description
            "Address family used by the routing protocol instance.";
        }
        leaf type {
          type identityref {
            base routing-protocol;
          }
          mandatory true;



Lhotka                  Expires September 4, 2011              [Page 18]


Internet-Draft         YANG Routing Configuration             March 2011


          description
            "Type of the routing protocol.";
        }
        leaf routing-table {
          type routing-table-ref;
          description
            "The routing table to which the protocol instance is
             connected. By default it is the main routing table for the
             given address family.";
        }
        leaf import-filter {
          type route-filter-ref;
          description
            "Reference to a route filter that is used for
             filtering routes passed from this routing protocol instance
             to the routing table specified by the 'routing-table'
             sibling node. If this leaf is not present, the behavior is
             protocol-specific, but typically it means that all routes
             are accepted.";
        }
        leaf export-filter {
          type route-filter-ref;
          description
            "Reference to a route filter that is used for
             filtering routes passed from the routing table specified
             by the 'routing-table' sibling to this routing protocol
             instance. If this leaf is not present, the behavior is
             protocol-specific - typically it means that all routes
             are accepted, except for the 'direct' and 'static'
             pseudo-protocols which accept no routes from
             anywhere.";
        }
      }
    }
    container route-pipes {
      description
        "Route pipes facilitate transport of routes between pairs
         of routing tables.";
      list route-pipe {
        key "name";
        description
          "A route-pipe is a unidirectional connection between
           'origin' and 'recipient'.";
        leaf name {
          type string;
        }
        leaf description {
          type string;



Lhotka                  Expires September 4, 2011              [Page 19]


Internet-Draft         YANG Routing Configuration             March 2011


        }
        leaf origin {
          type routing-table-ref;
          mandatory true;
          description
            "The originating routing-table.";
        }
        leaf recipient {
          type routing-table-ref;
          mandatory true;
          description
            "The receiving routing-table.";
        }
        leaf route-filter {
          type route-filter-ref;
          description
            "All routes passing through the route pipe are filtered by
             the route filter referred to by this leaf. If it is not
             present, all routes from 'origin' are passed to
             'destination'.";
        }
      }
    }
    container route-filters {
      description
        "Non-trivial route filters are expected to be defined in
         other modules.";
      list route-filter {
        key "name";
        description
          "A route filter is used for filtering routes between
           routing protocol instances and routing tables (import
           filter) and vice versa (export filter), and in route pipes
           that connect pairs of routing tables.";
        leaf name {
          type string;
        }
        leaf description {
          type string;
        }
        leaf type {
          type identityref {
            base route-filter;
          }
          default "route-filter";
          description
            "Type of the route-filter. The default value
             represents an all-blocking filter.";



Lhotka                  Expires September 4, 2011              [Page 20]


Internet-Draft         YANG Routing Configuration             March 2011


        }
      }
    }

    /* Operational state data */

    container routing-tables {
      config false;
      description
        "Routing tables and their contents.";
      list routing-table {
        min-elements 1;
        description
          "Exactly one routing table MUST be present for every 'name'
           entry appearing in '/routing/configured-routing-tables'.";
        leaf name {
          type routing-table-ref;
        }
        leaf address-family {
          type identityref {
            base address-family;
          }
          default "af-ipv4";
          description
            "Address family of all routes in the routing table.";
        }
        list route {
          leaf source-protocol {
            type routing-protocol-instance-ref;
            description
              "Protocol instance from which the route comes.";
          }
          leaf last-modified {
            type yang:date-and-time;
            description
              "Time stamp of the last modification of the
               route. If the route was never modified, it is the time
               when the route was inserted to the routing table.";
          }
          uses ip-route-content;
        }
      }
    }
  }
}


<CODE ENDS>



Lhotka                  Expires September 4, 2011              [Page 21]


Internet-Draft         YANG Routing Configuration             March 2011


6.  IANA Considerations

   This document requests the following registration of a namespace URI
   in the IETF XML registry [RFC3688]:

   -----------------------------------------------------
   URI: urn:ietf:params:xml:ns:yang:ietf-routing

   Registrant Contact: The IESG.

   XML: N/A, the requested URI is an XML namespace.
   -----------------------------------------------------







































Lhotka                  Expires September 4, 2011              [Page 22]


Internet-Draft         YANG Routing Configuration             March 2011


7.  Security Considerations

   TBD.
















































Lhotka                  Expires September 4, 2011              [Page 23]


Internet-Draft         YANG Routing Configuration             March 2011


8.  Acknowledgments

   The author wishes to thank the following individuals who provided
   helpful suggestions and/or comments on this document: TBD.















































Lhotka                  Expires September 4, 2011              [Page 24]


Internet-Draft         YANG Routing Configuration             March 2011


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
              December 2006.

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

   [RFC6021]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6021, September 2010.

   [XML-INFOSET]
              Tobin, R. and J. Cowan, "XML Information Set (Second
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-infoset-20040204, February 2004,
              <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.

   [YANG-IF]  Bjorklund, M., "A YANG Data Model for Interface
              Configuration", draft-bjorklund-netmod-interfaces-cfg-00
              (work in progress), December 2010.

9.2.  Informative References

   [RFC6087]  Bierman, A., "Guidelines for Authors and Reviewers of YANG
              Data Model Documents", RFC 6087, January 2011.

   [RFC6110]  Lhotka, L., Ed., "Mapping YANG to Document Schema
              Definition Languages and Validating NETCONF Content",
              RFC 6110, February 2011.













Lhotka                  Expires September 4, 2011              [Page 25]


Internet-Draft         YANG Routing Configuration             March 2011


Appendix A.  Example Module for Routing Information Protocol

   This appendix demonstrates how the "ietf-routing" module can be
   extended to support a new routing protocol.  Appendix A.1 contains a
   YANG module that is used for this purpose.  It is intended only as an
   illustration and not as a real definition of a data model for the RIP
   routing protocol.  This module also imports the "ietf-interfaces"
   module defined in [YANG-IF].

   Appendix A.2 then contains a complete instance XML document - a reply
   to the NETCONF <get> message from a server that uses the RIP protocol
   as well as static routing.  A route filter is also defined in order
   to prevent static routes to private networks from being redistributed
   to RIP.  The instance document also uses data nodes from the two
   example YANG modules "ex-ethernet" and "ex-ip" defined in [YANG-IF].

A.1.  Example YANG Module for Routing Information Protocol

   module example-rip {
     namespace "http://example.com/rip";
     prefix rip;

     import ietf-interfaces {
       prefix if;
     }
     import ietf-routing {
       prefix rt;
     }

     identity rip {
       base rt:routing-protocol;
       description
         "Identity for the RIP routing protocol.";
     }

     typedef rip-metric {
       type uint8 {
         range "0..16";
       }
     }

     augment "/rt:routing/rt:routing-protocol-instances/" +
             "rt:routing-protocol-instance" {
       when "rt:type='rip:rip'";
       container rip-configuration {
         container rip-interfaces {
           list rip-interface {
             key "name";



Lhotka                  Expires September 4, 2011              [Page 26]


Internet-Draft         YANG Routing Configuration             March 2011


             leaf name {
               type if:interface-ref;
             }
             leaf enabled {
               type boolean;
               default "true";
             }
             leaf metric {
               type rip-metric;
               default "1";
             }
             /* Additional per-interface RIP configuration */
           }
         }
         leaf update-interval {
           type uint8 {
             range "10..60";
           }
           units "seconds";
           default "30";
           description
             "Time interval between periodic updates.";
         }
         /* Additional RIP configuration */
       }
     }
     augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:route" {
         when "../../../rt:routing-protocol-instances/" +
              "rt:routing-protocol-instance[rt:name=" +
              "current()/rt:source-protocol]/rt:type='rip:rip'";
       description
         "RIP-specific route components.";
       leaf metric {
         type rip-metric;
       }
       leaf tag {
         type uint16;
         default "0";
         description
           "This leaf may be used to carry additional info, e.g. AS
            number.";
       }
     }
   }

A.2.  Sample Reply to the NETCONF <get> Message

   <?xml version="1.0" encoding="utf-8"?>



Lhotka                  Expires September 4, 2011              [Page 27]


Internet-Draft         YANG Routing Configuration             March 2011


   <nc:rpc-reply
       message-id="101"
       xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
       xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
       xmlns:eth="http://example.com/ethernet"
       xmlns:ip="http://example.com/ip"
       xmlns:rip="http://example.com/rip"
       xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
     <nc:data>
       <if:interfaces>
         <if:interface>
           <if:name>eth0</if:name>
           <if:type>eth:ethernet</if:type>
           <if:location>05:00.0</if:location>
           <ip:ip>
             <ip:address>
             <ip:ip>192.0.2.1</ip:ip>
             <ip:prefix-length>24</ip:prefix-length>
             </ip:address>
           </ip:ip>
         </if:interface>
         <if:interface>
           <if:name>eth1</if:name>
           <if:type>eth:ethernet</if:type>
           <if:location>05:00.1</if:location>
           <ip:ip>
             <ip:address>
             <ip:ip>192.168.1.1</ip:ip>
             <ip:prefix-length>24</ip:prefix-length>
             </ip:address>
           </ip:ip>
         </if:interface>
       </if:interfaces>
       <routing>
         <configured-routing-tables>
           <name>rt0</name>
         </configured-routing-tables>
         <routing-protocol-instances>
           <routing-protocol-instance>
             <name>direct</name>
             <type>direct</type>
           </routing-protocol-instance>
           <routing-protocol-instance>
             <name>st0</name>
             <description>
               Static routing is used for the internal network.
             </description>
             <type>static</type>



Lhotka                  Expires September 4, 2011              [Page 28]


Internet-Draft         YANG Routing Configuration             March 2011


             <static-routes>
               <static-route>
                 <id>id-6378</id>
                 <destination-prefix>192.168.2.0/24</destination-prefix>
                 <next-hop>192.168.1.254</next-hop>
               </static-route>
             </static-routes>
           </routing-protocol-instance>
           <routing-protocol-instance>
             <name>rip0</name>
             <type>rip:rip</type>
             <export-filter>to-rip</export-filter>
             <rip:rip-configuration>
               <rip:rip-interfaces>
                 <rip:rip-interface>
                   <rip:name>eth0</rip:name>
                 </rip:rip-interface>
               </rip:rip-interfaces>
             </rip:rip-configuration>
           </routing-protocol-instance>
         </routing-protocol-instances>
         <route-filters>
           <route-filter>
             <name>to-rip</name>
             <description>
               Block redistribution of static routes.
             </description>
           </route-filter>
         </route-filters>
         <routing-tables>
           <routing-table>
             <name>rt0</name>
             <route>
               <destination-prefix>192.168.1.0/24</destination-prefix>
               <source-protocol>direct</source-protocol>
               <outgoing-interface>eth0</outgoing-interface>
               <last-modified>2010-02-24T17:11:23+01:00</last-modified>
             </route>
             <route>
               <destination-prefix>192.168.2.0/24</destination-prefix>
               <source-protocol>st0</source-protocol>
               <next-hop>192.168.1.254</next-hop>
               <rip:tag>64500</rip:tag>
               <last-modified>2010-02-24T17:11:27+01:00</last-modified>
             </route>
             <route>
               <destination-prefix>0.0.0.0/0</destination-prefix>
               <next-hop>192.0.2.2</next-hop>



Lhotka                  Expires September 4, 2011              [Page 29]


Internet-Draft         YANG Routing Configuration             March 2011


               <rip:metric>2</rip:metric>
               <rip:tag>64500</rip:tag>
               <source-protocol>rip0</source-protocol>
               <last-modified>2010-03-03T13:00:23+01:00</last-modified>
             </route>
           </routing-table>
         </routing-tables>
       </routing>
     </nc:data>
   </nc:rpc-reply>









































Lhotka                  Expires September 4, 2011              [Page 30]


Internet-Draft         YANG Routing Configuration             March 2011


Author's Address

   Ladislav Lhotka
   CESNET

   Email: lhotka@cesnet.cz













































Lhotka                  Expires September 4, 2011              [Page 31]


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