rfc9183.original   rfc9183.txt 
INTERNET-DRAFT M. Zhang Internet Engineering Task Force (IETF) M. Zhang
Intended Status: Proposed Standard Huawei Request for Comments: 9183 Independent
D. Eastlake Category: Standards Track D. Eastlake 3rd
Futurewei ISSN: 2070-1721 Futurewei
R. Perlman R. Perlman
EMC EMC
M. Cullen M. Cullen
Painless Security Painless Security
H. Zhai H. Zhai
JIT JIT
Expires: May 11, 2022 November 12, 2021 February 2022
Transparent Interconnection of Lots of Links (TRILL) Single Nickname for an Area Border RBridge in Multilevel Transparent
Single Area Border RBridge Nickname for Multilevel Interconnection of Lots of Links (TRILL)
draft-ietf-trill-multilevel-single-nickname-17.txt
Abstract Abstract
A major issue in multilevel TRILL is how to manage RBridge nicknames. A major issue in multilevel TRILL is how to manage RBridge nicknames.
In this document, area border RBridges use a single nickname in both In this document, area border RBridges use a single nickname in both
Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames Level 1 and Level 2. RBridges in Level 2 must obtain unique
but RBridges in different Level 1 areas may have the same nicknames. nicknames but RBridges in different Level 1 areas may have the same
nicknames.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the authors or the TRILL Working Group mailing list
trill@ietf.org>.
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
https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
https://www.ietf.org/shadow.html.
Table of Contents
1. Introduction............................................3
2. Acronyms and Terminology................................4
3. Nickname Handling on Border RBridges....................5
3.1. Actions on Unicast Packets............................5
3.2. Actions on Multi-Destination Packets..................6
4. Per-flow Load Balancing.................................9 This document is a product of the Internet Engineering Task Force
4.1. L2 to L1 Ingress Nickname Replacement................9 (IETF). It represents the consensus of the IETF community. It has
4.2. L1 to L2 Egress Nickname Replacement..................9 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 7841.
5. Protocol Extensions for Discovery......................10 Information about the current status of this document, any errata,
5.1. Discovery of Border RBridges in L1...................10 and how to provide feedback on it may be obtained at
5.2. Discovery of Border RBridge Sets in L2...............10 https://www.rfc-editor.org/info/rfc9183.
6. One Border RBridge Connects Multiple Areas.............12 Copyright Notice
7. E-L1FS/E-L2FS Backwards Compatibility..................13
8. Manageability Considerations...........................13
9. Security Considerations................................15 Copyright (c) 2022 IETF Trust and the persons identified as the
10. IANA Considerations...................................15 document authors. All rights reserved.
11. References............................................16 This document is subject to BCP 78 and the IETF Trust's Legal
11.1. Normative References................................16 Provisions Relating to IETF Documents
11.2. Informative References..............................17 (https://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 Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Appendix A. Level Transition Clarification................18 Table of Contents
Authors' Addresses........................................19 1. Introduction
2. Acronyms and Terminology
3. Nickname Handling on Border RBridges
3.1. Actions on Unicast Packets
3.2. Actions on Multi-destination Packets
4. Per-Flow Load Balancing
4.1. L2-to-L1 Ingress Nickname Replacement
4.2. L1-to-L2 Egress Nickname Replacement
5. Protocol Extensions for Discovery
5.1. Discovery of Border RBridges in L1
5.2. Discovery of Border RBridge Sets in L2
6. One Border RBridge Connects Multiple Areas
7. E-L1FS/E-L2FS Backwards Compatibility
8. Manageability Considerations
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Level Transition Clarification
Authors' Addresses
1. Introduction 1. Introduction
TRILL (Transparent Interconnection of Lots of Links [RFC6325] TRILL (Transparent Interconnection of Lots of Links) [RFC6325]
[RFC7780]) multilevel techniques are designed to improve TRILL [RFC7780] multilevel techniques are designed to improve TRILL
scalability issues. scalability issues.
[RFC8243] (Alternatives for Multilevel Transparent Interconnection of "Alternatives for Multilevel Transparent Interconnection of Lots of
Lots of Links (TRILL)) is an educational document to explain Links (TRILL)" [RFC8243] is an educational document to explain
multilevel TRILL and list possible concerns. It does not specify a multilevel TRILL and list possible concerns. It does not specify a
protocol. As described in [RFC8243], there have been two proposed protocol. As described in [RFC8243], there have been two proposed
approaches. One approach, which is referred to as the "unique approaches. One approach, which is referred to as the "unique
nickname" approach, gives unique nicknames to all the TRILL switches nickname" approach, gives unique nicknames to all the TRILL switches
in the multilevel campus, either by having the Level 1/Level 2 border in the multilevel campus either by having the Level 1/Level 2 border
TRILL switches advertise which nicknames are not available for TRILL switches advertise which nicknames are not available for
assignment in the area, or by partitioning the 16-bit nickname into assignment in the area or by partitioning the 16-bit nickname into an
an "area" field and a "nickname inside the area" field. [RFC8397] is "area" field and a "nickname inside the area" field. [RFC8397] is
the standards track document specifying a "unique nickname" flavor of the Standards Track document specifying a "unique nickname" flavor of
TRILL multilevel. The other approach, which is referred to in TRILL multilevel. The other approach, which is referred to in
[RFC8243] as the "aggregated nickname" approach, involves assigning [RFC8243] as the "aggregated nickname" approach, involves assigning
nicknames to the areas, and allowing nicknames to be reused inside nicknames to the areas, and allowing nicknames to be reused inside
different areas, by having the border TRILL switches rewrite the different areas, by having the border TRILL switches rewrite the
nickname fields when entering or leaving an area. [RFC8243] makes the nickname fields when entering or leaving an area. [RFC8243] makes
case that, while unique nickname multilevel solutions are simpler, the case that, while unique nickname multilevel solutions are
aggregated nickname solutions scale better. simpler, aggregated nickname solutions scale better.
The approach specified in this standards track document is somewhat The approach specified in this Standards Track document is somewhat
similar to the "aggregated nickname" approach in [RFC8243] but with a similar to the "aggregated nickname" approach in [RFC8243] but with a
very important difference. In this document, the nickname of an area very important difference. In this document, the nickname of an area
border RBridge is used in both Level 1 (L1) and Level 2 (L2). No border RBridge is used in both Level 1 (L1) and Level 2 (L2). No
additional nicknames are assigned to represent L1 areas as such. additional nicknames are assigned to represent L1 areas as such.
Instead, multiple border RBridges are allowed and each L1 area is Instead, multiple border RBridges are allowed and each L1 area is
denoted by the set of all nicknames of those border RBridges of the denoted by the set of all nicknames of those border RBridges of the
area. For this approach, nicknames in the L2 area MUST be unique but area. For this approach, nicknames in the L2 area MUST be unique but
nicknames inside an L1 area can be reused in other L1 areas that also nicknames inside an L1 area can be reused in other L1 areas that also
use this approach. The use of the approach specified in this document use this approach. The use of the approach specified in this
in one L1 area does not prohibit the use of other approaches in other document in one L1 area does not prohibit the use of other approaches
L1 areas in the same TRILL campus, for example the use of the unique in other L1 areas in the same TRILL campus, for example the use of
nickname approach specified in [RFC8397]. The TRILL packet format is the unique nickname approach specified in [RFC8397]. The TRILL
unchanged by this document, but data plane processing is changed at packet format is unchanged by this document, but data plane
Border RBridges and efficient high volume data flow at Border processing is changed at Border RBridges and efficient high volume
RBridges might require forwarding hardware change. data flow at Border RBridges might require forwarding hardware
change.
2. Acronyms and Terminology 2. Acronyms and Terminology
Data Label: VLAN or FGL Fine-Grained Label (FGL). Area Border RBridge: A border RBridge between a Level 1 area and
Level 2.
DBRB: Designated Border RBridge. Data Label: VLAN or Fine-Grained Label (FGL).
IS-IS: Intermediate System to Intermediate System [IS-IS]. DBRB: Designated Border RBridge.
Level: Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 IS-IS: Intermediate System to Intermediate System [IS-IS].
for inter-area. Routing information is exchanged between Level 1
RBridges within the same Level 1 area, and Level 2 RBridges can only Level: Similar to IS-IS, TRILL has Level 1 for intra-area and
form relationships and exchange information with other Level 2 Level 2 for inter-area. Routing information is exchanged between
RBridges. Level 1 RBridges within the same Level 1 area, and Level 2
RBridges can only form relationships and exchange information with
other Level 2 RBridges.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Familiarity with [RFC6325] is assumed in this document. Familiarity with [RFC6325] is assumed in this document.
3. Nickname Handling on Border RBridges 3. Nickname Handling on Border RBridges
This section provides an illustrative example and description of the This section provides an illustrative example and description of the
border learning border RBridge nicknames. border learning border RBridge nicknames.
Area {2,20} level 2 Area {3,30} Area {2,20} Level 2 Area {3,30}
+-------------------+ +-----------------+ +--------------+ +-------------------+ +-----------------+ +--------------+
| | | | | | | | | | | |
| S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D |
| 27 | | 39 | | 44 | | 27 | | 39 | | 44 |
| ----RB20--- ----RB30--- | | ----RB20--- ----RB30--- |
+-------------------+ +-----------------+ +--------------+ +-------------------+ +-----------------+ +--------------+
Figure 1: An Example Topology for TRILL Multilevel Figure 1: An Example Topology for TRILL Multilevel
In Figure 1, RB2, RB20, RB3 and RB30 are area border TRILL switches In Figure 1, RB2, RB20, RB3, and RB30 are area border TRILL switches
(RBridges). Their nicknames are 2, 20, 3 and 30 respectively and are (RBridges). Their nicknames are 2, 20, 3, and 30, respectively, and
used as TRILL switch identifiers in their areas [RFC6325]. Area are used as TRILL switch identifiers in their areas [RFC6325]. Area
border RBridges use the set of border nicknames to denote the L1 area border RBridges use the set of border nicknames to denote the L1 area
that they are attached to. For example, RB2 and RB20 use nicknames that they are attached to. For example, RB2 and RB20 use nicknames
{2,20} to denote the L1 area on the left. {2,20} to denote the L1 area on the left.
A source S is attached to RB27 and a destination D is attached to A source S is attached to RB27 and a destination D is attached to
RB44. RB27 has a nickname, say 27, and RB44 has a nickname, say 44 RB44. RB27 has a nickname (say, 27), and RB44 has a nickname (say,
(and in fact, they could even have the same nickname, since the TRILL 44). (In fact, they could even have the same nickname, since the
switch nickname will not be visible outside these Level 1 areas). TRILL switch nickname will not be visible outside these Level 1
areas.)
3.1. Actions on Unicast Packets 3.1. Actions on Unicast Packets
Let's say that S transmits a frame to destination D and let's say Let's say that S transmits a frame to destination D and let's say
that D's location has been learned by the relevant TRILL switches that D's location has been learned by the relevant TRILL switches
already. These relevant switches have learned the following: already. These relevant switches have learned the following:
1) RB27 has learned that D is connected to nickname 3. 1) RB27 has learned that D is connected to nickname 3.
2) RB3 has learned that D is attached to nickname 44.
2) RB3 has learned that D is attached to nickname 44.
The following sequence of events will occur: The following sequence of events will occur:
- S transmits an Ethernet frame with source MAC = S and destination 1. S transmits an Ethernet frame with source MAC = S and destination
MAC = D. MAC = D.
- RB27 encapsulates with a TRILL header with ingress RBridge = 27, 2. RB27 encapsulates with a TRILL header with ingress RBridge = 27
and egress RBridge = 3 producing a TRILL Data packet. and egress RBridge = 3 producing a TRILL Data packet.
- RB2 and RB20 have announced in the Level 1 IS-IS area designated 3. RB2 and RB20 have announced in the Level 1 IS-IS area designated
{2,20}, that they are attached to the nicknames of all the border {2,20} that they are attached to the nicknames of all the border
RBridges in the Level 2 area including RB3 and RB30. Therefore, RBridges in the Level 2 area including RB3 and RB30. Therefore,
IS-IS routes the packet to RB2 (or RB20, if RB20 on the least-cost IS-IS routes the packet to RB2 (or RB20, if RB20 is on the least-
route from RB27 to RB3). cost route from RB27 to RB3).
- RB2, when transitioning the packet from Level 1 to Level 2, 4. RB2, when transitioning the packet from Level 1 to Level 2,
replaces the ingress TRILL switch nickname with its own nickname, replaces the ingress TRILL switch nickname with its own nickname,
replacing 27 with 2. Within Level 2, the ingress RBridge field in replacing 27 with 2. Within Level 2, the ingress RBridge field
the TRILL header will therefore be 2, and the egress RBridge field in the TRILL header will therefore be 2, and the egress RBridge
will be 3. (The egress nickname MAY be replaced with any area field will be 3. (The egress nickname MAY be replaced with any
nickname selected from {3,30} such as 30. See Section 4 for the area nickname selected from {3,30} such as 30. See Section 4 for
detail of the selection method. Here, suppose the egress nickname the detail of the selection method. Here, suppose the egress
remains 3.) Also, RB2 learns that S is attached to nickname 27 in nickname remains 3.) Also, RB2 learns that S is attached to
area {2,20} to accommodate return traffic. RB2 SHOULD synchronize nickname 27 in area {2,20} to accommodate return traffic. RB2
with RB20 using ESADI protocol [RFC7357] that MAC = S is attached SHOULD synchronize with RB20 using the End Station Address
to nickname 27. Distribution Information (ESADI) protocol [RFC7357] that MAC = S
is attached to nickname 27.
- The packet is forwarded through Level 2, to RB3, which has 5. The packet is forwarded through Level 2, to RB3, which has
advertised, in Level 2, its L2 nickname as 3. advertised, in Level 2, its L2 nickname as 3.
- RB3, when forwarding into area {3,30}, replaces the egress 6. RB3, when forwarding into area {3,30}, replaces the egress
nickname in the TRILL header with RB44's nickname (44) based on nickname in the TRILL header with RB44's nickname (44) based on
looking up D. (The ingress nickname MAY be replaced with any area looking up D. (The ingress nickname MAY be replaced with any
nickname selected from {2,20}. See Section 4 for the detail of the area nickname selected from {2,20}. See Section 4 for the detail
selection method. Here, suppose the ingress nickname remains 2.) of the selection method. Here, suppose the ingress nickname
So, within the destination area, the ingress nickname will be 2 remains 2.) So, within the destination area, the ingress
and the egress nickname will be 44. nickname will be 2 and the egress nickname will be 44.
- RB44, when decapsulating, learns that S is attached to nickname 2, 7. RB44, when decapsulating, learns that S is attached to nickname
which is one of the area nicknames of the ingress. 2, which is one of the area nicknames of the ingress.
3.2. Actions on Multi-Destination Packets 3.2. Actions on Multi-destination Packets
Distribution trees for flooding of multi-destination packets are Distribution trees for flooding of multi-destination packets are
calculated separately within each L1 area and in L2. When a multi- calculated separately within each L1 area and in L2. When a multi-
destination packet arrives at the border, it needs to be transitioned destination packet arrives at the border, it needs to be transitioned
either from L1 to L2, or from L2 to L1. All border RBridges are either from L1 to L2, or from L2 to L1. All border RBridges are
eligible for Level transition. However, for each multi-destination eligible for Level transition. However, for each multi-destination
packet, only one of them acts as the Designated Border RBridge (DBRB) packet, only one of them acts as the Designated Border RBridge (DBRB)
to do the transition while other non-DBRBs MUST drop the received to do the transition while other non-DBRBs MUST drop the received
copies. By default, the border RBridge with the smallest nickname, copies. By default, the border RBridge with the smallest nickname,
considered as an unsigned integer, is elected DBRB. All border considered as an unsigned integer, is elected DBRB. All border
RBridges of an area MUST agree on the mechanism used to determine the RBridges of an area MUST agree on the mechanism used to determine the
DBRB locally. The use of an alternative is possible, but out of the DBRB locally. The use of an alternative is possible, but out of the
scope of this document; one such mechanism is used in Section 4 for scope of this document; one such mechanism is used in Section 4 for
load balancing. load balancing.
As per [RFC6325], multi-destination packets can be classified into As per [RFC6325], multi-destination packets can be classified into
three types: unicast packet with unknown destination MAC address three types: unicast packets with unknown destination MAC addresses
(unknown-unicast packet), multicast packet and broadcast packet. Now (unknown-unicast packets), multicast packets, and broadcast packets.
suppose that D's location has not been learned by RB27 or the frame Now suppose that D's location has not been learned by RB27 or the
received by RB27 is recognized as broadcast or multicast. What will frame received by RB27 is recognized as broadcast or multicast. What
happen within a Level 1 area (as it would in TRILL today) is that will happen within a Level 1 area (as it would in TRILL today) is
RB27 will forward the packet as multi-destination, setting its M bit that RB27 will forward the packet as multi-destination, setting its M
to 1 and choosing an L1 tree, flooding the packet on the distribution bit to 1 and choosing an L1 tree, which would flood the packet on
tree, subject to possible pruning. that distribution tree (subject to potential pruning).
When the copies of the multi-destination packet arrive at area border When the copies of the multi-destination packet arrive at area border
RBridges, non-DBRBs MUST drop the packet while the DBRB, say RB2, RBridges, non-DBRBs MUST drop the packet while the DBRB (say, RB2)
needs to do the Level transition for the multi-destination packet. needs to do the Level transition for the multi-destination packet.
For an unknown-unicast packet, if the DBRB has learnt the destination For an unknown-unicast packet, if the DBRB has learned the
MAC address, it SHOULD convert the packet to unicast and set its M destination MAC address, it SHOULD convert the packet to unicast and
bit to 0. Otherwise, the multi-destination packet will continue to be set its M bit to 0. Otherwise, the multi-destination packet will
flooded as multicast packet on the distribution tree. The DBRB continue to be flooded as a multicast packet on the distribution
chooses the new distribution tree by replacing the egress nickname tree. The DBRB chooses the new distribution tree by replacing the
with the new tree root RBridge nickname from the area the packet is egress nickname with the new tree root RBridge nickname from the area
entering. The following sequence of events will occur: the packet is entering. The following sequence of events will occur:
- RB2, when transitioning the packet from Level 1 to Level 2, 1. RB2, when transitioning the packet from Level 1 to Level 2,
replaces the ingress TRILL switch nickname with its own nickname, replaces the ingress TRILL switch nickname with its own nickname,
replacing 27 with 2. RB2 also MUST replace the egress RBridge replacing 27 with 2. RB2 also MUST replace the egress RBridge
nickname with an L2 tree root RBridge nickname (say 39). In order nickname with an L2 tree root RBridge nickname (say, 39). In
to accommodate return traffic, RB2 records that S is attached to order to accommodate return traffic, RB2 records that S is
nickname 27 and SHOULD use the ESADI protocol [RFC7357] to attached to nickname 27 and SHOULD use the ESADI protocol
synchronize this attachment information with other border RBridges [RFC7357] to synchronize this attachment information with other
(say RB20) in the area. border RBridges (say, RB20) in the area.
- RB20, will receive the packet flooded on the L2 tree by RB2. It is 2. RB20 will receive the packet flooded on the L2 tree by RB2. It
important that RB20 does not transition this packet back to L1 as is important that RB20 does not transition this packet back to L1
it does for a multicast packet normally received from another as it does for a multicast packet normally received from another
remote L1 area. RB20 should examine the ingress nickname of this remote L1 area. RB20 should examine the ingress nickname of this
packet. If this nickname is found to be a border RBridge nickname packet. If this nickname is found to be a border RBridge
of the area {2,20}, RB2 must not forward the packet into this nickname of the area {2,20}, RB2 must not forward the packet into
area. this area.
- The multidestination packet is flooded on the Level 2 tree to 3. The multi-destination packet is flooded on the Level 2 tree to
reach all border routers for all L1 areas including both RB3 and reach all border routers for all L1 areas including both RB3 and
RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will
drop the packet. drop the packet.
- RB3, when forwarding into area {3,30}, replaces the egress 4. RB3, when forwarding into area {3,30}, replaces the egress
nickname in the TRILL header with the root RBridge nickname of a nickname in the TRILL header with the root RBridge nickname of a
distribution tree of L1 area {3,30} say 30. (Here, the ingress distribution tree of L1 area {3,30} -- say, 30. (Here, the
nickname MAY be replaced with a different area nickname selected ingress nickname MAY be replaced with a different area nickname
from {2,20}, the set of border RBridges to the ingress area, as selected from {2,20}, the set of border RBridges to the ingress
specified in Section 4.) Now suppose that RB27 has learned the area, as specified in Section 4.) Now suppose that RB27 has
location of D (attached to nickname 3), but RB3 does not know learned the location of D (attached to nickname 3), but RB3 does
where D is because this information has fallen out of cache or RB3 not know where D is because this information has fallen out of
has re-started or some other reason. In that case, RB3 must turn cache or RB3 has restarted or some other reason. In that case,
the packet into a multi-destination packet and floods it on a RB3 must turn the packet into a multi-destination packet and then
distribution tree in the L1 area {3,30}. floods it on a distribution tree in the L1 area {3,30}.
- RB30, will receive the packet flooded on the L1 tree by RB3. It is 5. RB30 will receive the packet flooded on the L1 tree by RB3. It
important that RB30 does not transition this packet back to L2. is important that RB30 does not transition this packet back to
RB30 should also examine the ingress nickname of this packet. If L2. RB30 should also examine the ingress nickname of this
this nickname is found to be an L2 border RBridge nickname, RB30 packet. If this nickname is found to be an L2 Border RBridge
must not transition the packet back to L2. Nickname, RB30 must not transition the packet back to L2.
- The multicast listener RB44, when decapsulating the received 6. The multicast listener RB44, when decapsulating the received
packet, learns that S is attached to nickname 2, which is one of packet, learns that S is attached to nickname 2, which is one of
the area nicknames of the ingress. the area nicknames of the ingress.
See also Appendix A. See also Appendix A.
4. Per-flow Load Balancing 4. Per-Flow Load Balancing
Area border RBridges perform ingress/egress nickname replacement when Area border RBridges perform ingress/egress nickname replacement when
they transition TRILL data packets between Level 1 and Level 2. The they transition TRILL Data packets between Level 1 and Level 2. The
egress nickname will again be replaced when the packet transitions egress nickname will again be replaced when the packet transitions
from Level 2 to Level 1. This nickname replacement enables the per- from Level 2 to Level 1. This nickname replacement enables the per-
flow load balance which is specified in the following subsections. flow load balance, which is specified in the following subsections.
The mechanism specified in Setion 4.1 or that in 4.2 or both is The mechanism specified in Section 4.1 or that in Section 4.2 or both
necessary in general to load balance traffic across L2 paths. is necessary in general to load-balance traffic across L2 paths.
4.1. L2 to L1 Ingress Nickname Replacement 4.1. L2-to-L1 Ingress Nickname Replacement
When a TRILL data packet from other L1 areas arrives at an area When a TRILL Data packet from other L1 areas arrives at an area
border RBridge, this RBridge MAY select one area nickname of the border RBridge, this RBridge MAY select one area nickname of the
ingress area to replace the ingress nickname of the packet so that ingress area to replace the ingress nickname of the packet so that
the returning TRILL data packet can be forwarded to this selected the returning TRILL Data packet can be forwarded to this selected
nickname to help load balance return unicast traffic over multiple nickname to help load-balance return unicast traffic over multiple
paths. The selection is simply based on a pseudorandom algorithm as paths. The selection is simply based on a pseudorandom algorithm as
discussed in Section 5.3 of [RFC7357]. With the random ingress discussed in Section 5.3 of [RFC7357]. With the random ingress
nickname replacement, the border RBridge actually achieves a per-flow nickname replacement, the border RBridge actually achieves a per-flow
load balance for returning traffic. load balance for returning traffic.
All area border RBridges for an L1 area MUST agree on the same All area border RBridges for an L1 area MUST agree on the same
pseudorandom algorithm. The source MAC address, ingress area pseudorandom algorithm. The source MAC address, ingress area
nicknames, egress area nicknames and the Data Label of the received nicknames, egress area nicknames, and the Data Label of the received
TRILL data packet are candidate factors of the input of this TRILL Data packet are candidate factors of the input of this
pseudorandom algorithm. Note that the value of the destination MAC pseudorandom algorithm. Note that the value of the destination MAC
address SHOULD be excluded from the input of this pseudorandom address SHOULD be excluded from the input of this pseudorandom
algorithm, otherwise the egress RBridge could see one source MAC algorithm; otherwise, the egress RBridge could see one source MAC
address flip-flopping among multiple ingress RBridges. address flip-flopping among multiple ingress RBridges.
4.2. L1 to L2 Egress Nickname Replacement 4.2. L1-to-L2 Egress Nickname Replacement
When a unicast TRILL data packet originated from an L1 area arrives When a unicast TRILL Data packet originated from an L1 area arrives
at an area border RBridge of that L1 area, that RBridge MAY select at an area border RBridge of that L1 area, that RBridge MAY select
one area nickname of the egress area to replace the egress nickname one area nickname of the egress area to replace the egress nickname
of the packet. By default, it SHOULD choose the egress area border of the packet. By default, it SHOULD choose the egress area border
RBridge with the least cost route to reach or, if there are multiple RBridge with the least cost route to reach or, if there are multiple
equal cost egress area border RBridges, use the pseudorandom equal cost egress area border RBridges, use the pseudorandom
algorithm as defined in Section 5.3 of [RFC7357] to select one. The algorithm as defined in Section 5.3 of [RFC7357] to select one. The
use of that algorithm MAY be extended to selection among some stable use of that algorithm MAY be extended to selection among some stable
set of egress area border RBridges that include non-least-cost set of egress area border RBridges that include non-least-cost
alternatives if it is desired to obtain more load spreading at the alternatives if it is desired to obtain more load spreading at the
cost of sometimes using a non-least-cost Level 2 route to forward the cost of sometimes using a non-least-cost Level 2 route to forward the
TRILL data packet to the egress area. TRILL Data packet to the egress area.
5. Protocol Extensions for Discovery 5. Protocol Extensions for Discovery
The following topology change scenarios will trigger the discovery The following topology change scenarios will trigger the discovery
processes as defined in Sections 5.1 and 5.2: processes as defined in Sections 5.1 and 5.2:
- A new node comes up or recovers from a previous failure.
- A node goes down. * A new node comes up or recovers from a previous failure.
- A link or node fails and causes partition of an L1/L2 area.
- A link or node whose failure have caused partitioning of an L1/L2 * A node goes down.
* A link or node fails and causes partition of an L1/L2 area.
* A link or node whose failure has caused partitioning of an L1/L2
area is repaired. area is repaired.
5.1. Discovery of Border RBridges in L1 5.1. Discovery of Border RBridges in L1
The following Level 1 Border RBridge APPsub-TLV will be included in The following Level 1 Border RBridge APPsub-TLV will be included in
an E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the TRILL
TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an area GENINFO-TLV. Through listening for this APPsub-TLV, an area border
border RBridge discovers all other area border RBridges in this area. RBridge discovers all other area border RBridges in this area.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = L1-BORDER-RBRIDGE | (2 bytes) | Type = L1-BORDER-RBRIDGE | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes) | Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes) | Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Level 1 Border RBridge (TRILL APPsub-TLV type tbd1) Type: Level 1 Border RBridge (TRILL APPsub-TLV type 256)
o Length: 2 Length: 2
o Sender Nickname: The nickname the originating IS will use as the Sender Nickname: The nickname the originating IS will use as the L1
L1 Border RBridge nickname. This field is useful because the Border RBridge Nickname. This field is useful because the
originating IS might own multiple nicknames. originating IS might own multiple nicknames.
5.2. Discovery of Border RBridge Sets in L2 5.2. Discovery of Border RBridge Sets in L2
The following APPsub-TLV will be included in an E-L2FS FS-LSP The following APPsub-TLV will be included in an E-L2FS FS-LSP
fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV. fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV.
Through listening to this APPsub-TLV in L2, an area border RBridge Through listening to this APPsub-TLV in L2, an area border RBridge
discovers all groups of L1 border RBridges and each such group discovers all groups of L1 border RBridges and each such group
identifies an area. identifies an area.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = L1-BORDER-RB-GROUP | (2 bytes) | Type = L1-BORDER-RB-GROUP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes) | Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1 Border RBridge Nickname 1 | (2 bytes) | L1 Border RBridge Nickname 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1 Border RBridge Nickname k | (2 bytes) | L1 Border RBridge Nickname k | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type tbd2) Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type 257)
o Length: 2 * k. If length is not a multiple of 2, the APPsub-TLV is Length: 2 * k. If length is not a multiple of 2, the APPsub-TLV is
corrupt and MUST be ignored. corrupt and MUST be ignored.
o L1 Border RBridge Nickname: The nickname that an area border L1 Border RBridge Nickname: The nickname that an area border RBridge
RBridge uses as the L1 Border RBridge nickname. The L1-BORDER-RB- uses as the L1 Border RBridge Nickname. The L1-BORDER-RB-GROUP
GROUP TLV generated by an area border RBridge MUST include all L1 TLV generated by an area border RBridge MUST include all L1 Border
Border RBridge nicknames of the area. It's RECOMMENDED that these RBridge Nicknames of the area. It's RECOMMENDED that these k
k nicknames are ordered in ascending order according to the nicknames are ordered in ascending order according to the 2-octet
2-octet nickname considered as an unsigned integer. nickname considered as an unsigned integer.
When an L1 area is partitioned [RFC8243], border RBridges will re- When an L1 area is partitioned [RFC8243], border RBridges will re-
discover each other in both L1 and L2 through exchanging LSPs. In L2, discover each other in both L1 and L2 through exchanging LSPs. In
the set of border RBridge nicknames for this splitting area will L2, the set of border RBridge nicknames for this splitting area will
change. Border RBridges that detect such a change MUST flush the change. Border RBridges that detect such a change MUST flush the
reachability information associated to any RBridge nickname from this reachability information associated to any RBridge nickname from this
changing set. changing set.
6. One Border RBridge Connects Multiple Areas 6. One Border RBridge Connects Multiple Areas
It's possible that one border RBridge (say RB1) connects multiple L1 It's possible that one border RBridge (say, RB1) connects multiple L1
areas. RB1 SHOULD use a single area nickname for itself for all these areas. RB1 SHOULD use a single area nickname for itself for all
areas to minimize nickname consumption and the number of nicknames these areas to minimize nickname consumption and the number of
being advertised in L2; however, such a border RBridge might have to nicknames being advertised in L2; however, such a border RBridge
hold multiple nicknames, for example it might the root of multiple L1 might have to hold multiple nicknames -- for example, it might be the
or multiple L2 distribution trees. root of multiple L1 or multiple L2 distribution trees.
Nicknames used within one of these L1 areas can be reused within Nicknames used within one of these L1 areas can be reused within
other areas. It's important that packets destined to those duplicated other areas. It's important that packets destined to those
nicknames are sent to the right area. Since these areas are connected duplicated nicknames are sent to the right area. Since these areas
to form a layer 2 network, duplicated {MAC, Data Label} across these are connected to form a layer 2 network, duplicated {MAC, Data Label}
areas SHOULD NOT occur (see Section 4.2.6 of [RFC6325] for tie across these areas SHOULD NOT occur (see Section 4.2.6 of [RFC6325]
breaking rules). Now suppose a TRILL data packet arrives at the area for tie breaking rules). Now suppose a TRILL Data packet arrives at
border nickname of RB1. For a unicast packet, RB1 can look up the the area border nickname of RB1. For a unicast packet, RB1 can look
{MAC, Data Label} entry in its MAC table to identify the right up the {MAC, Data Label} entry in its MAC table to identify the right
destination area (i.e., the outgoing interface) and the egress destination area (i.e., the outgoing interface) and the egress
RBridge's nickname. For a multicast packet for each attached L1 RBridge's nickname. For a multicast packet for each attached L1
area: either RB1 is not the DBRB and RB1 will not transition the area: either RB1 is not the DBRB and RB1 will not transition the
packet or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows the packet, or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows the
following rules: following rules:
- if this packet originated from an area out of the connected areas, * If this packet originated from an area out of the connected areas,
RB1 replicates this packet and floods it on the proper Level 1 RB1 replicates this packet and floods it on the proper Level 1
trees of all the areas in which it acts as the DBRB. trees of all the areas in which it acts as the DBRB.
- if the packet originated from one of the connected areas, RB1 * If the packet originated from one of the connected areas, RB1
replicates the packet it receives from the Level 1 tree and floods replicates the packet it receives from the Level 1 tree and floods
it on other proper Level 1 trees of all the areas in which it acts it on other proper Level 1 trees of all the areas in which it acts
as the DBRB except the originating area (i.e., the area connected as the DBRB except the originating area (i.e., the area connected
to the incoming interface). RB1 might also receive the replication to the incoming interface). RB1 might also receive the
of the packet from the Level 2 tree. This replication MUST be replication of the packet from the Level 2 tree. This replication
dropped by RB1. It recognizes such packets by their ingress MUST be dropped by RB1. It recognizes such packets by their
nickname being the nickname of one of the border RBridges of an L1 ingress nickname being the nickname of one of the border RBridges
area for which the receiving border RBridge is DBRB. of an L1 area for which the receiving border RBridge is DBRB.
7. E-L1FS/E-L2FS Backwards Compatibility 7. E-L1FS/E-L2FS Backwards Compatibility
All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780]. The All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780]. The
Extended TLVs defined in Section 5 are to be used in Extended Level Extended TLVs defined in Section 5 are to be used in Extended Level
1/2 Flooding Scope (E-L1FS/E-L2FS) PDUs. Area border RBridges MUST 1/2 Flooding Scope (E-L1FS/E-L2FS) Protocol Data Units (PDUs). Area
support both E-L1FS and E-L2FS. RBridges that do not support both border RBridges MUST support both E-L1FS and E-L2FS. RBridges that
E-L1FS or E-L2FS cannot serve as area border RBridges but they can do not support both E-L1FS or E-L2FS cannot serve as area border
appear in an L1 area acting as non-area-border RBridges. RBridges but they can appear in an L1 area acting as non-area-border
RBridges.
8. Manageability Considerations 8. Manageability Considerations
If an L1 Border RBridge Nickname is configured at an RBridge and that If an L1 Border RBridge Nickname is configured at an RBridge and that
RBridge has both L1 and L2 adjacencies, the multilevel feature as RBridge has both L1 and L2 adjacencies, the multilevel feature as
specified in this document is turned on for that RBridge and it specified in this document is turned on for that RBridge and normally
normally uses an L2 nickname in both L1 and L2 although, as provided uses an L2 nickname in both L1 and L2 although, as provided below,
below, such an RBridge may have to fall back to multilevel unique such an RBridge may have to fall back to multilevel unique nickname
nickname behavior [RFC8397] in which case it uses this L1 nickname. behavior [RFC8397], in which case it uses this L1 nickname. In
In contrast, unique nickname multilevel as specified in [RFC8397] is contrast, unique nickname multilevel as specified in [RFC8397] is
enabled by the presence of L1 and L2 adjacencies without an L1 Border enabled by the presence of L1 and L2 adjacencies without an L1 Border
RBridge Nickname being configured. RBridges supporting only unique RBridge Nickname being configured. RBridges supporting only unique
nickname multilevel do not support the configuration of an L2 Border nickname multilevel do not support the configuration of an L2 Border
RBridge Nickname. RBridges supporting only the single level TRILL RBridge Nickname. RBridges supporting only the single-level TRILL
base protocol specified in [RFC6325] do not support L2 adjacencies. base protocol specified in [RFC6325] do not support L2 adjacencies.
RBridges that support and are configured to use single nickname RBridges that support and are configured to use single nickname
multilevel as specified in this document MUST support unique nickname multilevel as specified in this document MUST support unique nickname
multilevel ([RFC8397]). If there are multiple border RBridges multilevel [RFC8397]. If there are multiple border RBridges between
between an L1 area and L2 and one or more of them only support or are an L1 area and L2, and one or more of them only support or are only
only configured for unique nickname multilevel ([RFC8397]), any of configured for unique nickname multilevel [RFC8397], any of these
these border RBridges that are configured to use single nickname border RBridges that are configured to use single nickname multilevel
multilevel MUST fall back to behaving as a unique nickname border MUST fall back to behaving as a unique nickname border RBridge for
RBridge for that L1 area. Because overlapping sets of RBridges may be that L1 area. Because overlapping sets of RBridges may be the border
the border RBridges for different L1 areas, an RBridge supporting RBridges for different L1 areas, an RBridge supporting single
single nickname MUST be able to simultaneously support single nickname MUST be able to simultaneously support single nickname for
nickname for some of its L1 areas and unique nickname for others. For some of its L1 areas and unique nickname for others. For example,
example, RB1 and RB2 might be border RBridges for L1 area A1 using RB1 and RB2 might be border RBridges for L1 area A1 using single
single nickname while RB2 and RB3 are border RBridges for area A2. If nickname while RB2 and RB3 are border RBridges for area A2. If RB3
RB3 only supports unique nicknames then RB2 must fall back to unique only supports unique nicknames, then RB2 must fall back to unique
nickname for area A2 but continue to support single nickname for area nickname for area A2 but continue to support single nickname for area
A1. Operators SHOULD be notified when this fall back occurs. The A1. Operators SHOULD be notified when this fallback occurs. The
presence of border RBridges using unique nickname multilevel can be presence of border RBridges using unique nickname multilevel can be
detected because they advertise in L1 the blocks of nicknames detected because they advertise in L1 the blocks of nicknames
available within that L1 area. available within that L1 area.
In both the unique nickname approach specified in [RFC8397] and the In both the unique nickname approach specified in [RFC8397] and the
single nickname aggregated approach specified in this document, an single nickname aggregated approach specified in this document, an
RBridge that has L1 and L2 adjacencies uses the same nickname in L1 RBridge that has L1 and L2 adjacencies uses the same nickname in L1
and L2. If an RBridge is configured with an L1 Border RBridge and L2. If an RBridge is configured with an L1 Border RBridge
Nickname for any a Level 1 area, it uses this nickname across the Nickname for any a Level 1 area, it uses this nickname across the
Level 2 area. This L1 Border RBridge Nickname cannot be used in any Level 2 area. This L1 Border RBridge Nickname cannot be used in any
other Level 1 area except other Level 1 areas for which the same other Level 1 area except other Level 1 areas for which the same
RBridge is a border RBridge with this L1 Border RBridge Nickname RBridge is a border RBridge with this L1 Border RBridge Nickname
configured. configured.
In addition to the manageability considerations specified above, the In addition to the manageability considerations specified above, the
manageability specifications in [RFC6325] still apply. manageability specifications in [RFC6325] still apply.
Border RBridges replace ingress and/or egress nickname when a TRILL Border RBridges replace ingress and/or egress nickname when a TRILL
data packet traverses TRILL L2 area. A TRILL OAM message will be Data packet traverses a TRILL L2 area. A TRILL Operations,
forwarded through the multilevel single nickname TRILL campus using a Administration, and Maintenance (OAM) message will be forwarded
MAC address belonging to the destination RBridge [RFC7455]. through the multilevel single nickname TRILL campus using a MAC
address belonging to the destination RBridge [RFC7455].
9. Security Considerations 9. Security Considerations
For general TRILL Security Considerations, see [RFC6325]. For general TRILL Security Considerations, see [RFC6325].
The newly defined TRILL APPsub-TLVs in Section 5 are transported in The newly defined TRILL APPsub-TLVs in Section 5 are transported in
IS-IS PDUs whose authenticity can be enforced using regular IS-IS IS-IS PDUs whose authenticity can be enforced using regular IS-IS
security mechanism [IS-IS] [RFC5310]. Malicious devices may also fake security mechanism [IS-IS] [RFC5310]. Malicious devices may also
the APPsub-TLVs to attract TRILL data packets, interfere with fake the APPsub-TLVs to attract TRILL Data packets, interfere with
multilevel TRILL operation, induce excessive state in TRILL switches multilevel TRILL operation, induce excessive state in TRILL switches
(or in any bridges that may be part of the TRILL campus), etc. For (or in any bridges that may be part of the TRILL campus), etc. For
this reason, RBridges SHOULD be configured to use the IS-IS this reason, RBridges SHOULD be configured to use the IS-IS
Authentication TLV (10) in their IS-IS PDUs so that IS-IS security Authentication TLV (10) in their IS-IS PDUs so that IS-IS security
[RFC5310] can be used to authenticate those PDUs and discard them if [RFC5310] can be used to authenticate those PDUs and discard them if
they are forged. they are forged.
Using a variation of aggregated nicknames, and the resulting possible Using a variation of aggregated nicknames, and the resulting possible
duplication of nicknames between areas, increases the possibility of duplication of nicknames between areas, increases the possibility of
a TRILL Data packet being delivered to the wrong egress RBridge if a TRILL Data packet being delivered to the wrong egress RBridge if
areas are unexpectedly merged as compared with a scheme were all areas are unexpectedly merged as compared with a scheme where all
nicknames in the TRILL campus are, except as a transient condition, nicknames in the TRILL campus are, except as a transient condition,
unique such as the scheme in [RFC8397]. However, in many cases the unique such as the scheme in [RFC8397]. However, in many cases, the
data would be discarded at that egress RBridge because it would not data would be discarded at that egress RBridge because it would not
match a known end station data label/MAC address. match a known end station Data Label / MAC address.
10. IANA Considerations 10. IANA Considerations
IANA is requested to allocate two new types under the TRILL GENINFO IANA has allocated two new types under the TRILL GENINFO TLV
TLV [RFC7357] from the range allocated by standards action for the [RFC7357] from the range allocated by Standards Action [RFC8126] for
TRILL APPsub-TLVs defined in Section 5. The following entries are the TRILL APPsub-TLVs defined in Section 5. The following entries
added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application have been added to the "TRILL APPsub-TLV Types under IS-IS TLV 251
Identifier 1" Registry on the TRILL Parameters IANA web page. Application Identifier 1" registry on the TRILL Parameters IANA web
page.
Type Name Reference +======+====================+===========+
--------- ---- --------- | Type | Name | Reference |
tbd1[256] L1-BORDER-RBRIDGE [This document] +======+====================+===========+
tbd2[257] L1-BORDER-RB-GROUP [This document] | 256 | L1-BORDER-RBRIDGE | RFC 9183 |
+------+--------------------+-----------+
| 257 | L1-BORDER-RB-GROUP | RFC 9183 |
+------+--------------------+-----------+
11. References Table 1
11.1. Normative References 11. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 11.1. Normative References
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Ghanwani, "Routing Bridges (RBridges): Base Protocol Requirement Levels", BCP 14, RFC 2119,
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc6325>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Scope Link State PDUs (LSPs)", RFC 7356, DOI Ghanwani, "Routing Bridges (RBridges): Base Protocol
10.17487/RFC7356, September 2014, <https://www.rfc- Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
editor.org/info/rfc7356>. <https://www.rfc-editor.org/info/rfc6325>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Stokes, "Transparent Interconnection of Lots of Links Scope Link State PDUs (LSPs)", RFC 7356,
(TRILL): End Station Address Distribution Information DOI 10.17487/RFC7356, September 2014,
(ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, <https://www.rfc-editor.org/info/rfc7356>.
September 2014, <https://www.rfc-editor.org/info/rfc7357>.
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
3rd, D., Aldrin, S., and Y. Li, "Transparent Stokes, "Transparent Interconnection of Lots of Links
Interconnection of Lots of Links (TRILL): Fault (TRILL): End Station Address Distribution Information
Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
<https://www.rfc-editor.org/info/rfc7455>. September 2014, <https://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake
Ghanwani, A., and S. Gupta, "Transparent Interconnection of 3rd, D., Aldrin, S., and Y. Li, "Transparent
Lots of Links (TRILL): Clarifications, Corrections, and Interconnection of Lots of Links (TRILL): Fault
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, Management", RFC 7455, DOI 10.17487/RFC7455, March 2015,
<https://www.rfc-editor.org/info/rfc7780>. <https://www.rfc-editor.org/info/rfc7455>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May Ghanwani, A., and S. Gupta, "Transparent Interconnection
2017, <https://www.rfc-editor.org/info/rfc8174>. of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<https://www.rfc-editor.org/info/rfc7780>.
[RFC8397] Zhang, M., Eastlake 3rd, D., Perlman, R., Zhai, H., and D. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Liu, "Transparent Interconnection of Lots of Links (TRILL) Writing an IANA Considerations Section in RFCs", BCP 26,
Multilevel Using Unique Nicknames", RFC 8397, DOI RFC 8126, DOI 10.17487/RFC8126, June 2017,
10.17487/RFC8397, May 2018, <https://www.rfc- <https://www.rfc-editor.org/info/rfc8126>.
editor.org/info/rfc8397>.
11.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[IS-IS] International Organization for Standardization, ISO/IEC [RFC8397] Zhang, M., Eastlake 3rd, D., Perlman, R., Zhai, H., and D.
10589:2002, "Information technology -- Telecommunications Liu, "Transparent Interconnection of Lots of Links (TRILL)
and information exchange between systems -- Intermediate Multilevel Using Unique Nicknames", RFC 8397,
System to Intermediate System intra-domain routeing DOI 10.17487/RFC8397, May 2018,
information exchange protocol for use in conjunction with <https://www.rfc-editor.org/info/rfc8397>.
the protocol for providing the connectionless-mode network
service", ISO 8473, Second Edition, November 2002.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 11.2. Informative References
and M. Fanto, "IS-IS Generic Cryptographic Authentication",
RFC 5310, DOI 10.17487/RFC5310, February 2009,
<https://www.rfc-editor.org/info/rfc5310>.
[RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and [IS-IS] International Organization for Standardization,
H. Zhai, "Alternatives for Multilevel Transparent "Information technology -- Telecommunications and
Interconnection of Lots of Links (TRILL)", RFC 8243, DOI information exchange between systems -- Intermediate
10.17487/RFC8243, September 2017, <https://www.rfc- System to Intermediate System intra-domain routeing
editor.org/info/rfc8243>. information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode network
service (ISO 8473)", ISO 8473, ISO/IEC 10589:2002, Second
Edition, November 2002.
Appendix A. Level Transition Clarification [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, <https://www.rfc-editor.org/info/rfc5310>.
[RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A.,
and H. Zhai, "Alternatives for Multilevel Transparent
Interconnection of Lots of Links (TRILL)", RFC 8243,
DOI 10.17487/RFC8243, September 2017,
<https://www.rfc-editor.org/info/rfc8243>.
Appendix A. Level Transition Clarification
It's possible that an L1 RBridge is only reachable from a non-DBRB It's possible that an L1 RBridge is only reachable from a non-DBRB
border RBridge. If this non-DBRB RBridge refrains from Level border RBridge. If this non-DBRB RBridge refrains from Level
transition, the question is, how can a multicast packet reach this L1 transition, the question is, how can a multicast packet reach this L1
RBridge? The answer is, it will be reached after the DBRB performs RBridge? The answer is, it will be reached after the DBRB performs
the Level transition and floods the packet using an L1 distribution the Level transition and floods the packet using an L1 distribution
tree. tree.
Take the following figure as an example. RB77 is reachable from the Take the following figure as an example. RB77 is reachable from the
border RBridge RB30 while RB3 is the DBRB. RB3 transitions the border RBridge RB30 while RB3 is the DBRB. RB3 transitions the
multicast packet into L1 and floods the packet on the distribution multicast packet into L1 and floods the packet on the distribution
tree rooted from RB3. This packet is finally flooded to RB77 via tree rooted from RB3. This packet is finally flooded to RB77 via
RB30. RB30.
Area{3,30} Area{3,30}
+--------------+ (root) RB3 o +--------------+ (root) RB3 o
| | \ | | \
-RB3 | | o RB30 -RB3 | | o RB30
| | | / | | | /
-RB30-RB77 | RB77 o -RB30-RB77 | RB77 o
+--------------+ +--------------+
Example Topology L1 Tree Example Topology L1 Tree
In the above example, the multicast packet is forwarded along a non- In the above example, the multicast packet is forwarded along a non-
optimal path. A possible improvement is to have RB3 configured not to optimal path. A possible improvement is to have RB3 configured not
belong to this area. In this way, RB30 will surely act as the DBRB to to belong to this area. In this way, RB30 will surely act as the
do the Level transition. DBRB to do the Level transition.
Authors' Addresses Authors' Addresses
Mingui Zhang Mingui Zhang
Huawei Technologies Independent
No. 156 Beiqing Rd. Haidian District Beijing
Beijing 100095 China
China
Email: zhangmingui@huawei.com
Donald E. Eastlake, 3rd
Futurewei Technologies
2386 Panoramic Circle
Apopka, FL 32703
United States
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman Email: zhangmingui@qq.com
EMC
2010 256th Avenue NE, #200
Bellevue, WA 98007
United States
Email: radia@alum.mit.edu Donald E. Eastlake, 3rd
Futurewei Technologies
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Margaret Cullen Phone: +1-508-333-2270
Painless Security Email: d3e3e3@gmail.com
356 Abbott Street
North Andover, MA 01845
United States
Phone: +1-781-405-7464 Radia Perlman
Email: margaret@painless-security.com EMC
URI: https://www.painless-security.com 2010 256th Avenue NE, #200
Bellevue, WA 98007
United States of America
Hongjun Zhai Email: radia@alum.mit.edu
Jinling Institute of Technology
99 Hongjing Avenue, Jiangning District
Nanjing, Jiangsu 211169
China
Email: honjun.zhai@tom.com Margaret Cullen
Painless Security
356 Abbott Street
North Andover, MA 01845
United States of America
Copyright, Disclaimer, and Additional IPR Provisions Phone: +1-781-405-7464
Email: margaret@painless-security.com
URI: https://www.painless-security.com
Copyright (c) 2021 IETF Trust and the persons identified as the Hongjun Zhai
document authors. All rights reserved. Jinling Institute of Technology
99 Hongjing Avenue, Jiangning District
Nanjing
Jiangsu, 211169
China
This document is subject to BCP 78 and the IETF Trust's Legal Email: honjun.zhai@tom.com
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.
 End of changes. 139 change blocks. 
422 lines changed or deleted 438 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/