< draft-xie-ps-centralized-address-management-01.txt		draft-xie-ps-centralized-address-management-02.txt >
	Internet Working Group C. Xie		Internet Working Group C. Xie
	Internet Draft Q. Sun		Internet Draft Q. Sun
	Intended status: Informational China Telecom		Intended status: Informational China Telecom
	Expires: January 2017 W. Xu		Expires: September 2017 W. Xu
	W. Liu		W. Liu
	Huawei		Huawei
	I. Farrer		I. Farrer
	N. Kowalewski		N. Kowalewski
	Deutsche Telekom AG		Deutsche Telekom AG
	July 8, 2016		Y. Cheng
			China Unicom
			March 12, 2017
	Problem statement for centralized address management		Problem statement for centralized address management
	draft-xie-ps-centralized-address-management-01		draft-xie-ps-centralized-address-management-02
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 38 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on January 8, 2017.		This Internet-Draft will expire on September 11, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	1. Introduction		1. Introduction
	The increase in number, diversity and complexity of modern network		The increase in number, diversity and complexity of modern network
	devices and services bring new challenges for the management of		devices and services bring new challenges for the management of
	network resources, such as IP addresses, bandwidth, and services that		network resources, such as IP addresses, bandwidth, and services that
	utilize such resources. However, current approaches for address management		utilize such resources. However, current approaches for address management
	often result in sub-optimal allocation efficiency and significant		often result in sub-optimal allocation efficiency and significant
	complexity for using, sharing and sharing such resources.		complexity for using, sharing and sharing such resources.
	Address resources are often managed across multiple, partly disconnected		Address resources are often managed across multiple, partly disconnected
	technical systems which have limited means of model based interoperation.		technical systems which have limited means of model based inter-operation.
	In the interest of reducing complexity, improve utilization of resources		In the interest of reducing complexity, improve utilization of resources
	and reduce overall associated OPEX and CAPEX, operators are looking for		and reduce overall associated OPEX and CAPEX, operators are looking for
	an intelligent, agile and flexible integrated approach to control and		an intelligent, agile and flexible integrated approach to control and
	manage IP address resources. Assignment of such resources should be		manage IP address resources. Assignment of such resources should be
	possible across many services, and offer means of categorizing, selecting		possible across many services, and offer means of categorizing, selecting
	and decision making on the assignment and revocation of address resources.		and decision making on the assignment and revocation of address resources.
	?		?
	Among the resources aforementioned, the relevance of address management		Among the resources aforementioned, the relevance of address management
	gained traction by operators as it is a fundamental precursor for the		gained traction by operators as it is a fundamental precursor for the
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	then compute and configure an optimized forwarding path between them.		then compute and configure an optimized forwarding path between them.
	In the examples above, the address allocation policy, e.g., specific		In the examples above, the address allocation policy, e.g., specific
	IP address assigned to a specific VM, usually originates from a		IP address assigned to a specific VM, usually originates from a
	management system, e.g, OSS, OpenStack, SDN controller, DHCP server		management system, e.g, OSS, OpenStack, SDN controller, DHCP server
	instance. Many such systems are configured rather statically, via CLI		instance. Many such systems are configured rather statically, via CLI
	or per configuration file.		or per configuration file.
	This approach poses the following problems for operators:		This approach poses the following problems for operators:
	o Low allocation efficiency due to pre-allocation		o Low allocation efficiency due to pre-allocation
	o Manual configuration of address policy, with risk for consistancy in		o Manual configuration of address policy, with risk for consistency in
	applying policy		applying policy
	o Complexity in making real-time changes to assignment		o Complexity in making real-time changes to assignment
	o Lack of an open, programmable interface between systems which		o Lack of an open, programmable interface between systems which
	requires IP addresses and the Management Systems handling the		requires IP addresses and the Management Systems handling the
	respective IP address resources		respective IP address resources
	Address pool management is a sub-issue of address management.		Address pool management is a sub-issue of address management.
	Currently, operators are facing the following issues:		Currently, operators are facing the following issues:
	?		?
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 33 ¶
	2. Conventions used in this document		2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Terminology		3. Terminology
	IPAM: IP address management		IPAM: IP address management
	I2AM: Interface to address management
	I2APM: Interface to address pool management
	4. Problems and Use Cases		4. Problems and Use Cases
	The BNG, which manages one of more routable IP addresses on behalf of		The BNG, which manages one of more routable IP addresses on behalf of
	each subscriber, should be configured with the IP address pools allocated		each subscriber, should be configured with the IP address pools allocated
	to subscribers. However, operators are increasingly challenged by the IPv4		to subscribers. However, operators are increasingly challenged by the IPv4
	address shortage and IPv4 address pools are scattered into many blocks as		address shortage and IPv4 address pools are scattered into many blocks as
	small as an IPv4/24 per in many cases. In the worst case configuration		small as an IPv4/24 per in many cases. In the worst case configuration
	of such address pools on a large number of Broadband Network Gateway (BNG)		of such address pools on a large number of Broadband Network Gateway (BNG)
	has to be done manually by for operators and is labor intensive. For large		has to be done manually by for operators and is labor intensive. For large
	scale MAN, there can a three digit number of BNGs to configure.		scale MAN, there can a three digit number of BNGs to configure.
	skipping to change at page 5, line 10 ¶		skipping to change at page 5, line 10 ¶
	small as an IPv4/24 per in many cases. In the worst case configuration		small as an IPv4/24 per in many cases. In the worst case configuration
	of such address pools on a large number of Broadband Network Gateway (BNG)		of such address pools on a large number of Broadband Network Gateway (BNG)
	has to be done manually by for operators and is labor intensive. For large		has to be done manually by for operators and is labor intensive. For large
	scale MAN, there can a three digit number of BNGs to configure.		scale MAN, there can a three digit number of BNGs to configure.
	?		?
	Usual approaches of manual configuration on BNGs with such data in a static		Usual approaches of manual configuration on BNGs with such data in a static
	way will not only create great workload, it also limits utilization efficiency		way will not only create great workload, it also limits utilization efficiency
	of the address pools when the number of subscribers varies or shrinks at a given BNG		of the address pools when the number of subscribers varies or shrinks at a given BNG
	instance.		instance.
	With NFV technology maturing, it can be envisioned that the edge of the IP network		With NFV technology maturing, it can be envisioned that the edge of the IP network
	will become a software-based virtualized vBNG entity itself, so the network element		will become a software-based virtualized vBNG entity itself, so the network element
	itself is dynamically created and changed. Such virtualized network elements are going		itself is dynamically created and changed. Such virtualized network elements are going
	to become more common and may be launched and withdrawn dynamically, based on actual		to become more common and may be launched and withdrawn dynamically, based on actual
	traffic and user load, and an efficient dynamic assignments and re-use of address		traffic and user load, and an efficient dynamic assignments and re-use of address
	resources will be much more necessary than with a classical hardware-based entities		resources will be much more necessary than with a classical hardware-based entities.
	+---------------+		+---------------+
	| Address |		| Address |
	| Management |		| Management |
	| Server |		| Server |
	+---------------+		+---------------+
	| | |		| | |
	| | |		| | |
	| | | Configuration:		| | | Configuration:
	| | | IPv6 address pools		| | | IPv6 address pools
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	+--------+ ``'--'`` `''-''``		+--------+ ``'--'`` `''-''``
	Figure 1 Address pools configuration on the BNGs		Figure 1 Address pools configuration on the BNGs
	Figure 1 illustrates address pool configuration for BNGs. Each BNG		Figure 1 illustrates address pool configuration for BNGs. Each BNG
	requires configuration with several IPv4 and IPv6 address pools used		requires configuration with several IPv4 and IPv6 address pools used
	?		?
	for allocation to subscribers. Those address pools are configured		for allocation to subscribers. Those address pools are configured
	through an API from a centralized Address Management Server. Typical		through an API from a centralized Address Management Server. Typical
	examples include IPv4 and IPv6 address pool configuration.		examples include IPv4 and IPv6 address pool configuration. The
			centralized management approach is very crucial for dynamically
			service creation that concerned Virtual BNGs
	The second use case for address pool configuration is for IPv6		The second use case for address pool configuration is for IPv6
	migration. IPv6 transition mechanisms (e.g. DS-Lite, lw4over6, etc.),		migration. IPv6 transition mechanisms (e.g. DS-Lite, lw4over6, etc.),
	need to be configured with address pools to be used as translated		need to be configured with address pools to be used as translated
	routable addresses. When high availability features, e.g. active-		routable addresses. When high availability features, e.g. active-
	active/active-standby failover mechanism, are used, different address		active/active-standby failover mechanism, are used, different address
	pools may need to be configured on each transition instance. This		pools may need to be configured on each transition instance. This
	will further increase the number of address pools that need to be		will further increase the number of address pools that need to be
	configured.		configured.
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 28 ¶
	The Management System(SDN controller) get the IP address of the two		The Management System(SDN controller) get the IP address of the two
	inter-communication hosts from address management system through an		inter-communication hosts from address management system through an
	open, programmable interface, then the SDN controller could design an		open, programmable interface, then the SDN controller could design an
	optimized forwarding path, and deploy it into forwarding plane.		optimized forwarding path, and deploy it into forwarding plane.
	Another common model is that the MNS/OSS and IPAM perform address management		Another common model is that the MNS/OSS and IPAM perform address management
	on different levels of granularity. The overall authoritative ownership of		on different levels of granularity. The overall authoritative ownership of
	all address resources lies with the IPAM, and the resources available in		all address resources lies with the IPAM, and the resources available in
	there are subject to a formally regulated assignment process (e.g. ARIN, RIPE,		there are subject to a formally regulated assignment process (e.g. ARIN, RIPE,
	etc.). From IPAM, blocks of addresses can be requested according to inherently		etc.). From IPAM, blocks of addresses can be requested according to inherently
	defined IP Address assignment policy. Requests are made by or on behalf of IP address		defined IP Address assignment policy. Requests are made by or on behalf of IP
	consuming entities, typically by provisioning intermediaries like MNS, OSS.		address consuming entities, typically by provisioning intermediaries like MNS,
	These systems may further break down the resource according to application specific		OSS. These systems may further break down the resource according to application
	substructures (e.g. DNS, DHCPv4, DHCPv6, OpenStack, ...) and sub-delegate them as needed.		specific substructures (e.g. DNS, DHCPv4, DHCPv6, OpenStack, ...) and sub-delegate
			them as needed.
	+---------------+ IP resource +----------------+		+---------------+ IP resource +----------------+
	| | Request | |		| | Request | |
	| IPAM + <-----------------+ Management |		| IPAM + <-----------------+ Management |
	| - Resources | | System |		| - Resources | | System |
	| - Policies +-----------------> + e.g. OSS, NMS |		| - Policies +-----------------> + e.g. OSS, NMS |
	| | Configuration: | |		| | Configuration: | |
	+---------------+ IP address object +-------/-------+		+---------------+ IP address object +-------/-------+
	| Configuration:		| Configuration:
	| IP address object		| IP address object
	skipping to change at page 9, line 35 ¶		skipping to change at page 9, line 35 ¶
	9.2. Informative References		9.2. Informative References
	[WIKI] https://en.wikipedia.org/wiki/IP_address_management		[WIKI] https://en.wikipedia.org/wiki/IP_address_management
	10. Acknowledgments		10. Acknowledgments
	The authors of this draft would like to thank the following persons		The authors of this draft would like to thank the following persons
	for the provided valuable feedback and contributions: Benoit Claise,		for the provided valuable feedback and contributions: Benoit Claise,
	Marc Blancet, Yu Fu, John Strassner, Jun Bi, Diego Lopez, Zhiheng Liu,		Marc Blancet, Yu Fu, John Strassner, Jun Bi, Diego Lopez, Zhiheng Liu,
	Laurent Ciavaglia, Fred Baker, Joel Jaeggli.		Laurent Ciavaglia, Fred Baker, Joel Jaeggli, Will Liu, Giuseppe Fioccola.
	Authors' Addresses		Authors' Addresses
	Chongfeng Xie		Chongfeng Xie
	China Telecom Beijing Research Institute		China Telecom Beijing Research Institute
	China Telecom Beijing Information Science&Technology Innovation Park		China Telecom Beijing Information Science&Technology Innovation Park
	Beiqijia Town Changping District Beijing 102209 China		Beiqijia Town Changping District Beijing 102209 China
	Email: xiechf@ctbri.com.cn		Email: xiechf.bri@chinatelecom.cn
	?		?
	Qiong Sun		Qiong Sun
	China Telecom Beijing Research Institute		China Telecom Beijing Research Institute
	China Telecom Beijing Information Science&Technology Innovation Park		China Telecom Beijing Information Science&Technology Innovation Park
	Beiqijia Town Changping District Beijing 102209 China		Beiqijia Town Changping District Beijing 102209 China
	Email: sunqiong@ctbri.com.cn		Email: sunqiong@ctbri.com.cn
	Weiping Xu		Weiping Xu
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	skipping to change at line 495 ¶		skipping to change at page 10, line 37 ¶
	Bonn, NRW 53227		Bonn, NRW 53227
	Germany		Germany
	Email: ian.farrer@telekom.de		Email: ian.farrer@telekom.de
	Normen B. Kowalewski		Normen B. Kowalewski
	Deutsche Telekom AG		Deutsche Telekom AG
	CTO-ATI, Landgrabenweg 151		CTO-ATI, Landgrabenweg 151
	Bonn, NRW 53227		Bonn, NRW 53227
	Germany		Germany
	Email: normen.kowalewski@telekom.de		Email: normen.kowalewski@telekom.de
			Ying Cheng
			China Unicom
			No.21 Financial Street, XiCheng District
			Beijing 100033
			China
			Email: chengying10@chinaunicom.cn
End of changes. 14 change blocks.
	18 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/