TRILL Working Group Tissa Senevirathne Internet Draft Les Ginsberg Intended status: Standard Track CISCO Ayan Banerjee Consultant Sam Aldrin HuaaWei Naveen Nimmu Broadcom June 17, 2012 Expires: December 2012 Multi Topology Encoding within TRILL data frames draft-tissa-trill-mt-encode-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 17, 2012. Senevirathne Expires December 17, 2012 [Page 1] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Two alternate methods of encoding Multi Topology Identifier within the TRILL data frames are presented. Methods proposed herein do not require overloading TRILL RBridge nickname to encode Multi Topology Identifier. A method that expands TRILL nickname space from 16bits to 24 bits is also presented in this draft. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................4 3. Multi Topology Encoding and nickname Expansion.................4 3.1. Nickname construction.....................................5 3.2. Use of Next-Hop VLAN for MT Encoding......................6 4. Multi Topology Interoperability................................6 4.1. Interoperability during Migration.........................6 4.2. Interoperability with RBridges with Non MT capable data plane..........................................................7 4.3. Interoperability with MT unaware RBRdiges.................8 5. Backward compatibility.........................................8 6. IS-IS sub-TLV definition.......................................8 6.1. Nickname MSB capability...................................8 6.1.1. TRILL sub-TLVs for 24bit nicknames...................8 6.2. MT capability.............................................9 7. Security Considerations........................................9 8. Assignment Considerations.....................................9 8.1. IANA Considerations.......................................9 8.2. IEEE Considerations......................................10 9. References....................................................10 9.1. Normative References.....................................10 9.2. Informative References...................................10 10. Acknowledgments..............................................11 Authors' Addresses...............................................11 Senevirathne Expires December 17, 2012 [Page 2] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 1. Introduction Multi Topology is an attractive concept that allows creating different virtual topologies or overlays on top of a single physical topology. There are several important applications. Few such applications are listed below. The list below is by no means an exhaustive list and there are other applications that may utilize the MT framework. Application specific topology (Storage topology vs. data topology) Virtual topologies for different customers Expansion of TRILL nickname space Traffic Engineering [RFC5120] presents Multi topology (MT) framework for IS-IS. MT has two important parts; IS-IS control plane extensions and Data plane encoding. [RFC5120] presents IS-IS control plane extensions. [TRILL- MT1] and [TRILL-MT2] presents required IS-IS sub-TLV definitions and the data plane encoding for TRILL. In this document we propose methods that facilitate encoding of 16 bit Multi topology ID in to TRILL frames without reducing the effective TRILL nickname space. Additionally, the proposed scheme does not require definition of new Topology mapping sub-TLV. In other words, IS-IS control plane is similar to [RFC5120] and does not require additional complexity of mapping absolute Topology ID to abbreviated topology ID. Methods proposed in this document encode the MT topology ID into TRILL data frames without modifying the TRILL header. Hence, MT capable, RBridges interfacing with non-MT capable RBridges can selectively not encode the proposed MT extensions on interfaces with non-MT capable RBridges. Non MT capable RBridges do not required to be in the base topology. They can be in any valid topology. Only restriction is non-MT capable RBridges can belong to a single topology only. In its IS-IS HELLO messages, RrRidges exchange its MT capability and topology information. RBridges that are not capable of supporting proposed MT extension in data plane, MUST announce itself as non MT capable, but MAY advertise its association to a topology other than the base topology by including MT extensions proposed in [RFC5120]. MT encoding capability is announced by setting the proposed MT encoding capability bit in Port TRILL Version sub-TLV [rfc6326bis]. Presence of IS-IS Multi Topology TLV Senevirathne Expires December 17, 2012 [Page 3] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 [RFC5120], indicates only the associated topology. MT encoding capability indicates RBRidges ability to support proposed data plane extensions. When MT capability is not set RBridge MUST not use the proposed data plane encoding methods, instead it must associate the announcing RBRidge to the advertised topology or base topology in the absence of Multi-Topology TLV [RFC5120]. TRILL protocol, as defined in [RFC6325], defines 16bit nickname space. 16bit nickname space allows up to 65536 unique nicknames. However, it has been discussed in the working group that, more the 65536 unique names are required in certain large deployments. Possible usage of Upperbits of Nickname is also being considered for encoding Multitoplogy, which further reduces the available nick name space. Presented in this document is a method that allows expanding the 16bit nickname space to a 24bit nickname space, without modifying the TRILL header defined in [RFC6325]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. Multi Topology Encoding and nickname Expansion [RFC6325] TRILL Base Protocol, proposes encoding scheme of TRILL frames. TRILL frames contain outer MAC Header, 802.1QTAG, TRILL 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- 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. Senevirathne Expires December 17, 2012 [Page 4] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 Outer Ethernet Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ethertype = MT-ETHTYPE | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ethertype = NICKN-ETHTYPE |EG-NICKN-MSB | IG-NICKN-MSB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TRILL Header | . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Payload . . . | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 MT ID /NICKN MSB extentions in TRILL Ethtype-MT : 16 bit Ethtype to encode Multi Topology ID. MT-ID : 16bit Multi Topology IDNICKN-Ethtype : 16 bit Ethtype to 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 Each RBridge that is compatible with the proposed scheme, First 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 concatenated with the Egress TRILL nickname and the Ingress TRILL nickname to form 24bit nickname space. The derived nickname MUST be utilized for forwarding. Senevirathne Expires December 17, 2012 [Page 5] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 3.2. Use of Next-Hop VLAN for MT Encoding Alternatively, Next-Hop VLAN may be utilized to encode MT ID in point to point only networks. Next Hop VLAN on TRILL outer header is independent of the inner VLAN. On Point-Pont links Next Hop VLAN is only required to be of local significance. Hence, we propose to map topologies to Next-Hop VLAN per link basis. For sake of simplicity, we propose to map topology-id to Next-VLAN based on local policies such as configuration. 4. Multi Topology Interoperability There are three possible scenarios of Interoperability with RBridges that are non-MT capable. 1. Interoperability During migration. 2. Interoperability with RBridges that are non-MT capable in the data plane. (i.e. Software is MT aware and supports the extensions specified here-in but, data plane is not capable of supporting the proposed encoding methods). 3. Interoperability with Rbridges that are MT unaware in both Control and data planes. 4.1. Interoperability during Migration We recommend upgrading from the core to the edge, as depicted in the figure below. With this approach, different clusters of RBridges may belong to different topologies or to the same topology. RBridges in the core provide connectivity to RBridge clusters at the edge in a topology aware manner. Senevirathne Expires December 17, 2012 [Page 6] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 +-----------+ | | Edge-1 to Edge 4 are | Edge-1 | RBridge clusters that are | | Non MT aware | | +-----------+ o | o +---------------+ +----------+ | | | | | Core (Topology| +----------+ |Edge 3 |o--------o| aware) | | | | | | Topologies |o--------o| Edge 4 | +----------+ | T1 and T2 | | | | | +----------+ +---------------+ o | O +-----------+ | | |Edge 2 | | | | | +-----------+ Figure 1 MT aware interconnect In the above diagram Core may be configured to connect Edge 1 and Edge 2 to a different Topology than the topology of Edge 3 and Edge 4. RBridges in Edge 1 - 4 are not required to be MT capable or aware. RBridges in the core associate the corresponding links to the appropriate topology. 4.2. Interoperability with RBridges with Non MT capable data plane RBridges with Non MT capable data plane may implement MT support by dedicating a separate link for each topology. Alternatively, RBRidges, on point-point links may assign a different next hop VLAN for different topologies and derive topology ID based on VLAN. Use Next-Hop VLAN reduces the need for multiple physical Senevirathne Expires December 17, 2012 [Page 7] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 links. This method may be utilized as a permanent method for MT encoding in Point-Pont only networks. 4.3. Interoperability with MT unaware RBRdiges MT aware RBridges identify MT unaware RBridges with either not presence of capability flags (pre RFC6326bis) or MT capability flags not being set (Section 6.2. ). In such an event MT aware RBridges MUST only forward traffic related to the base topology to MT unaware RBridges. Additionally, proposed encoding MUST be removed prior to forwarding to MT unaware RBRidges. 5. Backward compatibility The proposed methods are encoded as part of the outer header of the TRILL frame. An RBridge that is aware of the proposed extensions when interfacing with an RBridge that is not capable of the proposed extensions MUST remove the proposed encoding from the outer header, prior to transmission of TRILL frames on those links that has RBridges that are not capable of the proposed extensions. 6. IS-IS sub-TLV definition 6.1. Nickname MSB 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 Senevirathne Expires December 17, 2012 [Page 8] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 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 Version sub-TLV. 1. MT Encoding capability 2. MT to NH-VLAN Encoding capability MT Encoding capability flag indicates the RBridge is capable encoding MT ID using ETHTYPE-MT as defined in section 3. MT to NH-VLAN Encoding capability flag indicates the announcing RBRidge is capable of using NH-VLAN to MT ID mapping as presented in section 3.2. When both of the flags are set RBRridge SHOULD select MT Encoding capability. 7. Security Considerations TBD 8. Assignment Considerations 8.1. IANA Considerations IANA is requested to allocate MT Encoding capability Flag,MT to NH- VLAN Encoding capability Flags and Nickname MSB capability flag 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: Senevirathne Expires December 17, 2012 [Page 9] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 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 IEEE is requested to assign new Ether Type to represent MT-ETHTYPE defined in section 3. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RF5120] Przygienda, T. et.al , "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate System (IS- ISs)", RFC 5120, February, 2008. 9.2. Informative References [TRILL-MT1] Manral,V. et.al., "Multiple Topology Routing Extensions for Transparent Interconnection of Lots of Links (TRILL)", draft-manral-isis-trill-multi-topo-03, Work in Progress, December, 2011. [TRILL-MT2] Eastlake, D. et.al., "Multi Topology TRILL", draft- eastlake-trill-rbridge-multi-topo-02, Work in Progress, January, 2012. [rfc6326bis] Eastlake, D. et.al., "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", draft-eastlake-isis- rfc6326bis-02, Work in Progress, December, 2011. Senevirathne Expires December 17, 2012 [Page 10] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 10. Acknowledgments Special acknowledgment to Dinesh Dutt, for encouragements, support and coming up with the initial idea. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Tissa Senevirathne CISCO Systems 375 East Tasman Drive, San Jose, CA 95134 Phone: +1-408-853-2291 Email: tsenevir@cisco.com Les Ginsberg CISCO Systems 510 McCarthy Blvd, Milpitas, CA 95035. Email: ginsberg@cisco.com Ayan Banerjee Consultant Email: ayabaner@gmail.com Senevirathne Expires December 17, 2012 [Page 11] Internet-Draft draft-tissa-trill-mt-encode-01 June 2012 Sam Aldrin HuaWei Technologies 2330 Central Expressway Santa Clara, CA 95951, USA Email: aldrin.ietf@gmail.com Naveen Nimmu Broadcom th 9 Floor, Building no 9, Raheja Mind space Hi-Tec City, Madhapur, Hyderabad - 500 081 India. Email: naveen@broadcom.com Senevirathne Expires December 17, 2012 [Page 12]