Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network on Demand (VNoD) using Interface to Routing System
draft-hares-i2rs-use-case-vn-vc-03

Versions: 00 01 02 03                                                   
Routing Area Working Group                                      S. Hares
Internet-Draft                                                   M. Chen
Intended status: Informational                       Huawei Technologies
Expires: January 5, 2015                                    July 4, 2014


 Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network
           on Demand (VNoD) using Interface to Routing System
                   draft-hares-i2rs-use-case-vn-vc-03

Abstract

   Software Defined Networks (SDN) provide a way to virtualize and
   abstract the network in order to present virtual or abstract
   resources to third-party applications running in software.
   Applications can utilize a programmable interface to receive these
   virtual or abstract resource descriptions in a form that allows
   monitoring or manipulation of resources within the network.  The
   Interface to the Routing System (I2RS) provides an interface directly
   to the routing System to monitor best paths to any destination or
   change routes in the routing information base (RIB) or MPLS Label
   Information Base (LIB).  The I2RS interfaces may be combined with
   other interfaces to the forwarding plane (ForCES (RFC3746)), device
   configuration (NETCONF), or mid-level/peer-to-peer (ALTO, draft-ietf-
   alto-protocol) system to create these virtual pathways.

   This document outlines how SDN networks can use the I2RS interface to
   implement an automated set of network services for the Virtual
   Connection on Demand (VCoD) and Virtual Network on Demand (VNoD).
   These systems provide service routing a better way to create paths
   within a hub and spoke environment, and provide service routing the
   ability to create pathways based on service.

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."




Hares & Chen             Expires January 5, 2015                [Page 1]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   This Internet-Draft will expire on January 5, 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Summary of I2RS requirements  . . . . . . . . . . . . . . . .   3
   3.  Virtual Circuit on Demand . . . . . . . . . . . . . . . . . .   5
     3.1.  Why I2RS enabled solutions are necessary  . . . . . . . .   6
     3.2.  Why is not in scope for I2RS  . . . . . . . . . . . . . .   6
     3.3.  Example Topology for Virtual Circuit on Demand (VCoD) . .   6
     3.4.  I2RS Requirements for Virtual Circuit on Demand (VCoD)  .   7
   4.  Virtual Network on Demand (VNoD)  . . . . . . . . . . . . . .   8
   5.  Automated On Demand Networks  . . . . . . . . . . . . . . . .  10
   6.  What is Missing in RIB Informational Model (RIB IM) . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The Interface to the Routing System (I2RS) architecture
   ([I-D.ietf-i2rs-architecture]) describes a mechanism where the
   distributed control plane can be augmented by an outside control
   plane through an open accessible programmatic interface.  I2RS
   provides a "halfway point" between completely an architecture that
   replaces the traditional distributed control planes and directly
   configuring devices via off-board processes.





Hares & Chen             Expires January 5, 2015                [Page 2]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   This draft proposes a set of use cases using I2RS mechanisms to
   implement a Software Defined Network (SDN) to enact virtual
   connections and virtual networks as automated services.  This
   document focuses on how I2RS would support two automated network
   services: Virtual Connection on Demand (VCoD) and Virtual Network on
   Demand (VNoD).  Virtual Connections on Demand (VCoD) and Virtual
   Network on Demand (VNoD) may be used within hub-spoke networks and
   improve service routing.  In the future, an application enabled SDN
   service may provide the Virtual Circuits (VCoD) and Virtual Networks
   on Demand (VNoD) for any type of network service.

   This document contains a summary of I2RS requirements from VCoD and
   VNoD use case, background to I2RS, a VCoD use case, a VNoD use case,
   and a discussion of what the RIB Information Model is missing.  Those
   familiar with I2RS problem statement
   ([I-D.ietf-i2rs-problem-statement]), I2RS architecture
   ([I-D.ietf-i2rs-architecture]), and the concepts of Virtual
   Connections (VCs) or Virtual Networks (VNs) may wish to skip the
   background section.

1.1.  Requirements Language

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

