Internet DRAFT - draft-kumar-casm-requirements-and-framework

draft-kumar-casm-requirements-and-framework







Internet Engineering Task Force                                 R. Kumar
Internet-Draft                                                 A. Lohiya
Intended status: Informational                          Juniper Networks
Expires: August 3, 2017                                      M. Blanchet
                                                                Viagenie
                                                        January 30, 2017


 Centralized Address Space Management(CASM) Requirements and Framework
             draft-kumar-casm-requirements-and-framework-00

Abstract

   The organizations use IP Address Space Management (IPAM) tools to
   manage their IP address space, often with proprietary database and
   interfaces.  This document describes evolution of IPAM into a
   standardized interfaces for centralized management of IP addresses.

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 August 3, 2017.

Copyright Notice

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




Kumar, et al.            Expires August 3, 2017                 [Page 1]

Internet-Draft    Centralized Address Space Management      January 2017


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Requirements from CASM system . . . . . . . . . . . . . . . .   3
     4.1.  General operational requirements  . . . . . . . . . . . .   3
     4.2.  Interafce modeling requirements . . . . . . . . . . . . .   3
     4.3.  Functional requirements . . . . . . . . . . . . . . . . .   4
       4.3.1.  Address pools . . . . . . . . . . . . . . . . . . . .   4
       4.3.2.  Pool management . . . . . . . . . . . . . . . . . . .   5
       4.3.3.  Integration with other address services . . . . . . .   5
   5.  Archiectural framework  . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The address space management is an intergral part of any network
   management solution.  The network architectures are rapidally
   changing with the migration toward private and public clouds.  At the
   same time, application architectures are also evolving with a shift
   toward micro-services and multi-tiered approach.

   There is a pressing need to define a new address management system
   which can meet these diverse set of requirements.  Such a system must
   be built with well defined interfaces so users can easily migrate
   from one vendor to another without rewriting their network management
   systems.

   This document identifies a broad set of requirements and defins a
   architectural framework that should become the basis to develop a new
   address management system.  We are calling this new system as
   Centralized Address Space Management (CSAM) system.

2.  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].





Kumar, et al.            Expires August 3, 2017                 [Page 2]

Internet-Draft    Centralized Address Space Management      January 2017


3.  Terminology

   CASM:   Centralized Address Space Management

   IPAM:   IP Address Management

4.  Requirements from CASM system

   In order to build CASM, there is a clear need to define a broad set
   of requirements that must be the basis for defining the architecture
   framework for CASM.  The requirements should be able to meet the
   various use-cases identified in the draft.

   This sections identifies the major set of requirements for defining
   CASM system.

4.1.  General operational requirements

   Some requirements are not specific to any particular functiolaity of
   CASM but applicable to all aspects of CASM system.

      Multi-tenancy: All interfaces exposed by CASM system must be
      multi-tenant capable.  This is highly desirable for cloud based
      network management solutions.  It may also be applicable for a
      service provider with different managed services use-case
      scenario.

      Autentication and Authorization: All interfaces exposed by CASM
      system must support an authentication scheme.  It also highly
      desriable to support operational restrictions on certain resources
      based on identity for security reasons.

      Audit Logging: All CASM actvities must be logged for auditing or
      debugging purposes.  The system must provide an interface to
      access these records.

      Error notification: All interfaces exposed by CASM system must
      support error handling and user-defined error notification
      mechanism suh as alert or email.  There may also be need to take
      corrective action for autonomus operation.

4.2.  Interafce modeling requirements

   The interface to external user must be meta-dat driven as much as
   possible to meet wider set of use-cases, e.g., instead of requesting
   an explicit IPv4 address, user should specify an adsress request
   based on its requirements.




Kumar, et al.            Expires August 3, 2017                 [Page 3]

Internet-Draft    Centralized Address Space Management      January 2017


   The following requirements should be considered for pool management
   interface defintion.  The attributes should be realted to the
   requestor which could a physical device, virtual machine, container
   or other entities present in a network.

      Fucntional attributes such as switch, router, firewall, server,
      end-point

      Form-factoral attributes such as physical, virtual

      Opertional attributes such as management plane, control plane,
      data plane

      Network segment identifier, such as VLAN, VxLAN or other user-
      defined value

      Network segment type such as point-to-point, multi-point, loopback

      Addressing scope attributes such as private, public, vpn, unicast,
      multicast

      Extensible user-defined attributes

4.3.  Functional requirements

   The CASM should support following functionality for it to be adopted
   for wide varierty of use cases.

