[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 draft-ietf-trill-cmt

TRILL Working Group                                  Tissa Senevirathne
Internet Draft                                                    CISCO
Intended status: Standard Track                    Janardhanan Pathangi
                                                                   DELL
                                                             Jon Hudson
                                                                Brocade

                                                        January 5, 2012
Expires: July 2012



                Coordinated Multicast Trees (CMT)for TRILL
                       draft-tissa-trill-cmt-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 July 5, 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 July 5, 2012                  [Page 1]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   TRILL facilitates loop free connectivity to non TRILL legacy
   networks via choice of an Appointed Forwarder for set of VLANs.
   Appointed Forwarder provides VLAN level load sharing with active-
   standby model. Mission critical operations such as High Performance
   Data Centers require active-active load sharing model. Active-Active
   load sharing model can be accomplished by representing any given non
   TRILL legacy network with a single virtual RBridge. Virtual
   representation of the non-TRILL legacy network with a single RBridge
   poses serious challenges in multi-destination RPF calculations. This
   document presents the required enhancements to build Coordinated
   Multicast Trees (CMT) within the TRILL campus. CMT provides
   flexibility to RBridges to select desired path of association to a
   given distribution tree.

Table of Contents


   1. Introduction...................................................3
      1.1. Contributors..............................................4
   2. Conventions used in this document..............................5
   3. IS-IS extension................................................5
      3.1. AFFINITY TLV..............................................5
   4. Multicast Tree Construction and use of Affinity Sub-TLV........7
      4.1. Update to RFC 6325........................................8
      4.2. Announcing virtual RBridge nickname.......................9
      4.3. Affinity Sub-TLV capability...............................9
   5. Theory of operation............................................9
      5.1. Distribution Tree provisioning............................9
      5.2. Affinity Sub-TLV advertisement............................9
      5.3. Affinity sub-TLV conflict resolution.....................10
      5.4. Ingress Multi-Destination Forwarding.....................10
         5.4.1. Forwarding when n < k...............................10
      5.5. Egress Multi-Destination Forwarding......................11
         5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv.....11
         5.5.2. Traffic Arriving on other Trees.....................11
      5.6. Failure scenarios........................................11
         5.6.1. Edge RBridge RBk failure............................11
      5.7. Backward compatibility...................................12
   6. Security Considerations.......................................12
   7. IANA Considerations...........................................13
   8. References....................................................13
      8.1. Normative References.....................................13


Senevirathne             Expires July 5, 2012                  [Page 2]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


      8.2. Informative References...................................13
   9. Acknowledgments...............................................13
   10. Authors' Addresses...........................................14

1. Introduction

   TRILL presented in [RFC6325] and other related documents, provide
   methods of utilizing all available paths for active forwarding, with
   minimum configuration. TRILL utilizes IS-IS as control plane and
   encapsulates native frames with a TRILL header.

   Legacy networks utilize IEEE 802.1D Spanning Tree Protocol as the
   control protocol and utilizes at any given time, a single path among
   all available paths for active forwarding. Legacy networks forward
   frames in "native" format.

   [RFC6325],[RFC6327] and [RFC6439] provide methods for
   interoperability between TRILL and Legacy networks. [RFC6439],
   provide active-standby solution, where only one of the RBridges is
   in active forwarding state for any given VLAN. The RBridge in active
   forwarding state for any given VLAN is referred to as the Appointed
   Forwarder (AF). All frames ingressing into a TRILL network via the
   Appointed Forwarder are encapsulated with the TRILL header with a
   nickname held by the ingress AF RBridge. Due to failures, re-
   configurations and other network dynamics, Appointed Forwarder for
   any set of VLANs may change. RBridges maintain forwarding table that
   contain destination MAC address to egress RBridge binding. In the
   event of AF change, forwarding tables of remote RBridges may
   continue to forward traffic to the previous AF and may get discarded
   at the egress, causing traffic disruption.

   Mission critical applications such as High Performance Data Centers
   require resiliency during failover. The active-active forwarding
   model minimizes impact during failures and maximizes the available
   network bandwidth. A typical deployment scenario, depicted in Figure
   2, which may have either End Stations and/or Legacy bridges attached
   to the RBridges.  These Legacy devices typically are multi-homed to
   several RBridges and treats all of the uplinks as a single Link
   Aggregation (LAG) bundle. The Appointed Forwarder designation
   presented in [RFC6439] requires each of the edge RBridges to
   exchange TRILL hello packets. By design, a LAG does not forward
   packets received on one of the member ports of the LAG to other
   member ports of the same LAG. As a result AF designation methods
   presented in [RFC6439] cannot be applied to deployment scenario
   depicted in Figure 2




Senevirathne             Expires July 5, 2012                  [Page 3]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


   An active-active load sharing model can be implemented by
   representing the edge of the network connected to a specific group
   of RBridges by a single virtual RBridge. In addition to an active-
   active forwarding model, there may be other applications that may
   requires similar representations.

   Sections 4.5.1 and 4.5.2 of [RFC6325] specify distribution tree
   calculation and Reverse Path Forwarding Check calculation algorithms
   for multi-destination forwarding. The algorithms specified in
   [RFC6325], strictly depends on link cost and parent RBridge
   priority. As a result, based on the network topology, it may be
   possible that a given edge RBridge, if it is forwarding on behalf of
   the virtual RBridge, may not have a candidate multicast tree that
   the edge RBridge can forward traffic on because there is no tree for
   which the virtual RBridge is a leaf node from the edge RBridge.

   In this document we present a method that allows RBridges to specify
   the path of association to distribution trees. Remote RBridges
   calculate the SPF and derive the RPF for distribution trees based on
   the distribution tree association advertisements. In the absence of
   distribution tree association advertisements, remote RBridges derive
   the SPF based on the algorithm specified in section 4.5.1 of [RFC
   6325].

   Other applications, beside the above mentioned active-active
   forwarding model, may utilize the distribution tree association
   framework presented in this document to associate to distribution
   trees through a preferred path.

   This proposal requires presence of multiple multi-destination trees
   within the TRILL campus and updating all the RBridges in the network
   to support the new Affinity sub-TLV. It is expected that both of
   these requirements will be met as they are control plane changes,
   and will be common deployment scenario. In case any of the above two
   conditions are not met RBridges MUST support a fallback option for
   interoperability. Since the fallback is expected to be a temporary
   phenomenon till all RBridges are upgraded, this proposal gives
   guidelines for such fallbacks, and does not mandate or specify any
   specific set of fallback options.

1.1. Contributors

   The work in this document is a result of much passionate discussions
   and contributions from following individuals. Their names are listed
   in alphabetical order and do not in any means intended to be ranked
   in any other way.



Senevirathne             Expires July 5, 2012                  [Page 4]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


   Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Mingui Zhang, Radia
   Perlman, Shivakumar Sundaram.

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

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying [RFC2119] significance.



3. IS-IS extension



3.1. AFFINITY TLV

   Association of a RBridge to a multicast tree through a specific path
   is accomplished by using a new IS-IS sub-TLV, Affinity TLV.

   AFFINITY TLV is a sub-TLV under Router capability TLV (242) [RFC
   4971]. [RFC6326bis] formally defines the Affinity sub-TLV. The
   details of the Affinity sub-TLV are presented for clarity and
   readers are encouraged to refer to [RFC6326bis] for latest updates.





















Senevirathne             Expires July 5, 2012                  [Page 5]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


      +-+-+-+-+-+-+-+-+
      |Type=AFFNITYTLV|                (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                (1 byte)
      +---------------+---------------+
      | nickname                      |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | number of trees               |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |tree-num of 1st preferred root |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |tree-num of 2nd preferred root |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                               .
      +-------------------------------+
      |tree-num of Nth preferred root |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1 Affinity TLV structure

     o Type: AFINITYTLV, (TBD).

     o Length: 4 + 2*n, where n is the number of nicknames of affinity
        trees listed tree numbers.

     o Nickname : TRILL 16bit nickname of the RBridge whose
        association to the listed multicast trees are through the
        announcing RBRidge.

     o Number of trees : number of trees for which association
        (affinity) being announced.

     o  Tree-num of preferred root: The tree Number of the multicast
        tree.















Senevirathne             Expires July 5, 2012                  [Page 6]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


4. Multicast Tree Construction and use of Affinity Sub-TLV

            ------------------
           /                    \
          |                      |
          | TRILL Campus         |
          |                      |
           \                     /
            ---------------------
               |       |    |
   |           |       |     ----------
            DRB|       |              |
           +------+ +------+      +------+
           |      | |      |      |      |
           |(RB1) | |(RB2) |      | (RBk)|
           +------+ +------+      +------+
               |       |               |
               |       |    -----------    ----
               |       |   |    -------------  |
                -----  |   |    -----------  | |
            LAG---->(| |   | )            (| | |) LAG
                    +-------+    . .  .  +-------+
                    | CE1   |            | CEn   |
                    |       |            |       |
                    +-------+            +-------+

                        Figure 2 Reference Topology






















Senevirathne             Expires July 5, 2012                  [Page 7]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


            ------------------              Sample Multicast Tree (T1)
           /                    \
          |                      |                  |
          | TRILL Campus         |                  o RBn
          |                      |                / | \
           \                     /               /  |  ---\
            ---------------------             RB1o  o      o
               |       |    |                    |   RB2    RBk
   |           |       |     ----------          |
            DRB|       |              |          oRBv
           +------+ +------+      +------+
           |      | |      |      |   |
           |(RB1) | |(RB2) |      | (RBk)|
           +------+ +------+      +------+
            ooo|ooooooo|oooooooooooooo|oo
           o                             o
           o  virtual RBridge RBv        o
            ooo|ooooooo|ooo|ooooooooooooo  ----
               |       |   |       ----------  |
                -----  |   |     ----------  | |
            LAG---->(| |   | )            (| | | )  LAG
                    +-------+    . .  .  +-------+
                    | CE1   |            | CEn   |
                    |       |            |       |
                    +-------+            +-------+

                     Figure 3 Example Logical Topology



4.1. Update to RFC 6325

   Section 4.5.1 of [RFC6325], is updated as below:

   Each RBridge that desires to be a parent RBridge for a specific
   multi-destination distribution tree x for child RBridge RBy or
   nickname Ny (in the event of announcing multiple nicknames),
   announces the desired association through Affinity sub-TLV.

   When such an Affinity sub-TLV is present, the association specified
   by the affinity sub-TLV MUST be used when constructing the SPF tree.
   In the absence of such Affinity sub-TLV, or if there are RBRidges in
   the network that are do not support Affinity sub-TLV, SPF tree is
   calculated as specified in the section 4.5.1 of [RFC6325]. Section
   4.3. below explains methods of identifying RBridges that support
   Affinity sub-TLV capability.



Senevirathne             Expires July 5, 2012                  [Page 8]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


4.2. Announcing virtual RBridge nickname

   Each edge RBridge RB1 to RBk advertise virtual RBridge nickname RBv
   using nickname sub-TLV (6), [RFC6326bis], along with their original
   nicknames RBi, RBj.

4.3. Affinity Sub-TLV capability.

   RBridges that announce the TRILL version sub-TLV [RFC6326bis] and
   set the Affinity capability bit (section 7. ) support the Affinity
   sub-TLV and calculation of multi-destination distribution trees as
   specified herein.

5. Theory of operation

5.1. Distribution Tree provisioning

   Let's assume there are n distribution trees and k edge RBridges in
   the edge group of interest.

   If n >= k

     Let's assume edge RBridges are sorted in numerically ascending
     order by SystemID such that RB1 < RB2 < RBk. Each Rbridge in the
     numerically sorted list is assigned a monotonically increasing
     number j such that; RB1=0, RB2=1, RBi=j and RBi+1=j+1.



     Assign each tree to RBi such that tree number { (tree_number) %
     k}+1 is assigned to RBridge i for tree_number from 1 to n. where n
     is the number of trees and k is the number of RBridges considered
     for tree allocation.

   If n < k

     Distribution trees are assigned to RBridges RB1 to RBn, using the
     same algorithm as n >= k case. RBridges RBn+1 to RBk do not
     participate in active-active forwarding process on behalf of RBv.

5.2. Affinity Sub-TLV advertisement

   Each RBridge in the RB1..RBk domain advertises Affinity TLV on
   behalf of RBv.

   As an example, let's assume that RB1 has chosen Trees t1 and tk+1 on
   behalf of RBv.


Senevirathne             Expires July 5, 2012                  [Page 9]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


   RB1 advertises affinity TLV; {RBv, Num of Trees=2, t1, tk+1.

   Other RBridges in the RB1..RBk edge group follow the same procedure.

5.3. Affinity sub-TLV conflict resolution

   If different RBridges advertise Affinity sub-TLVs that try to
   associate the same virtual RBridge as their child in the same tree
   or trees, those Affinity sub-TLVs are in conflict for those trees.
   The nicknames of the conflicting RBridges are compared to identify
   which RBridge holds the nickname that is the highest priority to be
   a tree root, with the System ID as the tie breaker

   The RBridge with the highest priority to be a tree root will retain
   the Affinity association. Other RBridges with lower priority to be a
   tree root MUST stop advertising their conflicting Affinity sub-TLV,
   re-calculate the multicast tree affinity allocation, and, if
   appropriate, advertise a new non-conflict Affinity sub-TLV.

   Similarly, remote RBridges MUST honor the Affinity sub-TLV from the
   RBridge with the highest priority to be a tree root and ignore the
   conflicting Affinity sub-TLV entries advertised by the RBridges with
   lower priorities to be tree roots.

5.4. Ingress Multi-Destination Forwarding

   If there is at least one tree on which RBv has affinity via RBk ,
   then RBk performs the following operations, for multi-destination
   frames received from a CE node:

   1. Flood to locally attached CE nodes subjected to VLAN and multicast
     pruning.
   2. Encapsulate in TRILL header and assign ingress RBridge nickname as
     RBv. (nickname of the virtual RBridge).
   3. Forward to one of the distribution trees, tree x in which RBv is
     associated with RBk


5.4.1. Forwarding when n < k

     If there is no tree on which RBv can claim affinity via RBk
     (Probably because the number of trees n built is less than number
     of RBridges k announcing the affinity sub-TLV), then RBk MUST fall
     back to one of the following

     1. This RBridge should stop forwarding frames from the CE nodes,
        and should mark its link as passive. This will prevent CE nodes


Senevirathne             Expires July 5, 2012                 [Page 10]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


        from forwarding data on to this RBridge, and only use those
        RBridges which have been assigned a tree -OR-
     2. This RBridge tunnels multi-destination frames received from
        attached native devices to an RBridge RBy that has an assigned
        tree. The tunnel destination should forward it to the TRILL
        network, and also to its local access links .  (The mechanism
        of tunneling and handshake between the tunnel source and
        destination are out of scope of this specification and may be
        addressed in future documents).

   Above fallback options may be very specific to active-active
   forwarding scenario. However, as stated above, Affinity sub-TLV may
   be used  in other applications. In such event the application SHOULD
   specify applicable fallback options.

5.5. Egress Multi-Destination Forwarding

5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv

   Multi-destination frames arriving at RBk on a Tree x, where RBk has
   announced the affinity of RBv via x, MUST be forwarded to CE members
   of RBv. Forwarding to other end-nodes and RBridges that are not part
   of the network represented by the RBv virtual RBridge MUST follow
   the forwarding rules specified in [RFC6325].

5.5.2. Traffic Arriving on other Trees

   Multi-destination frames arriving at RBk on a Tree y, where RBk has
   not announced the affinity of RBv via y, MUST NOT be forwarded to CE
   members of RBv. Forwarding to other end-nodes and RBridges that are
   not part of the network represented by the RBv virtual RBridge but
   MUST follow the forwarding rules specified in RFC6325.

5.6. Failure scenarios

5.6.1. Edge RBridge RBk failure

   Each of the member RBridges of given virtual RBridge edge group is
   aware of its member RBridges through configuration or some other
   method.

   Member RBridges detects nodal failure of a member RBridge through
   IS-IS LSP advertisements or lack thereof.

   Upon detecting a member failure, each of the member RBridges of the
   RBv edge group start recovery timer T_rec for failed RBrdige RBi. If
   the previously failed RBridge RBi has not recovered after the expiry


Senevirathne             Expires July 5, 2012                 [Page 11]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


   of timer T_rec, members RBridges perform distribution tree
   assignment algorithm specified in section 5.1. Each of the member
   RBridges re-advertises the Affinity sub-TLV with new tree
   assignment. This action causes the campus to update the tree
   calculation with the new assignment.

   RBi upon start-up, starts advertising its presence through ISIS LSP
   and starts a timer T_i. Member RBridges detecting the presence of RB
   start a timer T_j. Timer T_j SHOULD be at least < T_i/2. (Please see
   note below)

   Upon expiry of timer T_j, member RBridges recalculate the multi-
   destination tree assignment and advertised the related trees using
   Affinity sub-TLV.

   Upon expiry of timer T_i, RBi recalculate the multi-destination tree
   assignment and to advertised the related trees using Affinity TLV.

   Note: Timers T_i and T_j are designed such that to minimize traffic
   down time and avoid multi-destination packet duplication.

   Above failure recovery algorithm is presented as a guideline.
   Implementations MAY include other failure recover algorithms.
   Details of such algorithms are outside the scope of this document.

5.7. Backward compatibility

   Implementations MUST support backward compatibility mode to
   interoperate with pre Affinity sub-TLV RBRidges in the network. Such
   backward compatibility operation MAY include, however is not limited
   to, tunneling and/or active-standby modes of operations.

   Example:

   Step 1.  Stop using virtual RBRidge nickname for traffic ingressing
     from CE nodes
   Step 2.  Stop performing active-active forwarding. And fall back to
     active standby forwarding, based on locally defined policies.
     Definition such policies are outside the scope of this document
     and may be addressed in future documents.

6. Security Considerations

   Security considerations are similar to RFC 6325,RFC 6326 and RFC
   6327. Additional security considerations are being discussed.




Senevirathne             Expires July 5, 2012                 [Page 12]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


7. IANA Considerations

   IANA is requested to allocate a capability bit for "Affinity
   Supported" in the TRILL-VER sub-TLV. "Affinity Supported" capability
   bit and Affinity sub-TLV are specified and allocated in
   [RFC6326bis].


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.

   [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol
             Specification", RFC 6325, July 2011.

   [RFC6327] Eastlake, D. et.al., "RBridge: Adjacency", RFC 6327, July
             2011.

   [RFC6349] Eastlake, D. et.al., "RBridge: Appointed Forwarder", RFC
             6349, November 2011.

   [RFC6326bis] Eastlake, D. et.al., "Transparent Interconnection of
             Lots of Links (TRILL) Use of IS-IS", draft-eastlake-isis-
             rfc6326bis-02.txt, Work in Progress, December 2011.

8.2. Informative References

   [RFC6165] Banerjee, A. and Ward, D. "Extensions to IS-IS for Layer-2
             Systems", RFC 6165, April 2011.

   [RFC4971] Vasseur, JP. et.al "Intermediate System to Intermediate
             System (IS-IS) Extensions for Advertising Router
             Information", RFC 4971, July 2007.

9. Acknowledgments

   Authors wish to extend their appreciations towards individuals who
   volunteered to review and comment on the work presented in this
   document and provided constructive and critical feedback. Specific
   acknowledgements are due for Ronak Desai, Gayatri Ramachandran,
   Varun Shah and Anoop Ghanwani.

   This document was prepared using 2-Word-v2.0.template.dot.



Senevirathne             Expires July 5, 2012                 [Page 13]


Internet-Draft  Coordinated Multicast Trees for TRILL      January 2012


10. Authors' Addresses

   Tissa Senevirathne
   Cisco Systems
   375 East Tasman Drive,
   San Jose, CA 95134

   Phone: 408-853-2291
   Email: tsenevir@cisco.com


   JanardhananPathangi
   Dell/Force10 Networks
   Olympia Technology Park,
   Guindy Chennai 600 032

   Phone: +91 44 4220 8400
   Email: Pathangi_Janardhanan@Dell.com


   Jon Hudson
   Brocade
   130 Holger Way
   San Jose, CA 95134 USA

   Email: jon.hudson@gmail.com























Senevirathne             Expires July 5, 2012                 [Page 14]


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