2.  Summary of I2RS requirements

   This section contains a summary of what each use case indicates is
   needed in the I2RS protocol (features and data).  Section 3-5 provide
   descriptions of the Virtual Circuit on Demand (VCoD), Virtual Network
   on Demand (VNoD), and Automated on Demand Networks.  Each of these
   sections specifies a use case description followed by a summary of
   I2RS requirements.

   The use cases in this document have been numbered to allow coherent
   compilation of the the I2RS requirements into a single list.  In this
   draft, each unique requirement for the I2RS protocol(I2RS client-I2RS
   agent) for the Virtual Circuit on Demand (VCoD) use caes has the
   label VCoD-REQnn where nn is an number.  Each unique requirement for
   the VNoD use case has the label VNoD-REQnn where nn is a number.
   This use case also indicates things which are lacking in the Each
   unique requirement for for VCoD additions to the I2RS RIB
   Informational Model VCOD-IM-REQnn (where nn is a unique number).
   Similarly, each unique requirement for VNoD additions to the RIB
   informational Model is identified with VNoD-IM-REQnn where nn is a
   unique number.  Section 6 contains a list of what is missing in the
   RIB Informational Model.



Hares & Chen             Expires January 5, 2015                [Page 3]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   The requirements for Virtual Connections on Demand (VCoD) use cases
   are:

   o  VCoD-REQ01: I2RS Agent SHOULD provide the ability to read the
      virtual network topology database for the technology supported to
      determine nodes and connections.  For optical, these are the
      optical connections and what node they connect to, and the
      topologies created.  For MPLS, this is virtual circuit available,
      what nodes they connect to, and the network topologies created.
      For IP technologies, this could include the GRE tunnels, what
      interface it connects to, and the topologies created.  For
      Ethernet circuits this should involve circuit type (e.g, point-to-
      point (P2P) or point-to-multipoint (P2MP)) and what nodes it can
      reach, and the topologies created.

   o  VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence the
      configuration of a virtual circuit in a node.

   o  VCod-REQ03: I2RS Agent SHOULD provide monitor and provide
      statistics on the virtual connection to the I2RS client via a Read
      request or status Notification.  The I2RS client can then
      determine if the connection falls below a quality level the
      application has requested.  If the I2RS client does determine the
      circuit is below the required quality, it could create another
      circuit.  The I2RS may choose to create the second virtual
      circuit, transfer flows, and then break the first circuit.

   The Virtual Network on Demand (VCoD) contains the same first three
   requirements.  This means that:

   o  VNoD-REQ01 = VCoD-REQ01,

   o  VNoD-REQ02 = VCoD-REQ02, and

   o  VNoD-REQ03 = VCoD-REQ03.

   These requirements will not be repeated, so the VNoD begin with VNoD-
   REQ-04.

   The requirements for the Virtual Networks on Demand (VNoD) are:

   o  VT-VN-REQ04: I2RS Agent SHOULD provide the ability to influence
      the configuration of a virtual network in a node.

   o  VT-VN-REQ05: I2RS Agent SHOULD provide the ability to report
      statistics on the network nodes and end-to-end traffic flows via
      read of status data or via notifications of status.




Hares & Chen             Expires January 5, 2015                [Page 4]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   o  VT-VN-REQ06: The I2RS protocol and RIB Informational Model (IM)
      MUST support logical tunnels of type MPLS as well as IP, GRE,
      VxLAN, and GRE.  Large carrier networks utilize MPLS in a variety
      of forms (LDP, static MPLS TE, or dynamic TE LSPs created by RSVP-
      TE).

   o  VT-VN-REQ07: I2RS SHOULD support Informational Models and features
      to allow MPLS technologies to create Hub-spoke topology and
      service routing in networks in Carriers, Enterprise, and Data
      Centers.

   o  VT-VN-REQ08: I2RS protocols, Information Models, and Data Models
      MUST be able to support Carriers using these MPLS technologies to
      support networks for Mobile BackHaul, on-demand MPLS overlays, and
      on-demand video conferencing networkings.