4.3.1.  Address pools

   A CASM system should allow ability to manage different kind of
   address pools.  The following pools should be considered for
   implementation; this is not mandatory or exhaustive by any means but
   given here as most commonly used in networks.  The CASM system should
   allow user-defined pools with any address objects.

      Unicast address pool:

         Private IPv4 addresses

         Public IPv4 addresses

         IPv6 addresses

         MAC Addresses

      Mulicast address pool:




Kumar, et al.            Expires August 3, 2017                 [Page 4]

Internet-Draft    Centralized Address Space Management      January 2017


         IPv4 address

         IPv6 address

4.3.2.  Pool management

   There should be a rich set of functionality as defined in this
   section for operation of a given pool.

      Address management:

         Address allocation either as single or block

         Address reservation

         Allocation logic such as mapping schemes or algorithm per pool

      General management:

         Pool initializing, resizing, threshold markings for resource
         monitoring

         Pool attributes such as used to automatcally create DNS record

         Pool priority for searching across different pools

         Pool fragmenetation rules, such as how pool can be sub-divided

         Pool lease rules for alloation requests

4.3.3.  Integration with other address services

   In order to build a complete address management system, it is
   important that CASM should be able to integrate with other address
   services.  This will provide a complete solution to network operators
   without requiring any manual or proprietary workflows.

      DHCP server:

         Interface to initialize address pools on DHCP server

         Notification interface whenever an address lease is modified

         Interface to access address lease records from DHCP server

         Ability to store lease records and play back to DHCP server on
         reboot




Kumar, et al.            Expires August 3, 2017                 [Page 5]

Internet-Draft    Centralized Address Space Management      January 2017


      DNS server:

         Interface to create DNS records on DNS server based on DHCP
         server events

      NAT device:

         Interface to initialize NAT pools

         Interface to access NAT records from NAT device

         Ability to store NAT records and play back to NAT device on
         reboot

5.  Archiectural framework

   Based on the requirements specifed in this document, we propose the
   following high-level architecture for building CASM.

   There are three broad categories for CASM interface defintion:

      Pool management interface: Interface to external user or
      applications such as SDN controller to manage addresses

      Log interface: Interface to access log and records such as DHCP,
      DNS, NAT

      Integration interface: Interface to address services such as DHCP,
      DNS, NAT

   The propsed CASM framework is shown in Figure 1.




















Kumar, et al.            Expires August 3, 2017                 [Page 6]

Internet-Draft    Centralized Address Space Management      January 2017


        +----------------+ +------+ +----+ +-----+ +-----------------------+
        |Interface for   | |SDN/  | |OSS/| |ADMIN| |Interface for logs,    |
        |managing address| |Legacy| |BSS | |     | |DHCP, DNS, NAT, Address|
        |space and pools | |      | |    | |     | |allocation records     |
        +--------+-------+ +--+---+ +-+--+ +--+--+ +----------+------------+
                 |            |       |       |               ^
                 |            |       |       |               |
                 |            |       |       |               |
                 |            |       |       |               |
                 v            v       v       v               |
        +---+------------+-------+-------+---------------+------+
        |    Address Space Management (IPAM) System             |
        |      +-----------+ +----------+ +--------+            |
        |      | Pool      | |Address   | |Database|            |
        |      | Management| |Management| |        |            |
        |      +-----------+ +----------+ +--------+            |
        |                                                       |
        +-------------------------+-----------------------------+
                    |
        +-----------v------------+
        |Address Helper Plug|ins |
        +----+--+------+-----+---+
          |  |         |     |--------------------+
          |  +----+    |                          |
          |       |     ------------+             |
          v       +----|            |             |
        +--------+    +-----+  +----------+   +--------+
        | DNS    |    |NAT  |  |  Address |   | DHCP   |
        | Servers|    |     |  |  Mapping |   | Servers|
        |        |    |     |  |  Systems |   |        |
        +--------+    +-----+  +----------+   +--------+


                        Figure 1: CASM Architecture

6.  Acknowledgements

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   TBD







Kumar, et al.            Expires August 3, 2017                 [Page 7]

Internet-Draft    Centralized Address Space Management      January 2017


9.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Rakesh Kumar
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   US

   Email: rkkumar@juniper.net


   Anil Lohiya
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   US

   Email: alohiya@juniper.net


   Marc Blanchet
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada

   Email: marc.blanchet@viagenie.ca
   URI:   http://viagenie.ca
















Kumar, et al.            Expires August 3, 2017                 [Page 8]