< draft-tissa-trill-mt-encode-01.txt		draft-tissa-trill-mt-encode-02.txt >
	TRILL Working Group Tissa Senevirathne		TRILL Working Group Tissa Senevirathne
	Internet Draft Les Ginsberg		Internet Draft Les Ginsberg
			Satya Dillikar
	Intended status: Standard Track CISCO		Intended status: Standard Track CISCO
	Ayan Banerjee		Ayan Banerjee
	Consultant		Consultant
	Sam Aldrin		Sam Aldrin
	HuaaWei		HuaaWei
	Naveen Nimmu		Naveen Nimmu
	Broadcom		Broadcom
	June 17, 2012		September 11, 2012
	Expires: December 2012		Expires: March 2013
	Multi Topology Encoding within TRILL data frames		Multi Topology Encoding within TRILL data frames
	draft-tissa-trill-mt-encode-01.txt		draft-tissa-trill-mt-encode-02.txt
	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), 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-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 42		skipping to change at page 1, line 43
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference 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 November 17, 2012.		This Internet-Draft will expire on December 11, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 29		skipping to change at page 2, line 29
	Two alternate methods of encoding Multi Topology Identifier within		Two alternate methods of encoding Multi Topology Identifier within
	the TRILL data frames are presented. Methods proposed herein do not		the TRILL data frames are presented. Methods proposed herein do not
	require overloading TRILL RBridge nickname to encode Multi Topology		require overloading TRILL RBridge nickname to encode Multi Topology
	Identifier. A method that expands TRILL nickname space from 16bits		Identifier. A method that expands TRILL nickname space from 16bits
	to 24 bits is also presented in this draft.		to 24 bits is also presented in this draft.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................3
	2. Conventions used in this document..............................4		2. Conventions used in this document..............................4
	3. Multi Topology Encoding and nickname Expansion.................4		3. Multi Topology Encoding........................................4
	3.1. Nickname construction.....................................5		3.1. Nickname construction.....................................5
	3.2. Use of Next-Hop VLAN for MT Encoding......................6		3.2. Use of Next-Hop VLAN for MT Encoding......................5
	4. Multi Topology Interoperability................................6		4. Multi Topology Interoperability................................6
	4.1. Interoperability during Migration.........................6		4.1. Interoperability during Migration.........................6
	4.2. Interoperability with RBridges with Non MT capable data		4.2. Interoperability with RBridges with Non MT capable data
	plane..........................................................7		plane..........................................................7
	4.3. Interoperability with MT unaware RBRdiges.................8		4.3. Interoperability with MT unaware RBRdiges.................8
	5. Backward compatibility.........................................8		5. Backward compatibility.........................................8
	6. IS-IS sub-TLV definition.......................................8		6. IS-IS sub-TLV definition.......................................8
	6.1. Nickname MSB capability...................................8		6.1. MT capability.............................................8
	6.1.1. TRILL sub-TLVs for 24bit nicknames...................8
	6.2. MT capability.............................................9
	7. Security Considerations........................................9		7. Security Considerations........................................9
	8. Assignment Considerations.....................................9		8. Assignment Considerations.....................................9
	8.1. IANA Considerations.......................................9		8.1. IANA Considerations.......................................9
	8.2. IEEE Considerations......................................10		8.2. IEEE Considerations.......................................9
	9. References....................................................10		9. References.....................................................9
	9.1. Normative References.....................................10		9.1. Normative References......................................9
	9.2. Informative References...................................10		9.2. Informative References....................................9
	10. Acknowledgments..............................................11		10. Acknowledgments...............................................9
	Authors' Addresses...............................................11		Authors' Addresses...............................................10
	1. Introduction		1. Introduction
	Multi Topology is an attractive concept that allows creating		Multi Topology is an attractive concept that allows creating
	different virtual topologies or overlays on top of a single physical		different virtual topologies or overlays on top of a single physical
	topology. There are several important applications. Few such		topology. There are several important applications. Few such
	applications are listed below. The list below is by no means an		applications are listed below. The list below is by no means an
	exhaustive list and there are other applications that may utilize		exhaustive list and there are other applications that may utilize
	the MT framework.		the MT framework.
	skipping to change at page 4, line 28		skipping to change at page 4, line 26
	name space. Presented in this document is a method that allows		name space. Presented in this document is a method that allows
	expanding the 16bit nickname space to a 24bit nickname space,		expanding the 16bit nickname space to a 24bit nickname space,
	without modifying the TRILL header defined in [RFC6325].		without modifying the TRILL header defined in [RFC6325].
	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 RFC-2119 [RFC2119].		document are to be interpreted as described in RFC-2119 [RFC2119].
	3. Multi Topology Encoding and nickname Expansion		3. Multi Topology Encoding
	[RFC6325] TRILL Base Protocol, proposes encoding scheme of TRILL		[RFC6325] TRILL Base Protocol, proposes encoding scheme of TRILL
	frames. TRILL frames contain outer MAC Header, 802.1QTAG, TRILL		frames. TRILL frames contain outer MAC Header, 802.1QTAG, TRILL
	header and user Data. We propose to include multi topology ID after		header and user Data. We propose to include multi topology ID after
	the 802.1Q TAG. Multi Toplogy ID is preceded by Ethernet Type MT-		the 802.1Q TAG. Multi Toplogy ID is preceded by Ethernet Type MT-
	ETHTYPE.		ETHTYPE.
	The expansion of nickname space requires expansion of both ingress
	and egress nickname spaces. We propose to encode 8bit MSB of egress
	nickname followed by 8bit MSB of ingress nickname in to the outer
	header. Figure 1 below depicts the proposed encoding.
	Outer Ethernet Header:		Outer Ethernet Header:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Outer Destination MAC Address |		| Outer Destination MAC Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Outer Destination MAC Address | Outer Source MAC Address |		| Outer Destination MAC Address | Outer Source MAC Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Outer Source MAC Address |		| Outer Source MAC Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |		|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ethertype = MT-ETHTYPE | MT-ID |		|Ethertype = MT-ETHTYPE | MT-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ethertype = NICKN-ETHTYPE |EG-NICKN-MSB | IG-NICKN-MSB |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TRILL Header |		| TRILL Header |
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. Payload .		. Payload .
	. .		. .
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1 MT ID /NICKN MSB extentions in TRILL		Figure 1 MT ID extensions in TRILL
	Ethtype-MT : 16 bit Ethtype to encode Multi Topology ID.		Ethtype-MT : 16 bit Ethtype to encode Multi Topology ID.
	MT-ID : 16bit Multi Topology IDNICKN-Ethtype : 16 bit Ethtype to		MT-ID : 16bit Multi Topology IDNICKN-Ethtype : 16 bit Ethtype to
	encode nickname expansion.		encode nickname expansion.
	EG-NICKN-MSB : 8bit MSB of the Egress nickname
	IG-NICKN-MSB : 8bit MSB of the Ingress nickname
	3.1. Nickname construction		3.1. Nickname construction
	Each RBridge that is compatible with the proposed scheme, First		Each RBridge that is compatible with the proposed scheme, First
	check for presence of Nick-Ethtype, if present extract the EG-NICKN-		check for presence of Nick-Ethtype, if present extract the EG-NICKN-
	MSB and IG-NICKN-MSB. EG-NICKN-MSB and IG-NICKN-MSB are then		MSB and IG-NICKN-MSB. EG-NICKN-MSB and IG-NICKN-MSB are then
	concatenated with the Egress TRILL nickname and the Ingress TRILL		concatenated with the Egress TRILL nickname and the Ingress TRILL
	nickname to form 24bit nickname space. The derived nickname MUST be		nickname to form 24bit nickname space. The derived nickname MUST be
	utilized for forwarding.		utilized for forwarding.
	3.2. Use of Next-Hop VLAN for MT Encoding		3.2. Use of Next-Hop VLAN for MT Encoding
	skipping to change at page 8, line 11		skipping to change at page 8, line 11
	Alternatively, RBRidges, on point-point links may assign a different		Alternatively, RBRidges, on point-point links may assign a different
	next hop VLAN for different topologies and derive topology ID based		next hop VLAN for different topologies and derive topology ID based
	on VLAN. Use Next-Hop VLAN reduces the need for multiple physical		on VLAN. Use Next-Hop VLAN reduces the need for multiple physical
	links. This method may be utilized as a permanent method for MT		links. This method may be utilized as a permanent method for MT
	encoding in Point-Pont only networks.		encoding in Point-Pont only networks.
	4.3. Interoperability with MT unaware RBRdiges		4.3. Interoperability with MT unaware RBRdiges
	MT aware RBridges identify MT unaware RBridges with either not		MT aware RBridges identify MT unaware RBridges with either not
	presence of capability flags (pre RFC6326bis) or MT capability flags		presence of capability flags (pre RFC6326bis) or MT capability flags
	not being set (Section 6.2. ). In such an event MT aware RBridges		not being set (Section 6.1. ). In such an event MT aware RBridges
	MUST only forward traffic related to the base topology to MT unaware		MUST only forward traffic related to the base topology to MT unaware
	RBridges. Additionally, proposed encoding MUST be removed prior to		RBridges. Additionally, proposed encoding MUST be removed prior to
	forwarding to MT unaware RBRidges.		forwarding to MT unaware RBRidges.
	5. Backward compatibility		5. Backward compatibility
	The proposed methods are encoded as part of the outer header of the		The proposed methods are encoded as part of the outer header of the
	TRILL frame. An RBridge that is aware of the proposed extensions		TRILL frame. An RBridge that is aware of the proposed extensions
	when interfacing with an RBridge that is not capable of the proposed		when interfacing with an RBridge that is not capable of the proposed
	extensions MUST remove the proposed encoding from the outer header,		extensions MUST remove the proposed encoding from the outer header,
	prior to transmission of TRILL frames on those links that has		prior to transmission of TRILL frames on those links that has
	RBridges that are not capable of the proposed extensions.		RBridges that are not capable of the proposed extensions.
	6. IS-IS sub-TLV definition		6. IS-IS sub-TLV definition
	6.1. Nickname MSB capability		6.1. MT capability
	To enable auto configuration and detection of Nickname MSB
	capability of the peer RBRIDGE, We propose to define a flag to
	indicate the Nickname MSB capability.
	If this capability is not present in the peer RBridge, the ETH-
	NICKN-MSB will be stripped out from the frame before , the frame is
	forwarded to the Nickname MSB unaware RBridge.
	6.1.1. TRILL sub-TLVs for 24bit nicknames
	TRILL standard [RFC6325] is defined for 16bit nickname space. All
	the associated sub-TLVs [RFC6326] are also defined to accommodate
	16bit nicknames. These sub-TLVs cannot be reused to accommodate
	24bit nicknames as that will break the backward compatibility.
	Hence, we propose to request new set of ISIS sub-TLV for following
	TRILL specific sub-TLVs under Router Capability TLV.
	Nickname sub-TLV
	Tree Identifier sub-TLV
	Tree Used Identifier sub-TLV
	Interested VLAN and Spanning Tree Root sub-TLV
	Interested Labels and Spanning Tree Root sub-TLV
	Affinity sub-TLV
	6.2. MT capability
	We propose to define two MT capability flags within Port TRILL		We propose to define two MT capability flags within Port TRILL
	Version sub-TLV.		Version sub-TLV.
	1. MT Encoding capability		1. MT Encoding capability
	2. MT to NH-VLAN Encoding capability		2. MT to NH-VLAN Encoding capability
	MT Encoding capability flag indicates the RBridge is capable		MT Encoding capability flag indicates the RBridge is capable
	encoding MT ID using ETHTYPE-MT as defined in section 3.		encoding MT ID using ETHTYPE-MT as defined in section 3.
	skipping to change at page 9, line 40		skipping to change at page 9, line 17
	TBD		TBD
	8. Assignment Considerations		8. Assignment Considerations
	8.1. IANA Considerations		8.1. IANA Considerations
	IANA is requested to allocate MT Encoding capability Flag,MT to NH-		IANA is requested to allocate MT Encoding capability Flag,MT to NH-
	VLAN Encoding capability Flags and Nickname MSB capability flag		VLAN Encoding capability Flags and Nickname MSB capability flag
	under Port TRILL version sub-TLV.		under Port TRILL version sub-TLV.
	Additionally IANA is requested to allocate new set of sub-TLV code
	points under Router capability TLV for the following to accommodate
	24bit nickname space:
	24bit Nickname sub-TLV
	24bit Tree Identifier sub-TLV
	24bit Tree Used Identifier sub-TLV
	24bit Interested VLAN and Spanning Tree Root sub-TLV
	24bit Interested Labels and Spanning Tree Root sub-TLV
	24bit Affinity sub-TLV
	8.2. IEEE Considerations		8.2. IEEE Considerations
	IEEE is requested to assign new Ether Type to represent MT-ETHTYPE		IEEE is requested to assign new Ether Type to represent MT-ETHTYPE
	defined in section 3.		defined in section 3.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 11, line 29		skipping to change at page 10, line 24
	Phone: +1-408-853-2291		Phone: +1-408-853-2291
	Email: tsenevir@cisco.com		Email: tsenevir@cisco.com
	Les Ginsberg		Les Ginsberg
	CISCO Systems		CISCO Systems
	510 McCarthy Blvd,		510 McCarthy Blvd,
	Milpitas, CA 95035.		Milpitas, CA 95035.
	Email: ginsberg@cisco.com		Email: ginsberg@cisco.com
			Satya Dillikar
			CISCO Systems
			375 East Tasman Drive,
			San Jose, CA 95134
			Email: dsatya@cisco.com
	Ayan Banerjee		Ayan Banerjee
	Consultant		Consultant
	Email: ayabaner@gmail.com		Email: ayabaner@gmail.com
	Sam Aldrin		Sam Aldrin
	HuaWei Technologies		HuaWei Technologies
	2330 Central Expressway		2330 Central Expressway
	Santa Clara, CA 95951, USA		Santa Clara, CA 95951, USA
	Email: aldrin.ietf@gmail.com		Email: aldrin.ietf@gmail.com
End of changes. 17 change blocks.
	76 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/