3.  Virtual Circuit on Demand

   Virtual Circuit on Demand (VCoD) application associates to I2RS
   client (or clients) which can communicate with the I2RS agent (or
   agents) which control the VCoD circuit's creation, deletion,
   modification, query for information or status changes.  Information
   for this application needs to include for network topology, interface
   statistics, available circuits per node, available bandwidth on
   circuits.  Interface statistics might be required on a historical and
   instantaneous time basis.  The circuit statistics might also need
   jitter, delay, and exit-point performance.

   The virtual circuits may be obtained via RIB Informational Model (RIB
   IM) ([I-D.ietf-i2rs-rib-info-model]) from the interface list, or from
   the nexthop lists.  Write access to set-up new interfaces is not
   clearly spelled out in the current version of the RIB IM, nor are the
   statistics (historical or time).  This use case points out additional
   Information Models (IMs) that need to be added to the I2RS
   information models.

   In the example topology below, the VCoD application's I2RS client
   communicates with I2RS agents to set-up virtual circuits from Edge 1
   to Edge 2.  The I2RS client communicates with I2RS Agent-1 on node 1,
   I2RS Agent-2 on node 2, I2RS Agent-3 on node 3, and I2RS Agent 4 on
   node 4 for to set-up the virtual circuit.  The VCoD application
   contains the necessary logic to determine the pathway from Edge 1 to
   Edge 2.

   A second option for VCoD is to have an application communicate with
   two I2RS clients who cooperate to set-up the virtual connections
   between Edge 1 and Edge 2.  Information passed between the two




Hares & Chen             Expires January 5, 2015                [Page 5]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   clients can be done via other IETF protocols (E.g. stateful PCE or
   ALTO).

3.1.  Why I2RS enabled solutions are necessary

   Past solutions in this area have included uses of device
   configuration across multiple nodes (SNMP or NETCONF based) with
   proprietary services combined with topology queries.  The lack of
   coordinated responses to routing topology queries has created
   problems in quickly obtaining and configuring changes for Virtual
   Circuits.  New algorithms can create better services in routing and
   switching.  These algorithms include Fast-Reroute of RSVP or IGPs
   which aid the automatic re-establishment of some circuits, but the
   complexity of some of these algorithms increases cost within the
   network elements.  It's often difficult to justify the added
   complexity in the database and algorithms of routing protocols to
   solve what is considered a point case.

   While the set-up of these virtual circuits is possible with current
   technology, the lack of the I2RS-like framework makes VCoD network
   complex.  With this support, VCoD may be able to reduce complexity on
   the individual nodes.

3.2.  Why is not in scope for I2RS

   The means by which the VCoD application determines which I2RS client
   to associate with is outside the I2RS protocol and architecture.  A
   list of virtual circuits per node may be queried from the RIB
   Informational Model's (RIB IM) ([I-D.ietf-i2rs-rib-info-model])
   interface and nexthop lists.  However, other means may be used to
   determine the possible interfaces on a node.  For example, ALTO could
   inform the application which nodes have an I2RS Agent supporting the
   VCoD service, and SNMP/NETCONF could be used to determine which
   interfaces were configured.

3.3.  Example Topology for Virtual Circuit on Demand (VCoD)















Hares & Chen             Expires January 5, 2015                [Page 6]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


         +----------------------------+
         | Application (VCoD)         |
         +---*------------------------+
             |                      |
             |                      |
       +-------*------------+<NETCONF>+-------------------+< NETCONF
       |I2RS client 1       |< PCE info> |I2RS Commissioner-2 |< PCEP
       |VC controller       |            | VN controller     |
       +--*----------*--*-*-+            +-------------------+
          |          |  | |               |               |
          |          |  | |--------------------------+    |
          |          |  |-----------+     |          |    |
          |          |              |     |          |    |
        +--------+ +--------+      +---------+  +----------+
        | I2RS   | | I2RS   |      | I2RS    |  | I2RS     |
        | Agent-1| |Agent-2 |      | Agent-3 |  | Agent-4  |
        |--------| |--------+      +---------+  +----------+
        | node 1 | | node 2 |      | node 3  |  | node 4   |
        +--------+ +--------+      +---------+  +----------+
           |  |        | |            |  |
       edge1  |--------| |------------|  |
                                         |----edge2



