<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-kumar-requirements-and-framework-00" ipr="trust200902">
 <front>
   <title abbrev="Centralized Address Space Management"> Centralized Address Space Management(CASM) Requirements and Framework</title>
   <author fullname="Rakesh Kumar" initials="R." surname="Kumar">
       <organization>Juniper Networks</organization>
       <address>
           <postal>
               <street>1133 Innovation Way</street>
               <city>Sunnyvale</city>
               <region>CA</region>
               <country>US</country>
               <code>94089</code>
           </postal>
           <email>rkkumar@juniper.net</email>
       </address>
   </author>

   <author fullname="Anil Lohiya" initials="A." surname="Lohiya">
       <organization>Juniper Networks</organization>
    
        <address>
            <postal>
                <street>1133 Innovation Way</street>
                <city>Sunnyvale</city>
                <region>CA</region>
                <country>US</country>
                <code>94089</code>
            </postal>
            <email>alohiya@juniper.net</email>
        </address>
   </author>

   <author fullname="Marc Blanchet" initials="M." surname="Blanchet">
       <organization>Viagenie</organization>
       <address>
           <postal>
               <street>246 Aberdeen</street>
               <city>Quebec</city>
               <region>QC</region>
               <code>G1R 2E1</code>
               <country>Canada</country>
           </postal>
           <email>marc.blanchet@viagenie.ca</email>
           <uri>http://viagenie.ca</uri>
       </address>
   </author>

   <date year="2017" />

   <area>Operations</area>

   <workgroup>Internet Engineering Task Force</workgroup>

   <keyword>IPAM,SDN</keyword>

   <abstract>
       <t>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.</t>
   </abstract>
 </front>

 <middle>
 <section title="Introduction">
     <t>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. </t>
     
     <t>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.</t>
    
     <t>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.</t>
 </section>

 <section title="Requirements Language">
     <t>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 <xref
     target="RFC2119">RFC 2119</xref>.</t>
 </section>
 
 <section title="Terminology">
     <t><list style="hanging">
         <t hangText="CASM: ">Centralized Address Space Management</t>

         <t hangText="IPAM: ">IP Address Management</t>
     </list></t>
 </section>
 
 <section title="Requirements from CASM system">
     <t>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.</t>
     
     <t>This sections identifies the major set of requirements for defining CASM system. </t>
     
     <section title="General operational requirements">
         <t>Some requirements are not specific to any particular functiolaity of CASM but applicable
         to all aspects of CASM system. </t>
         <t><list>
             <t>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. </t>
             
             <t>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. </t>
             
             <t>Audit Logging: All CASM actvities must be logged for auditing or debugging purposes.
             The system must provide an interface to access these records. </t>
             
             <t>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.</t>
         </list> </t>
     </section>
     
     <section title="Interafce modeling requirements">
        <t>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. </t>

        <t>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. </t>
        <t><list>
             <t>Fucntional attributes such as switch, router, firewall, server, end-point</t>
             <t>Form-factoral attributes such as physical, virtual</t>
             <t>Opertional attributes such as management plane, control plane, data plane</t>
             <t>Network segment identifier, such as VLAN, VxLAN or other user-defined value</t>
             <t>Network segment type such as point-to-point, multi-point, loopback</t>
             <t>Addressing scope attributes such as private, public, vpn, unicast, multicast</t>
             <t>Extensible user-defined attributes</t>
         </list> </t>
     </section>

     <section title="Functional requirements">
         
         <t>The CASM should support following functionality for it to be adopted for wide varierty of
         use cases. </t>

         <section title="Address pools">
             <t>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. </t>
             
             <t><list>
                 <t>Unicast address pool: <list>
                     <t>Private IPv4 addresses</t>
                     <t>Public IPv4 addresses</t>
                     <t>IPv6 addresses</t>
                     <t>MAC Addresses</t>
                 </list> </t>

                <t>Mulicast address pool: <list>
                     <t>IPv4 address</t>
                     <t>IPv6 address</t>
                </list> </t>
             </list> </t>
         </section>
         
         <section title="Pool management">
             <t>There should be a rich set of functionality as defined in this section for operation
                 of a given pool. </t>
             
             <t><list>
                 <t>Address management: <list>
                     <t>Address allocation either as single or block</t>
                     <t>Address reservation</t>
                     <t>Allocation logic such as mapping schemes or algorithm per pool</t>
                 </list> </t>
                 
                 <t>General management: <list>
                     <t>Pool initializing, resizing, threshold markings for resource monitoring</t>
                     <t>Pool attributes such as used to automatcally create DNS record</t>
                     <t>Pool priority for searching across different pools</t>
                     <t>Pool fragmenetation rules, such as how pool can be sub-divided</t>
                     <t>Pool lease rules for alloation requests</t>
                 </list> </t>
             </list> </t>
         </section>

         <section title="Integration with other address services">
             <t>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.</t>
    
             <t><list>
                 <t>DHCP server: <list>
                     <t>Interface to initialize address pools on DHCP server</t>
                     <t>Notification interface whenever an address lease is modified</t>
                     <t>Interface to access address lease records from DHCP server</t>
                     <t>Ability to store lease records and play back to DHCP server on reboot</t>
                 </list> </t>
        
                 <t>DNS server: <list>
                     <t>Interface to create DNS records on DNS server based on DHCP server events</t>
                 </list> </t>
                 
                 <t>NAT device: <list>
                     <t>Interface to initialize NAT pools</t>
                     <t>Interface to access NAT records from NAT device</t>
                     <t>Ability to store NAT records and play back to NAT device on reboot</t>
                 </list> </t>
             </list> </t>
         </section>
     </section>
 </section>

 <section title="Archiectural framework">
     <t>Based on the requirements specifed in this document, we propose the following high-level
     architecture for building CASM. </t>
     
     <t>There are three broad categories for CASM interface defintion: </t>
     
     <t><list>
         <t>Pool management interface: Interface to external user or applications such as SDN controller
         to manage addresses </t>
         <t>Log interface: Interface to access log and records such as DHCP, DNS, NAT</t>
         <t>Integration interface: Interface to address services such as DHCP, DNS, NAT</t>
     </list> </t>
     
     <t>The propsed CASM framework is shown in <xref
    target="CASM"/>. <figure anchor="CASM"
         title="CASM Architecture">
         <artwork>

        +----------------+ +------+ +----+ +-----+ +-----------------------+
        |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----+    +-v---+  +----v-----+   +---v----+
        +--------+|   +-----+| +----------+|  +--------+|
        | DNS    ||   |NAT  || |  Address ||  | DHCP   ||
        | Servers||   |     || |  Mapping ||  | Servers||
        |        |+   |     |+ |  Systems |+  |        |+
        +--------+    +-----+  +----------+   +--------+

         </artwork>
     </figure></t>
 </section>
 
 <section anchor="Acknowledgements" title="Acknowledgements">
     <t>This document started from a slide deck authored by Rakesh Kumar and Anil Lohiya.</t>
 </section>
 
 <section anchor="IANA" title="IANA Considerations">
     <t>This memo includes no request to IANA.</t>
 </section>

 <section anchor="Security" title="Security Considerations">
     <t>TBD</t>
  </section>
</middle>

 <back>
   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->

     &RFC2119;

   </references>

 </back>
</rfc>
