Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)IndependentBeijingChinazhangmingui@qq.comFuturewei Technologies2386 Panoramic CircleApopkaFL32703United States of America+1-508-333-2270d3e3e3@gmail.comEMC2010 256th Avenue NE, #200BellevueWA98007United States of Americaradia@alum.mit.eduPainless Security356 Abbott StreetNorth AndoverMA01845United States of America+1-781-405-7464margaret@painless-security.comhttps://www.painless-security.comJinling Institute of Technology99 Hongjing Avenue, Jiangning DistrictNanjingJiangsu211169Chinahonjun.zhai@tom.comaggregated
A major issue in multilevel TRILL is how to manage RBridge nicknames.
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
but RBridges in different Level 1 areas may have the same nicknames.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 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
() 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.
Table of Contents
. Introduction
. Acronyms and Terminology
. Nickname Handling on Border RBridges
. Actions on Unicast Packets
. Actions on Multi-destination Packets
. Per-Flow Load Balancing
. L2-to-L1 Ingress Nickname Replacement
. L1-to-L2 Egress Nickname Replacement
. Protocol Extensions for Discovery
. Discovery of Border RBridges in L1
. Discovery of Border RBridge Sets in L2
. One Border RBridge Connects Multiple Areas
. E-L1FS/E-L2FS Backwards Compatibility
. Manageability Considerations
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. Level Transition Clarification
Authors' Addresses
Introduction
TRILL (Transparent Interconnection of Lots of Links) multilevel techniques are designed to improve TRILL
scalability issues.
"" is an educational
document to explain multilevel TRILL and list possible concerns. It does
not specify a protocol. As described in , there have been two proposed approaches. One approach,
which is referred to as the "unique nickname" approach, gives unique
nicknames to all the TRILL switches in the multilevel campus either by
having the Level 1/Level 2 border TRILL switches advertise which nicknames
are not available for assignment in the area or by partitioning the 16-bit
nickname into an "area" field and a "nickname inside the area" field. is the Standards Track document
specifying a "unique nickname" flavor of TRILL multilevel. The other
approach, which is referred to in
as the "aggregated nickname" approach, involves assigning nicknames to the
areas, and allowing nicknames to be reused inside different areas, by
having the border TRILL switches rewrite the nickname fields when entering
or leaving an area. makes the
case that, while unique nickname multilevel solutions are simpler,
aggregated nickname solutions scale better.
The approach specified in this Standards Track document is somewhat
similar to the "aggregated nickname" approach in but with a
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
additional nicknames are assigned to represent L1 areas as such.
Instead, multiple border RBridges are allowed and each L1 area is
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
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
in one L1 area does not prohibit the use of other approaches in other
L1 areas in the same TRILL campus, for example the use of the unique
nickname approach specified in . The TRILL packet format is
unchanged by this document, but data plane processing is changed at
Border RBridges and efficient high volume data flow at Border
RBridges might require forwarding hardware change.Acronyms and Terminology
Area Border RBridge:
A border RBridge between a Level 1 area and Level 2.
Data Label:
VLAN or Fine-Grained Label (FGL).
DBRB:
Designated Border RBridge.
IS-IS:
Intermediate System to Intermediate System .
Level:
Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 for
inter-area. Routing information is exchanged between 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Familiarity with is assumed in this document.Nickname Handling on Border RBridges
This section provides an illustrative example and description of the
border learning border RBridge nicknames.
In , RB2, RB20, RB3, and RB30 are area border TRILL switches
(RBridges). Their nicknames are 2, 20, 3, and 30, respectively, and are
used as TRILL switch identifiers in their areas . 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
{2,20} to denote the L1 area on the left.
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).
(In fact, they could even have the same nickname, since the TRILL
switch nickname will not be visible outside these Level 1 areas.)Actions on Unicast Packets
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
already. These relevant switches have learned the following:
RB27 has learned that D is connected to nickname 3.
RB3 has learned that D is attached to nickname 44.
The following sequence of events will occur:
S transmits an Ethernet frame with source MAC = S and destination MAC =
D.
RB27 encapsulates with a TRILL header with ingress RBridge = 27 and
egress RBridge = 3 producing a TRILL Data packet.
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 RBridges in the
Level 2 area including RB3 and RB30. Therefore, IS-IS routes the packet to
RB2 (or RB20, if RB20 is on the least-cost route from RB27 to RB3).
RB2, when transitioning the packet from Level 1 to Level 2, replaces
the ingress TRILL switch nickname with its own nickname, replacing 27 with
2. Within Level 2, the ingress RBridge field in the TRILL header will
therefore be 2, and the egress RBridge field will be 3. (The egress
nickname MAY be replaced with any area nickname selected
from {3,30} such as 30. See for the detail of the
selection method. Here, suppose the egress nickname remains 3.) Also, RB2
learns that S is attached to nickname 27 in area {2,20} to accommodate
return traffic. RB2 SHOULD synchronize with RB20 using the
End Station Address Distribution Information (ESADI) protocol that MAC = S is attached to nickname 27.
The packet is forwarded through Level 2, to RB3, which has
advertised, in Level 2, its L2 nickname as 3.
RB3, when forwarding into area {3,30}, replaces the egress nickname
in the TRILL header with RB44's nickname (44) based on looking up
D. (The ingress nickname MAY be replaced with any area
nickname selected from {2,20}. See for the
detail of the selection method. Here, suppose the ingress nickname
remains 2.) So, within the destination area, the ingress nickname will
be 2 and the egress nickname will be 44.
RB44, when decapsulating, learns that S is attached to
nickname 2, which is one of the area nicknames of the
ingress.
Actions on Multi-destination Packets
Distribution trees for flooding of multi-destination packets are calculated
separately within each L1 area and in L2. When a multi-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 eligible for Level
transition. However, for each multi-destination packet, only one of them
acts as the Designated Border RBridge (DBRB) to do the transition while
other non-DBRBs MUST drop the received copies. By default,
the border RBridge with the smallest nickname, considered as an unsigned
integer, is elected DBRB. All border 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 scope of
this document; one such mechanism is used in for load balancing.
As per ,
multi-destination packets can be classified into three types: unicast
packets with unknown destination MAC addresses (unknown-unicast packets),
multicast packets, and broadcast packets. Now suppose that D's location has
not been learned by RB27 or the frame received by RB27 is recognized as
broadcast or multicast. What will happen within a Level 1 area (as it would
in TRILL today) is that RB27 will forward the packet as multi-destination,
setting its M bit to 1 and choosing an L1 tree, which would flood the packet
on that distribution tree (subject to potential pruning).
When the copies of the multi-destination packet arrive at area border
RBridges, non-DBRBs MUST drop the packet while the DBRB (say, RB2)
needs to do the Level transition for the multi-destination packet.
For an unknown-unicast packet, if the DBRB has learned the destination
MAC address, it SHOULD convert the packet to unicast and set its M
bit to 0. Otherwise, the multi-destination packet will continue to be
flooded as a multicast packet on the distribution tree. The DBRB
chooses the new distribution tree by replacing the egress nickname
with the new tree root RBridge nickname from the area the packet is
entering. The following sequence of events will occur:
RB2, when transitioning the packet from Level 1 to Level 2, replaces
the ingress TRILL switch nickname with its own nickname, replacing 27
with 2. RB2 also MUST replace the egress RBridge nickname
with an L2 tree root RBridge nickname (say, 39). In order to accommodate
return traffic, RB2 records that S is attached to nickname 27 and
SHOULD use the ESADI protocol to synchronize this attachment information with other
border RBridges (say, RB20) in the area.
RB20 will receive the packet flooded on the L2 tree by RB2. It
is important that RB20 does not transition this packet back to L1 as
it does for a multicast packet normally received from another remote
L1 area. RB20 should examine the ingress nickname of this packet. If
this nickname is found to be a border RBridge nickname of the area
{2,20}, RB2 must not forward the packet into this area.
The multi-destination packet is flooded on the Level 2 tree
to reach all border routers for all L1 areas including both RB3
and RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30
will drop the packet.
RB3, when forwarding into area {3,30}, replaces the
egress nickname in the TRILL header with the root RBridge
nickname of a distribution tree of L1 area {3,30} -- say,
30. (Here, the ingress nickname MAY be
replaced with a different area nickname selected from
{2,20}, the set of border RBridges to the ingress area, as
specified in .)
Now suppose that RB27 has learned the location of D
(attached to nickname 3), but RB3 does not know where D is
because this information has fallen out of cache or RB3
has restarted or some other reason. In that case, RB3 must
turn the packet into a multi-destination packet and then
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 important that RB30 does not
transition this packet back to L2. RB30 should also
examine the ingress nickname of this packet. If this
nickname is found to be an L2 Border RBridge
Nickname, RB30 must not transition the packet back to
L2.
The multicast listener RB44, when
decapsulating the received packet, learns that S
is attached to nickname 2, which is one of the
area nicknames of the ingress.
See also .Per-Flow Load Balancing
Area border RBridges perform ingress/egress nickname replacement when they
transition TRILL Data packets between Level 1 and Level 2. The egress
nickname will again be replaced when the packet transitions from Level 2 to
Level 1. This nickname replacement enables the per-flow load balance, which
is specified in the following subsections. The mechanism specified in
or that in or both is necessary in general to load-balance traffic
across L2 paths.L2-to-L1 Ingress Nickname Replacement
When a TRILL Data packet from other L1 areas arrives at an area border
RBridge, this RBridge MAY select one area nickname of the
ingress area to replace the ingress nickname of the packet so that the
returning TRILL Data packet can be forwarded to this selected nickname to
help load-balance return unicast traffic over multiple paths. The selection
is simply based on a pseudorandom algorithm as discussed in . With
the random ingress nickname replacement, the border RBridge actually
achieves a per-flow load balance for returning traffic.
All area border RBridges for an L1 area MUST agree on the same
pseudorandom algorithm. The source MAC address, ingress area
nicknames, egress area nicknames, and the Data Label of the received
TRILL Data packet are candidate factors of the input of this
pseudorandom algorithm. Note that the value of the destination MAC
address SHOULD be excluded from the input of this pseudorandom
algorithm; otherwise, the egress RBridge could see one source MAC
address flip-flopping among multiple ingress RBridges.L1-to-L2 Egress Nickname Replacement
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
one area nickname of the egress area to replace the egress nickname 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 equal
cost egress area border RBridges, use the pseudorandom algorithm as defined
in to select one. The use of that algorithm
MAY be extended to selection among some stable set of egress
area border RBridges that include non-least-cost 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 TRILL Data packet to the egress
area.Protocol Extensions for Discovery
The following topology change scenarios will trigger the discovery
processes as defined in Sections and :
A new node comes up or recovers from a previous failure.
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.
Discovery of Border RBridges in L1
The following Level 1 Border RBridge APPsub-TLV will be included in E-L1FS
FS-LSP fragment zero as an
APPsub-TLV of the TRILL GENINFO-TLV. Through listening for this APPsub-TLV,
an area border RBridge discovers all other area border RBridges in this
area.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = L1-BORDER-RBRIDGE | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Level 1 Border RBridge (TRILL APPsub-TLV type 256)
Length:
2
Sender Nickname:
The nickname the originating IS will use as the L1 Border
RBridge Nickname. This field is useful because the originating IS
might own multiple nicknames.
Discovery of Border RBridge Sets in L2
The following APPsub-TLV will be included in an E-L2FS FS-LSP
fragment zero as an APPsub-TLV of the TRILL GENINFO-TLV.
Through listening to this APPsub-TLV in L2, an area border RBridge
discovers all groups of L1 border RBridges and each such group
identifies an area.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = L1-BORDER-RB-GROUP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1 Border RBridge Nickname 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1 Border RBridge Nickname k | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Level 1 Border RBridge Group (TRILL APPsub-TLV type 257)
Length:
2 * k. If length is not a multiple of 2, the APPsub-TLV is corrupt and
MUST be ignored.
L1 Border RBridge Nickname:
The nickname that an area border RBridge uses as the L1 Border RBridge
Nickname. The L1-BORDER-RB-GROUP TLV generated by an area border RBridge
MUST include all L1 Border RBridge Nicknames of the area. It's
RECOMMENDED that these k nicknames are ordered in ascending
order according to the 2-octet nickname considered as an unsigned integer.
When an L1 area is partitioned ,
border RBridges will re-discover each other in both L1 and L2 through
exchanging LSPs. In L2, the set of border RBridge nicknames for this
splitting area will change. Border RBridges that detect such a change
MUST flush the reachability information associated to any
RBridge nickname from this changing set.One Border RBridge Connects Multiple Areas
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 to minimize nickname consumption and the number of
nicknames being advertised in L2; however, such a border RBridge might have
to hold multiple nicknames -- for example, it might be the root of multiple
L1 or multiple L2 distribution trees.
Nicknames used within one of these L1 areas can be reused within other
areas. It's important that packets destined to those duplicated nicknames
are sent to the right area. Since these areas are connected to form a layer
2 network, duplicated {MAC, Data Label} across these areas SHOULD NOT occur (see for tie breaking rules). Now suppose
a TRILL Data packet arrives at the area border nickname of RB1. For a
unicast packet, RB1 can look up the {MAC, Data Label} entry in its MAC
table to identify the right destination area (i.e., the outgoing interface)
and the egress RBridge's nickname. For a multicast packet for each
attached L1 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
following rules:
If this packet originated from an area out of the connected areas,
RB1 replicates this packet and floods it on the proper Level 1
trees of all the areas in which it acts as the DBRB.
If the packet originated from one of the connected areas, RB1
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
as the DBRB except the originating area (i.e., the area connected
to the incoming interface). RB1 might also receive the replication
of the packet from the Level 2 tree. This replication MUST be
dropped by RB1. It recognizes such packets by their ingress
nickname being the nickname of one of the border RBridges of an L1
area for which the receiving border RBridge is DBRB.
E-L1FS/E-L2FS Backwards Compatibility
All Level 2 RBridges MUST support E-L2FS . The Extended TLVs defined in are to be used in Extended Level 1/2 Flooding Scope
(E-L1FS/E-L2FS) Protocol Data Units (PDUs). Area border RBridges
MUST support both E-L1FS and E-L2FS. RBridges that do not
support both E-L1FS or E-L2FS cannot serve as area border RBridges but they
can appear in an L1 area acting as non-area-border RBridges.Manageability Considerations
If an L1 Border RBridge Nickname is configured at an RBridge and that
RBridge has both L1 and L2 adjacencies, the multilevel feature as specified
in this document is turned on for that RBridge and normally uses an L2
nickname in both L1 and L2 although, as provided below, such an RBridge may
have to fall back to multilevel unique nickname behavior , in which case it uses this L1 nickname.
In contrast, unique nickname multilevel as specified in is enabled by the presence of L1 and L2
adjacencies without an L1 Border RBridge Nickname being configured.
RBridges supporting only unique nickname multilevel do not support the
configuration of an L2 Border RBridge Nickname. RBridges supporting only
the single-level TRILL base protocol specified in do not support L2 adjacencies.
RBridges that support and are configured to use single nickname multilevel
as specified in this document MUST support unique nickname
multilevel . If there are
multiple border RBridges between an L1 area and L2, and one or more of them
only support or are only configured for unique nickname multilevel , any of these border RBridges that are
configured to use single nickname multilevel MUST fall back
to behaving as a unique nickname border RBridge for that L1 area. Because
overlapping sets of RBridges may be the border RBridges for different L1
areas, an RBridge supporting single nickname MUST be able to
simultaneously support single nickname for some of its L1 areas and unique
nickname for others. For example, RB1 and RB2 might be border RBridges for
L1 area A1 using single nickname while RB2 and RB3 are border RBridges for
area A2. If RB3 only supports unique nicknames, then RB2 must fall back to
unique nickname for area A2 but continue to support single nickname for
area A1. Operators SHOULD be notified when this fallback
occurs. The presence of border RBridges using unique nickname multilevel
can be detected because they advertise in L1 the blocks of nicknames
available within that L1 area.
In both the unique nickname approach specified in and the single nickname aggregated approach specified in
this document, an 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 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 other
Level 1 area except other Level 1 areas for which the same RBridge is a
border RBridge with this L1 Border RBridge Nickname configured.
In addition to the manageability considerations specified above, the
manageability specifications in
still apply.
Border RBridges replace ingress and/or egress nickname when a TRILL Data
packet traverses a TRILL L2 area. A TRILL Operations, Administration, and
Maintenance (OAM) message will be forwarded through the multilevel single
nickname TRILL campus using a MAC address belonging to the destination
RBridge .Security Considerations
For general TRILL Security Considerations, see .
The newly defined TRILL APPsub-TLVs in are transported in IS-IS PDUs whose authenticity can be
enforced using regular IS-IS security mechanism . Malicious devices may also fake
the APPsub-TLVs to attract TRILL Data packets, interfere with multilevel
TRILL operation, induce excessive state in TRILL switches (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
Authentication TLV (10) in their IS-IS PDUs so that IS-IS security can be used to authenticate those PDUs
and discard them if they are forged.
Using a variation of aggregated nicknames, and the resulting possible
duplication of nicknames between areas, increases the possibility of a
TRILL Data packet being delivered to the wrong egress RBridge if areas are
unexpectedly merged as compared with a scheme where all nicknames in the
TRILL campus are, except as a transient condition, unique such as the
scheme in . However, in many
cases, the data would be discarded at that egress RBridge because it would
not match a known end station Data Label / MAC address.IANA Considerations
IANA has allocated two new types under the TRILL GENINFO TLV
from the range allocated by
Standards Action for the TRILL APPsub-TLVs defined in . The following entries have been added to the "TRILL
APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on
the TRILL Parameters IANA web page.
Type
Name
Reference
256
L1-BORDER-RBRIDGE
RFC 9183
257
L1-BORDER-RB-GROUP
RFC 9183
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Routing Bridges (RBridges): Base Protocol SpecificationRouting Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]IS-IS Flooding Scope Link State PDUs (LSPs)Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) ProtocolThe IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.Transparent Interconnection of Lots of Links (TRILL): Fault ManagementThis document specifies Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (Connectivity Fault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL-specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1. This document updates RFC 6325.Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and UpdatesSince the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs 6325, 7177, and 7179.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique NicknamesTRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.Informative ReferencesInformation technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)International Organization for StandardizationISO 8473ISO/IEC 10589:2002Second EditionIS-IS Generic Cryptographic AuthenticationThis document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases.Level Transition Clarification
It's possible that an L1 RBridge is only reachable from a non-DBRB
border RBridge. If this non-DBRB RBridge refrains from Level
transition, the question is, how can a multicast packet reach this L1
RBridge? The answer is, it will be reached after the DBRB performs
the Level transition and floods the packet using an L1 distribution
tree.
Take the following figure as an example. RB77 is reachable from the
border RBridge RB30 while RB3 is the DBRB. RB3 transitions the
multicast packet into L1 and floods the packet on the distribution
tree rooted from RB3. This packet is finally flooded to RB77 via
RB30.
Area{3,30}
+--------------+ (root) RB3 o
| | \
-RB3 | | o RB30
| | | /
-RB30-RB77 | RB77 o
+--------------+
Example Topology L1 Tree
In the above example, the multicast packet is forwarded along a non-optimal
path. A possible improvement is to have RB3 configured not to belong to
this area. In this way, RB30 will surely act as the DBRB to do the Level
transition.Authors' AddressesIndependentBeijingChinazhangmingui@qq.comFuturewei Technologies2386 Panoramic CircleApopkaFL32703United States of America+1-508-333-2270d3e3e3@gmail.comEMC2010 256th Avenue NE, #200BellevueWA98007United States of Americaradia@alum.mit.eduPainless Security356 Abbott StreetNorth AndoverMA01845United States of America+1-781-405-7464margaret@painless-security.comhttps://www.painless-security.comJinling Institute of Technology99 Hongjing Avenue, Jiangning DistrictNanjingJiangsu211169Chinahonjun.zhai@tom.com