< draft-ietf-trill-multilevel-unique-nickname-06.txt		draft-ietf-trill-multilevel-unique-nickname-07.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
	Dell EMC		Dell EMC
	H. Zhai		H. Zhai
	JIT		JIT
	D. Liu		D. Liu
	China Telcom Co., Ltd		China Telcom Co., Ltd
	Expires: September 6, 2018 March 5, 2018		Expires: September 15, 2018 March 14, 2018
	TRILL Multilevel Using Unique Nicknames		TRILL Multilevel Using Unique Nicknames
	draft-ietf-trill-multilevel-unique-nickname-06.txt		draft-ietf-trill-multilevel-unique-nickname-07.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 RFC 8243. 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.
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	3.2.2. Global Distribution Trees		3.2.2. Global Distribution Trees
	Within Level 2, the RBridge with the highest tree root priority		Within Level 2, the RBridge with the highest tree root priority
	advertises the set of global trees by providing a list of Level 2		advertises the set of global trees by providing a list of Level 2
	RBridge nicknames just as defined in Section 4.5 of [RFC6325].		RBridge nicknames just as defined in Section 4.5 of [RFC6325].
	According to [RFC6325], the RBridge with the highest root priority		According to [RFC6325], the RBridge with the highest root priority
	advertises the tree roots for a Level 1 area. There has to be a		advertises the tree roots for a Level 1 area. There has to be a
	border RBridge with the highest root tree priority in each area so		border RBridge with the highest root tree priority in each area so
	that it can advertises the global tree root nicknames into the area.		that it can advertises the global tree root nicknames into the area.
	Also, this border RBridge needs to advertise the set of local		Also, this border RBridge MUST advertise the set of local
	distribution trees by providing another set of nicknames. Since		distribution trees by providing another set of nicknames. Since
	nicknames of global tree roots and local tree roots indicate		nicknames of global tree roots and local tree roots indicate
	different flooding scopes, these two set MUST NOT overlap. If a		different flooding scopes, these two set MUST NOT overlap. If a
	border RBridge has been assigned both as a global tree root and a		border RBridge has been assigned both as a global tree root and a
	local tree root, it has to acquire both a global tree root		local tree root, it MUST acquire both a global tree root nickname(s)
	nickname(s) and local tree root nickname(s). However, non-border		and local tree root nickname(s). However, non-border RBridges in an
	RBridges in an area do not differentiate between a global tree root		area do not differentiate between a global tree root nickname and a
	nickname and a local tree root nickname.		local tree root nickname.
	Suppose RB3 is the RBridge with the highest tree root priority within		Suppose RB3 is the RBridge with the highest tree root priority within
	Level 2, and RB2 is the highest tree root priority in Area X. RB2		Level 2, and RB2 is the highest tree root priority in Area X. RB2
	advertises in Area X that nickname RB3 is the root of a distribution		advertises in Area X that nickname RB3 is the root of a distribution
	tree. Figure 3.2 through Figure 3.5 illustrate how different RBridges		tree. Figure 3.2 through Figure 3.5 illustrate how different RBridges
	view the global distribution tree.		view the global distribution tree.
	RB2,RB3,Rb,Rc,Rd,Re,Rk,RB44		RB2,RB3,Rb,Rc,Rd,Re,Rk,RB44
	o		o
	/		/
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	Level 2 RBridges contend for nicknames in the range from 0xF000		Level 2 RBridges contend for nicknames in the range from 0xF000
	through 0xFFBF the same way as specified in [RFC6325], using Level 2		through 0xFFBF the same way as specified in [RFC6325], using Level 2
	LSPs. The highest priority border router for a Level 1 area should		LSPs. The highest priority border router for a Level 1 area should
	contend with others in Level 2 for blocks of nicknames for the range		contend with others in Level 2 for blocks of nicknames for the range
	from 0x0001 to 0xEFFF. Blocks of 64 aligned on multiple of 64		from 0x0001 to 0xEFFF. Blocks of 64 aligned on multiple of 64
	boundaries are RECOMMENDED in this document.		boundaries are RECOMMENDED in this document.
	The nickname contention in Level 2 will figure out which blocks of		The nickname contention in Level 2 will figure out which blocks of
	nicknames are available for an area and which blocks of nicknames are		nicknames are available for an area and which blocks of nicknames are
	used else where. The NickBlockFlags APPsub-TLV as specified in		used elsewhere. The NickBlockFlags APPsub-TLV as specified in Section
	Section 4.3 will be used by the border RBridge(s) to announce the		4.3 will be used by the border RBridge(s) to announce the nickname
	nickname availability.		availability.
	4.3. Nickname Announcements		4.3. Nickname Announcements
	Border RBridges need to exchange nickname information between Level 1		Border RBridges need to exchange nickname information between Level 1
	and Level 2, otherwise forwarding paths inward/outward will not be		and Level 2, otherwise forwarding paths inward/outward will not be
	calculated. For this purpose, border RBridges need to fabricate		calculated. For this purpose, border RBridges need to fabricate
	nickname announcements. Sub-TLVs used for such announcements are		nickname announcements. Sub-TLVs used for such announcements are
	specified as follows.		specified as follows.
	Besides its own nickname(s), a border RBridge needs to announce, in		Besides its own nickname(s), a border RBridge MUST announce, in its
	its area, the ownership of all external nicknames that are reachable		area, the ownership of all external nicknames that are reachable from
	from this border RBridge. These external nicknames include nicknames		this border RBridge. These external nicknames include nicknames used
	used in other unique nickname areas and nicknames in Level 2. Non-		in other unique nickname areas and nicknames in Level 2. Non-border
	border RBridge nicknames within aggregated nickname areas are		RBridge nicknames within aggregated nickname areas are excluded.
	excluded. Also, a border RBridge needs to announce, in Level 2, the		Also, a border RBridge MUST announce, in Level 2, the ownership of
	ownership of all nicknames within its area. From listening to these		all nicknames within its area. From listening to these Level 2
	Level 2 announcements, border RBridges can figure out the nicknames		announcements, border RBridges can figure out the nicknames used by
	used by other areas.		other areas.
	RBridges in the TRILL base protocol use the Nickname Sub-TLV as		RBridges in the TRILL base protocol use the Nickname Sub-TLV as
	specified in Section 2.3.2 of [RFC7176] to announce the ownership of		specified in Section 2.3.2 of [RFC7176] to announce the ownership of
	nicknames. However, it becomes uneconomic to use this Sub-TLV to		nicknames. However, it becomes uneconomic to use this Sub-TLV to
	announce a mass of internal/external nicknames. To address this		announce a mass of internal/external nicknames. To address this
	issue, border RBridges should make use of the NickBlockFlags APPsub-		issue, border RBridges SHOULD make use of the NickBlockFlags APPsub-
	TLV to advertise into the Level 1 area the inclusive range of		TLV to advertise into the Level 1 area the inclusive range of
	nicknames that are available or not for self allocation by the Level		nicknames that are available or not for self allocation by the Level
	1 RBridges in that area. Its structure is as follows:		1 RBridges in that area. Its structure is as follows:
	0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15		0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| type = tbd2 |		| type = tbd2 |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| length |		| length |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	skipping to change at page 11, line 29 ¶		skipping to change at page 11, line 29 ¶
	and is out the scope of this document.		and is out the scope of this document.
	As specified in Section 4.2.6 of [RFC6325], multiple border RBridges		As specified in Section 4.2.6 of [RFC6325], multiple border RBridges
	may claim the same nicknames outward and/or inward. Other RBridges		may claim the same nicknames outward and/or inward. Other RBridges
	add those nicknames as if they are attached to all of those border		add those nicknames as if they are attached to all of those border
	RBridges.		RBridges.
	4.4. Capability Indication		4.4. Capability Indication
	All border RBridge MUST understand the NickBlockFlags APPsub-TLV. Non		All border RBridge MUST understand the NickBlockFlags APPsub-TLV. Non
	border RBridges in an area SHOULD understand the NickBlockFlags		border RBridges in an area should understand the NickBlockFlags
	APPsub-TLV. If an RBridge within an area understands the		APPsub-TLV. If an RBridge within an area understands the
	NickBlockFlags APPsub-TLV, it MUST indicate this capability by		NickBlockFlags APPsub-TLV, it MUST indicate this capability by
	announcing it in its TRILL-VER Sub-TLV. (See Section 7).		announcing it in its TRILL-VER Sub-TLV. (See Section 7).
	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 MUST 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 [RFC8243]).		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 MUST announce nicknames heard
	heard from Level 2 into their area like just like an unique nickname		from Level 2 into their area like just like an unique nickname border
	border RBridge. But these RBridges do not announce nicknames of their		RBridge. But these RBridges do not announce nicknames of their area
	area into Level 2.		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
	Since TRILL multilevel uses the existing IS-IS multilevel facilities		Since TRILL multilevel uses the existing IS-IS multilevel facilities
	[IS-IS], flooding of control traffic for link state information is		[IS-IS], flooding of control traffic for link state information is
	automatically confined to a Level 1 area or to Level 2 except (for		automatically confined to a Level 1 area or to Level 2 except (for
	limited types of information that can be specifically flagged for		limited types of information that can be specifically flagged for
	wider flooding). This addresses the TRILL scalability issues as		wider flooding). This addresses the TRILL scalability issues as
	specified in Section 2 of [RFC8243] and also, except of the wider		specified in Section 2 of [RFC8243] and also, except for the wider
	flooding case, this confines the scope of the effects of malicious		flooding case, this confines the scope of the effects of malicious
	events that could be communicated through the link state. However,		events that could be communicated through the link state. However,
	due to the nature that unique nickname areas share a common nickname		due to the nature that unique nickname areas share a common nickname
	space, border RBridges still have to leak nickname information		space, border RBridges still have to leak nickname information
	between levels. Such leaking means that nickname related events in		between levels. Such leaking means that nickname related events in
	one area can affect other areas.		one area can affect other areas.
	For this purpose, border RBridges need to fabricate the nickname		For this purpose, border RBridges need to fabricate the nickname
	announcements as specified in Section 4.3. Malicious devices may also		announcements as specified in Section 4.3. Malicious devices may also
	fake the NickBlockFlags APPsub-TLV to announce a range of nicknames.		fake the NickBlockFlags APPsub-TLV to announce a range of nicknames.
	By doing this, the attacker can attract TRILL data packets that are		By doing this, the attacker can attract TRILL data packets that are
	originally to reach a bunch of other RBridges. For this reason,		originally to reach a bunch of other RBridges. For this reason,
	RBridges SHOULD be configured to include the IS-IS Authentication TLV		RBridges SHOULD be configured to use the IS-IS Authentication TLV
	(10) in the IS-IS PDUs that contains the NickBlockFlags APPsub-TLV,		(10) in the IS-IS PDUs, particularly those containing the
	so that IS-IS security ([RFC5310]) can be used to authenticate those		NickBlockFlags APPsub-TLV, so that IS-IS security ([RFC5310]) can be
	PDUs and discard them if they are forged.		used to authenticate those PDUs and discard them if they are forged.
	If border RBridges do not prune multi-destination distribution tree		If border RBridges do not prune multi-destination distribution tree
	traffic in Data Labels that are configured to be area local, then		traffic in Data Labels that are configured to be area local, then
	traffic that should have been contained within an area might be		traffic that should have been contained within an area might be
	wrongly delivered to end stations in that Data Label in other areas,		wrongly delivered to end stations in that Data Label in other areas,
	that is, the Data Label would no longer be area local. This would		that is, the Data Label would no longer be area local. This would
	generally violate security constraints that require traffic to be		generally violate security constraints that require traffic to be
	delivered only to end stations in that Data Label in a single area.		delivered only to end stations in that Data Label in a single area.
	For general TRILL Security Considerations, see [RFC6325].		For general TRILL Security Considerations, see [RFC6325].
End of changes. 13 change blocks.
	32 lines changed or deleted		32 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/