TRILL Working Group H. Zhai
Internet-Draft ZTE
Intended status: Standards Track T. Senevirathne
Expires: June 13, 2013 Cisco Systems
R. Perlman
Intel Labs
D. Eastlake 3rd
M. Zhang
Huawei
F. Hu
ZTE
December 10, 2012
RBridge: Pseudo-Nickname
draft-hu-trill-pseudonode-nickname-04
Abstract
RBridges provide frame forwarding service to layer2 switches or end
stations at the edge of TRILL campus. As defined in [RFC6325], when
there are multiple RBridges attached to the same LAN segment, only
one edge RBridge is allowed to be the frame forwarder of a specific
VLAN in order to avoid potential frame duplication and loops in the
TRILL campus. However, in some application scenarios, for example an
end station is multi-homed to multiple RBridges needs to improve the
resiliency and increase the available network bandwidth of the
connection. This means all those RBriges attached to the end station
can act as the frame forwarders of a specific VLAN. This kind of
active-active connection violates the definition above. Frame
duplication and forwarding loops may happen and it may cause the
flip-flopping of the egress RBridge nickname associated to the MAC
address of such an end station in remote RBridges' forwarding tables.
The Reverse Path Forwarding Check does not work as well, which has
been addressed in [CMT]. This document proposes the concept of
Virtual RBridge, along with the pseudo-nickname configuration for
this Virtual RBridge, to address the above problems in accompany with
[CMT].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Zhai, et al. Expires June 13, 2013 [Page 1]
Internet-Draft Pseudo-Nickname December 2012
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."
This Internet-Draft will expire on June 13, 2013.
Copyright Notice
Copyright (c) 2012 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.
Zhai, et al. Expires June 13, 2013 [Page 2]
Internet-Draft Pseudo-Nickname December 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . . 5
1.2. Contributors . . . . . . . . . . . . . . . . . . . . . . . 5
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Appointed Forwarders on Shared Links . . . . . . . . . . . 6
2.2. Multi-homing and Link Aggregation to TRILL Network . . . . 6
3. Concept of Virtual RBridge and Pseudo-nickname . . . . . . . . 7
3.1. VLAN-x Appointed Forwarder for member interfaces in RBv . 7
3.2. Announcing Pseudo-Nickname of RBv . . . . . . . . . . . . 8
4. Distribution Trees for Member RBridges in RBv . . . . . . . . 8
4.1. Trees for Native Frames Ingressing . . . . . . . . . . . . 9
4.2. Designated Forwarder for traffic received on
Distribution trees . . . . . . . . . . . . . . . . . . . . 9
5. Frame Processing . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Native Frames Ingressing . . . . . . . . . . . . . . . . . 12
5.2. TRILL Data Frames Egressing . . . . . . . . . . . . . . . 12
5.2.1. Unicast TRILL Data Frames . . . . . . . . . . . . . . 12
5.2.2. Multi-Destination TRILL Data Frames . . . . . . . . . 13
6. Member Link Failure in RBv . . . . . . . . . . . . . . . . . . 14
6.1. Link Protection for Unicast Frame Egressing . . . . . . . 14
6.2. Link Protection for Multi-destination Frame Egressing . . 15
7. Extensions to ESADI . . . . . . . . . . . . . . . . . . . . . 15
8. OAM Frames . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Configuration Consistency . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Rationale for MAC Sharing among Member RBridges . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Zhai, et al. Expires June 13, 2013 [Page 3]
Internet-Draft Pseudo-Nickname December 2012
1. Introduction
The IETF TRILL protocol [RFC6325] provides optimal pair-wise data
frame forwarding without configuration, safe forwarding even during
periods of temporary loops, and support for multi-pathing of both
unicast and multicast traffic. TRILL accomplishes this by using
[IS-IS] [RFC1195] link state routing and encapsulating traffic using
a header that includes a hop count. The design supports VLANs and
optimization of the distribution of multi-destination frames based on
VLANs and IP derived multicast groups. Devices that implement TRILL
are called RBridges.
In TRILL protocol, RBridges are identified by nicknames (16-bits).
At the edge of TRILL network, some RBridges connect to legacy
networks on one side and connect to the TRILL network on the other
side. These RBridges are called edge RBridges. For the connectivity
between the two types of network, edge RBridges provide frame
forwarding service to end stations located in legacy networks. When
receiving a native frame from such a local end station S, the service
edge RBridge RB1 encapsulates the frame in a TRILL header, addressing
the packet to RBridge RBx to which the destination end station D is
attached. The TRILL header contains an "ingress RBridge nickname"
field (filled with RB1's nickname), an "egress RBridge nickname"
field (filled with RBx's nickname), and a hop count. On receiving
such a frame, RBx removes the TRILL header and forwards it in native
form to D. Meanwhile, based on the de-capsulation of that frame, RBx
learns the { ingress RBridge nickname, source MAC address, VLAN ID }
triplet. Edge RBridges maintain such triplets in their forwarding
tables for the future forwarding of native frames.
In TRILL protocol, RBridges are identified by nicknames (16-bits).
At the edge of TRILL network, some RBridges connect to legacy
networks on one side and connect to the TRILL network on the other
side. These RBridges are called edge RBridges. For the connectivity
between the two types of network, edge RBridges provide frame
forwarding service to end stations located in legacy networks. When
receiving a native frame from such a local end station S, the service
edge RBridge RB1 encapsulates the frame in a TRILL header, addressing
the packet to RBridge RBx to which the destination end station D is
attached. The TRILL header contains an "ingress RBridge nickname"
field (filled with RB1's nickname), an "egress RBridge nickname"
field (filled with RBx's nickname), and a hop count. On receiving
such a frame, RBx removes the TRILL header and forwards it in native
form to D. Meanwhile, based on the de-capsulation of that frame, RBx
learns the { ingress RBridge nickname, source MAC address, VLAN ID }
triplet. Edge RBridges maintain such triplets in their forwarding
tables for the future forwarding of native frames.
Zhai, et al. Expires June 13, 2013 [Page 4]
Internet-Draft Pseudo-Nickname December 2012
In this document, the concept of Virtual RBridge group, together with
its Pseudo-nickname, is introduced to address the rest of above
issues. For a member RBridge of such a group, it uses the pseudo-
nickname, instead of its own nickname, as the ingress RBridge
nickname when ingressing frames into TRILL campus. So, in such a
RBridge Group, even if there are more than one RBridge providing
frame forwarding service for an end station or the service RBridge
changes over from one to another member RBridge in same group, the
ingress RBridge nickname associated to this end station needs not be
unchanged in remote RBridges' forwarding tables.
This document is organized as follows: Section 2 describes why
virtual RBridge along with its pseudo-nickname is needed. Section 3
gives the concept of virtual RBridge. Section 4 describes
distribution trees allocation across member RBridges in a RBv.
Section 5 covers the processing of transit frames in consideration of
the pseudo-nickname.
Familiarity with [RFC6325] is assumed in this document.
1.1. Terminology and Acronyms
This document uses the acronyms defined in [RFC6325] and the
following additional acronym:
AF - Appointed Forwarder
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 [RFC2119].
When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in
[RFC2119].
1.2. Contributors
We would like to thank Mingjiang Chen for his contributions to this
document. Additionally, we would like to thank Erik Nordmark, Les
Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan
Pathang, and Jon Hudson for their good questions and comments.
2. Problem Statement
Zhai, et al. Expires June 13, 2013 [Page 5]
Internet-Draft Pseudo-Nickname December 2012
2.1. Appointed Forwarders on Shared Links
Even there are multiple RBridges on a shared link, together with end
stations, only one RBridge is allowed to provide frame forwarding
services in VLAN-x to the end stations to avoid possible frame
duplication or loops in TRILL campus. The service RBridge is called
VLAN-x Appointed Forwarder (AF).
However, AF for any set of VLANs on a shared link may change over
from one RBridge to another, due to network dynamics such as failures
and configuration changes. RBridges rely on LSPs to propagate these
network dynamics. However, the propagation is time consuming and the
network may take a considerable long time to converge. Before the
network converges, remote RBridges may continue to forward traffic to
the previous AF and the traffic is dropped at the previous egress
RBridge, causing traffic disruption.
2.2. Multi-homing and Link Aggregation to TRILL Network
In order to improve the reliability of connection to TRILL network,
multi-homing technique may be employed by a legacy device which can
be a switch or end host. Take Figure 1 as an example, switch SW1
multi-homes to TRILL network by connecting to RB1 and RB2 with
respective links. Then the end station S1 can continue to get frame
forwarding service from TRILL network even if one of its up-links
(e.g., SW1-RB1) fails.
..........................................
: TRILL Network :
:+-----+ /\-/\-/\-/\-/\ :
+-----| RB1 |-----/ \ :
| :+-----+ / \ :
+---+ : | / Transit \ +-----+ :
S1 o--|SW1| +---+ < RBridges >---| RBx |---o Sx
+---+ | : \ Campus / +-----+ :
| | :+-----+ \ / :
+-----| RB2 |-----\ / :
| :+-----+ \/\-/\-/\-/\-/ :
| : | :
S2 o----+ :
..........................................
Figure 1 Multi-homing to TRILL Network
SW1 may treat the two links as a LAG (Link Aggregation Group) bundle,
so that the two links form active-active load sharing model instead
of previous active-standby model. That is to say, in Figure 1, two
Zhai, et al. Expires June 13, 2013 [Page 6]
Internet-Draft Pseudo-Nickname December 2012
RBridges (i.e., RB1 and RB2) provides frame forwarding service to S1
simultaneously in a VLAN. As stated previously, that simultaneous
frame forwarding may result in frame duplication, loops and the flip-
flopping of the ingress RBridge associated to the MAC of S1 in remote
RBridges' (e.g., RBx) forwarding tables. The flip-flopping in turn
causes packet disorder in reverse traffic and worsens the traffic
disruption. Therefore, the concept of Virtual RBridge, together with
its nickname, is introduced in the following section to fix these
issues.
3. Concept of Virtual RBridge and Pseudo-nickname
A Virtual RBridge (RBv) represents a group of different end station
service ports on different edge RBridges. After joining RBv, such an
RBridge port is called a member port of RBv, and such an RBridge
becomes a member RBridge of RBv. An RBv is identified by its virtual
nickname in TRILL campus, and this nickname is also referred to as
pseudo-nickname in this document.
After joining an RBv, a member RBridge will announce its connection
to RBv by including the information of that RBv, e.g., the pseudo-
nickname of RBv, in its self-originated LSP. From such LSPs, other
RBridges that are not members of the RBv believe those member
RBridges are connected to RBv.
When a native frame from an end station S1 is received from such a
port, the member RBridge encapsulates the frame with the RBv's
nickname, instead of its own nickname, as the ingress nickname. When
the destination RBridges receive and de-capsulate this frame, they
will learn that S1 is reachable through RBv.
NOTE: An RBridge port can join at most one RBv at any time, but
different ports on the same RBridge can join the same RBv or
different RBvs. Furthermore, for a member RBridge, it MUST move out
of an RBv and clear the RBv's information from its self-originated
LSPs when it loses all of its member ports of the RBv, due to port
failure, configuration, etc.
3.1. VLAN-x Appointed Forwarder for member interfaces in RBv
If member RBridges in RBv cannot see each others' Hellos on their
member ports (e.g., in the LAG scenario), then each RBridge becomes
Designated RBridge (DRB) for that port and appoints itself as AF for
all VLANs.
On the other hand, if they can see each others' Hellos on the member
ports in RBv (e.g., in the shared link scenario), the TRILL Hello
Zhai, et al. Expires June 13, 2013 [Page 7]
Internet-Draft Pseudo-Nickname December 2012
protocol in [RFC6325] is used for DRB election and for VLAN-x AFs
appointment on those ports. Then the DRB appoints different member
ports as AFs for different sets of VLANs.
By using the AF framework specified in [RFC6325], a unified framework
of RBv for both LAG and shared LAN edge connectivity is provided in
this document. It also allows
o Detection and protection against mis-configuration at the edge,
e.g., on the device SW1 the two interfaces are not configured as
LAG then RB1 and RB2 work in an unexpected active-standby mode
rather than expected active-active mode for S1 or
o Avoidance of loops in the event that S1 and S2 were connected by a
native Ethernet Link. In this event, RB1's Hellos originated on
link RB1-SW1 will be forwarded by S1 through the Ethernet Link to
S2 then received by RB2, and vice versa. Therefore, RB1 and RB2
work in an active-standby mode for S1 (or S2) in a VLAN to avoid
potential forwarding loops.
3.2. Announcing Pseudo-Nickname of RBv
Each member RBridge advertises the RBv's pseudo-nickname using the
nickname sub-TLV [rfc6326bis], along with its regular nickname(s), in
its LSPs. For a member RBridge, when its last member port is
disconnected to RBv, it MUST leave from RBv and clear RBv's pseudo-
nickname from its update LSPs.
RBv's pseudo-nickname is ignored when determining the distribution
tree root for the campus. The tree root priority of RBv's nickname
SHOULD be set to 0, and this nickname SHOULD NOT be listed in the s
nicknames by the RBridge holding the highest priority tree root
nickname.
4. Distribution Trees for Member RBridges in RBv
In TRILL, RBridges use distribution trees to forward multi-
destination frames. To guarantee member RBridges of an RBv group to
ingress (i.e., northbound forwarding) and egress (i.e., southbound
forwarding) multi-destination frames properly, and to provide
protection in case of member link failure as well, this document
proposes to allocate the trees among member RBridges in northbound
and southbound directions respectively. Section 4.1 describes the
allocation of trees for the ingressing of multi-destination frames,
while Section 4.2 covers the allocation of trees for the egressing of
multi-destination frames. Then for each member RBridge, frames
received from each direction can be forwarded based on the tree
Zhai, et al. Expires June 13, 2013 [Page 8]
Internet-Draft Pseudo-Nickname December 2012
allocation.
4.1. Trees for Native Frames Ingressing
In the TRILL header of the multi-destination frames, the ingress
nickname identifies the ingress RBridge and the egress nickname
specifies the root of the chosen distribution tree. After receiving
a multi-destination TRILL data frame, RBn performs Reverse Path
Forwarding (RPF) check on the multi-destination frame to avoid
temporary multicast loops during topology changes.
RPF specifies that a multi-destination TRILL data frame ingressed by
an RBridge and forwarded on a distribution tree can only be received
by RBn on an expected port. If the frame is received not from that
port, it MUST be dropped.
However, member RBridges use RBv's pseudo-nickname other than their
own nicknames as the ingress nickname when they forward northbound
frames regardless unicast or non-unicast frames. Therefore, when
these TRILL data frames arrive at RBn, they will be treated as frames
ingressed by the same RBridge, i.e., RBv. If they are multi-
destination frames and the same distribution tree is chosen by
different member RBridges to forward these frames, they may travel on
the tree and arrive at RBn on different ports. Then the RPF check is
violated, and some of the frames reaching the RBridge on unexpected
ports will be dropped by RBn.
[CMT] proposes to assign different distribution trees for each member
RBridge to fix the above RPF check issue, and makes use of the
Affinity sub-TLV defined in [rfc6326bis] to achieve this kind of
assignment.
This document supposes the approach proposed in [CMT] is supported by
member RBridges of RBv.
When a member RBridge joins in or leaves from a virtual RBridge
group, the assignment of distribution trees may change. That change
beyond the scope of this document.
4.2. Designated Forwarder for traffic received on Distribution trees
Methodology explained above addresses the association of distribution
trees to RBx on behalf of RBv for native traffic received from the
edge. However, remote RBridge RBn who is unaware of the RBv
association may choose to forward traffic along any of the available
distribution trees. Only one member RBridge RBx of the virtual
RBridge is allowed to de-capsulate the TRILL frames and forwards them
as native frames. In this document, this member RBridge is called
Zhai, et al. Expires June 13, 2013 [Page 9]
Internet-Draft Pseudo-Nickname December 2012
the Designated Forwarder.
It is important to note that RBv represents multiple, multi-homed
devices connected to the same RBv. Some of the devices may have
operational links to all member RBridges of RBv and some may have
operational links only to a subset of all member RBridges. The
objective of this proposal is to identify a member RBridge RBx per
distribution tree and end-device (LAG), that will de-capsulate and
forward traffic received from a specific distribution tree(s) to
specific end-device that multi-homes to the RBv.
We propose to represent each of the end devices *multi-homed* to RBv
by a unique identifier (LAG-ID) within the RBv group. Each of the
RBx advertises { RBv, LAG-ID } using ESADI framework. Please see
Section 7 for ESADI-TLV.
Each RBx, in turn, performs election of Designated Forwarder for each
LAG-ID per distribution tree "t".
------------------
/ \
| |
| TRILL Campus |
| |
\ /
---------------------
| | |
| | +--------+
| | |
+------+ +------+ +------+
| RB1 | | RB2 | | RB3 |
o|oooooo|oo|oooooo|oooooo|oooooo|o
o +------+ +------+ +------+ o
o | | | | | o
o | | +----+ | | o
o | Virtual|RBridge|(RBv)| | o
ooo|oooooooo|ooooooo|ooooo|ooo|ooo
| | +-----|-----+ |
+------+ | | +-------+ |
(| | |)<--LAG1 (| |)<--LAG2
+-------+ +-------+
| CE1 | | CE2 |
+-------+ +-------+
Figure 2 RBv with Multiple Multi-homed Devices
Assume RB(i) are the member RBridges of RBv that advertise
Zhai, et al. Expires June 13, 2013 [Page 10]
Internet-Draft Pseudo-Nickname December 2012
association of LAG-ID(j).
Suppose there are T(m) distribution trees in the network.
Step 1: Sort the RB(i) set in ascending order based on their
system-id.
Step 2: Sort distribution tree T(m) in ascending order based on their
tree-number.
Step 3: Allocate the sorted list in Step 2 in round-robin manner to
the sorted RBridge list in step 1.
Step 4: Repeat Step 1-3 for all of the LAG-ID associated with RBv.
Through the above steps, within a specific LAG, each RBx is assigned
with a set of distribution trees, and this RBx will become Designated
Forwarder for these trees. RBx MUST only forward traffic (received
on these trees) to member links on which it is the Designated
Forwarder.
For example, in Figure 2, CE1 multi-homes to RB1, RB2 and RB3, and
CE2 multi-homes to RB2 and RB3 in the same RBv; CE1 and CE2 are
represented by LAG1 and LAG2 respectively. Assume RB1 < RB2 < RB3
based on their system id, and there are five trees available in TRILL
campus, say T1 < T2 < T3 < T4 < T5 based on their tree-number. After
the election is performed in LAG1, T1 and T4 is allocated to RB1, T2
and T5 are allocated to RB2, and T3 is assigned to RB3. In other
words, RB1 is the Designated Forwarder for LAG1 on T1 and T4, RB2 is
the Designated Forwarder for LAG1 on T2 and T5 and RB3 is the
Designated Forwarder for LAG1 on T3. After the election is performed
for LAG2, T1, T3 and T5 are allocated to RB2, T2 and T4 are allocated
to RB3.
However, since only one member RBridge of RBv is elected as AF for e
set of VLANs on a shared link and responsible to egress multi-
destination TRILL data frames to this link, each member RBridge MUST
assign itself as the Designated Forwarder for all the distribution
trees to guarantee multi-destination frames on any tree will be
egressed onto this link by an member RBridge (please refer
Section 5.2.2 for more details).
5. Frame Processing
Zhai, et al. Expires June 13, 2013 [Page 11]
Internet-Draft Pseudo-Nickname December 2012
5.1. Native Frames Ingressing
When RB1 receives a native frame on one of its member ports of RBv,
it uses the pseudo-nickname of RBv, instead of its own nickname, as
the ingress nickname, if it is the appointed forwarder for the VLAN
of the frame on that port. If the frame is not received on a member
port, RB1 MUST NOT use RBv's pseudo-nickname as ingress nickname for
TRILL-encapsulation.
If the frame is ingressed as a multi-destination TRILL data frame,
RB1 can only choose one of its assigned distribution trees to forward
the TRILL-encapsulated frame [CMT]. Otherwise, the multi-destination
TRILL data frame will fail the RPF check on remote RBridges and
suffer unexpected packet loss.
Source MAC address learning is performed during the frame de-
capsulation as described in [RFC6325]. The learned MAC address
SHOULD be shared with other member RBridges within the same RBv group
(See Appendix A for more details for the information sharing).
5.2. TRILL Data Frames Egressing
This section describes egress processing of the received TRILL data
frames on a member RBridge (say RBn) in the virtual RBridge group.
Section 5.2.1 describes unicast TRILL data frames egress processing
and Section 5.2.2 specifies the multi-destination TRILL data frames
egressing.
5.2.1. Unicast TRILL Data Frames
When receiving a unicast TRILL data frame, RBn checks the egress
nickname in the TRILL header of the frame. If the egress nickname is
one of RBn's own nicknames, the frame is processed as defined in in
[RFC6325].
If the egress nickname is RBv's pseudo-nickname and RBn is a member
RBridge of RBv, RBn is responsible to learn the source MAC address.
If the learned { Inner.MacSA, Inner.VLAN ID, ingress nickname }
triplet is a new one or it updates a previously learned one, this
triplet SHOULD be shared with other member RBridges within the RBv
(See Appendix A for more details for the triplet sharing).
Then the frame is de-capsulated to its native form. The Inner.MacDA
and Inner.VLAN ID are looked up in RBn's local forwarding address
cache, and one of the three following cases occurs:
Zhai, et al. Expires June 13, 2013 [Page 12]
Internet-Draft Pseudo-Nickname December 2012
o If the destination end station identified by the Inner.MacDA and
Inner.VLAN ID is on a local link to RBv, this frame is egressed
onto that link *regardless of whether RBn is the Inner.VLAN AF on
this link*.
o Else if RBn can reach the destination through another member
RBridge RBk, it re-encapsulates the native frame into a unicast
TRILL data frame and sends it to RBk. RBn uses RBk's own
nickname, instead of RBv's pseudo-nickname as the egress nickname
for the re-encapsulation, and remains the ingress nickname
unchanged. If the hop count value of the frame is too small for
the frame to reach RBk safely, RBn SHOULD increase that value
properly in doing the re-encapsulation. [NOTE: When receiving
that re-encapsulated TRILL frame, as the egress nickname of the
frame is RBk's own nickname rather than the RBv's pseudo-nickname,
RBk will process it as Section 4.6.2.4 in [RFC6325]., and will not
re-forward it to another RBridge.]
o Else, RBn does not know how to reach the destination; it sends the
native frame out of all its member ports of RBv on which it is
appointed forwarders for the Inner.VLAN.
5.2.2. Multi-Destination TRILL Data Frames
If RBn is the AF for the Inner.VLAN, the source MAC address is
learned. If the learned { Inner.MacSA, Inner.VLAN ID, ingress
nickname } triplet is a new one or updates a previously learned one,
this triplet SHOULD be shared among the members RBridges within the
virtual RBridge group (See Appendix A for more details for the
triplet sharing).
Then a copy of the frame is de-capsulated into its native form.
Before the native frame is sent out of the ports on which RBn is
appointed forwarder for the Inner.VLAN, the following extra check is
performed for each member port of RBv:
o Frames MUST only be forwarded out on member ports of RBv where RBn
is the Designated Forwarder for the Tree Tn on which the frame was
received.
Zhai, et al. Expires June 13, 2013 [Page 13]
Internet-Draft Pseudo-Nickname December 2012
6. Member Link Failure in RBv
------------------
/ \
| |
| TRILL Campus |
| |
\ /
---------------------
| | |
| | +--------+
| | |
+------+ +------+ +------+
| RB1 | | RB2 | | RB3 |
o|oooooo|oo|oooooo|oooooo|oooooo|o
o +------+ +------+ +------+ o
o | | | | | o
o | | +----+ | | o
o | Virtual|RBridge|(RBv)| | o
ooo|oooooooo|ooooooo|ooooo|ooo|ooo
| \|/ | +-----|-----+ |
+- B --+ | | +-------+ |
/|\ (| | |)<--LAG1 (| |)<--LAG2
+-------+ +-------+
| CE1 | | CE2 |
+-------+ +-------+
B - Failed Link or Link bundle
Figure 3 Member Link Failure in LAG1
As shown in Figure 3, suppose the link RB1-CE1 fails. Both unicast
frames and multi-destination frames cannot be sent from RB1 to CE1.
Section 6.1 discusses the failure protection for unicast frames
receiving, and Section 6.2 describes the failure protection for
multi-destination frames.
6.1. Link Protection for Unicast Frame Egressing
When the link CE1-RB1 fails, RB1 loses the connection to the local
link to CE1. The MAC entry through the failed link to CE1 is removed
from RB1's local forwarding table immediately. Another MAC entry
through another member RBridge (say RB2) that has local link to CE1
is installed into RB1's forwarding table only if RB1 is still a
member RBridge of RBv. Then when TRILL data frames to CE1 is
delivered to RB1, it can be re-encapsulated (ingress nickname remains
unchanged and egress nickname is replaced by RB2's nickname) by RB1
Zhai, et al. Expires June 13, 2013 [Page 14]
Internet-Draft Pseudo-Nickname December 2012
and forwarded based on the above installed MAC entry. The member
RBridge who receives the redirected frames will egress them to CE1.
When the failure recovers, RB1 will be aware that it can reach CE1 by
observing CE1's native frames. Then RB1 installs the MAC entry for
link RB1-CE1, which restores the link CE1-RB1.
6.2. Link Protection for Multi-destination Frame Egressing
When RBx loses all of its links to a given edge device (represented
by a unique LAG-ID), it MUST advertise membership withdrawal. This
in turn triggers other RBridges to re-calculate the Designated
Forwarder allocation for the device.
For example, in Figure 3, let's assume RB1 is the Designated
Forwarder on T1 and T4 for CE1 (identified as LAG1), and is egressing
multi-destination traffic from T1 to CE1 before the failure. When
that failure occurs, RB1 loses its only local link to CE1 and
advertises to other RBridges its membership withdrawal for LAG1.
This triggers RB2 and RB3 to re-calculate the Designated Forwarder
allocation for LAG1.
After the re-calculation, trees T1, T3 and T5 are allocated to RB2,
and T2 and T4 to RB3. That is to say, RB2 becomes the Designated
Forwarder on the 3 trees and RB3 becomes the Designated Forwarder on
the 2 trees for LAG1. Then RB2 takes the place of RB1 to egress the
traffic to CE1.
Similarly, when the first attachment link between RBx and an edge
device becomes operational, RBx joins in the virtual RBridge group
and advertises membership adding. This in turn triggers other
RBridges as well as itself to re-calculate the Designated Forwarder
allocation for the device.
7. Extensions to ESADI
We propose to use sub-TLV within ESADI [ESADI] to advertise following
3 different scenarios.
o Membership Add
o Membership Withdrawal
o Membership Refresh
Zhai, et al. Expires June 13, 2013 [Page 15]
Internet-Draft Pseudo-Nickname December 2012
+-+-+-+-+-+-+-+-+
| Type= LM | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBv Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV |OC | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAG-ID (1) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAG-ID (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Edge Membership advertisement sub-TLV
o LM (1 byte): Defines the type of Edge Membership sub-TLV.
o Length (1 byte): Defines the length of this sub-TLV which should
be greater than 3.
o RBv Nickname (2 bytes): 2 byte nickname of the RBv assigned to the
edge group.
o RESV (6 bits): Transmitted as zero and ignored on receipt.
o OC (2 bits): Define the operation code.
* 00: Add (LAG-IDs in this sub-TLV are new and need to be
reconsidered for Designated Forwarder election).
* 01: Withdrawal (LAG-IDs in this sub-TLV do not have an active
links from the announcing RBridge for RBv and Designated
Forwarder election MUST be recalculated).
* 10: Refresh (LAG-IDs in this sub-TLV are being refreshed and no
state change from the perspective of the announcing RBridge).
* 11: Reserved and currently unused.
o LAG-ID (2 bytes): an unsigned positive integer that uniquely
identifies an end device multi-homed to the RBv.
When receiving such a sub-TLV, if the RBridge has no membership for
the listed LAGs in the RBv, it ignores the sub-TLV. If it has the
Zhai, et al. Expires June 13, 2013 [Page 16]
Internet-Draft Pseudo-Nickname December 2012
membership, receiving such a sub-TLV where the operation code is 00
or 01 will triggers it to re-calculate the Designated Forwarder on
each tree for the listed LAGs.
8. OAM Frames
Attention must be paid when generating the OAM frames. When an OAM
frame is generated with the ingress nickname of RBv, the originator
RBridge's nickname MUST be included in the OAM message to ensure the
response is returned to the originating member of the RBv group.
9. Configuration Consistency
It is important that VLAN membership of member ports of end switch
SW1 is consistent across all of the member ports in the point-point
scenario. Any inconsistencies in VLAN membership may result in
packet loss or non-shortest paths.
Take Figure 1 for example, suppose RB1 configures VLAN1 and VLAN2 for
the link SW1-RB1, while RB2 only configures VLAN1 for the SW1-RB2
link. Both RB1 and RB2 use the same ingress nickname RBv for all
frames originating from S1. Hence, a remote RBridge RBx will learn
that MAC addresses from S1 on VLAN2 are originating from RBv. As a
result, on the returning path, RBx may deliver VLAN2 traffic to RB2.
However, RB2 does not have VLAN2 configured on SW1-RB2 link and hence
the frame may be dropped or has to be redirected to RB1 if RB2 knows
RB1 can reach S1 in VLAN2.
10. IANA Considerations
TBD.
11. Security Considerations
TBD.
12. Acknowledgements
We would like to thank Mingjiang Chen for his contributions to this
document. Additionally, we would like to thank Erik Nordmark, Les
Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan
Pathang, and Jon Hudson for their good questions and comments.
Zhai, et al. Expires June 13, 2013 [Page 17]
Internet-Draft Pseudo-Nickname December 2012
13. Normative References
[CMT] Senevirathne, T., Pathangi, J., and J. Hudson,
"Coordinated Multicast Trees (CMT)for TRILL",
draft-ietf-trill-cmt-01.txt Work in Progress,
November 2012.
[ESADI] Zhai, H., Hu, F., Perlman, R., and D. Eastlake, "TRILL
(Transparent Interconnection of Lots of Links): The ESADI
(End Station Address Distribution Information) Protocol",
draft-ietf-trill-esadi-01.txt Work in Progress,
October 2012.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[rfc6326bis]
Eastlake 3rd, D., Banerjee, A., Ghanwani, A., and R.
Perlman, "Transparent Interconnection of Lots of Links
(TRILL) Use of IS-IS",
draft-ietf-isis-rfc6326bis-00.txt Work in Progress,
October 2012.
Appendix A. Rationale for MAC Sharing among Member RBridges
With the introduction of virtual RBridge, MAC flip-flopping problem
in LAN or LAG is resolved. However, in order to forward traffic
effectively, member RBridges should share some of their learned MAC
addresses with each other.
Zhai, et al. Expires June 13, 2013 [Page 18]
Internet-Draft Pseudo-Nickname December 2012
...........................................
ooooo TRILL Network :
o : +-----+ /\-/\-/\-/\-/\ :
+---o----| RB1 |----/ \ :
| o : +-----+ / \ :
+-----+o : o | / Transit \ +-----+ :
S1 o--| SW1 |o RBv o | < RBridges >---| RBx |---o Sx
+-----+o : o | \ Campus / +-----+ :
| o : +-----+ \ / :
+---o----| RB2 |----\ / :
o +-----+ \/\-/\-/\-/\-/ :
ooooo :
...........................................
Figure 5 RBv in LAG scenario
Take Figure 5 as an example, the VLAN-x native frames from S1 to Sx
will enter TRILL campus via one member RBridge of the RBv (say RB1).
RB1 learns the location of S1 in VLAN-x. However, RBx may deliver
the reverse traffic to RB2 if it thinks the shortest path to RBv is
through RB2. If RB2 has not learned the location of S1 in VLAN-x
from the MAC sharing, RB2 has to transmit the reverse traffic to S1
as unknown unicast.
Thus, the learned MAC addresses of attached end stations on one
member RBridge SHOULD be shared with the rest member RBridges in the
same RBv. With these information shared, when RB2 receives reverse
frames, it can determine how to forward them to S1. For example, it
can redirect them to RB1 if link RB2-S1 fails.
Since RBx always delivers the reverse traffic to RBv via RB2, RB2
egresses the traffic and learns the location of Sx. But RB1 will not
know where Sx is, if RB2 does not share this information with RB1.
As a result, RB1 has to treat the traffic from S1 to Sx as traffic
with unknown destination and flood it in TRILL, which adds additional
forwarding burden on TRILL network.
Therefore, in addition to local attached end station MAC addresses,
the learned remote MAC addresses should also be shared among all
member RBridges of an RBv. With such information shared, RB1 can
treat the traffic to Sx as known destination traffic and unicast it
to RBx.
The design for above MAC sharing is currently beyond the scope of
this document.
Zhai, et al. Expires June 13, 2013 [Page 19]
Internet-Draft Pseudo-Nickname December 2012
Authors' Addresses
Hongjun Zhai
ZTE
68 Zijinghua Road, Yuhuatai District
Nanjing, Jiangsu 210012
China
Phone: +86 25 52877345
Email: zhai.hongjun@zte.com.cn
Tissa Senevirathne
Cisco Systems
375 East Tasman Drive
San Jose, CA 95134
USA
Phone: +1-408-853-2291
Email: tsenevir@cisco.com
Radia Perlman
Intel Labs
2200 Mission College Blvd
Santa Clara, CA 95054-1549
USA
Phone: +1-408-765-8080
Email: Radia@alum.mit.edu
Donald Eastlake 3rd
Huawei
155 Beaver Street
Milford, MA 01757
USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Zhai, et al. Expires June 13, 2013 [Page 20]
Internet-Draft Pseudo-Nickname December 2012
Mingui Zhang
Huawei
Huawei Building, No.156 Beiqing Rd.
Beijing, Beijing 100095
China
Email: zhangmingui@huawei.com
Fangwei Hu
ZTE
889 Bibo Road, Pudong District
Shanghai, Shanghai 201203
China
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Zhai, et al. Expires June 13, 2013 [Page 21]