Internet DRAFT - draft-hao-trill-dup-avoidance-active-active
draft-hao-trill-dup-avoidance-active-active
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]
