< draft-ietf-trill-multilevel-unique-nickname-03.txt		draft-ietf-trill-multilevel-unique-nickname-04.txt >
	TRILL Working Group M. Zhang		TRILL Working Group M. Zhang
	Internet Draft D. Eastlake 3rd		Internet Draft D. Eastlake 3rd
	Intended Category: Proposed Standard Huawei		Intended Category: Proposed Standard Huawei
	R. Perlman		R. Perlman
	EMC		Dell EMC
	M. Cullen		Expires: August 19, 2018 February 20, 2018
	Painless Security
	H. Zhai
	JIT
	D. Liu
	China Telcom Co., Ltd
	Expires: May 26, 2018 November 22, 2017
	TRILL Multilevel Using Unique Nicknames		TRILL Multilevel Using Unique Nicknames
	draft-ietf-trill-multilevel-unique-nickname-03.txt		draft-ietf-trill-multilevel-unique-nickname-04.txt
	Abstract		Abstract
	TRILL routing can be extended to support multiple levels by building		TRILL routing can be extended to support multiple levels by building
	on the multilevel feature of IS-IS routing. Depending on how		on the multilevel feature of IS-IS routing. Depending on how
	nicknames are managed, there are two primary alternatives to realize		nicknames are managed, there are two primary alternatives to realize
	TRILL multilevel: the unique nickname approach and the aggregated		TRILL multilevel: the unique nickname approach and the aggregated
	nickname approach as discussed in [MultiL]. This document specifies a		nickname approach as discussed in RFC 8243. This document specifies a
	unique nickname approach. This approach gives unique nicknames to all		unique nickname approach. This approach gives unique nicknames to all
	TRILL switches across the multilevel TRILL campus.		TRILL switches across the multilevel TRILL campus.
	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
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	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
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The multiple level feature of [IS-IS] can increase the scalability of		The multiple level feature of [IS-IS] can increase the scalability of
	TRILL as discussed in [MultiL]. However, multilevel IS-IS needs some		TRILL as discussed in [RFC8243]. However, multilevel IS-IS needs some
	extensions to support the TRILL multilevel feature. The two most		extensions to support the TRILL multilevel feature. The two most
	significant extensions are how TRILL switch nicknames are managed and		significant extensions are how TRILL switch nicknames are managed and
	how distribution trees are handled [MultiL].		how distribution trees are handled [RFC8243].
	There are two primary alternatives to realize TRILL multilevel		There are two primary alternatives to realize TRILL multilevel
	[MultiL]. One approach, which is referred to as the "aggregated		[RFC8243]. One approach, which is referred to as the "aggregated
	nickname" approach, involves assigning nicknames to the areas, and		nickname" approach, involves assigning nicknames to the areas, and
	allowing nicknames to be reused in different areas, by having the		allowing nicknames to be reused in different areas, by having the
	border TRILL switches rewrite nickname fields when entering or		border TRILL switches rewrite nickname fields when entering or
	leaving an area. For more description about the aggregated nickname		leaving an area. For more description of the aggregated nickname
	approach, one can refer to [MultiL] and [SingleN]. The other		approach, one can refer to [RFC8243] and [SingleN]. The other
	approach, which is referred to as the "unique nickname" approach, is		approach, which is referred to as the "unique nickname" approach, is
	specified in this document. Unique nickname approach gives unique		specified in this document. The unique nickname approach gives unique
	nicknames to all the TRILL switches in the multilevel campus, by		nicknames to all the TRILL switches in the multilevel campus, by
	having the Level-1/Level-2 border TRILL switches advertise into the		having the Level-1/Level-2 border TRILL switches advertise into the
	Level 1 area which nicknames are not available for assignment in the		Level 1 area which nicknames are not available for assignment in the
	area, and insert into Level 2 area which nicknames are used by this		area, and insert into Level 2 area which nicknames are used by this
	area so that other areas cannot use them anymore, as well as		area so that other areas cannot use them anymore, as well as
	informing the rest of the campus how to reach the nicknames residing		informing the rest of the campus how to reach the nicknames residing
	in this area. In the document, protocol extensions that support such		in this area. In the document, protocol extensions that support such
	advertisement are specified.		advertisement are specified.
	Each RBridge in a unique nickname area calculates two types of trees:		Each RBridge in a unique nickname area calculates two types of trees:
	local distribution trees and global distributions trees. For multi-		local distribution trees and global distributions trees. For multi-
	destination traffic that is limited to an area, the packets will be		destination traffic that is limited to an area, the packets will be
	flooded on the local distribution tree. Otherwise, the multi-		flooded on a local distribution tree. Otherwise, the multi-
	destination packets will be flooded along the global distribution		destination packets will be flooded along a global distribution
	tree.		tree.
	In the unique nickname approach, nicknames are globally valid so that		In the unique nickname approach, nicknames are globally valid so that
	border RBridges do not rewrite the nickname field of TRILL data		border RBridges do not rewrite the nickname field of TRILL data
	packets that transition between Level 1 and Level 2, as border		packets that transition between Level 1 and Level 2, as border
	RBridges do in the aggregated nickname approach. If a border RBridge		RBridges do in the aggregated nickname approach. If a border RBridge
	is a transit node on a forwarding path, it does not learn MAC		is a transit node on a forwarding path, it does not learn MAC
	addresses of the TRILL data packets forwarded along this path.		addresses of the TRILL data packets forwarded along this path.
	Testing and maintenance operations that originate in one area and		Testing and maintenance operations that originate in one area and
	terminate in a different area are also simplified [MultiL]. For these		terminate in a different area are also simplified [RFC8243]. For
	reasons, unique nickname approach might realize simpler border		these reasons, the unique nickname approach might realize simpler
	RBridges than the aggregated nickname approach. However, the unique		border RBridges than the aggregated nickname approach. However, the
	nickname approach is less scalable and may be less well suited for		unique nickname approach is less scalable and may be less well suited
	very large campuses.		for very large campuses.
	2. Acronyms and Terminology		2. Acronyms and Terminology
	Data Label: VLAN or FGL [RFC7172]		Data Label: VLAN or FGL [RFC7172]
	IS-IS: Intermediate System to Intermediate System [IS-IS]		IS-IS: Intermediate System to Intermediate System [IS-IS]
	RBridge: A device implementing the TRILL protocol.		RBridge: A device implementing the TRILL protocol.
	TRILL: TRansparent Interconnection of Lots of Links or Tunneled		TRILL: TRansparent Interconnection of Lots of Links or Tunneled
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 23 ¶
	Area X level 2 Area Y		Area X level 2 Area Y
	+-----------------+ +---------------------+ +------------+		+-----------------+ +---------------------+ +------------+
	| | | | | |		| | | | | |
	S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D		S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D
	| 27 | | | | 44 |		| 27 | | | | 44 |
	| | | | | |		| | | | | |
	+-----------------+ +---------------------+ +------------+		+-----------------+ +---------------------+ +------------+
	Figure 3.1: An example topology for TRILL multilevel		Figure 3.1: An example topology for TRILL multilevel
	Figure 3.1 is adapted from the example topology of [MultiL].		Figure 3.1 is adapted from the example topology of [RFC8243].
	The routing processes are described in the following two subsections.		The routing processes are described in the following two subsections.
	3.1. Unicast Routing		3.1. Unicast Routing
	The plain RBridge RB27 has a different view of the topology of the		The plain RBridge RB27 has a different view of the topology of the
	TRILL campus than its border RBridge RB2. For an outward path that		TRILL campus than its border RBridge RB2. For an outward path that
	reaches an RBridge not in the same area (say RB44), RB27 calculates		reaches an RBridge not in the same area (say RB44), RB27 calculates
	the segment of the path in Area X, the border RBridge RB2 calculates		the segment of the path in Area X, the border RBridge RB2 calculates
	the segment in Level 2, while the border RBridge to the destination		the segment in Level 2, while the border RBridge to the destination
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	- The packet is forwarded through Level 2, from RB2 to RB3, which		- The packet is forwarded through Level 2, from RB2 to RB3, which
	has advertised, in Level 2, it owns the nickname 44.		has advertised, in Level 2, it owns the nickname 44.
	- RB3, when forwarding into Area Y, does not change the ingress		- RB3, when forwarding into Area Y, does not change the ingress
	nickname 27 or the egress nickname 44.		nickname 27 or the egress nickname 44.
	- RB44, when decapsulating, learns that S is attached to nickname		- RB44, when decapsulating, learns that S is attached to nickname
	27.		27.
	3.2. Multicast Routing		3.2. Multi-destination Routing
	The scope of multicast routing is defined by the tree root nickname.		The scope of Multi-destination routing is defined by the tree root
	A tree with a Level 2 tree root nickname is global and a tree with		nickname. A tree with a Level 2 tree root nickname is global and a
	Level 1 tree root nickname is local. See Section 4.2 for the Level 1		tree with Level 1 tree root nickname is local. See Section 4.2 for
	and Level 2 nickname allocation.		the Level 1 and Level 2 nickname allocation.
	Border RBridges announce the global trees to be calculated only for		Border RBridges announce the global trees to be calculated only for
	those Data Labels that span across areas. APPsub-TLVs as specified in		those Data Labels that span across areas. APPsub-TLVs as specified in
	Section 3.2 of [RFC7968] will be advertised for this purpose. Based		Section 3.2 of [RFC7968] will be advertised for this purpose. Based
	on the Data Label, an ingress RBridge can determine whether a global		on the Data Label, an ingress RBridge can determine whether a global
	tree or a local tree is to be used for a TRILL multi-destination Data		tree or a local tree is to be used for a TRILL multi-destination Data
	packet.		packet.
	If there are legacy TRILL switches that do not understand the APPsub-		If there are legacy TRILL switches that do not understand the APPsub-
	TLVs for tree selection, configuration MUST guarantee that Data		TLVs for tree selection, configuration MUST guarantee that Data
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	Hello. The state machines for Level 1 and Level 2 adjacency are		Hello. The state machines for Level 1 and Level 2 adjacency are
	independent and two RBridges on the same LAN link can have any		independent and two RBridges on the same LAN link can have any
	adjacency state for Level 1 and, separately, any adjacency state for		adjacency state for Level 1 and, separately, any adjacency state for
	Level 2. Level 1 and Level 2 link state flooding are independent		Level 2. Level 1 and Level 2 link state flooding are independent
	using Level 1 and Level 2 versions of the relevant IS-IS PDUs (LSP,		using Level 1 and Level 2 versions of the relevant IS-IS PDUs (LSP,
	CSNP, PSNP, FS-LSP, FS-CSNP and FS-PSNP). Thus Level 1 link state		CSNP, PSNP, FS-LSP, FS-CSNP and FS-PSNP). Thus Level 1 link state
	information stays within a Level 1 area and Level 2 link state		information stays within a Level 1 area and Level 2 link state
	information stays in Level 2 unless there are specific provisions for		information stays in Level 2 unless there are specific provisions for
	leaking (copying) information between levels. This is why multilevel		leaking (copying) information between levels. This is why multilevel
	can address the TRILL scalability issues as specified in Section 2 of		can address the TRILL scalability issues as specified in Section 2 of
	[MultiL].		[RFC8243].
	The former "campus wide" minimum acceptable link size Sz is		The former "campus wide" minimum acceptable link size Sz is
	calculated as before by Level 1 RBridges (including border RBridges)		calculated as before by Level 1 RBridges (including border RBridges)
	using the originatingLSPBufferSize advertised in Level 1 LSP so it is		using the originatingLSPBufferSize advertised in Level 1 LSP so it is
	area local in multilevel TRILL. A minimum acceptable link size in		area local in multilevel TRILL. A minimum acceptable link size in
	Level 2, called Sz2, is calculated by the RBridges participating in		Level 2, called Sz2, is calculated by the RBridges participating in
	Level 2 in the same way as Sz is calculated but using the		Level 2 in the same way as Sz is calculated but using the
	originatingLSPBufferSize distributed in Level 2 LSPs.		originatingLSPBufferSize distributed in Level 2 LSPs.
	4.2. Nickname Allocation		4.2. Nickname Allocation
	skipping to change at page 11, line 45 ¶		skipping to change at page 11, line 45 ¶
	If there are RBridges that do not understand the NickBlockFlags		If there are RBridges that do not understand the NickBlockFlags
	APPsub-TLV, border RBridges of the area will also use the traditional		APPsub-TLV, border RBridges of the area will also use the traditional
	Nickname Sub-TLV [RFC7176] to announce into the area those nicknames		Nickname Sub-TLV [RFC7176] to announce into the area those nicknames
	covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose		covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose
	OK is 0. The available range of nicknames for this area should be		OK is 0. The available range of nicknames for this area should be
	configure on these traditional RBridges.		configure on these traditional RBridges.
	5. Mix with Aggregated nickname Areas		5. Mix with Aggregated nickname Areas
	The design of TRILL multilevel allows a mixture of unique nickname		The design of TRILL multilevel allows a mixture of unique nickname
	areas and aggregated nickname areas (see Section 1.2 of [MultiL]).		areas and aggregated nickname areas (see Section 1.2 of [RFC8243]).
	Usage of nickname space must be planed so that nicknames used in any		Usage of nickname space must be planed so that nicknames used in any
	one unique nickname area and Level 2 are never used in any other		one unique nickname area and Level 2 are never used in any other
	areas which includes unique nickname areas as well as aggregated		areas which includes unique nickname areas as well as aggregated
	nickname areas. In other words, nickname re-usage is merely allowed		nickname areas. In other words, nickname re-usage is merely allowed
	among aggregated nickname areas.		among aggregated nickname areas.
	Border RBridges of an aggregated area need to announce nicknames		Border RBridges of an aggregated area need to announce nicknames
	heard from Level 2 into their area like just like an unique nickname		heard from Level 2 into their area like just like an unique nickname
	border RBridge. But these RBridges do not announce nicknames of their		border RBridge. But these RBridges do not announce nicknames of their
	area into Level 2.		area into Level 2.
	Each border RBridge of the aggregated areas will appear on the global		Each border RBridge of the aggregated areas will appear on the global
	tree, as specified in Section 4.1, as a single node. The global trees		tree, as specified in Section 4.1, as a single node. The global trees
	for unique nickname areas span unique nickname areas and Level 2 but		for unique nickname areas span unique nickname areas and Level 2 but
	never reach the inside of aggregated areas.		never reach the inside of aggregated areas.
	6. Security Considerations		6. Security Considerations
	With TRILL multilevel, flooding of control traffic for link state		With TRILL multilevel, flooding of control traffic for link state
	information of Level 1 and Level 2 is separated. This addresses the		information of Level 1 and Level 2 is separated. This addresses the
	TRILL scalability issues as specified in Section 2 of [MultiL] and		TRILL scalability issues as specified in Section 2 of [RFC8243] and
	also confines the effective scope of possible malicious events.		also confines the effective scope of possible malicious events.
	However, due to the nature that unique nickname areas share a unique		However, due to the nature that unique nickname areas share a unique
	nickname space, border RBridges still have to leak nickname		nickname space, border RBridges still have to leak nickname
	information between levels. For this purpose, border RBridges need to		information between levels. For this purpose, border RBridges need to
	fabricate the nickname announcements as specified in Section 4.3.		fabricate the nickname announcements as specified in Section 4.3.
	Malicious devices may also fake the NickBlockFlags APPsub-TLV to		Malicious devices may also fake the NickBlockFlags APPsub-TLV to
	announce a range of nicknames. By doing this, the attacker can		announce a range of nicknames. By doing this, the attacker can
	attract TRILL data packets that are originally to reach a bunch of		attract TRILL data packets that are originally to reach a bunch of
	other RBridges. For this reason, RBridges SHOULD be configured to		other RBridges. For this reason, RBridges SHOULD be configured to
	include the IS-IS Authentication TLV (10) in the IS-IS PDUs that		include the IS-IS Authentication TLV (10) in the IS-IS PDUs that
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 10 ¶
	[IS-IS] International Organization for Standardization,		[IS-IS] International Organization for Standardization,
	"Information technology -- Telecommunications and		"Information technology -- Telecommunications and
	information exchange between systems -- Intermediate System		information exchange between systems -- Intermediate System
	to Intermediate System intra-domain routeing information		to Intermediate System intra-domain routeing information
	exchange protocol for use in conjunction with the protocol		exchange protocol for use in conjunction with the protocol
	for providing the connectionless-mode network service (ISO		for providing the connectionless-mode network service (ISO
	8473)", ISO/IEC 10589:2002, Second Edition, November 2002.		8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
	8.2. Informative References		8.2. Informative References
	[MultiL] Perlman, R., Eastlake, D., et al, "Alternatives for
	Multilevel TRILL (Transparent Interconnection of Lots of
	Links)", draft-ietf-trill-rbridge-multilevel, Work in
	Progress.
	[SingleN] Zhang, M., Eastlake, D., et al, "Single Area Border RBridge		[SingleN] Zhang, M., Eastlake, D., et al, "Single Area Border RBridge
	Nickname for TRILL Multilevel", draft-ietf-trill-		Nickname for TRILL Multilevel", draft-ietf-trill-
	multilevel-single-nickname, Work in Progress.		multilevel-single-nickname, Work in Progress.
	[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic		[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
	Authentication", RFC 5304, DOI 10.17487/RFC5304, October		Authentication", RFC 5304, DOI 10.17487/RFC5304, October
	2008, <http://www.rfc-editor.org/info/rfc5304>.		2008, <http://www.rfc-editor.org/info/rfc5304>.
	[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,		[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
	and M. Fanto, "IS-IS Generic Cryptographic Authentication",		and M. Fanto, "IS-IS Generic Cryptographic Authentication",
	RFC 5310, DOI 10.17487/RFC5310, February 2009,		RFC 5310, DOI 10.17487/RFC5310, February 2009,
	<http://www.rfc-editor.org/info/rfc5310>.		<http://www.rfc-editor.org/info/rfc5310>.
			[RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and
			H. Zhai, "Alternatives for Multilevel Transparent
			Interconnection of Lots of Links (TRILL)", RFC 8243, DOI
			10.17487/RFC8243, September 2017,
			<https://www.rfc-editor.org/info/rfc8243>.
			9. Contributors
			The contributions of the following are gratefully acknowledged:
			Margaret Cullen, Hongjun Zhai, Dongxin Liu
	Author's Addresses		Author's Addresses
	Mingui Zhang		Mingui Zhang
	Huawei Technologies		Huawei Technologies
	No. 156 Beiqing Rd., Haidian District		No. 156 Beiqing Rd., Haidian District
	Beijing 100095		Beijing 100095
	China		China
	Phone: +86-13810702575		Phone: +86-13810702575
	Email: zhangmingui@huawei.com		Email: zhangmingui@huawei.com
	skipping to change at page 15, line 26 ¶		skipping to change at page 15, line 26 ¶
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Huawei Technologies		Huawei Technologies
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757		Milford, MA 01757
	United States		United States
	Phone: +1-508-333-2270		Phone: +1-508-333-2270
	Email: d3e3e3@gmail.com		Email: d3e3e3@gmail.com
	Radia Perlman		Radia Perlman
	EMC		Dell EMC
	2010 256th Avenue NE, #200		176 South Street
	Bellevue, WA 98007		Hopkinton, MA 01748
	United States		United States
	Email: radia@alum.mit.edu		Email: radia@alum.mit.edu
	Margaret Cullen
	Painless Security
	14 Summer St. Suite 202
	Malden, MA 02148
	United States
	Email: margaret@painless-security.com
	Hongjun Zhai
	Jinling Institute of Technology
	99 Hongjing Avenue, Jiangning District
	Nanjing, Jiangsu 211169
	China
	Email: honjun.zhai@tom.com
	Dongxin Liu
	China Telcom Co., Ltd
	109 West Zhongshan Ave, Tianhe District
	Guangzhou 510630
	P.R. China
	Email: liudx@gsta.com
End of changes. 21 change blocks.
	41 lines changed or deleted		42 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/