[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

TRILL Working Group                                  Tissa Senevirathne
Internet Draft                                             Les Ginsberg
                                                         Satya Dillikar
Intended status: Standard Track                                   CISCO

                                                          Ayan Banerjee
                                                             Consultant

                                                             Sam Aldrin
                                                                HuaaWei

                                                            Naveen Nimmu
                                                                Broadcom

                                                     September 11, 2012
Expires: March 2013



             Multi Topology Encoding within TRILL data frames
                    draft-tissa-trill-mt-encode-02.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 December 11, 2012.






Senevirathne            Expires March 11, 2013                 [Page 1]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 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........................................4
      3.1. Nickname construction.....................................5
      3.2. Use of Next-Hop VLAN for MT Encoding......................5
   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. MT capability.............................................8
   7. Security Considerations........................................9
   8. Assignment  Considerations.....................................9
      8.1. IANA Considerations.......................................9
      8.2. IEEE Considerations.......................................9
   9. References.....................................................9
      9.1. Normative References......................................9
      9.2. Informative References....................................9
   10. Acknowledgments...............................................9
   Authors' Addresses...............................................10




Senevirathne            Expires March 11, 2013                 [Page 2]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 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
   [RFC5120], indicates only the associated topology. MT encoding


Senevirathne            Expires March 11, 2013                 [Page 3]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 2012


   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

   [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.
















Senevirathne            Expires March 11, 2013                 [Page 4]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 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                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             TRILL Header                                      |
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .              Payload                                          .
   .                                                               .
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1  MT ID extensions 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.

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.



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


Senevirathne            Expires March 11, 2013                 [Page 5]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 2012


   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 March 11, 2013                 [Page 6]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 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 March 11, 2013                 [Page 7]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 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.1. ). 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. 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.









Senevirathne            Expires March 11, 2013                 [Page 8]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 2012


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.

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.

10. Acknowledgments

   Special acknowledgment to Dinesh Dutt, for encouragements, support
   and coming up with the initial idea.


Senevirathne            Expires March 11, 2013                 [Page 9]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 2012


   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


   Satya Dillikar
   CISCO Systems
   375 East Tasman Drive,
   San Jose, CA 95134

   Email: dsatya@cisco.com


   Ayan Banerjee
   Consultant

   Email: ayabaner@gmail.com














Senevirathne            Expires March 11, 2013                [Page 10]


Internet-Draft      draft-tissa-trill-mt-encode-02       September 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 March 11, 2013                [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/