INTERNET-DRAFT Mingui Zhang
Intended Status: Proposed Standard Huawei
Radia Perlman
Intel
Hongjun Zhai
ZTE
Mukhtiar Shaikh
Muhammad Durrani
Brocade
Expires: October 6, 2014 April 4, 2014
TRILL Active-Active Edge Using Multiple MAC Attachments
draft-zhang-trill-aa-multi-attach-02.txt
Abstract
TRILL active-active service is to provide end stations with flow
level load balance and resilience against link failures at the edge
of TRILL campuses.
This draft proposes that member RBridges in an active-active edge
RBridge group use their own nicknames as ingress RBridge nicknames to
encapsulate frames from attached end systems. Thus, remote edge
RBridges are required to learn multiple locations of one MAC address
in one Data Label. Design goals of this proposal are discussed in the
document.
Status of this Memo
This Internet-Draft is submitted to IETF 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Mingui Zhang, et al Expires October 6, 2014 [Page 1]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
Copyright and License 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5
4.1. Detail of Option C . . . . . . . . . . . . . . . . . . . . 6
4.2. Capability Flags TLV . . . . . . . . . . . . . . . . . . . 7
5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. No MAC Flip-Floping (Normal Unicast Egress) . . . . . . . . 8
5.2. Regular Unicast/Multicast Ingress . . . . . . . . . . . . . 8
5.3. Right Multicast Egress . . . . . . . . . . . . . . . . . . 9
5.3.1. No Duplication (Single Exit Point) . . . . . . . . . . 9
5.3.2. No Echo (Split Horizon) . . . . . . . . . . . . . . . . 9
5.4. No Black-hole & No Triangular Forwarding . . . . . . . . . 10
5.5. Load Balance Towards the AAE . . . . . . . . . . . . . . . 10
5.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
7.1. TRILL APPsub-TLVs . . . . . . . . . . . . . . . . . . . . . 11
7.2. Active Active Flags . . . . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Scenarios on Split Horizon . . . . . . . . . . . . . . 13
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Mingui Zhang, et al Expires October 6, 2014 [Page 2]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
1. Introduction
In the TRILL Active-Active Edge (AAE) topology, a Multi-Chassis Link
Aggregation Group (MC-LAG) is used to connect multiple RBridges to a
switch or a vSwitch. An endnode clump is attached to this switch or
vSwitch. It's required that data traffic within a specific Data Label
(VLAN or Fine Grained Label (FGL)) from this endnode clump can be
ingressed and egressed by any of these RBridges simultaneously. End
systems in the clump can spread their traffic among these edge
RBridges at the flow level. When a link fails, end systems can keep
using the rest of links in the MC-LAG without waiting for the
convergence of TRILL, which provides the resilience towards link
failures.
Since a packet from each endnode can be ingressed by any RBridge in
the AAE group, a remote edge RBridge may observe multiple attachment
points (i.e., egress RBridges) for this endnode identified by its MAC
address. This issue is known as the "MAC flip-flopping". Three
potential solutions arise to address this issue:
1) AAE member RBridges use a pseudonode nickname, instead of their
own, as the ingress nickname for end systems attached to the MC-
LAG. [CMT] falls within this category.
2) AAE member RBridges split work among themselves for which one
will be responsible for which MAC addresses. A member RBridge will
encapsulate the packet using its own nickname if it is responsible
for the source MAC address. Otherwise, if the frame is known
unicast, it encapsulates the packet using the nickname of the
responsible RBridge; if the frame is multicast, it needs to
redirect the packet to its responsible RBridge for encapsulation.
3) AAE member RBridges keep using their own nicknames. Remote edge
RBridges are required to keep multiple points of attachment per
VLAN for a MAC address attached to the AAE.
The purpose of this ID is to develop an approach based on solution 3.
Although it focuses on exploring solution 3, the major design goals
discussed here are common for AAE. Through mirroring the scenarios
studied in this draft, other potential solutions may benefit as well.
The main body of the document is organized as follows. Section 2
lists the acronyms and terminologies. Section 3 gives the overview
model. Section 4 provides three options for incremental deployment.
Section 5 describes how this approach meets the design goals.
2. Acronyms and Terminology
Mingui Zhang, et al Expires October 6, 2014 [Page 3]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
2.1. Acronyms
TRILL: TRansparent Interconnection of Lots of Links
AAE: Active-Active Edge
MC-LAG: Multi-Chassis Link Aggregation Group
IS-IS: Intermediate System to Intermediate System
FGL: Fine Grained Label
Data Label: VLAN or FGL
ESADI: End Station Address Distribution Information
2.2. Terminology
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].
Familiarity with [RFC6325], [RFC6327], [RFC6327bis] and [RFC6439] is
assumed in this document.
3. Overview
+-----+
| RB4 |
+----------+-----+----------+
| |
| |
| Rest of campus |
| |
| |
+-+-----+--+-----+--+-----+-+
| RB1 | | RB2 | | RB3 |
+-----\ +-----+ /-----+
\ | /
\ | /
|||MC-LAG1
|||
+---+
| B |
+---+
H1 H2 H3 H4: VLAN 10
Figure 3.1: An example topology of TRILL Active-Active Edge
Figure 3.1 shows an example network of TRILL Active-Active Edge. In
this figure, endnodes (H1, H2, H3 and H4) are attached to a bridge
(B) which communicates with multiple RBridges (RB1, RB2 and RB3) via
the MC-LAG. Suppose RB4 is a 'remote' RBridge out of the AAE group in
the TRILL campus. This connection model is also applicable to the
Mingui Zhang, et al Expires October 6, 2014 [Page 4]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
virtualized environment where the physical bridge can be replaced
with a vSwitch while those bare metal hosts are replaced with virtual
machines (VM).
For a packet received from their attached endnode clumps, member
RBridges of the AAE group always encapsulate it using their own
nickname no matter it's unicast or multicast.
The remote RBridge RB4 will see multiple attachments of one MAC from
the end nodes.
4. Backward Compatibility
Three options are listed below to cope with incremental deployment
scenarios. Among them, Option C can be hardware independent.
-- Option A
A new capability announcement would appear in LSPs. "I can cope
with multiple endnode attachments". Only if all edge RBridges
announce this capability can the AAE group use this approach. For
those legacy RBridges who are not capable to cope with multiple
endnode attachments, new type TRILL switches will not establish
connectivity with them so that they are isolated from these new
type TRILL switches. Note only edge RBridges (those that are
Appointed Forwarders [RFC6439]) need to be able to support this.
It does not affect totally transit RBridges.
-- Option B
Each edge RBridge in the AAE group ingress data frames from any
MC-LAG into a specific TRILL topology. In this way, the topology
ID is used as the discriminator of different locations of a
specific MAC address at the remote RBridge. TRILL MAY reserve a
list of topology IDs to be dedicated to AAE. RBridges which do not
support this reserved list MUST NOT establish connectivity with
edge RBridges in the AAE group.
-- Option C
As pointed out in Section 4.2.6 of [RFC6325] and Section 5.3 of
[ESADI], one MAC address may be persistently claimed to be
attached to multiple RBridges within the same Data Label in the
TRILL ESADI PDUs. For this option, AAE member RBridges make use of
TRILL ESADI protocol to distribute multiple attachments of MAC
addresses. Remote RBridges disable the data plane learning for
such multi-attached MAC addresses.
Mingui Zhang, et al Expires October 6, 2014 [Page 5]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
4.1. Detail of Option C
An RBridge in an AAE MUST advertise all Data Labels enabled for all
its attached MC-LAG. This causes remote RBridges to disable the MAC
learning via the TRILL Data packet decapsulation within these data
labels for this RBridge. The advertisement of such Data Labels can be
realized by taking one reserved flag from the Interested VLANs and
Spanning Tree Roots Sub-TLV (Section 2.3.6 of [RFC6326bis]) or one
reserved flag from the Interested Labels and Spanning Tree Roots Sub-
TLV (Section 2.3.8 of [RFC6326bis]). When this flag is set to 1, the
originating IS is advertising Data Labels for MC-LAGs rather than a
plain LAN link. (See Section 7.2)
Whenever a MAC from the MC-LAG of this AAE is learned, it need
advertise it via ESADI. In the TRILL ESADI PDUs, the originating IS
need includes all other RBridges' nicknames in the same AAE. It
requires each AAE member to be aware of other RBridges in the same
AAE (See Section 5.3.2). MAC Reachability TLVs [RFC6165] are composed
in a way that each TLV only contains MAC addresses for a single MC-
LAG. Each such TLV or TLVs MUST be enclosed by a pair of boundary
TRILL APPsub-TLVs defined as follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = NICKNAME-GROUP-START | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (1) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (2) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............. | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (n) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Nickname Group Start (TRILL APPsub-TLV type #TBD)
o Length: 2*n, where n is the number of RBridges in the AAE.
o Nickname: The nickname of an RBridge in the same AAE group as the
originating IS. The nickname of the originating IS is also
included.
Mingui Zhang, et al Expires October 6, 2014 [Page 6]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = NICKNAME-GROUP-END | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Nickname Group End (TRILL APPsub-TLV type #TBD)
o Length: 0
This pair of TRILL APPsub-TLVs SHOULD be included respectively in a
pair of GENINFO TLVs [RFC6823] in the ESADI-LSP. There may be more
than one occurrences of such pair of APPsub-TLVs in one ESADI-LSP
fragment.
For those MAC Reachability TLVs not enclosed by the boundary TLVs,
[EASDI] applies. Otherwise, this document applies.
When the remote RBridge learns MAC addresses via ESADI, it always
regards that the packets destined to these MAC addresses are to be
egressed by the closest one (the one to which the remote RBridge has
the least cost forwarding path) of those RBridges identified by the
nicknames in the Nickname Group Start TLV. If there are multiple such
member RBridges, the one with the lowest System ID will be recorded
as the egress RBridge.
When another RBridge in the same AAE group receives the ESADI-LSP
with above pair of boundary TRILL APPsub-TLVs, it also learns MAC
addresses served by the corresponding MC-LAG. This RBridge should
regard as if these MAC addresses are attached to itself. This point
can also be understood as that, the RBridge itself is always the
closest one out of all the AAE member RBridges.
An AAE member RBridge also need to advertise in ESADI the MAC
addresses learned from a plain link (non MC-LAG link) with data
labels happen to be covered by the Data Labels of any attached MC-
LAG. The reason is that data plane learning within these Data Labels
at the remote RBridge has been disabled for this RBridge.
4.2. Capability Flags TLV
The following Capability Flags TLV will be included in LSP as TRILL
APPsub-TLV of GENINFO-TLV.
Mingui Zhang, et al Expires October 6, 2014 [Page 7]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = MULTI-MAC-ATTACH-CAP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|H| Reserved |
+-+-+-+-+-+-+-+-+
o Type: Multi-MAC-Attach Capability (TRILL APPsub-TLV type #TBD)
o Length: 1
o E: When this bit is set, it indicates the originating IS keeps
multiple MAC attachments in the ESADI-LSDB while disables the MAC
learning from the remote TRILL Data decapsulation as specified in
Option C.
o H: When this bit is set, it indicates that the originating IS
keeps multiple MAC attachments with new hardware at the data
plane.
o Reserved: Reserved flags for future use.
Capability specification for Option B is out the scope of this
document. It may be specified in documents for TRILL multi-topology.
5. Design Goals
Proposals to meet the major design goals of AAE are explored in this
section.
5.1. No MAC Flip-Floping (Normal Unicast Egress)
Since all RBridges talking with the AAE RBridges in the campus are
able to keep multiple locations for one MAC address, a MAC address
learned from one AAE member will not be overwritten by the same MAC
address learned from another AAE member. Although multiple entries
for this MAC address will be created, the remote RBridge can adhere
to one of the locations (e.g., the closest one) for each MAC address
rather than keep flip-floping among them.
5.2. Regular Unicast/Multicast Ingress
MC-LAG guarantees that each frame will be sent upward to the AAE via
exactly one uplink. RBridges in the AAE can simply follow the process
per [RFC6325] to ingress the frame. For example, each RBridge uses
its own nickname as the ingress nickname to encapsulate the packet.
In such scenario, each RBridge takes for granted that it is the
Mingui Zhang, et al Expires October 6, 2014 [Page 8]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
Appointed Forwarder for the Data Labels enabled on the uplink of the
MC-LAG.
5.3. Right Multicast Egress
A fundamental design goal of AAE is that there is no duplication and
forwarding loop.
5.3.1. No Duplication (Single Exit Point)
When multi-destination packets for a specific Data Label are received
from the campus, it's important that exactly one RBridge out of the
AAE group let through each multicast packet, therefore no duplication
happens. Since AAE member RBridges support MC-LAG, they are able to
utilize the hashing function of MC-LAG to determine the single exit
point.
5.3.2. No Echo (Split Horizon)
When a multicast frame originated from an MC-LAG is ingressed by an
RBridge of an AAE group, forwarded across the TRILL network and then
received by another RBridge in the same AAE group, it is important
that this RBridge does not egress this frame back to this MC-LAG.
Otherwise, it will cause a forwarding loop (echo). The well known
'split horizon' technique can be used to eliminate the echo issue.
RBridges in the AAE group need split horizon based on the ingress
RBridge nickname plus the Data Label (VLAN or FGL) of the TRILL Data
packet. They need set up per port filtering lists consists of the
tuple of <ingress nickname, Data Label>. Packets with information
matching with any entry of the filtering list MUST NOT be egressed
out of that port. The information of such filters is obtained by
listening to the following "MC-LAG Group RBridges" TRILL APPsub-TLV
included in the GENINFO TLV in LSPs.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = MC-LAG-GROUP-RBRIDGES | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| MC-LAG System ID | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: MC-LAG Group RBridges (TRILL APPsub-TLV type #TBD)
o Length: 10
Mingui Zhang, et al Expires October 6, 2014 [Page 9]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
o Sender Nickname: The nickname of the originating IS.
o MC-LAG System ID: The System ID of the MC-LAG as specified in
Section 6.3.2 in [802.1ax-rev].
All enabled VLANs/FGLs MUST be consistent on all ports connected to
an MC-LAG [802.1ax-rev]. So that the enabled Data Labels need not be
included in the MC-LAG Group RBridges TRILL APPsub-TLV. They can be
locally obtained from the port attached to that MC-LAG.
Through parsing an MC-LAG Group RBridges TRILL APPsub-TLV, the
receiver RBridge discovers all other RBridges connected to the same
MC-LAG. The Sender Nickname of the originating IS will be added into
the filtering list of the port attached to the MC-LAG. For example,
RB3 in Figure 3.1 will set up a filtering list looks like {<RB1,
VLAN10>, <RB2, VLAN10>} on its port attached to MC-LAG1. According to
split horizon, TRILL Data packets within VLAN10 ingressed by RB1 or
RB2 will not be egressed out of this port.
When there are multiple MC-LAGs connected to the same RBridge, these
MC-LAGs may have overlap Data Labels. Customer may need hosts within
these overlap Data Labels communicate with each other. In Appendix A,
several scenarios are given to explain how hosts communicate within
the overlap Data Labels and how split horizon happens.
5.4. No Black-hole & No Triangular Forwarding
If a sub-link of the MC-LAG fails while remote RBridges continue to
send packets to those MAC addresses they have learned via the failed
port, black-hole happens.
The AAE member attached to the failed sub-link can make use of ESADI
protocol to flush those failure affected MAC addresses as defined in
Section 5.2 of [ESADI]. After doing that, no traffic will be sent to
the failed port, hence no black-hole happens.
5.5. Load Balance Towards the AAE
Since a remote RBridge can record multiple attachments of one MAC
address, this remote RBridge can choose to spread the traffic to this
MAC towards any of the AAE members. Each of them is able to egress
the traffic. With Option A and Option B, flow-level load balance
mechanisms can be implemented to optimize the distribution of the
traffic load from the remote RBridge towards the AAE group.
5.6. Scalability
In order to record the multiple attachments of MAC addresses learned
Mingui Zhang, et al Expires October 6, 2014 [Page 10]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
from AAE RBridges, more entries may be consumed in the table of
learned MAC addresses. However, MAC addresses attached to MC-LAG is
probably only a small part of all MAC addresses in the whole TRILL
campus. As a result, the extra space required by the multi-attached
MAC addresses may be much less than the RBridge's current unused MAC
table space.
Also, with option C, remote RBridges will keep the multiple
attachments of a MAC address in the ESADI link state databases. In
the MAC table, an RBridge still establishes only one entry for each
MAC address.
6. Security Considerations
Authenticity for contents transported in IS-IS PDUs is enforced using
regular IS-IS security mechanism [ISIS][RFC5310].
For security considerations pertain to extensions hosted by TRILL
ESADI, Security Considerations in [ESADI] should be referred.
7. IANA Considerations
7.1. TRILL APPsub-TLVs
IANA is requested to create several new sub-registries under the
Generic Information TLV (#251) [RFC6823] for TRILL APPsub-TLVs
defined in Section 4.1, 4.2 and 5.3.2 of this document.
Reference: [ESADI] and [This document]
Type Name Reference
---------- -------- -----------
0 Reserved
1 ESADI-PARAM [ESADI]
2-254 Unassigned
255 Reserved
256 NICKNAME-GROUP-START This document
257 NICKNAME-GROUP-END This document
258 MULTI-MAC-ATTACH-CAP This document
259 MC-LAG-GROUP-RBRIDGES This document
260-65534 Available
65535 Unassigned
7.2. Active Active Flags
Similar as Section 7.1 of [ESADI], this document requires IANA to
create two sub-registries for TRILL Active-Active as follows.
Mingui Zhang, et al Expires October 6, 2014 [Page 11]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
One flag bit appears in the "Interested VLANs and Spanning Tree Roots
Sub-TLV".
References: [RFC6326bis], [ESADI] and [This document]
Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 M4 IPv4 Multicast Router Attached [RFC6326bis]
1 M6 IPv6 Multicast Router Attached [RFC6326bis]
2 - Unassigned
3 ES ESADI Participation [ESADI]
4-15 - (used for a VLAN ID) [RFC6326bis]
16 AA Enabled VLANs for Active-Active This document
17-19 - Unassigned
20-31 - (used for a VLAN ID) [RFC6326bis]
One flag bit appears in the "Interested Labels and Spanning Tree
Roots Sub-TLV".
References: [RFC6326bis], [ESADI] and [This document]
Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 M4 IPv4 Multicast Router Attached [RFC6326bis]
1 M6 IPv6 Multicast Router Attached [RFC6326bis]
2 BM Bit Map [RFC6326bis]
3 ES ESADI Participation [ESADI]
4 AA FGLs Enabled for Active-Active This document
5-7 - Unassigned
Acknowledgements
Authors would like to thank the comments and suggestions from Donald
Eastlake, Erik Nordmark, Fangwei Hu and Liang Xia.
8. References
8.1. Normative References
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and
V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
6327, July 2011.
[RFC6327bis] D. Eastlake, R. Perlman, et al, "TRILL: Adjacency",
Mingui Zhang, et al Expires October 6, 2014 [Page 12]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
draft-ietf-trill-rfc6327bis-04.txt, January 2014, in RFC Ed
Queue.
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu,
"Routing Bridges (RBridges): Appointed Forwarders", RFC
6439, November 2011.
[ESADI] H. Zhai, F. Hu, et al, "TRILL (Transparent Interconnection
of Lots of Links): ESADI (End Station Address Distribution
Information) Protocol", draft-ietf-trill-esadi-05.txt,
February 2014, working in progress.
[RFC6326bis] D. Eastlake, R. Perlman, et al, "Routing Bridges
(RBridges): Adjacency", draft-ietf-trill-rfc6327bis-03.txt,
January 2014, work in progress.
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Generic Information in IS-IS", RFC 6823, December 20165
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
8.2. Informative References
[CMT] T. Senevirathne, J. Pathangi, et al, "Coordinated Multicast
Trees (CMT)for TRILL", draft-ietf-trill-cmt-02.txt,
November 2012, working in progress.
[802.1ax-rev] IEEE, "Local and Metropolitan Area Networks - Link
Aggregation", IEEE P802.1AX-REV/D3.2, February 2014.
[ISIS] ISO, "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication",
RFC 5310, February 2009.
Appendix A. Scenarios on Split Horizon
Mingui Zhang, et al Expires October 6, 2014 [Page 13]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
+------------------+ +------------------+ +------------------+
| RB1 | | RB2 | | RB3 |
+------------------+ +------------------+ +------------------+
L1 L2 L3 L1 L2 L3 L1 L2 L3
VL10~20 VL15~25 VL15 VL10~20 VL15~25 VL15 VL10~20 VL15~25 VL15
MC-LAG1 MC-LAG2 LAN MC-LAG1 MC-LAG2 LAN MC-LAG1 MC-LAG2 LAN
B1 B2 B10 B1 B2 B20 B1 B2 B30
Figure A.1: An example topology to explain split horizon
Suppose RB1, RB2 and RB3 are the Active-Active group connecting MC-
LAG1 and MC-LAG2. MC-LAG1 and MC-LAG2 are connected to B1 and B2 at
their other ends. Suppose all these RBridges use port L1 to connect
MC-LAG1 while they use port L2 to connect MC-LAG2. Assume all three
L1 enable VLAN 10~20 while all three L2 enable VLAN 15~25. So that
there is a overlap of VLAN 15~20. Customer needs hosts in these
overlap VLANs communicate with each other. That is, hosts attached to
B1 in VLAN 15~20 need communicate with hosts attached to B2 in VLAN
15~20. Assume the remote plain RBridge RB4 also has hosts attached in
VLAN 15~20 which need communicate with those hosts in these VLANs
attached to B1 and B2.
Two major requirements:
1. Frames ingressed from RB1-L1-VLAN 15~20 MUST NOT be egressed out
of ports RB2-L1 and RB3-L1. At the same time,
2. frames coming from B1-VLAN 15~20 should reach B2-VLAN 15~20.
RB3 stores the information for split horizon on its ports L1&L2. On
L1: {<ingress_nickname_RB1, VLAN 10~20>, <ingress_nickname_RB2, VLAN
10~20>} and on L2: {<ingress_nickname_RB1, VLAN 15~25>,
<ingress_nickname_RB2, VLAN 15~25>}.
Five clarification scenarios:
a. Suppose RB2/RB3 receives a TRILL multicast data packet with data
label VLAN 15 and ingress nickname RB1. RB3 is the single exit
point (selected out according to the hashing function of MC-LAG)
for this packet. On ports L1&L2, RB3 has covered
<ingress_nickname_RB1, VLAN 15>, so that RB3 will not egress this
packet out of either L1 or L2. Here, _split horizon_ happens.
Beforehand, RB1 obtains a native frame on port L1 from B1 in VLAN
15. RB1 judges it should be forwarded as a multicast frame across
the TRILL campus. Also, RB1 replicates this frame without TRILL
encapsulation and sends it out of port L2, so that B2 will get
this frame.
Mingui Zhang, et al Expires October 6, 2014 [Page 14]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
b. Suppose RB2/RB3 receives a TRILL multicast data packet with data
label VLAN 15 and ingress nickname RB4. RB3 is the single exit
point. On ports L1&L2, since RB3 has not stored any tuple with
ingress_ nickname_RB4, RB3 will decapsulate the packet and egress
it out of both ports L1 and L2. So both B1 and B2 will receive the
frame.
c. Suppose there is a plain LAN link port L3 on RB1, RB2 and RB3,
connecting to B10, B20 and B30 respectively. These L3 ports happen
to be configured with VLAN 15. On port L3, RB1 and RB3 stores no
information of split horizon for AAE (since this port has not been
configured to be in any MC-LAG). They will egress the packet
ingressed out of RB1-L1 in VLAN 15.
d. If a packet is ingressed from RB1-L1 or RB1-L2 with data label
VLAN 15, port RB1-L3 will not egress packets with ingress-
nickname-RB1. RB1 need replicates this frame without encapsulation
and sends it out of port L3.
e. If a packet is ingressed from RB1-L3, since RB1-L1 and RB1-L2
cannot egress packets with data label VLAN 15 and ingress-
nickname-RB1, RB1 need replicates this frame without encapsulation
and sends it out of port L1 and L2.
Mingui Zhang, et al Expires October 6, 2014 [Page 15]
INTERNET-DRAFT MAC Multi-Attach for Active/Active April 4, 2014
Author's Addresses
Mingui Zhang
Huawei Technologies
No.156 Beiqing Rd. Haidian District,
Beijing 100095 P.R. China
Email: zhangmingui@huawei.com
Radia Perlman
Intel
Email: radiaperlman@gmail.com
Hongjun Zhai
ZTE Corporation
68 Zijinghua Road
Nanjing 200012 China
Phone: +86-25-52877345
Email: zhai.hongjun@zte.com.cn
Mukhtiar Shaikh
Brocade
Email: mshaikh@brocade.com
Muhammad Durrani
Brocade
Email: mdurrani@brocade.com
Mingui Zhang, et al Expires October 6, 2014 [Page 16]