INTERNET-DRAFT Mingui Zhang
Intended Status: Proposed Standard Huawei
Updates: 7176 Radia Perlman
EMC
Hongjun Zhai
ZTE
Muhammad Durrani
Mukhtiar Shaikh
Brocade
Sujay Gupta
IP Infusion
Expires: March 1, 2015 August 28, 2014
TRILL Active-Active Edge Using Multiple MAC Attachments
draft-ietf-trill-aa-multi-attach-01.txt
Abstract
TRILL active-active service provides end stations with flow level
load balance and resilience against link failures at the edge of
TRILL campuses.
This draft specifies a method in which 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 keep multiple locations of one
MAC address in one Data Label. Design goals of this specification 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
Mingui Zhang, et al Expires March 1, 2015 [Page 1]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
http://www.ietf.org/shadow.html
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 . . . . . . . . . . . . . . . . . . . 4
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Incremental Deployable Options . . . . . . . . . . . . . . . . 5
4.1. Detail of Option C . . . . . . . . . . . . . . . . . . . . 6
4.2. Capability Flags TLV . . . . . . . . . . . . . . . . . . . 8
5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. No MAC Flip-Floping (Normal Unicast Egress) . . . . . . . . 9
5.2. Regular Unicast/Multicast Ingress . . . . . . . . . . . . . 9
5.3. Right Multicast Egress . . . . . . . . . . . . . . . . . . 10
5.3.1. No Duplication (Single Exit Point) . . . . . . . . . . 10
5.3.2. No Echo (Split Horizon) . . . . . . . . . . . . . . . . 10
5.4. No Black-hole or Triangular Forwarding . . . . . . . . . . 11
5.5. Load Balance Towards the AAE . . . . . . . . . . . . . . . 12
5.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 12
6. E-L1FS Backwards Compatibility . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
8.1. TRILL APPsub-TLVs . . . . . . . . . . . . . . . . . . . . . 13
8.2. Active Active Flags . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Scenarios on Split Horizon . . . . . . . . . . . . . . 15
Mingui Zhang, et al Expires March 1, 2015 [Page 2]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
In the TRILL Active-Active Edge (AAE) topology, a Local Active-Active
Link Protocol (LAALP), for example, a Multi-Chassis Link Aggregation
Group (MC-LAG), is used to connect multiple RBridges to multiport
Customer Equipment (CE), such as a switch, vSwitch or multi-port end
station. An endnode clump is attached to this switch or vSwitch
[AAp]. It's required that data traffic within a specific VLAN from
this endnode clump (including the multi-port end station) 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 keep using
the rest of links in the LAALP without waiting for the convergence of
TRILL, which provides resilience to link failures.
Since a frame 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 and Data Label (VLAN or Fine Grained Label (FGL)). 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
LAALP. [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 frame using its own nickname if it is responsible
for the source MAC address. Otherwise, if the frame is known
unicast, it encapsulates the frame using the nickname of the
responsible RBridge; if the frame is multicast, it needs to
redirect the frame 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
MAC address and Data Label attached to the AAE.
The purpose of this document 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 all three AAE solutions.
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
Mingui Zhang, et al Expires March 1, 2015 [Page 3]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
model. Section 4 provides three options for incremental deployment.
Section 5 describes how this approach meets the design goals.
2. Acronyms and Terminology
2.1. Acronyms
AAE: Active-Active Edge
CE : Customer Equipment (end station or bridge). The device can be
either physical or virtual equipment.
Data Label: VLAN or FGL
ESADI: End Station Address Distribution Information [ESADI]
FGL: Fine Grained Label [RFC7172]
IS-IS: Intermediate System to Intermediate System [ISIS]
LAALP: As in [AAp], Local Active-Active Link Protocol. Any protocol
similar to MC-LAG that runs in a distributed fashions on a CE, the
links from that CE to a set of edge group RBridges, and on those
RBridges.
MC-LAG: Multi-Chassis LAG. Proprietary extensions of Link Aggregation
[802.1AX] to multiple devices (chassis) at one end.
TRILL: TRansparent Interconnection of Lots of Links [RFC6325]
vSwitch: A virtual switch such as a hypervisor that also simulates a
bridge.
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], [RFC6439] and [RFC7177] is assumed in
this document.
3. Overview
Mingui Zhang, et al Expires March 1, 2015 [Page 4]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
+-----+
| RB4 |
+----------+-----+----------+
| |
| |
| Rest of campus |
| |
| |
+-+-----+--+-----+--+-----+-+
| RB1 | | RB2 | | RB3 |
+-----\ +-----+ /-----+
\ | /
\ | /
|||LAALP1
|||
+---+
| B |
+---+
H1 H2 H3 H4: VLAN 10
Figure 3.1: An example topology for TRILL Active-Active Edge
Figure 3.1 shows an example network for TRILL Active-Active Edge. In
this figure, endnodes (H1, H2, H3 and H4) are attached to a bridge
which communicates with multiple RBridges (RB1, RB2 and RB3) via the
LAALP. Suppose RB4 is a 'remote' RBridge out of the AAE group in the
TRILL campus. This connection model is also applicable to the
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 frame received from its attached endnode clumps, a member
RBridge of the AAE group always encapsulates that frame using its own
nickname as the ingress nickname no matter whether it's unicast or
multicast.
The remote RBridge RB4 will see multiple attachments of one MAC from
each of the end nodes.
4. Incremental Deployable Options
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 attachments for an endnode". Only if all edge
Mingui Zhang, et al Expires March 1, 2015 [Page 5]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
RBridges announce this capability can the AAE group use this
approach. For those legacy edge RBridges who are not capable of
coping 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 transit RBridges.
-- Option B
Each edge RBridge in the AAE group ingresses frames from any LAALP
into a specific TRILL topology [TRILL-MT]. In this way, the
topology ID is used as the discriminator of different locations of
a specific MAC address at the remote RBridge. TRILL could reserve
a list of topology IDs to be dedicated to AAE. RBridges that do
not support this reserved list would 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 LSPs. For this option, AAE member RBridges make use of
TRILL ESADI protocol to distribute multiple attachments of a MAC
address. Remote RBridges SHOULD disable the MAC learning for such
multi-attached MAC addresses from TRILL Data packet decapsulation.
4.1. Detail of Option C
An RBridge in an AAE MUST advertise all Data Labels enabled for all
its attached LAALPs. Receiver edge RBridges MUST avoid flip-flopping
of MAC learned from the TRILL Data packet decapsulation for the
originating RBridge within these Data Labels. It's RECOMMENDED that
the receiver edge RBridge disables the MAC learning from the TRILL
Data packet decapsulation within those advertised Data Labels for the
originating RBridge. However, alternative implementations may be used
to produce the same expected behavior. A promising way is to make use
of the confidence level mechanism [RFC6325]. For example, let the
receiver edge RBridge give a prevailing confidence value (e.g., 0x21)
to the first learned MAC attachment over others from the TRILL Data
packet decapsulation. So the receiver edge RBridge will stick to this
MAC attachment until it is rewritten by one learned from the ESADI
protocol [ESADI]. The MAC attachment learned from ESADI is set to
have higher confidence value (e.g., 0x80) to override any alternative
learning from the decapsulation of received TRILL Data packets
[RFC6325].
Mingui Zhang, et al Expires March 1, 2015 [Page 6]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
The advertisement of enabled Data Labels for LAALP can be realized by
allocating one reserved flag from the Interested VLANs and Spanning
Tree Roots Sub-TLV (Section 2.3.6 of [RFC7176]) and one reserved flag
from the Interested Labels and Spanning Tree Roots Sub-TLV (Section
2.3.8 of [RFC7176]). When this flag is set to 1, the originating IS
(RBridge) is advertising Data Labels for LAALPs rather than plain LAN
links. (See Section 7.2)
Whenever a MAC from the LAALP of this AAE is learned, it needs to be
advertised via the ESADI protocol [ESADI]. In its TRILL ESADI-LSPs,
the originating RBridge needs to include the identifier of this AAE.
Remote RBridges need to know all nicknames of RBridges in this AAE.
This is achieved by listening to the "LAALP Group RBridges" TRILL
APPsub-TLV defined in Section 5.3.2. MAC Reachability TLVs [RFC6165]
are composed in a way that each TLV only contains MAC addresses of
end nodes attached to a single LAALP. Each such TLV is enclosed in a
TRILL APPsub-TLV defined as follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LAALP-GROUP-MAC | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| MAC-Reachability TLV (7 + 6*n bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: LAALP Group MAC (TRILL APPsub-TLV type #TBD)
o Length: The MAC-Reachability TLV [RFC6165] is contained in the
value field as a sub-TLV. The total number of bytes contained in
the value field is given by k+8+6*n.
o LAALP ID Size: The length of the LAALP ID in bytes.
o LAALP ID: The ID of the LAALP which is in the size of variable k
bytes. Here, it also serves as the identifier of the AAE. If the
LAALP is an MC-LAG, it is the 8 byte ID as specified in Section
5.3.2 in [802.1AX].
o MAC-Reachability sub-TLV: The LAALP-GROUP-MAC APPsub-TLV value
contains the MAC-Reachability TLV as a sub-TLV. As specified in
Section 2.2 in [FS-LSP], the type and length fields of the MAC-
Reachability TLV are encoded as unsigned 16 bit integers. The one
octet unsigned Confidence along with these TLVs SHOULD be set to
Mingui Zhang, et al Expires March 1, 2015 [Page 7]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
prevail over those MAC addresses learned from TRILL Data
decapsulation by remote edge RBridges.
This LAALP-GROUP-MAC APPsub-TLV SHOULD be included in a TRILL GENINFO
TLV [ESADI] in the ESADI-LSP. There may be more than one occurrence
of such TRILL APPsub-TLV in one ESADI-LSP fragment.
For those MAC addresses contained in an LAALP-GROUP-MAC APPsub-TLV,
this document applies. Otherwise, [ESADI] applies. For example, an
AAE member RBridge continues to enclose MAC addresses learned from
TRILL Data packet decapsulation in MAC-Reachability TLV as per
[RFC6165] and advertise them using the ESADI protocol.
When the remote RBridge learns MAC addresses contained in the LAALP-
GROUP-MAC APPsub-TLV via the ESADI protocol [ESADI], it always sends
the packets destined to these MAC addresses to the closest one (the
one to which the remote RBridge has the least cost forwarding path)
of those RBridges in the AAE identified by the LAALP ID in the LAALP-
GROUP-MAC APPsub-TLV. If there are multiple such member RBridges, the
ingress RBridge is required to select a unique one in a pseudo-random
way as specified in Section 5.3 of [ESADI].
When another RBridge in the same AAE group receives an ESADI-LSP with
the LAALP-GROUP-MAC APPsub-TLV, it also learns MAC addresses of those
end nodes served by the corresponding LAALP. These MAC addresses
SHOULD be learned as if those end nodes are locally attached to this
RBridge itself.
An AAE member RBridge MUST use the LAALP-GROUP-MAC APPsub-TLV to
advertise the MAC addresses learned from a plain local link (a non
LAALP link) with Data Labels that happen to be covered by the Data
Labels of any attached LAALP. The reason is that MAC learning from
TRILL Data packet decapsulation within these Data Labels at the
remote edge RBridge has been disabled for this RBridge.
4.2. Capability Flags TLV
The following Capability Flags TLV will be included in an E-L1FS FS-
LSP fragment zero [RFC7180bis] as an APPsub-TLV of the TRILL GENINFO-
TLV.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = MULTI-MAC-ATTACH-CAP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|H| Reserved | (1 byte)
+-+-+-+-+-+-+-+-+
Mingui Zhang, et al Expires March 1, 2015 [Page 8]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
o Type: Multi-MAC-Attach Capability (TRILL APPsub-TLV type #TBD)
o Length: Set to 1.
o E: When this bit is set, it indicates the originating IS acts as
specified in Option C.
o H: When this bit is set, it indicates that the originating IS
keeps multiple MAC attachments learned from TRILL Data packet
decapsulation with fast path hardware.
o Reserved: Reserved flags for future use. These MUST be sent as
zero and ignored on receipt.
The Capability Flags TRILL APPsub-TLV is used to notify other
RBridges whether the originating IS supports the capability indicated
by the E and H bits. For example, if E bit is set, it indicates the
originating IS will act as defined in Option C. That is, it will
disable the MAC learning from TRILL Data packet decapsulation for AAE
RBridges within Data Labels advertised by them while waiting for the
TRILL ESADI LSPs to distribute the {MAC, Nickname, Data Label}
association. Meanwhile, this RBridge is able to act as an AAE
RBridge. It's required to advertise MAC addresses learned from LAALPs
in TRILL ESADI LSPs using the LAALP-GROUP-MAC APPsub-TLV defined in
Section 4.1. AAE RBridges supporting Options C won't establish
connectivity with remote edge RBridges unless this RBridge has
advertised this Capability Flags TLV with E bit set.
Capability specification for Option B is out the scope of this
document. It may be specified in documents for TRILL multi-topology
[TRILL-MT].
5. Design Goals
How this specification meets the major design goals of AAE is
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 is required
to adhere to a unique one of the locations (see Section 4.1) for each
MAC address rather than keep flip-flopping among them.
5.2. Regular Unicast/Multicast Ingress
Mingui Zhang, et al Expires March 1, 2015 [Page 9]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
LAALP 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 frame. In
such scenario, each RBridge takes for granted that it is the
Appointed Forwarder for the VLANs enabled on the uplink of the LAALP.
5.3. Right Multicast Egress
A fundamental design goal of AAE is that there is no duplication or
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. The LAALP should have defined its selection function (using
hashing or election algorithm) to designated a forwarder for a
multicast frame. Since AAE member RBridges support LAALP, they are
able to utilize that selection function of LAALP to determine the
single exit point. If the output of the selection function points to
the port attached to the receiver RBridge itself (i.e., the packet
should be egressed out of this node), it egresses this packet.
Otherwise, the packet MUST be dropped.
5.3.2. No Echo (Split Horizon)
When a multicast frame originated from an LAALP 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 LAALP.
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 to split horizon based on the ingress
RBridge nickname plus the VLAN of the TRILL Data packet. They need to
set up per port filtering lists consists of the tuple of <ingress
nickname, VLAN>. 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
"LAALP Group RBridges" APPsub-TLV included in the TRILL GENINFO TLV
in FS-LSPs [RFC7180bis].
Mingui Zhang, et al Expires March 1, 2015 [Page 10]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LAALP-GROUP-RBRIDGES | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| LAALP ID (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: LAALP Group RBridges (TRILL APPsub-TLV type #TBD)
o Length: 3+k
o Sender Nickname: The nickname of the originating IS.
o LAALP ID Size: The length of the LAALP ID in bytes.
o LAALP ID: The ID of the LAALP which is in the size of variable k
bytes. If the LAALP is an MC-LAG, it is the 8 byte ID as specified
in Section 5.3.2 in [802.1AX].
All enabled VLANs MUST be consistent on all ports connected to an
LAALP. So that the enabled VLANs need not to be included in the LAALP
Group RBridges TRILL APPsub-TLV. They can be locally obtained from
the port attached to that LAALP.
Through parsing LAALP Group RBridges TRILL APPsub-TLVs, the receiver
RBridge discovers all other RBridges connected to the same LAALP. The
Sender Nickname of the originating IS will be added into the
filtering list of the port attached to the LAALP. For example, RB3 in
Figure 3.1 will set up a filtering list looks like {<RB1, VLAN10>,
<RB2, VLAN10>} on its port attached to LAALP1. 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 LAALPs connected to the same RBridge, these
LAALPs may have overlap VLANs. Customer may need hosts within these
overlap VLANs to communicate with each other. In Appendix A, several
scenarios are given to explain how hosts communicate within the
overlap VLANs and how split horizon happens.
5.4. No Black-hole or Triangular Forwarding
If a sub-link of the LAALP fails while remote RBridges continue to
send packets towards the failed port, a black-hole happens. If the
Mingui Zhang, et al Expires March 1, 2015 [Page 11]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
AAE member RBridge with that failed port starts to redirect the
packets to other member RBridges for delivery, triangular forwarding
forms.
The member RBridge attached to the failed sub-link can make use of
the ESADI protocol to flush those failure affected MAC addresses as
defined in Section 5.2 of [ESADI]. After doing that, no packets will
be sent towards the failed port, hence no black-hole will happen. Nor
will the member RBridge need to redirect packets to other member
RBridges, which may otherwise lead to the triangular forwarding.
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 towards
the AAE members. Each of them is able to act as the egress point. By
doing this, the forwarding paths may be not limited to the least cost
Equal Cost Multiple Paths from the ingress RBridge to the AAE
RBridges. The traffic load from the remote RBridge towards the AAE
RBridges can be balanced based on a pseudo-random selection method
(see Section 4.1).
Note that the load balance method adopted at the ingress RBridge is
not to replace the load balance mechanism of LAALP. These two load
spreading mechanisms should take effect separately.
5.6. Scalability
With option A, multiple attachments need to be recorded for a MAC
address learned from AAE RBridges. More entries may be consumed in
the MAC table. However, MAC addresses attached to an LAALP are 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
can be accommodated by RBridges' unused MAC table space.
With option C, remote RBridges will keep the multiple attachments of
a MAC address in the ESADI link state databases. While in the MAC
table, an RBridge still establishes only one entry for each MAC
address.
6. E-L1FS Backwards Compatibility
The Extended TLVs defined in Section 4 and 5 are to be used in a
Level 1 Flooding Scope [FS-LSP] [RFC7180bis]. For those RBridges that
do not support E-L1FS, the MULTI-MAC-ATTACH-CAP TRILL APPsub-TLV will
not be sent out either. AAE RBridges will not establish connectivity
with these RBridges.
Mingui Zhang, et al Expires March 1, 2015 [Page 12]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
7. 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, see the Security Considerations section in [ESADI].
For general TRILL security considerations, see [RFC6325].
8. IANA Considerations
8.1. TRILL APPsub-TLVs
IANA is requested to allocate three new types under the Generic
Information TLV (#251) [RFC6823] for the TRILL APPsub-TLVs defined in
Section 4.1, 4.2 and 5.3.2 of this document.
Reference: [RFC7180bis] and [This document]
Type Name Reference
---------- -------- -----------
0 Reserved
1 ESADI-PARAM [ESADI]
2-251 Unassigned
252 LAALP-GROUP-MAC [This document]
253 MULTI-MAC-ATTACH-CAP [This document]
254 LAALP-GROUP-RBRIDGES [This document]
255 Reserved
256-65534 Unassigned
65535 Reserved
8.2. Active Active Flags
IANA is requested to allocate two flag bits, as follows:
One flag bit appears in the "Interested VLANs and Spanning Tree Roots
Sub-TLV".
Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 M4 IPv4 Multicast Router Attached [RFC7176]
1 M6 IPv6 Multicast Router Attached [RFC7176]
2 - Unassigned
3 ES ESADI Participation [ESADI]
4-15 - (used for a VLAN ID) [RFC7176]
16 AA Enabled VLANs for Active-Active [This document]
17-19 - Unassigned
Mingui Zhang, et al Expires March 1, 2015 [Page 13]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
20-31 - (used for a VLAN ID) [RFC7176]
One flag bit appears in the "Interested Labels and Spanning Tree
Roots Sub-TLV".
Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 M4 IPv4 Multicast Router Attached [RFC7176]
1 M6 IPv6 Multicast Router Attached [RFC7176]
2 BM Bit Map [RFC7176]
3 ES ESADI Participation [ESADI]
4 AA FGLs for Active-Active [This document]
5-7 - Unassigned
9. Acknowledgements
Authors would like to thank the comments and suggestions from Andrew
Qu, Donald Eastlake, Erik Nordmark, Fangwei Hu, Liang Xia, Weiguo Hao
and Yizhou Li.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu,
"Routing Bridges (RBridges): Appointed Forwarders", RFC
6439, November 2011.
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Generic Information in IS-IS", RFC 6823, December 20165
[RFC7172] D. Eastlake 3rd and M. Zhang and P. Agarwal and R. Perlman
and D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, May 2014.
[RFC7176] D. Eastlake 3rd and T. Senevirathne and A. Ghanwani and D.
Dutt and A. Banerjee, "Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS", RFC7176, May 2014.
Mingui Zhang, et al Expires March 1, 2015 [Page 14]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
[RFC7177] D. Eastlake 3rd and R. Perlman and A. Ghanwani and H. Yang
and V. Manral, "Transparent Interconnection of Lots of
Links (TRILL): Adjacency", RFC 7177, May 2014.
[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-09.txt, June
2014, in AUTH48, will be RFC 7357.
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area
networks / Link Aggregation", 802.1AX-2008, 1 January 2008.
[FS-LSP] L. Ginsberg, S. Previdi, et al, "IS-IS Flooding Scope
LSPs", draft-ietf-isis-fs-lsp-02.txt, June, 2014, in
AUTH48, will be RFC 7356.
[RFC7180bis] R. Perlman, M. Zhang, D. Eastlake, A. Banerjee, A.
Ghanwani, "TRILL: Clarifications, Corrections, and
Updates", draft-perlman-trill-rfc7180bis, work in progress.
10.2. Informative References
[CMT] T. Senevirathne, J. Pathangi, et al, "Coordinated Multicast
Trees (CMT)for TRILL", draft-ietf-trill-cmt-03.txt, April
2014, working in progress.
[TRILL-MT] D. Eastlake, M. Zhang, A. Banerjee, V. Manral, "TRILL:
Multi-Topology", draft-eastlake-trill-multi-topology, work
in progress.
[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.
[AAp] Y. Li, W. Hao, et al, "Problem Statement and Goals for
Active-Active TRILL Edge", draft-ietf-trill-active-active-
connection-prob-07, August 2014, Submitted to IESG for
Publication.
Appendix A. Scenarios on Split Horizon
Mingui Zhang, et al Expires March 1, 2015 [Page 15]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 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
LAALP1 LAALP2 LAN LAALP1 LAALP2 LAN LAALP1 LAALP2 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
LAALP1 and LAALP2. LAALP1 and LAALP2 are connected to B1 and B2 at
their other ends. Suppose all these RBridges use port L1 to connect
LAALP1 while they use port L2 to connect LAALP2. Assume all three L1
enable VLAN 10~20 while all three L2 enable VLAN 15~25. So that there
is an overlap of VLAN 15~20. Customer needs hosts in these overlap
VLANs to communicate with each other. That is, hosts attached to B1
in VLAN 15~20 need to 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 to 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 VLAN
15 and ingress nickname RB1. RB3 is the single exit point
(selected out according to the hashing function of LAALP) 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 packet 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 March 1, 2015 [Page 16]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
b. Suppose RB2/RB3 receives a TRILL multicast data packet with 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, RB2 and RB3 stores no
information of split horizon for AAE (since this port has not been
configured to be in any LAALP). They will egress the packet
ingressed from RB1-L1 in VLAN 15.
d. If a packet is ingressed from RB1-L1 or RB1-L2 with VLAN 15, port
RB1-L3 will not egress packets with ingress-nickname-RB1. RB1
needs to replicate this frame without encapsulation and sends it
out of port L3. This kind of 'bounce' behavior for multicast
frames is just as specified in paragraph 2 of Section 4.6.1.2 of
[RFC6325].
e. If a packet is ingressed from RB1-L3, since RB1-L1 and RB1-L2
cannot egress packets with VLAN 15 and ingress-nickname-RB1, RB1
needs to replicate this frame without encapsulation and sends it
out of port L1 and L2. (Also see paragraph 2 of Section 4.6.1.2 of
[RFC6325].)
Mingui Zhang, et al Expires March 1, 2015 [Page 17]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 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
EMC
2010 256th Avenue NE, #200
Bellevue, WA 98007 USA
EMail: radia@alum.mit.edu
Hongjun Zhai
ZTE Corporation
68 Zijinghua Road
Nanjing 200012 China
Phone: +86-25-52877345
EMail: zhai.hongjun@zte.com.cn
Muhammad Durrani
Brocade
130 Holger Way
San Jose, CA 95134
EMail: mdurrani@brocade.com
Mukhtiar Shaikh
Brocade
130 Holger Way
San Jose, CA 95134
EMail: mshaikh@brocade.com
Sujay Gupta
IP Infusion,
RMZ Centennial
Mahadevapura Post
Mingui Zhang, et al Expires March 1, 2015 [Page 18]
INTERNET-DRAFT MAC Multi-Attach for Active/Active August 28, 2014
Bangalore - 560048
India
EMail: sujay.gupta@ipinfusion.com
Mingui Zhang, et al Expires March 1, 2015 [Page 19]