summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7782.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7782.txt')
-rw-r--r--doc/rfc/rfc7782.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc7782.txt b/doc/rfc/rfc7782.txt
new file mode 100644
index 0000000..c225115
--- /dev/null
+++ b/doc/rfc/rfc7782.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Zhang
+Request for Comments: 7782 Huawei
+Category: Standards Track R. Perlman
+ISSN: 2070-1721 EMC
+ H. Zhai
+ Astute Technology
+ M. Durrani
+ Cisco Systems
+ S. Gupta
+ IP Infusion
+ February 2016
+
+
+ Transparent Interconnection of Lots of Links (TRILL)
+ Active-Active Edge Using Multiple MAC Attachments
+
+Abstract
+
+ TRILL (Transparent Interconnection of Lots of Links) active-active
+ service provides end stations with flow-level load balance and
+ resilience against link failures at the edge of TRILL campuses, as
+ described in RFC 7379.
+
+ This document specifies a method by which member RBridges (also
+ referred to as Routing Bridges or TRILL switches) 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 (who are not in the group) will see one host
+ Media Access Control (MAC) address being associated with the multiple
+ RBridges in the group. Such remote edge RBridges are required to
+ maintain all those associations (i.e., MAC attachments) and to not
+ flip-flop among them (as would occur prior to the implementation of
+ this specification). The design goals of this specification are
+ discussed herein.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7782.
+
+
+
+Zhang, et al. Standards Track [Page 1]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 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
+ 3. Overview ........................................................5
+ 4. Incremental Deployable Options ..................................6
+ 4.1. Details of Option B ........................................7
+ 4.1.1. Advertising Data Labels for Active-Active Edge ......7
+ 4.1.2. Discovery of Active-Active Edge Members .............8
+ 4.1.3. Advertising Learned MAC Addresses ...................9
+ 4.2. Extended RBridge Capability Flags APPsub-TLV ..............11
+ 5. Meeting the Design Goals .......................................12
+ 5.1. No MAC Address Flip-Flopping (Normal Unicast Egress) ......12
+ 5.2. Regular Unicast/Multicast Ingress .........................12
+ 5.3. Correct Multicast Egress ..................................12
+ 5.3.1. No Duplication (Single Exit Point) .................12
+ 5.3.2. No Echo (Split Horizon) ............................13
+ 5.4. No Black-Hole or Triangular Forwarding ....................14
+ 5.5. Load Balance towards the AAE ..............................14
+ 5.6. Scalability ...............................................14
+ 6. E-L1FS Backward Compatibility ..................................15
+ 7. Security Considerations ........................................15
+ 8. IANA Considerations ............................................16
+ 8.1. TRILL APPsub-TLVs .........................................16
+ 8.2. Extended RBridge Capabilities Registry ....................16
+ 8.3. Active-Active Flags .......................................17
+ 9. References .....................................................17
+ 9.1. Normative References ......................................17
+ 9.2. Informative References ....................................19
+ Appendix A. Scenarios for Split Horizon ...........................20
+ Acknowledgments ...................................................21
+ Authors' Addresses ................................................22
+
+
+
+
+Zhang, et al. Standards Track [Page 2]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+1. Introduction
+
+ As discussed in [RFC7379], in a TRILL (Transparent Interconnection of
+ Lots of Links) Active-Active Edge (AAE) topology, a Local
+ Active-Active Link Protocol (LAALP) -- for example, a Multi-Chassis
+ Link Aggregation (MC-LAG) bundle -- is used to connect multiple
+ RBridges (Routing Bridges or TRILL switches) to multi-port Customer
+ Equipment (CE), such as a switch, virtual switch (vSwitch), or
+ multi-port end station. A set of end nodes is attached in the case
+ of a switch or vSwitch. It is required that data traffic within a
+ specific VLAN from this end node set (including the multi-port
+ end-station case) can be ingressed and egressed by any of these
+ RBridges simultaneously. End systems in the set can spread their
+ traffic among these edge RBridges at the flow level. When a link
+ fails, end systems keep using the remaining links in the LAALP
+ without waiting for the convergence of TRILL, which provides
+ resilience to link failures.
+
+ Since a frame from each end node can be ingressed by any RBridge in
+ the local AAE group, a remote edge RBridge may observe multiple
+ attachment points (i.e., egress RBridges) for this end node. This
+ issue is known as "MAC address flip-flopping"; see [RFC7379] for a
+ discussion.
+
+ Per this document, AAE member RBridges use their own nicknames to
+ ingress frames into the TRILL campus. Remote edge RBridges are
+ required to keep multiple points of attachment per MAC address and
+ Data Label (VLAN or Fine-Grained Label [RFC7172]) attached to the
+ AAE. This addresses the MAC flip-flopping issue. Using this
+ solution, as specified in this document, in an AAE group does not
+ prohibit the use of other solutions in other AAE groups in the same
+ TRILL campus. For example, the specification in this document and
+ the specification in [RFC7781] could be simultaneously deployed for
+ different AAE groups in the same campus.
+
+ The main body of this document is organized as follows: Section 2
+ lists acronyms and terms. Section 3 describes the overview model.
+ Section 4 provides options for incremental deployment. Section 5
+ describes how this approach meets the design goals. Section 6
+ discusses backward compatibility. Section 7 covers security
+ considerations. Section 8 covers IANA considerations.
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 3]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+2. Acronyms and Terminology
+
+ AAE: Active-Active Edge
+
+ Campus: A TRILL network consisting of TRILL switches, links, and
+ possibly bridges bounded by end stations and IP routers. For
+ TRILL, there is no "academic" implication in the name "campus".
+
+ CE: Customer Equipment (end station or bridge). The device can be
+ either physical or virtual equipment.
+
+ Data Label: VLAN or Fine-Grained Label (FGL)
+
+ DRNI: Distributed Resilient Network Interconnect. A link aggregation
+ specified in [802.1AX] that can provide an LAALP between (a) one,
+ two, or three CEs and (b) two or three RBridges.
+
+ E-L1FS: Extended Level 1 Flooding Scope
+
+ Edge RBridge: An RBridge providing end-station service on one or more
+ of its ports.
+
+ ESADI: End Station Address Distribution Information [RFC7357]
+
+ FGL: Fine-Grained Label [RFC7172]
+
+ FS-LSP: Flooding Scope Link State Protocol Data Unit
+
+ IS: Intermediate System [IS-IS]
+
+ IS-IS: Intermediate System to Intermediate System [IS-IS]
+
+ LAALP: Local Active-Active Link Protocol [RFC7379]. Any protocol
+ similar to MC-LAG (or DRNI) that runs in a distributed fashion on
+ a CE, on the links from that CE to a set of edge group RBridges,
+ and on those RBridges.
+
+ LSP: Link State PDU
+
+ MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of
+ link aggregation [802.1AX] that can provide an LAALP between one
+ CE and two or more RBridges.
+
+ PDU: Protocol Data Unit
+
+ RBridge: A device implementing the TRILL protocol.
+
+
+
+
+
+Zhang, et al. Standards Track [Page 4]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ TRILL: Transparent Interconnection of Lots of Links or Tunneled
+ Routing in the Link Layer [RFC6325] [RFC7177].
+
+ TRILL switch: An alternative name for an RBridge.
+
+ vSwitch: A virtual switch, such as a hypervisor, that also simulates
+ a bridge.
+
+ 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
+
+ +-----+
+ | RB4 |
+ +----------+-----+----------+
+ | |
+ | |
+ | Rest of campus |
+ | |
+ | |
+ +-+-----+--+-----+--+-----+-+
+ | RB1 | | RB2 | | RB3 |
+ +-----\ +-----+ /-----+
+ \ | /
+ \ | /
+ |||LAALP1
+ |||
+ +---+
+ | B |
+ +---+
+ H1 H2 H3 H4: VLAN 10
+
+ Figure 1: An Example Topology for TRILL Active-Active Edge
+
+ Figure 1 shows an example network for TRILL AAE (see also Figure 1 in
+ [RFC7379]). In this figure, end nodes (H1, H2, H3, and H4) are
+ attached to a bridge (B) that communicates with multiple RBridges
+ (RB1, RB2, and RB3) via the LAALP. Suppose that RB4 is a "remote"
+ RBridge not in 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 (VMs).
+
+
+
+
+Zhang, et al. Standards Track [Page 5]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ For a frame received from its attached end node sets, a member
+ RBridge of the AAE group conforming to this document always
+ encapsulates that frame using its own nickname as the ingress
+ nickname, regardless of whether it is unicast or multicast.
+
+ With the two options specified below, even though remote RBridge RB4
+ will see multiple attachments for each MAC address from one of the
+ end nodes, MAC address flip-flopping will not cause any problems.
+
+4. Incremental Deployable Options
+
+ This section specifies two options. Option A requires new hardware
+ support. Option B can be incrementally implemented throughout a
+ TRILL campus with common existing TRILL "fast path" hardware.
+ Further details on Option B are given in Section 4.1.
+
+ Option A:
+ A new capability announcement would appear in LSPs: "I can cope
+ with data-plane learning of multiple attachments for an end node."
+ This mode of operation is generally not supported by existing
+ TRILL fast path hardware. Only if all edge RBridges to which the
+ group has data connectivity -- and that are interested in any of
+ the Data Labels in which the AAE is interested -- announce this
+ capability can the AAE group safely use this approach. If all
+ such RBridges do not announce this "Option A" capability, then a
+ fallback would be needed, such as reverting from active-active to
+ active-standby operation or isolating the RBridges that would need
+ to support this capability but do not support it. Further details
+ for Option A are beyond the scope of this document, except that,
+ as described in Section 4.2, a bit is reserved to indicate support
+ for Option A, because a remote RBridge supporting Option A is
+ compatible with an AAE group using Option B.
+
+ Option B:
+ As pointed out in Section 4.2.6 of [RFC6325] and Section 5.3 of
+ [RFC7357], one MAC address may be persistently claimed to be
+ attached to multiple RBridges within the same Data Label in the
+ TRILL ESADI-LSPs. For Option B, AAE member RBridges make use of
+ the TRILL ESADI protocol to distribute multiple attachments of a
+ MAC address. Remote RBridges SHOULD disable data-plane MAC
+ learning for such multi-attached MAC addresses from TRILL Data
+ packet decapsulation, unless they also support Option A. The
+ ability to configure an RBridge to disable data-plane learning is
+ provided by the base TRILL protocol [RFC6325].
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 6]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+4.1. Details of Option B
+
+ With Option B, the receiving edge RBridges MUST avoid flip-flop
+ errors for MAC addresses learned from the TRILL Data packet
+ decapsulation for the originating RBridge within these Data Labels.
+ It is RECOMMENDED that the receiving edge RBridge disable data-plane
+ MAC learning from TRILL Data packet decapsulation within those
+ advertised Data Labels for the originating RBridge, unless the
+ receiving RBridge also supports Option A. Alternative
+ implementations that produce the same expected behavior, i.e., the
+ receiving edge RBridge does not flip-flop among multiple MAC
+ attachments, are acceptable. For example, the confidence-level
+ mechanism as specified in [RFC6325] can be used. Let the receiving
+ edge RBridge give a prevailing confidence value (e.g., 0x21) to the
+ first MAC attachment learned from the data plane over others from the
+ TRILL Data packet decapsulation. The receiving edge RBridge will
+ stick to this MAC attachment until it is overridden by one learned
+ from the ESADI protocol [RFC7357]. The MAC attachment learned from
+ ESADI is set to have a higher confidence value (e.g., 0x80) to
+ override any alternative learning from the decapsulation of received
+ TRILL Data packets [RFC6325].
+
+4.1.1. Advertising Data Labels for Active-Active Edge
+
+ An RBridge in an AAE group MUST participate in ESADI in Data Labels
+ enabled for its attached LAALPs. This document further registers two
+ data flags, which are used to advertise that the originating RBridge
+ supports and participates in an AAE. These two flags are allocated
+ from the Interested VLANs Flag Bits that appear in the Interested
+ VLANs and Spanning Tree Roots sub-TLV and the Interested Labels Flag
+ Bits that appear in the Interested Labels and Spanning Tree Roots
+ sub-TLV [RFC7176] (see Section 8.3). When these flags are set to 1,
+ the originating RBridge is advertising Data Labels for LAALPs rather
+ than plain LAN links.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 7]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+4.1.2. Discovery of Active-Active Edge Members
+
+ Remote edge RBridges need to discover RBridges in an AAE. This is
+ achieved by listening to the following "AA LAALP Group RBridges"
+ TRILL APPsub-TLV included in the TRILL GENINFO TLV in FS-LSPs
+ [RFC7780]:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = AA-LAALP-GROUP-RBRIDGES| (2 bytes)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | (2 bytes)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sender Nickname | (2 bytes)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LAALP ID Size | (1 byte)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
+ | LAALP ID (k bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
+
+ o Type: AA LAALP Group RBridges (TRILL APPsub-TLV type 252)
+
+ o Length: 3 + k
+
+ o Sender Nickname: The nickname the originating RBridge will use as
+ the ingress nickname. This field is useful because the
+ originating RBridge might own multiple nicknames.
+
+ o LAALP ID Size: The length, k, of the LAALP ID in bytes.
+
+ o LAALP ID: The ID of the LAALP, which is k bytes long. If the
+ LAALP is an MC-LAG or DRNI, it is the 8-byte ID, as specified in
+ Clause 6.3.2 of [802.1AX].
+
+ This APPsub-TLV is expected to rarely change, as it only does so in
+ cases of the creation or elimination of an AAE group, or of link
+ failure or restoration to the CE in such a group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 8]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+4.1.3. Advertising Learned MAC Addresses
+
+ Whenever MAC addresses from the LAALP of this AAE are learned through
+ ingress or configuration, the originating RBridge MUST advertise
+ these MAC addresses using the MAC-Reachability TLV [RFC6165] via the
+ ESADI protocol [RFC7357]. The MAC-Reachability TLVs 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 = AA-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: AA LAALP Group MAC (TRILL APPsub-TLV type 253)
+
+ 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, k, of the LAALP ID in bytes.
+
+ o LAALP ID: The ID of the LAALP, which is k bytes long. Here, it
+ also serves as the identifier of the AAE. If the LAALP is an
+ MC-LAG (or DRNI), it is the 8-byte ID, as specified in
+ Clause 6.3.2 of [802.1AX].
+
+ o MAC-Reachability sub-TLV: The AA-LAALP-GROUP-MAC APPsub-TLV value
+ contains the MAC-Reachability TLV as a sub-TLV (see [RFC6165];
+ n is the number of MAC addresses present). As specified in
+ Section 2.2 of [RFC7356], the Type and Length fields of the
+ MAC-Reachability TLV are encoded as unsigned 16-bit integers. The
+ 1-byte unsigned confidence value, along with these TLVs, SHOULD be
+ set to prevail over those MAC addresses learned from TRILL Data
+ decapsulation by remote edge RBridges.
+
+ This AA-LAALP-GROUP-MAC APPsub-TLV MUST be included in a TRILL
+ GENINFO TLV [RFC7357] in the ESADI-LSP. There may be more than one
+ occurrence of such TRILL APPsub-TLVs in one ESADI-LSP fragment.
+
+
+
+
+Zhang, et al. Standards Track [Page 9]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ For those MAC addresses contained in an AA-LAALP-GROUP-MAC
+ APPsub-TLV, this document applies. Otherwise, [RFC7357] applies.
+ For example, an AAE member RBridge continues to enclose MAC addresses
+ learned from TRILL Data packet decapsulation in MAC-Reachability TLVs
+ as per [RFC6165] and advertise them using the ESADI protocol.
+
+ When the remote RBridge learns MAC addresses contained in the
+ AA-LAALP-GROUP-MAC APPsub-TLV via the ESADI protocol [RFC7357], it
+ 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
+ AA-LAALP-GROUP-MAC APPsub-TLV. If there are multiple equal
+ least-cost member RBridges, the ingress RBridge is required to select
+ one of them in a pseudorandom way, as specified in Section 5.3 of
+ [RFC7357].
+
+ When another RBridge in the same AAE group receives an ESADI-LSP with
+ the AA-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 AA-LAALP-GROUP-MAC APPsub-TLV to
+ advertise in ESADI 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 normally been disabled for this RBridge.
+
+ This APPsub-TLV changes whenever the MAC reachability situation for
+ the LAALP changes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 10]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+4.2. Extended RBridge Capability Flags APPsub-TLV
+
+ The following Extended RBridge Capability Flags APPsub-TLV will be
+ included in E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of
+ the TRILL GENINFO TLV:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = EXTENDED-RBRIDGE-CAP | (2 bytes)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | (2 bytes)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Topology | (2 bytes)
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |E|H| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved (continued) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ o Type: Extended RBridge Capability (TRILL APPsub-TLV type 254)
+
+ o Length: Set to 10.
+
+ o Topology: Indicates the topology to which the capabilities apply.
+ When this field is set to zero, either topologies are not in use
+ or the capabilities apply to all topologies [TRILL-MT].
+
+ o E: Bit 0 of the capability bits. When this bit is set, it
+ indicates that the originating RBridge acts as specified in
+ Option B above.
+
+ o H: Bit 1 of the capability bits. When this bit is set, it
+ indicates that the originating RBridge keeps multiple MAC
+ attachments learned from TRILL Data packet decapsulation with fast
+ path hardware; that is, it acts as specified in Option A above.
+
+ o Reserved: Flags extending from bit 2 through bit 63 of the
+ capability bits. Reserved for future use. These MUST be sent as
+ zero and ignored on receipt.
+
+ The Extended RBridge Capability Flags TRILL APPsub-TLV is used to
+ notify other RBridges as to whether the originating RBridge supports
+ the capability indicated by the E and H bits. For example, if the
+ E bit is set, it indicates that the originating RBridge will act as
+ defined in Option B. That is, it will disable the MAC learning from
+ TRILL Data packet decapsulation within Data Labels advertised by AAE
+ RBridges 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 is required that MAC addresses
+
+
+
+Zhang, et al. Standards Track [Page 11]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ learned from local LAALPs be advertised in TRILL ESADI-LSPs, using
+ the AA-LAALP-GROUP-MAC APPsub-TLV, which is defined in Section 4.1.3.
+ If an RBridge in an AAE group, as specified herein, observes a remote
+ RBridge interested in one or more of that AAE group's Data Labels and
+ the remote RBridge does not support, as indicated by its extended
+ capabilities, either Option A or Option B, then the AAE group MUST
+ fall back to active-standby mode.
+
+ This APPsub-TLV is expected to rarely change, as it only needs to be
+ updated when RBridge capabilities change, e.g., due to an upgrade or
+ reconfiguration.
+
+5. Meeting the Design Goals
+
+ This section explores how this specification meets the major design
+ goals of AAE.
+
+5.1. No MAC Address Flip-Flopping (Normal Unicast Egress)
+
+ Since all RBridges talking with the AAE RBridges in the campus are
+ able to see multiple attachments for one MAC address in ESADI
+ [RFC7357], 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, for
+ return traffic the remote RBridge is required to consistently use one
+ of the attachments for each MAC address rather than flip-flopping
+ among them (see Section 4.2.6 of [RFC6325] and Section 5.3 of
+ [RFC7357]).
+
+5.2. Regular Unicast/Multicast Ingress
+
+ LAALP guarantees that each frame will be sent to the AAE via exactly
+ one uplink. RBridges in the AAE 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 a scenario, each RBridge takes for granted that it is the
+ Appointed Forwarder for the VLANs enabled on the uplink of the LAALP.
+
+5.3. Correct Multicast Egress
+
+ A fundamental design goal of AAE is that there must be no duplication
+ or forwarding loop.
+
+5.3.1. No Duplication (Single Exit Point)
+
+ When multi-destination TRILL Data packets for a specific Data Label
+ are received from the campus, it is important that exactly one
+ RBridge out of the AAE group let through each multi-destination
+
+
+
+Zhang, et al. Standards Track [Page 12]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ packet so that no duplication will happen. The LAALP will have
+ defined its selection function (using hashing or an election
+ algorithm) to designate a forwarder for a multi-destination frame.
+ Since AAE member RBridges support the LAALP, they are able to utilize
+ that selection function to determine the single exit point. If the
+ output of the selection function points to the port attached to the
+ receiving RBridge itself (i.e., the packet should be egressed out of
+ this node), the receiving RBridge MUST egress this packet for that
+ AAE group. Otherwise, the packet MUST NOT be egressed for that AAE
+ group. (For ports that lead to non-AAE links, the receiving RBridge
+ determines whether to egress the packet or not, according to
+ [RFC6325], which is updated by [RFC7172].)
+
+5.3.2. No Echo (Split Horizon)
+
+ When a multi-destination frame originated from an LAALP is ingressed
+ by an RBridge of an AAE group, distributed to the TRILL network, and
+ then received by another RBridge in the same AAE group, it is
+ important that this receiving RBridge does not egress this frame back
+ to this LAALP. Otherwise, it will cause a forwarding loop (echo).
+ The well-known "split horizon" technique (as discussed in
+ Section 2.2.1 of [RFC1058]) is used to eliminate the echo issue.
+
+ RBridges in the AAE group need to perform 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 consisting of the tuple
+ of <ingress nickname, VLAN>. Packets with information matching any
+ entry in the filtering list MUST NOT be egressed out of that port.
+ The information for such filters is obtained by listening to the
+ AA-LAALP-GROUP-RBRIDGES TRILL APPsub-TLVs, as defined in
+ Section 4.1.2. Note that all enabled VLANs MUST be consistent on all
+ ports connected to an LAALP. So, the enabled VLANs need not be
+ included in these TRILL APPsub-TLVs. They can be locally obtained
+ from the port attached to that LAALP. By parsing these APPsub-TLVs,
+ the receiving RBridge discovers all other RBridges connected to the
+ same LAALP. The Sender Nickname of the originating RBridge will be
+ added to the filtering list of the port attached to the LAALP. For
+ example, RB3 in Figure 1 will set up a filtering list that looks like
+ {<RB1, VLAN 10>, <RB2, VLAN 10>} on its port attached to LAALP1.
+ According to split horizon, TRILL Data packets within VLAN 10
+ 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 VLANs that overlap. Here, a VLAN overlap means that
+ this VLAN ID is enabled by multiple LAALPs. A customer may require
+ that hosts within these overlapped VLANs communicate with each other.
+
+
+
+
+
+Zhang, et al. Standards Track [Page 13]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ Appendix A provides several scenarios to explain how hosts
+ communicate within the overlapped 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
+ AAE member RBridge with that failed port starts to redirect the
+ packets to other member RBridges for delivery, triangular forwarding
+ occurs.
+
+ The member RBridge attached to the failed sub-link makes use of the
+ ESADI protocol to flush those MAC addresses affected by the failure,
+ as defined in Section 5.2 of [RFC7357]. After doing that, no packets
+ will be sent towards the failed port, and hence no black-hole will
+ happen. Nor will the member RBridge need to redirect packets to
+ other member RBridges; thus, triangular forwarding is avoided.
+
+5.5. Load Balance towards the AAE
+
+ Since a remote RBridge can see multiple attachments of one MAC
+ address in ESADI, this remote RBridge can choose to spread the
+ traffic towards the AAE members on a per-flow basis. Each of them is
+ able to act as the egress point. In doing this, the forwarding paths
+ need not be limited to the least-cost path selection 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
+ pseudorandom selection method (see Section 4.1.3).
+
+ Note that the load-balance method adopted at a remote 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 learning table. However, MAC addresses attached to an LAALP
+ are usually only a small part of all MAC addresses in the whole TRILL
+ campus. As a result, the extra table memory space required by
+ multi-attached MAC addresses can usually be accommodated in an
+ RBridge's unused MAC table space.
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 14]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ With Option B, remote RBridges will keep the multiple attachments of
+ a MAC address in the ESADI link-state databases, which are usually
+ maintained by software. In the MAC table, which is normally
+ implemented in hardware, an RBridge still establishes only one entry
+ for each MAC address.
+
+6. E-L1FS Backward Compatibility
+
+ The Extended TLVs defined in Sections 4.1.2, 4.1.3, and 4.2 of this
+ document are to be used in an Extended Level 1 Flooding Scope
+ (E-L1FS) PDU [RFC7356] [RFC7780]. For those RBridges that do not
+ support E-L1FS, the EXTENDED-RBRIDGE-CAP TRILL APPsub-TLV will not be
+ sent out either, and MAC multi-attach active-active is not supported.
+
+7. Security Considerations
+
+ For security considerations pertaining to extensions transported by
+ TRILL ESADI, see the Security Considerations section in [RFC7357].
+
+ For extensions not transported by TRILL ESADI, RBridges may be
+ configured to include the IS-IS Authentication TLV (10) in the IS-IS
+ PDUs to use IS-IS security [RFC5304] [RFC5310].
+
+ Since currently deployed LAALPs [RFC7379] are proprietary, security
+ over membership in, and internal management of, AAE groups is
+ proprietary. In environments where the above authentication is not
+ adopted, a rogue RBridge that insinuates itself into an AAE group can
+ disrupt end-station traffic flowing into or out of that group. For
+ example, if there are N RBridges in the group, it could typically
+ control 1/Nth of the traffic flowing out of that group and a similar
+ amount of unicast traffic flowing into that group.
+
+ For general TRILL security considerations, see [RFC6325].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 15]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+8. IANA Considerations
+
+8.1. TRILL APPsub-TLVs
+
+ IANA has allocated three new types under the TRILL GENINFO TLV
+ [RFC7357] for the TRILL APPsub-TLVs defined in Sections 4.1.2, 4.1.3,
+ and 4.2 of this document. The following entries have been added to
+ the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application
+ Identifier 1" registry on the TRILL Parameters IANA web page.
+
+ Type Name Reference
+ ---- ---- ---------
+ 252 AA-LAALP-GROUP-RBRIDGES RFC 7782
+ 253 AA-LAALP-GROUP-MAC RFC 7782
+ 254 EXTENDED-RBRIDGE-CAP RFC 7782
+
+8.2. Extended RBridge Capabilities Registry
+
+ IANA has created a registry under the "Transparent
+ Interconnection of Lots of Links (TRILL) Parameters" registry
+ as follows:
+
+ Name: Extended RBridge Capabilities
+
+ Registration Procedure: Expert Review
+
+ Reference: RFC 7782
+
+ Bit Mnemonic Description Reference
+ ---- -------- ----------- ---------
+ 0 E Option B Support RFC 7782
+ 1 H Option A Support RFC 7782
+ 2-63 - Unassigned
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 16]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+8.3. Active-Active Flags
+
+ IANA has allocated two flag bits, with mnemonic "AA", as follows:
+
+ One flag bit is allocated from the Interested VLANs Flag Bits.
+
+ Bit Mnemonic Description Reference
+ --- -------- ----------- ---------
+ 16 AA VLANs for Active-Active RFC 7782
+
+ One flag bit is allocated from the Interested Labels Flag Bits.
+
+ Bit Mnemonic Description Reference
+ --- -------- ----------- ---------
+ 4 AA FGLs for Active-Active RFC 7782
+
+9. References
+
+9.1. Normative References
+
+ [802.1AX] IEEE, "IEEE Standard for Local and metropolitan area
+ networks - Link Aggregation", IEEE Std 802.1AX-2014,
+ DOI 10.1109/IEEESTD.2014.7055197, December 2014.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
+ Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011,
+ <http://www.rfc-editor.org/info/rfc6165>.
+
+ [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
+ Ghanwani, "Routing Bridges (RBridges): Base Protocol
+ Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
+ <http://www.rfc-editor.org/info/rfc6325>.
+
+ [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
+ Hu, "Routing Bridges (RBridges): Appointed Forwarders",
+ RFC 6439, DOI 10.17487/RFC6439, November 2011,
+ <http://www.rfc-editor.org/info/rfc6439>.
+
+ [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
+ D. Dutt, "Transparent Interconnection of Lots of Links
+ (TRILL): Fine-Grained Labeling", RFC 7172,
+ DOI 10.17487/RFC7172, May 2014,
+ <http://www.rfc-editor.org/info/rfc7172>.
+
+
+
+Zhang, et al. Standards Track [Page 17]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
+ D., and A. Banerjee, "Transparent Interconnection of Lots
+ of Links (TRILL) Use of IS-IS", RFC 7176,
+ DOI 10.17487/RFC7176, May 2014,
+ <http://www.rfc-editor.org/info/rfc7176>.
+
+ [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
+ V. Manral, "Transparent Interconnection of Lots of Links
+ (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177,
+ May 2014, <http://www.rfc-editor.org/info/rfc7177>.
+
+ [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
+ Scope Link State PDUs (LSPs)", RFC 7356,
+ DOI 10.17487/RFC7356, September 2014,
+ <http://www.rfc-editor.org/info/rfc7356>.
+
+ [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
+ Stokes, "Transparent Interconnection of Lots of Links
+ (TRILL): End Station Address Distribution Information
+ (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
+ September 2014, <http://www.rfc-editor.org/info/rfc7357>.
+
+ [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
+ Ghanwani, A., and S. Gupta, "Transparent Interconnection
+ of Lots of Links (TRILL): Clarifications, Corrections, and
+ Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
+ <http://www.rfc-editor.org/info/rfc7780>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 18]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+9.2. Informative References
+
+ [IS-IS] International Organization for Standardization,
+ "Information technology -- Telecommunications and
+ information exchange between systems -- Intermediate
+ System to Intermediate System intra-domain routeing
+ information exchange protocol for use in conjunction with
+ the protocol for providing the connectionless-mode network
+ service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
+ November 2002.
+
+ [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
+ DOI 10.17487/RFC1058, June 1988,
+ <http://www.rfc-editor.org/info/rfc1058>.
+
+ [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
+ Authentication", RFC 5304, DOI 10.17487/RFC5304,
+ October 2008, <http://www.rfc-editor.org/info/rfc5304>.
+
+ [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
+ and M. Fanto, "IS-IS Generic Cryptographic
+ Authentication", RFC 5310, DOI 10.17487/RFC5310,
+ February 2009, <http://www.rfc-editor.org/info/rfc5310>.
+
+ [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
+ "Problem Statement and Goals for Active-Active Connection
+ at the Transparent Interconnection of Lots of Links
+ (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379,
+ October 2014, <http://www.rfc-editor.org/info/rfc7379>.
+
+ [RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y.
+ Li, "Transparent Interconnection of Lots of Links (TRILL):
+ Pseudo-Nickname for Active-Active Access", RFC 7781,
+ DOI 10.17487/RFC7781, February 2016,
+ <http://www.rfc-editor.org/info/rfc7781>.
+
+ [TRILL-MT] Eastlake 3rd, D., Zhang, M., Banerjee, A., and V. Manral,
+ "TRILL: Multi-Topology", Work in Progress,
+ draft-ietf-trill-multi-topology-00, September 2015.
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 19]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+Appendix A. Scenarios for Split Horizon
+
+ +------------------+ +------------------+ +------------------+
+ | 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 2: An Example Topology to Explain Split Horizon
+
+ Suppose that 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 that all these RBridges use port L1 to
+ connect LAALP1 while they use port L2 to connect LAALP2. Assume that
+ all three L1 ports enable VLANs 10-20 while all three L2 ports enable
+ VLANs 15-25, so that there is an overlap of VLANs 15-20. A customer
+ may require that hosts within these overlapped VLANs communicate with
+ each other. That is, hosts attached to B1 in VLANs 15-20 need to
+ communicate with hosts attached to B2 in VLANs 15-20. Assume that
+ the remote plain RBridge RB4 also has hosts attached in VLANs 15-20
+ that need to communicate with those hosts in these VLANs attached to
+ B1 and B2.
+
+ There are two major requirements:
+
+ 1. Frames ingressed from RB1-L1-VLANs 15-20 MUST NOT be egressed out
+ of ports RB2-L1 and RB3-L1.
+
+ 2. At the same time, frames coming from B1-VLANs 15-20 should reach
+ B2-VLANs 15-20.
+
+ RB3 stores the information for split horizon on its ports L1 and L2.
+
+ On L1: {<ingress_nickname_RB1, VLANs 10-20>,
+ <ingress_nickname_RB2, VLANs 10-20>}.
+
+ On L2: {<ingress_nickname_RB1, VLANs 15-25>,
+ <ingress_nickname_RB2, VLANs 15-25>}.
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Standards Track [Page 20]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+ Five clarification scenarios follow:
+
+ a. Suppose that RB2 or RB3 receives a TRILL multi-destination data
+ packet with VLAN 15 and ingress_nickname_RB1. RB3 is the single
+ exit point (selected according to the hashing function of LAALP)
+ for this packet. On ports L1 and 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 determines that it should be forwarded as a
+ multi-destination 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.
+
+ b. Suppose that RB2 or RB3 receives a TRILL multi-destination data
+ packet with VLAN 15 and ingress_nickname_RB4. RB3 is the single
+ exit point. On ports L1 and 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 that 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 store no information for 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
+ multi-destination frames is just as specified in paragraph 3 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 ports L1 and L2. (Also see paragraph 3 of Section 4.6.1.2
+ of [RFC6325].)
+
+Acknowledgments
+
+ The authors would like to thank the following people for their
+ comments and suggestions: Andrew Qu, Donald Eastlake, Erik Nordmark,
+ Fangwei Hu, Liang Xia, Weiguo Hao, Yizhou Li, and Mukhtiar Shaikh.
+
+
+
+
+Zhang, et al. Standards Track [Page 21]
+
+RFC 7782 Multi-Attach for Active-Active Edge February 2016
+
+
+Authors' Addresses
+
+ Mingui Zhang
+ Huawei Technologies
+ No. 156 Beiqing Rd., Haidian District
+ Beijing 100095
+ China
+
+ Email: zhangmingui@huawei.com
+
+
+ Radia Perlman
+ EMC
+ 2010 256th Avenue NE, #200
+ Bellevue, WA 98007
+ United States
+
+ Email: radia@alum.mit.edu
+
+
+ Hongjun Zhai
+ Nanjing Astute Software Technology Co. Ltd
+ 57 Andemen Avenue, Yuhuatai District
+ Nanjing, Jiangsu 210016
+ China
+
+ Email: honjun.zhai@tom.com
+
+
+ Muhammad Durrani
+ Cisco Systems
+ 170 West Tasman Dr.
+ San Jose, CA 95134
+ United States
+
+ Email: mdurrani@cisco.com
+
+
+ Sujay Gupta
+ IP Infusion
+ RMZ Centennial
+ Mahadevapura Post
+ Bangalore 560048
+ India
+
+ Email: sujay.gupta@ipinfusion.com
+
+
+
+
+
+Zhang, et al. Standards Track [Page 22]
+