3.4.  I2RS Requirements for Virtual Circuit on Demand (VCoD)

   The following things need to be supported for this application:

   o  VCoD-REQ01: I2RS Agents SHOULD provide the ability to read the
      virtual network topology database for the technology supported.
      For optical, these are the optical connections and what node they
      connect to, and the topologies created.  For MPLS, this is virtual
      circuit available, what nodes they connect to, and the network
      topologies created.  For IP technologies, this could include the
      GRE tunnels, what interface it connects to, and the topologies
      created.  For Ethernet circuits this should involve circuit type
      (e.g, point-to-point (p2p) or point-to-multipoint (p2mp)) and what
      nodes it can reach, and the topologies created.

   o  VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence the
      configuration of a virtual circuit in a node.

   o  VCoD-REQ03: I2RS Agent SHOULD provide monitor and provide
      statistics on the virtual connection to the I2RS client via a Read
      request or status Notification.  The I2RS client can then
      determine if the connection falls below a quality level the
      application has requested.  If the I2RS client does determine the



Hares & Chen             Expires January 5, 2015                [Page 7]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


      circuit is below the required quality, it could create another
      circuit.  The I2RS may choose to create the second virtual
      circuit, transfer flows, and then break the first circuit.

   What is needed in the RIB IM Model

   o  VCoD-RIB_IM-REQ01: The RIB IM model
      ([I-D.ietf-i2rs-rib-info-model] provides with each route an
      associated nexthop-list 0-N members.  Each nexthop-list is flagged
      with a protection preference (1 or 2), and a Load balance weight
      (1 to 99).  If the host routes for all nodes in the topology exist
      within the RIB IM model's instantiation, then the nexthop member
      on the nexthop-list SHOULD provide the following information:

      *  identifier for interface

      *  egress interface (logical, virtual, or physical)

      *  address of physical interface (IP address or MAC) plus RIB

      *  tunnel encapsulation for interface (IP GRE, MPLS tunnel),

      *  logical tunnel identifier

      *  RIB name (for look-up resolution)

      *  flags for specialized look-ups (Discard packets, discard with
         error notification, receive)

   o  VT-VC-RIB_IM-REQ02: The RIB IM model's primitives SHOULD include
      circuit type (p2p, mp2mp), optical connection information, and
      additional statistics per virtual circuit.

   o  VT-VC_RIB_IM-REQ03:The RIB IM model's instantiation within the
      protocol must provide an easy way to specify queries for this
      information.

4.  Virtual Network on Demand (VNoD)

   Virtual Networks on Demand (VNoD) are simply extensions to the
   Virtual Connections on Demand concept.  The I2RS client is tasked to
   create a virtual network instead of a single connection.

   The example sequence would be that the application discovers the
   appropriate I2RS clients (I2RS VNoD client 1 and I2RS VNoD Client 2)
   which support VNoD via a protocol outside the I2RS framework (e.g.
   ALTO).  The I2RS Client-2 works with the I2RS Agents 1-4 to set-up a
   virtual network.  This involves the following:



Hares & Chen             Expires January 5, 2015                [Page 8]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   o  gathering potential topology information (in order to create the
      network,

   o  set-up the virtual network (via influencing configurations on
      node),

   o  monitoring changes in topology (in order to potential failovers,

   o  influencing changes to virtual network via configurations, and

   o  removing the virtual network after the demand has expired.


                  +-------------------------+
                  | Application             |
                  +-------------------------+
                   |                      |
                   |                      |
        +------------------+< Policy   +-------------------+<Policy
        |I2RS VNoD client 1|<PCE info |I2RS client 2      |< PCEP
        |                  |           |                   |
        +------------------+           +-------------------+
                                        | |  |       |
           |----------------------------+ |  |       |
           |            +------------------  |       |
           |            |                    |       |
         +--------+ +--------+      +---------+  +----------+
         | I2RS   | | I2RS   |      | I2RS    |  | I2RS     |
         | Agent-1| |Agent-2 |      | Agent-3 |  | Agent-4  |
         |--------| |--------+      +---------+  +----------+
         | node 1 | | node 2 |      | node 3  |  | node 4   |
         +--------+ +--------+      +---------+  +----------+
            |  |        | |            |  | |      |  |
            |  |--------| |------------|  | +------+  |-end-point-3
            |                             |           |
        end-point-1                       |
                                          |----end-point2


   This topology shares some configuration needs with the central
   membership computation for MPLS VPNs from (draft-white-i2rs-use-
   cases) but the mechanisms are not specific to MPLS VPNs.

   This requires the following from I2RS protocol (client-agent)

   o  VCoD/VNoD-REQ01: I2RS Agents SHOULD provide the ability to read
      the virtual network topology database for the technology
      supported.  For optical, these are the optical connections and



Hares & Chen             Expires January 5, 2015                [Page 9]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


      what node they connect to, and the topologies created.  For MPLS,
      this is virtual circuit available, what nodes they connect to, and
      the network topologies created.  For IP technologies, this could
      include the GRE tunnels, what interface it connects to, and the
      topologies created.  For Ethernet circuits this should involve
      circuit type (e.g, point-to-point (p2p) or point-to-multipoint
      (p2mp)) and what nodes it can reach, and the topologies created.

   o  VCoD/VNoD-REQ02: I2RS Agent SHOULD provide the ability to
      influence the configuration of a virtual circuit in a node.

   o  VCoD/VnoD-REQ03: I2RS Agent SHOULD provide the ability to report
      statistics on the virtual connection to the I2RS client via read
      of status data or via notifications of status.  The I2RS client
      can then determine if the connection falls below a quality level
      the application has requested.  If the I2RS client does determine
      the circuit is below the required quality, it could create another
      circuit.  The I2RS may choose to create the second virtual
      circuit, transfer flows, and then break the first circuit.

   o  VNOD-REQ04: I2RS Agent SHOULD provide the ability to influence the
      configuration of a virtual network in a node.

   o  VNoD-REQ05: I2RS Agent SHOULD provide the ability to report
      statistics on the network nodes and end-to-end traffic flows via
      read of status data or via notifications of status.

5.  Automated On Demand Networks

   Automated On-Demand networks becomes a reasonable technology within a
   network by utilizing the I2RS architecture.  While automated on-
   demand circuit provisioning and de-provisioning is possible now, the
   effort to configure and reconfigure nodes to provide the Automatic
   On-Demand circuits can be difficult.  With I2RS, the I2RS client can
   instruct the I2RS Agents within a network to create On-Demand
   circuits and then remove the circuits returning the network to its
   configured state.  With I2RS enhanced monitoring capability, the
   monitoring needed for these state changes is incorporated within the
   I2RS framework.

   The current scope for these Automated On-Demand Circuits in the
   IETF's I2RS working group's charter is limited to hub-spoke networks
   and service routing.  This section discusses the progress on the I2RS
   against the use cases, and proposes additional additional Automated
   On-Demand Circuits.

   Current Status of the Automated On-Demand Functionality




Hares & Chen             Expires January 5, 2015               [Page 10]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   Both the hub-spoke network and service network may include a
   centralized control network element such as
   [I-D.ji-i2rs-usecases-ccne-service].  These centralized control
   network elements may use I2RS access to individual node's RIB
   information via the I2RS RIB Information Model (IM)
   ([I-D.ietf-i2rs-rib-info-model]), or obtain full network topology
   information from other protocols (BGP Route Reflector, PCE
   ([RFC4655]), or ALTO [I-D.bernstein-alto-topo]).  With the recent
   inclusion of IGP (OSPF and ISIS) link-state information into BGP TLVs
   via [I-D.ietf-idr-ls-distribution], all of these sources can provide
   centralized services that can provide topology maps at the AS and IGP
   level.

   I2RS Information Models (IM) are being proposed which can store:

   o  Network Topologies (IM) [I-D.medved-i2rs-topology-im], and

   o  Service Topologies IM) [I-D.hares-i2rs-info-model-service-topo].

   I2RS features Needed Future On-Demand Networks

   o  VNoD-REQ06: The I2RS protocol and RIB Informational Model (IM)
      MUST support logical tunnels of type MPLS as well as IP, GRE,
      VxLAN and GRE.  L Large Carrier networks utilize MPLS in a variety
      of forms (LDP, static MPLS TE, or dynamic TE LSPS created by RSVP-
      TE or CR-LDP).

   o  VNoD-REQ07: I2RS SHOULD support Informational Models and features
      to allow MPLS technologies to create Hub-spoke topology and
      service routing in networks in Carriers, Enterprise, and Data
      Centers.

   o  VNoD-REQ08: I2RS protocols, Information Models, and Data Models
      MUST be able to support Carriers using these MPLS technologies to
      support networks for Mobile BackHaul, on-demand MPLS overlays, and
      on-demand video conferencing networkings.

6.  What is Missing in RIB Informational Model (RIB IM)

   Based on these requirements, the following is needed in the RIB IM
   Model:

   o  VNoD-RIB_IM-REQ01: The RIB IM model
      ([I-D.ietf-i2rs-rib-info-model] provides with each route an
      associated nexthop-list 0-N members.  Each nexthop-list is flagged
      with a protection preference (1 or 2), and a Load balance weight
      (1 to 99).  If the host routes for all nodes in the topology exist




Hares & Chen             Expires January 5, 2015               [Page 11]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


      within the RIB IM model's instantiation, then the nexthop member
      on the nexthop-list SHOULD provide the following information:

      *  identifier for interface

      *  egress interface (logical, virtual, or physical)

      *  address of physical interface (IP address or MAC) plus RIB

      *  tunnel encapsulation for interface (IP GRE, MPLS tunnel),

      *  logical tunnel identifier

      *  RIB name (for look-up resolution)

      *  flags for specialized look-ups (Discard packets, discard with
         error notification, receive)

   o  VNoD-RIB_IM-REQ02: The RIB IM model's primitives SHOULD include
      circuit type (p2p, mp2mp), optical connection information, and
      additional statistics per virtual circuit.

   o  VNoD_RIB_IM-REQ03:The RIB IM model's instantiation within the
      protocol must provide an easy way to specify queries for this
      information.

7.  IANA Considerations

   This document includes no request to IANA.

8.  Security Considerations

   This document has no security issues as it just contains use cases.

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.

9.2.  Informative References

   [I-D.bernstein-alto-topo]
              Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology
              Service: Uses Cases, Requirements, and Framework", draft-
              bernstein-alto-topo-00 (work in progress), October 2013.




Hares & Chen             Expires January 5, 2015               [Page 12]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   [I-D.hares-i2rs-info-model-service-topo]
              Hares, S., Wu, W., and X. Guan, "An Information model for
              service topology", draft-hares-i2rs-info-model-service-
              topo-00 (work in progress), February 2014.

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

   [I-D.ietf-i2rs-problem-statement]
              Atlas, A., Nadeau, T., and D. Ward, "Interface to the
              Routing System Problem Statement", draft-ietf-i2rs-
              problem-statement-04 (work in progress), June 2014.

   [I-D.ietf-i2rs-rib-info-model]
              Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
              Information Base Info Model", draft-ietf-i2rs-rib-info-
              model-03 (work in progress), May 2014.

   [I-D.ietf-idr-ls-distribution]
              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
              Ray, "North-Bound Distribution of Link-State and TE
              Information using BGP", draft-ietf-idr-ls-distribution-05
              (work in progress), May 2014.

   [I-D.ji-i2rs-usecases-ccne-service]
              Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use
              Cases for Control of Forwarding Path by Central Control
              Network Element (CCNE)", draft-ji-i2rs-usecases-ccne-
              service-01 (work in progress), February 2014.

   [I-D.medved-i2rs-topology-im]
              Medved, J., Bahadur, N., Clemm, A., and H.
              Ananthakrishnan, "An Information Model for Network
              Topologies", draft-medved-i2rs-topology-im-01 (work in
              progress), October 2013.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

Authors' Addresses








Hares & Chen             Expires January 5, 2015               [Page 13]


Internet-Draft          I2RS Use Cases VCoD VNoD               July 2014


   Susan Hares
   Huawei Technologies
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com


   Mach Chen
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: mach.chen@huawei.com



































Hares & Chen             Expires January 5, 2015               [Page 14]