TRILL Working Group Tissa Senevirathne Internet Draft Ayan Banerjee Intended status: Standard Track Les Ginsberg CISCO Sam Aldrin HuaaWei March 26, 2012 Expires: September 2012 Multi Topology Encoding within TRILL data frames draft-tissa-trill-mt-encode-00.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 September 26, 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 Senevirathne Expires September 26, 2012 [Page 1] Internet-Draft draft-tissa-trill-mt-encode-00 March 2012 carefully, as they describe your rights and restrictions with respect to this document. Abstract Two alternative 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. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Multi Topology Encoding........................................4 3.1. Use of Next-Hop VLAN for MT Encoding......................4 4. Interoperability...............................................5 4.1. Interoperability during Migration.........................5 4.2. Interoperability with RBridges with Non MT capable data plane..........................................................6 5. IS-IS sub-TLV definition.......................................7 5.1. MT capability.............................................7 6. Security Considerations........................................7 7. Assignment Considerations.....................................7 7.1. IANA Considerations.......................................7 7.2. IEEE Considerations.......................................7 8. References.....................................................7 8.1. Normative References......................................7 8.2. Informative References....................................8 9. Acknowledgments................................................8 Authors' Addresses................................................8 1. Introduction Multi Topology is an attractive concept that allows to create different virtual or overlays on top of a single physical topology. There are several important applications. Few of such are listed below. The list below is 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 Senevirathne Expires September 26, 2012 [Page 2] Internet-Draft draft-tissa-trill-mt-encode-00 March 2012 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 12bit 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 [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] 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]. Senevirathne Expires September 26, 2012 [Page 3] Internet-Draft draft-tissa-trill-mt-encode-00 March 2012 3. Multi Topology Encoding [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. Figure 1 below depicts the proposed encoding. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TRILL Header | . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Payload . . . | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Encoding of MT ID in TRILL Required extensions to the IS-IS HELLO to support MT ID encoding is presented in the section x. 3.1. 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. Senevirathne Expires September 26, 2012 [Page 4] Internet-Draft draft-tissa-trill-mt-encode-00 March 2012 For sake of simplicity, we propose to map topology-id to Next-VLAN based on local policies such as configuration. 4. Interoperability There are two 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) 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 September 26, 2012 [Page 5] Internet-Draft draft-tissa-trill-mt-encode-00 March 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 reduce the need for multiple physical Senevirathne Expires September 26, 2012 [Page 6] Internet-Draft draft-tissa-trill-mt-encode-00 March 2012 links. This method may be utilized as a permanent method for MT encoding in Point-Pont only networks. 5. IS-IS sub-TLV definition 5.1. 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.1. When both of the flags are set RBRridge SHOULD select MT Encoding capability. 6. Security Considerations TBD 7. Assignment Considerations 7.1. IANA Considerations IANA is requested to allocate MT Encoding capability Flag and MT to NH-VLAN Encoding capability Flags under Port TRILL version sub-TLV.. 7.2. IEEE Considerations IEEE is requested to assign new Ether Type to represent MT-ETHTYPE defined in section 3. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Senevirathne Expires September 26, 2012 [Page 7] Internet-Draft draft-tissa-trill-mt-encode-00 March 2012 [RF5120] Przygienda, T. et.al , "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate System (IS- ISs)", RFC 5120, February, 2008. 8.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. 9. 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 Senevirathne Expires September 26, 2012 [Page 8] Internet-Draft draft-tissa-trill-mt-encode-00 March 2012 Ayan Banerjee CISCO Systems 425 East Tasman Drive, San Jose, CA 95134 Phone: +1-408-527-0539 Email: ayabaner@cisco.com Les Ginsberg CISCO Systems 510 McCarthy Blvd, Milpitas, CA 95035. Email: ginsberg@cisco.com Sam Aldrin HuaWei Technologies 2330 Central Expressway Santa Clara, CA 95951, USA Email: aldrin.ietf@gmail.com Senevirathne Expires September 26, 2012 [Page 9]