< draft-chen-ospf-ttz-req-00.txt		draft-chen-ospf-ttz-req-01.txt >
	Internet Engineering Task Force H. Chen		Internet Engineering Task Force H. Chen
	Internet-Draft R. Li		Internet-Draft R. Li
	Intended status: Informational Huawei Technologies		Intended status: Informational Huawei Technologies
	Expires: April 24, 2014 G. Cauchie		Expires: January 5, 2015 G. Cauchie
	N. So		N. So
	Tata Communications		Tata Communications
	V. Liu		V. Liu
	China Mobile		China Mobile
	M. Toy		M. Toy
	Comcast		Comcast
	L. Liu		L. Liu
	UC Davis		UC Davis
	October 21, 2013		July 4, 2014
	Requirements for OSPF Topology-Transparent Zone		Requirements for OSPF Topology-Transparent Zone
	draft-chen-ospf-ttz-req-00.txt		draft-chen-ospf-ttz-req-01.txt
	Abstract		Abstract
	This document presents a list of requirements for OSPF topology-		This document presents a list of requirements for OSPF topology-
	transparent zone in a domain. A topology-transparent zone comprises		transparent zone in a domain. A topology-transparent zone comprises
	a group of routers and a number of links connecting these routers.		a group of routers and a number of links connecting these routers.
	Any router outside of the zone is not aware of the zone. The		Any router outside of the zone is not aware of the zone. The
	information about the links and routers inside the zone is not		information about the links and routers inside the zone is not
	distributed to any router outside of the zone. Any link state change		distributed to any router outside of the zone. Any link state change
	such as a link down inside the zone is not seen by any router outside		such as a link down inside the zone is not seen by any router outside
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on April 24, 2014.		This Internet-Draft will expire on January 5, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	The number of routers in a network becomes larger and larger as the		The number of routers in a network becomes larger and larger as the
	Internet traffic keeps growing. Through splitting the network into		Internet traffic keeps growing. Through splitting the network into
	multiple areas, we can extend the network further. However, there		multiple areas, we can extend the network further. However, there
	are a number of issues when a network is split further into more		are a number of issues when a network is split further into more
	areas.		areas.
	At first, dividing an AS or an area into multiple areas is a very		At first, dividing an AS or an area into multiple areas is a very
	challenging task since it is involved in significant network		challenging task since it is involved in significant network
	architecture changes.		architecture changes.
	Secondly, it is complex for a Multi-Protocol Label Switching (MPLS)		Secondly, the services carried by the network may be interrupted
			while the network is being split from one area into multiple areas or
			from a number of existing areas into even more areas.
			Moreover, it is complex for a Multi-Protocol Label Switching (MPLS)
	Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple		Traffic Engineering (TE) Label Switching Path (LSP) crossing multiple
	areas to be setup. In one option, a TE path crossing multiple areas		areas to be setup. In one option, a TE path crossing multiple areas
	is computed by using collaborating Path Computation Elements (PCEs)		is computed by using collaborating Path Computation Elements (PCEs)
	[RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440],		[RFC5441] through the PCE Communication Protocol (PCEP)[RFC5440],
	which is not easy to configure by operators since the manual		which is not easy to configure by operators since the manual
	configuration of the sequence of domains is required. Although this		configuration of the sequence of domains is required. Although this
	issue can be addressed by using the Hierarchical PCE, this solution		issue can be addressed by using the Hierarchical PCE, this solution
	may further increase the complexity of network design. Especially,		may further increase the complexity of network design. Especially,
	the current PCE standard method may not guarantee that the path found		the current PCE standard method may not guarantee that the path found
	is optimal.		is optimal.
	Furthermore, some policies need to be configured on area border
	routers for reducing the number of link states such as summary Link-
	State Advertisements (LSAs) to be distributed to other routers in
	other areas.
	OSPF topology-transparent zone may resolve the issues above.		OSPF topology-transparent zone may resolve the issues above.
	A topology-transparent zone comprises a group of routers and a number		A topology-transparent zone comprises a group of routers and a number
	of links connecting these routers. Any router outside of the zone is		of links connecting these routers. Any router outside of the zone is
	not aware of the zone. The information about the links and routers		not aware of the zone. The information about the links and routers
	inside the zone is not distributed to any router outside of the zone.		inside the zone is not distributed to any router outside of the zone.
	Any link state change such as a link down inside the zone is not seen		Any link state change such as a link down inside the zone is not seen
	by any router outside of the zone.		by any router outside of the zone.
	This document presents requirements for OSPF topology-transparent		This document presents requirements for OSPF topology-transparent
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 16 ¶
	Topology-Transparent Zone (TTZ) may be deployed for resolving some		Topology-Transparent Zone (TTZ) may be deployed for resolving some
	critical issues in existing networks and future networks. The		critical issues in existing networks and future networks. The
	requirements for TTZ are listed as follows:		requirements for TTZ are listed as follows:
	o TTZ MUST be backward compatible. When a TTZ is deployed on a set		o TTZ MUST be backward compatible. When a TTZ is deployed on a set
	of routers in a network, the routers outside of the TTZ in the		of routers in a network, the routers outside of the TTZ in the
	network do not need to know or support TTZ.		network do not need to know or support TTZ.
	o A group of nodes in an existing network SHOULD be able to migrate		o A group of nodes in an existing network SHOULD be able to migrate
	to a TTZ smoothly after the configuration of TTZ on these nodes is		to a TTZ smoothly.
	activated.
	o All the nodes in an existing TTZ SHOULD be able to migrate back to		o All the nodes in an existing TTZ SHOULD be able to roll back to
	their OSPF area smoothly after the configuration of TTZ on these		their OSPF area smoothly.
	nodes is deleted.
	o TTZ MUST support at least one more levels of network hierarchies,		o TTZ MUST support at least one more levels of network hierarchies,
	in addition to the hierarchies supported by existing routing		in addition to the hierarchies supported by existing routing
	protocols.		protocols.
	o Users SHOULD be able to easily set up an end to end service		o Users SHOULD be able to easily set up an end to end service
	crossing TTZs.		crossing TTZs.
	o The protections on the service crossing TTZs SHOULD be transparent		o The protections on the service crossing TTZs SHOULD be transparent
	to TTZ.		to TTZ.
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	FRANCE		FRANCE
	Email: greg.cauchie@gmail.com		Email: greg.cauchie@gmail.com
	Ning So		Ning So
	Tata Communications		Tata Communications
	2613 Fairbourne Cir.		2613 Fairbourne Cir.
	Plano, TX 75082		Plano, TX 75082
	USA		USA
	Email: ning.so@tatacommunications.com		Email: ningso01@gmail.com
	Vic Liu		Vic Liu
	China Mobile		China Mobile
	No.32 Xuanwumen West Street, Xicheng District		No.32 Xuanwumen West Street, Xicheng District
	Beijing, 100053		Beijing, 100053
	China		China
	Email: liuzhiheng@chinamobile.com		Email: liuzhiheng@chinamobile.com
	Mehmet Toy		Mehmet Toy
End of changes. 10 change blocks.
	17 lines changed or deleted		14 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/