TRILL Weiguo Hao Yizhou Li Zhibo Hu Internet Draft Huawei Intended status: Standards Track February 14, 2014 Expires: August 2014 Frame Duplication Avoidance For TRILL Active-Active Access draft-hao-trill-dup-avoidance-active-active-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 Hao & Li,etc Expires August 14, 2014 [Page 1] Internet-Draft Frame Duplication Avoidance in TRILL February 2014 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 August 14, 2009. Copyright Notice Copyright (c) 2014 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 The problems in active-active connection to TRILL campus was introduced in [TRILL-Active-PS]. Frame duplication was a well recognized issue in that scenario. This draft proposes a Designated Forwarder (DF) mechanism to solve the issue of frame duplications. The basic idea is to elect one RBridge per VLAN from an edge group to be responsible for egressing the multicast frames. An edge group is a group of edge RBridges that a CE is multi-homed to in active- active mode. TRILL protocol extension for DF election is described in this draft. Hao & Li,etc Expires August 14, 2014 [Page 2] Internet-Draft Frame Duplication Avoidance in TRILL February 2014 Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 5 3. DF election mechanism overview............................... 5 4. DF election algorithm per VLAN............................... 6 5. Link and node failure process................................ 7 6. TRILL protocol extension..................................... 7 6.1. The LAGID TLV .......................................... 7 7. Security Considerations...................................... 8 8. IANA Considerations ......................................... 8 9. References .................................................. 8 9.1. Normative References.................................... 8 9.2. Informative References.................................. 8 10. Acknowledgments ............................................ 8 1. Introduction The IETF TRILL (Transparent Interconnection of Lots of Links) [RFC6325] protocol provides loop free and per hop based multipath data forwarding with minimum configuration. TRILL uses IS-IS [RFC6165] [RFC6326bis] as its control plane routing protocol and defines a TRILL specific header for user data. Customer edge(CE) devices typically are multi-homed to several RBridges which form an edge group. All of the uplinks of CE is considered as an Multi-Chassis Link Aggregation (MC-LAG) bundle. An active-active flow-based load-sharing mechanism is implemented to achieve better load balancing and high reliability. A CE device can be a layer3 end system by itself or a bridge switch through which layer3 end systems are accessed to TRILL campus. Draft [TRILL-Active-PS] lists basic problems which any active-active solutions should address: Hao & Li,etc Expires August 14, 2014 [Page 3] Internet-Draft Frame Duplication Avoidance in TRILL February 2014 +------+ | CEx | +------+ | +------+ |(RBx) | +------+ | ------------------- / \ | | | TRILL Campus | | | \ / -------------------- | | | -------- | -------- | | | +------+ +------+ +------+ |(RB1) | |(RB2) | | (RBk)| +------+ +------+ +------+ | | | | | ___________| |______ | | |LAG1 LAG2 | | +------+ +------+ | CE1 | | CE2 | +------+ +------+ Figure 1 TRILL Active-Active Access Scenario 1. Frame duplications 2. Loop 3. Address flip-flop 4. Unsynchronized information among member RBridges This document proposes a Designated Forwarder (DF) mechanism to solve the issue of frame duplications. Frame duplication may occur when a remote host sends multi-destination frame to a local CE which has active-active connection to the TRILL campus. The basic idea of DF is to elect one RBridge per VLAN from an edge group to be responsible for egressing the multicast traffic. An edge group is the group of edge RBridges that a CE is multi-homed to in active- Hao & Li,etc Expires August 14, 2014 [Page 4] Internet-Draft Frame Duplication Avoidance in TRILL February 2014 active mode. TRILL protocol extension can be easily extended to support DF election mechanism. 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]. This document uses the same terminology as found in the active- active problem statement draft [TRILL-Active-PS]. Some of the terms defined in the that document have been repeated in this section for the convenience of the reader, along with additional terminology that is used by this document. CE - customer equipment. Could be a bridge or end station. FGL -Fine Grained Label. Edge group - a group of edge RBs to which one CE is multiply Attached, a edge group corresponds to a MC-LAG. One RB can be in more than one edge group. 3. DF election mechanism overview Each CE is multi-homed to multiple edge RBs in active-active mode through an MC-LAG. These edge RBs form one edge group. An edge group corresponds to an MC-LAG. A RB may join multiple edge groups to provide active-active access for multiple CE devices. Each MC-LAG should be assigned a globally unique LAGID in network as identification. When an edge RB, say RB1, has any downlink port running in MC-LAG mode, the following DF election procedures are executed. 1. RB1 acquires the unique LAGID for that MC-LAG through manual or automatic provisioning. 2. RB1 then starts a timer (default value = 10 seconds) to allow the reception of LAGID TLV LSP from other RB nodes of same edge group. This timer value MUST be same across all RBs of same edge group. 3. RB1 announces self LAGID in TRILL LSP to TRILL campus before local timer expires. Hao & Li,etc Expires August 14, 2014 [Page 5] Internet-Draft Frame Duplication Avoidance in TRILL February 2014 4. All RBs that have same LAGID provisioned as in RB1's announcement discover each other and form an edge group. 5. DF election process starts when the timer expires. 6. Each RB in an edge group elects a DF using same algorithm which guarantees the same RB elected as DF per MC-LAG per VLAN. The RB that is elected as a DF for a given VLAN will unblocks multi- destination traffic in the egress direction towards the CE. All non- DF PEs continue to drop multi-destination traffic in the egress direction towards the CE. All edge RBs, including DF and non-DF, can ingress the traffic to TRILL campus as usual. On the other hand, only the elected DF RBridge can egress the multi-destination frame from TRILL campus to local access network. It ensures no duplicated frame received by local CE when a remote RB sends multicast traffic. 4. DF election algorithm per VLAN Assuming there are k RBs in an edge group, DF election algorithm per VLAN is as follows: 1. All RBs in an edge group are ordered and numbered from 0 to k-1 in ascending order according to the 7-octet IS-IS ID. 2. For VLAN ID m, choose RB whose number equals (m mod k) as DF. FGL are primarily intended for >4K tenants use in large Data Centers to provide traffic isolation among each tenants. When a CE is multi- homed to TRILL campus through FGL in active-active mode, DF election should be considered per FGL. If there are some specific multicast groups receivers connecting to TRILL campus, DF election should be considered per multicast group. If VLANs and multicast group addresses are statically configured on edge RBridge access port, the operators will ensure configuration consistency in an edge group. The algorithm always give consistent calculation result during DF election. If VLANs is dynamically enabled through VLAN registration protocol (VRP) (GVRP or MVRP), VLANs enabled for each MC-LAG should be either provisioned on all the corresponding ports on RBs of the same edge group or synchronized among those RBs. Similarly, the multicast groups dynamically joined through IGMP or MLD protocol by a RBridge port should follow the same logic. The detailed synchronization mechanism is beyond the scope of this draft. Hao & Li,etc Expires August 14, 2014 [Page 6] Internet-Draft Frame Duplication Avoidance in TRILL February 2014 In a steady state, all VLANs and multicast group addresses are consistent among all edge RBs in an edge group. Therefore the DF election algorithm gives the consistency calculation result for each MC-LAG and each VLAN(or FGL/multicast group). 5. Link and node failure process When an edge RB, say RB1, has all downlink ports in a particular MC- LAG failed, RB1 should announce a new LSP with the remaining alive LAGIDs. When other RBs in the same edge group as RB1 receive the LSP, these RBs think RB1 has left the edge group and will trigger the DF re-election process. If RB1 suffers a node failure, after other RBs in the same edge group know this information because RB1 becomes unreachable in the core IS-IS link state data base (all links to RB1 will appear to be down), other RBs will re-run the DF election process. 6. TRILL protocol extension The LAGID TLV is introduced to support global LAGID announcement. It is carried in an LSP PDU. Edge RBs rely on the LAGID TLV to automatically form edge group corresponding to each MC-LAG. DF election of the edge group is followed by such auto-discovery. 6.1. The LAGID TLV +-+-+-+-+-+-+-+-+ |Type= LAGID-TLV | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAGID | (10 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: TLV Type, TBD. o Length: indicates the length of LAGID field, it is a fixed value of ten. o LAGID: the global LAGID corresponding to a MC-LAG. Hao & Li,etc Expires August 14, 2014 [Page 7] Internet-Draft Frame Duplication Avoidance in TRILL February 2014 7. Security Considerations This draft does not introduce any extra security risks. For general TRILL Security Considerations, see [RFC6325]. 8. IANA Considerations TBD 9. References 9.1. Normative References [1] [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011. [2] [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol Specification", RFC 6325, July 2011. [3] [RFC6326bis] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake- isis-rfc6326bis, work in progress. 9.2. Informative References [4] [TRILL-Active-PS] Li,Y., et.al., "Problems of Active-Active connection at the TRILL Edge", draft-yizhou-trill-active- active-connection-prob-02, Work in progress, July 2014. 10. Acknowledgments The authors wish to acknowledge the important contributions of Donald Eastlake, Junlin Zhang. Hao & Li,etc Expires August 14, 2014 [Page 8] Internet-Draft Frame Duplication Avoidance in TRILL February 2014 Authors' Addresses Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56623144 Email: haoweiguo@huawei.com Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56625375 Email: liyizhou@huawei.com Zhibo Hu Huawei Technologies 156 Beiqing Road, Beijing 100095 China Phone: +86-010-60613388 Email: huzhibo@huawei.com Hao & Li,etc Expires August 14, 2014 [Page 9]