Internet DRAFT - draft-kumar-casm-problem-and-use-cases
draft-kumar-casm-problem-and-use-cases
Internet Engineering Task Force R. Kumar
Internet-Draft A. Lohiya
Intended status: Informational Juniper Networks
Expires: August 2, 2017 M. Blanchet
Viagenie
January 29, 2017
Centralized Address Space Management(CASM) Problems and Use cases
draft-kumar-casm-problem-and-use-cases-00
Abstract
The organisations 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 2, 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 2, 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 . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Address Space Management Use cases . . . . . . . . . . . . . 3
4.1. DHCP server pool . . . . . . . . . . . . . . . . . . . . 3
4.2. Static address configuration . . . . . . . . . . . . . . 3
4.3. Public IP address pool . . . . . . . . . . . . . . . . . 4
4.4. Multicast IP address pool . . . . . . . . . . . . . . . . 4
4.5. SDN controllers . . . . . . . . . . . . . . . . . . . . . 4
5. Legacy address space management (IPAM) systems . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Informative References . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The address space management is an intergral part of any network
management solution. The network may be based on legacy design or a
more modern private and public cloud, the network may be big or small
but every network operator need to manage the addressing needs of
network elements. Typically, network operators write proprietary
scripts or use cheat sheets to manage the addressing requirements.
In recent trends, open source communities have developed tools to
manage available IP addreess space.
The open source or proprietray tools and scripts are collectively
known as Internet Protocol Address Management (IPAM) system. The
organizations use IPAM system to manage their IP address space, often
with proprietary database and interfaces. One of the biggest
challenges with IPAM systems, is lack of standardized interface for
allocation, storing and retrieving information.
This document describes a diverse set of use cases for a IPAM system
and the probelms identfied with current IPAM approach. The problems
identifed here should become the basis for a new vision defined as
Centralized Address Space Management (CSAM).
Kumar, et al. Expires August 2, 2017 [Page 2]
Internet-Draft Centralized Address Space Management January 2017
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].
3. Terminology
CASM: Centralized Address Space Management
IPAM: IP Address Management
4. Address Space Management Use cases
The address space management is an intergral part of any network
management solution. Every device in the network be it a physical or
virtual, needs an IP address for communication with other devices in
the network. There is an absolute requirement that a network
operator must find a way to assign address to these devices.
The address management could be as simple as having one address pool
from where addresses are allocated or may a much more complex scheme
based on various requirements and nature of the network. This
section is going to identfiy few top uses cases of address
management.
4.1. DHCP server pool
One of the most common method to assign an IP address to a device or
function is DHCP. A device may request one or more IP addresses.
The DHCP server on network handles all the DHCP requests and assign
IP addresses. These addresses are allocated from a pre-defined
address pool.
A DHCP server might need multiple address pools if it manages DHCP
request on multiple network segments. An address management system
may be used to initialize these address pools on DHCP servers or
could also be configured statically. But the static assigment is
prone to misconfiguration and if the DHCP server is ever replaced,
the new server must be configured with the same old pool.
4.2. Static address configuration
Some devices or functions do not rely on DHCP protocols to obtain an
IP address. This could be due to lack of DHCP client functionality
or lack of DHCP server avaialable in the network segement for
whatever reason. In such situations, an IP address may be configured
statically but static IP address assignment is prone to errors as
Kumar, et al. Expires August 2, 2017 [Page 3]
Internet-Draft Centralized Address Space Management January 2017
mentioned earlier. The better way is to use an address management
system for configuring devices without DHCP support.
4.3. Public IP address pool
The public IPv4 addresses are very precious resources and should be
used very carefully. A given organization may have a small number of
these addresses, so it must find a way to allocate and free these
resources effectively. The manual configuration mechanism may not be
the best way to manage this resource.
4.4. Multicast IP address pool
The multicast addresses are used for distributing broadcast contents.
The multicast content distributor must be assigned an address and the
content consumer must somehow figure out that address. This is
usually configured manually or throgh proprietary mechanisms.
4.5. SDN controllers
In order to build private or public clouds, address management of
virtual machines, virtual functions and overlay networks is a very
important task. In addition, the network operator also need to
manage addressing of undelay network elements. The SDN controllers
and underlay management systems must coordinate addressing schemes to
ensure smooth operation. There is need for one address management
system that would meet the requirements of such a network deployment.
In order to create overlay networks and virtual workloads, the SDN
controller also manage MAC addresses to assign to virtual network
interfaces. But this is typically not handled by IPAM systems.
5. Legacy address space management (IPAM) systems
As mentioned earlier, address management is a central component of
every network management system. Organizations small or large deploy
different ways of achieving this; some write their own scripts or use
cheat sheets, and others use open source tools.
These systems may not be suitable for all kind of uses cases due to
lack of functionality and moreover the interfaces to these systems
are closed which makes migration from one system to other difficult.
Although, the functionality of IPAM systems vary from vendor to
vendor but in general as a whole, following drawbacks exists:
o Lack of common set of standard interfaces across IPAM system
vendors
Kumar, et al. Expires August 2, 2017 [Page 4]
Internet-Draft Centralized Address Space Management January 2017
o Address usually allocated with very little or no context
o Lacks ability to annotate requests with user-defined attributes as
private or public address
o Lacks capability to manage both unicast and multicast addresses
o MAC address and network segment (VLAN) does not given enough
information about user or usages
o Lack of built-in multi-tetancy into interfaces
o Lack of information about address requester such as virtual or
physical device
o Lack of integration with name services such as DNS
o Lack of integration with DHCP server to get address records
o Lack of integration with address translation services such as
NAT44 and NAT64
The purpose is not to show a laudry list of deficiencies in the
available IPAM system but to show a need to develop a new system that
can meet the address allocation requirements of modern network
architectures that gives consumers a portable way to use these
systems.
6. Acknowledgements
This document started from a slide deck authored by Rakesh Kumar and
Anil Lohiya.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
TBD
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>.
Kumar, et al. Expires August 2, 2017 [Page 5]
Internet-Draft Centralized Address Space Management January 2017
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 2, 2017 [Page 6]