< draft-xu-isis-flooding-reduction-in-msdc-00.txt		draft-xu-isis-flooding-reduction-in-msdc-01.txt >
	Network Working Group X. Xu		Network Working Group X. Xu
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track January 6, 2017		Intended status: Standards Track E. Auerswald
	Expires: July 10, 2017		Expires: November 3, 2017 fgn GmbH
			L. Fang
			ebay
			J. Tantsura
			Individual
			May 2, 2017
	IS-IS Flooding Reduction in MSDC		IS-IS Flooding Reduction in MSDC
	draft-xu-isis-flooding-reduction-in-msdc-00		draft-xu-isis-flooding-reduction-in-msdc-01
	Abstract		Abstract
	IS-IS is commonly used as a underlay routing protocol for MSDC		IS-IS is commonly used as an underlay routing protocol for MSDC
	(Massively Scalable Data Center) networks. This document proposes		(Massively Scalable Data Center) networks. For a given IS-IS router
	some extensions to IS-IS so as to reduce the IS-IS flooding within		within the CLOS topology, it would receive multiple copies of exactly
	MSDC networks greatly. The reduction of the IS-IS flooding is much		the same LSP from multiple IS-IS neighbors. In addition, two IS-IS
	beneficial to improve the scalability of MSDC networks.		neighbors may send each other the same LSP simultaneously. The
			unneccessary link-state information flooding wastes the precious
			process resource of IS-IS routers greatly due to the fact that there
			are too many IS-IS neighbors for each IS-IS router within the CLOS
			topology. This document proposes some extensions to IS-IS so as to
			reduce the IS-IS flooding within MSDC networks greatly. The
			reduction of the IS-IS flooding is much beneficial to improve the
			scalability of MSDC networks.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). 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 July 10, 2017.		This Internet-Draft will expire on November 3, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 18 ¶		skipping to change at page 2, line 33 ¶
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Modifications to Current IS-IS Behaviors . . . . . . . . . . 4		3. Modifications to Current IS-IS Behaviors . . . . . . . . . . 4
	3.1. IS-IS Routers as Non-DIS . . . . . . . . . . . . . . . . 4		3.1. IS-IS Routers as Non-DIS . . . . . . . . . . . . . . . . 4
	3.2. Controllers as DIS . . . . . . . . . . . . . . . . . . . 5		3.2. Controllers as DIS . . . . . . . . . . . . . . . . . . . 5
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . . 5		7.2. Informative References . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	IS-IS is commonly used as a underlay routing protocol for Massively		IS-IS is commonly used as an underlay routing protocol for Massively
	Scalable Data Center (MSDC) networks. In addition, centrolized		Scalable Data Center (MSDC) networks where CLOS is the most popular
	controllers are becoming fundamental network elements in most MSDCs.		toplogy. For a given IS-IS router within the CLOS topology, it would
	One or more controllers are usually connected to all routers within		receive multiple copies of exactly the same LSP from multiple IS-IS
	the MSDC network via a Local Area Network (LAN) which is dedicated		neighbors. In addition, two IS-IS neighbors may send each other the
	for network management purpose (called management LAN), as shown in		same LSP simultaneously. The unnecessary link-state information
	Figure 1.		flooding wastes the precious process resource of IS-IS routers
			greatly and therefore IS-IS could not scale very well in MSDC
			networks.
			To simplify the network management task, centralized controllers are
			becoming fundamental network elements in most MSDCs. One or more
			controllers are usually connected to all routers within the MSDC
			network via a Local Area Network (LAN) which is dedicated for network
			management purpose (called management LAN), as shown in Figure 1.
	+----------+ +----------+		+----------+ +----------+
	|Controller| |Controller|		|Controller| |Controller|
	+----+-----+ +-----+----+		+----+-----+ +-----+----+
	|DIS |Candidate DIS		|DIS |Candidate DIS
	| |		| |
	| |		| |
	---+---------+---+----------+-----------+---+---------+-Management LAN		---+---------+---+----------+-----------+---+---------+-Management LAN
	| | | | |		| | | | |
	|Non-DIS |Non-DIS |Non-DIS |Non-DIS |Non-DIS		|Non-DIS |Non-DIS |Non-DIS |Non-DIS |Non-DIS
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	controller being elected as IS-IS DIS initially. Once an IS-IS DIS		controller being elected as IS-IS DIS initially. Once an IS-IS DIS
	for the management LAN has been discovered, they start to send IS-IS		for the management LAN has been discovered, they start to send IS-IS
	Hello packets directly (as unicasts) to the IS-IS DIS periodically.		Hello packets directly (as unicasts) to the IS-IS DIS periodically.
	In addition, IS-IS routers would send IS-IS PDUs to the IS-IS DIS for		In addition, IS-IS routers would send IS-IS PDUs to the IS-IS DIS for
	the management LAN as unicasts as well. In contrast, the controller		the management LAN as unicasts as well. In contrast, the controller
	being elected as IS-IS DIS would send IS-IS PDUs as before. As a		being elected as IS-IS DIS would send IS-IS PDUs as before. As a
	result, IS-IS routers would not receive IS-IS PDUs from one another		result, IS-IS routers would not receive IS-IS PDUs from one another
	unless these IS-IS PDUs are forwarded as unknown unicasts over the		unless these IS-IS PDUs are forwarded as unknown unicasts over the
	management LAN. Through the above modifications to the current IS-IS		management LAN. Through the above modifications to the current IS-IS
	router behaviors, the IS-IS flooding is greatly reduced which is much		router behaviors, the IS-IS flooding is greatly reduced, which is
	beneficial to improve the scalability of MSDC networks.		much beneficial to improve the scalability of MSDC networks.
	1.1. Requirements Language		1.1. Requirements Language
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Terminology		2. Terminology
	This memo makes use of the terms defined in [RFC1195].		This memo makes use of the terms defined in [RFC1195].
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	Priority of those IS-IS routers to zero). As a result, IS-IS routers		Priority of those IS-IS routers to zero). As a result, IS-IS routers
	would not see each other over the management LAN. In other word, IS-		would not see each other over the management LAN. In other word, IS-
	IS routers would not establish adjacencies with one other.		IS routers would not establish adjacencies with one other.
	Furthermore, IS-IS routers SHOULD send all the types of IS-IS PDUs to		Furthermore, IS-IS routers SHOULD send all the types of IS-IS PDUs to
	the controller being elected as IS-IS DIS as unicasts as well.		the controller being elected as IS-IS DIS as unicasts as well.
	To advoid the data traffic from being forwarded across the management		To advoid the data traffic from being forwarded across the management
	LAN, the cost of all IS-IS routers' interfaces to the management LAN		LAN, the cost of all IS-IS routers' interfaces to the management LAN
	SHOULD be set to the maximum value.		SHOULD be set to the maximum value.
			When a given IS-IS router lost its connection to the management LAN,
			it SHOULD actively establish adjacency with all of its IS-IS
			neighbors within the CLOS network. As such, it could obtain the full
			LSDB of the CLOS network while flooding its self-originated LSPs to
			the remaining part of the whole CLOS network through these IS-IS
			neighbor.
	3.2. Controllers as DIS		3.2. Controllers as DIS
	The controller being elected as IS-IS DIS would send IS-IS PDUs as		The controller being elected as IS-IS DIS would send IS-IS PDUs as
	multicasts or unicasts as before. And it SHOULD accept and process		multicasts or unicasts as before. And it SHOULD accept and process
	those unicast IS-IS PDUs originated from IS-IS routers. Upon		those unicast IS-IS PDUs originated from IS-IS routers. Upon
	receiving any new LSP from a given IS-IS router, the controller being		receiving any new LSP from a given IS-IS router, the controller being
	elected as DIS MUST flood it immediately to the management LAN for		elected as DIS MUST flood it immediately to the management LAN for
	two purposes: 1) implicitly acknowledging the receipt of that LSP; 2)		two purposes: 1) implicitly acknowledging the receipt of that LSP; 2)
	synchronizing that LSP to all the other IS-IS routers.		synchronizing that LSP to all the other IS-IS routers.
	Futhermore, to decrease the frequency of advertising Complete		Furthermore, to decrease the frequency of advertising Complete
	Sequence Number PDU (CSNP) on the controller being elected as DIS,		Sequence Number PDU (CSNP) on the controller being elected as DIS,
	it's RECOMMENDED that IS-IS routers SHOULD send an explicit		it's RECOMMENDED that IS-IS routers SHOULD send an explicit
	acknowledgement with a Partial Sequence Number PDU (PSNP) upon		acknowledgement with a Partial Sequence Number PDU (PSNP) upon
	receiving a new LSP from the controller being elected as DIS.		receiving a new LSP from the controller being elected as DIS.
	4. Acknowledgements		4. Acknowledgements
	TBD.		The authors would like to thank Peter Lothberg for his valuable comments
			and suggestions on this document.
	5. IANA Considerations		5. IANA Considerations
	TBD.		TBD.
	6. Security Considerations		6. Security Considerations
	TBD.		TBD.
	7. References		7. References
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 11 ¶
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	7.2. Informative References		7.2. Informative References
	[RFC4136] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction		[RFC4136] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction
	in Stable Topologies", RFC 4136, DOI 10.17487/RFC4136,		in Stable Topologies", RFC 4136, DOI 10.17487/RFC4136,
	July 2005, <http://www.rfc-editor.org/info/rfc4136>.		July 2005, <http://www.rfc-editor.org/info/rfc4136>.
	Author's Address		Authors' Addresses
	Xiaohu Xu		Xiaohu Xu
	Huawei		Huawei
	Email: xuxiaohu@huawei.com		Email: xuxiaohu@huawei.com
			Erik Auerswald
			fgn GmbH
			Email: auerswald@fg-networking.de
			Luyuan Fang
			ebay
			Email: lufang@ebay.com
			Jeff Tantsura
			Individual
			Email: jefftant@gmail.com
End of changes. 12 change blocks.
	23 lines changed or deleted		51 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/