8377
PROPOSED STANDARD
Transparent Interconnection of Lots of Links (TRILL): Multi-Topology
Authors: D. Eastlake 3rd, M. Zhang, A. Banerjee
Date: July 2018
Area: rtg
Working Group: trill
Stream: IETF
Updates:
RFC 6325
Abstract
This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177.
RFC 8377
PROPOSED STANDARD
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8377 M. Zhang
Updates: <a href="./rfc6325">6325</a>, <a href="./rfc7177">7177</a> Huawei
Category: Standards Track A. Banerjee
ISSN: 2070-1721 Cisco
July 2018
<span class="h1">Transparent Interconnection of Lots of Links (TRILL):</span>
<span class="h1">Multi-Topology</span>
Abstract
This document specifies extensions to the IETF TRILL (Transparent
Interconnection of Lots of Links) protocol to support multi-topology
routing of unicast and multi-destination traffic based on IS-IS
(Intermediate System to Intermediate System) multi-topology specified
in <a href="./rfc5120">RFC 5120</a>. This document updates RFCs 6325 and 7177.
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 <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8377">https://www.rfc-editor.org/info/rfc8377</a>.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Eastlake, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Topologies ......................................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Links and Multi-Topology ...................................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. TRILL Switches and Multi-Topology ..........................<a href="#page-6">6</a>
<a href="#section-2.4">2.4</a>. TRILL Data Packets and Multi-Topology ......................<a href="#page-6">6</a>
<a href="#section-2.4.1">2.4.1</a>. Explicit Topology Labeling Support ..................<a href="#page-7">7</a>
<a href="#section-2.4.2">2.4.2</a>. The Explicit Topology Label .........................<a href="#page-8">8</a>
<a href="#section-2.4.3">2.4.3</a>. TRILL Use of the MT Label ...........................<a href="#page-8">8</a>
<a href="#section-3">3</a>. TRILL Multi-Topology Adjacency and Routing .....................<a href="#page-10">10</a>
<a href="#section-3.1">3.1</a>. Adjacency .................................................<a href="#page-10">10</a>
<a href="#section-3.2">3.2</a>. TRILL Switch Nicknames ....................................<a href="#page-10">10</a>
<a href="#section-3.3">3.3</a>. TRILL Unicast Routing .....................................<a href="#page-11">11</a>
<a href="#section-3.4">3.4</a>. TRILL Multi-Destination Routing ...........................<a href="#page-11">11</a>
<a href="#section-3.4.1">3.4.1</a>. Distribution Trees .................................<a href="#page-11">11</a>
<a href="#section-3.4.2">3.4.2</a>. Multi-Access Links .................................<a href="#page-13">13</a>
<a href="#section-4">4</a>. Mixed Links ....................................................<a href="#page-13">13</a>
<a href="#section-5">5</a>. Other Multi-Topology Considerations ............................<a href="#page-14">14</a>
<a href="#section-5.1">5.1</a>. Address Learning ..........................................<a href="#page-14">14</a>
<a href="#section-5.1.1">5.1.1</a>. Data Plane Learning ................................<a href="#page-14">14</a>
<a href="#section-5.1.2">5.1.2</a>. Multi-Topology ESADI ...............................<a href="#page-14">14</a>
<a href="#section-5.2">5.2</a>. Legacy Stubs ..............................................<a href="#page-14">14</a>
<a href="#section-5.3">5.3</a>. RBridge Channel Messages ..................................<a href="#page-14">14</a>
<a href="#section-5.4">5.4</a>. Implementations Considerations ............................<a href="#page-15">15</a>
<a href="#section-6">6</a>. Allocation Considerations ......................................<a href="#page-15">15</a>
<a href="#section-6.1">6.1</a>. IEEE Registration Authority Considerations ................<a href="#page-15">15</a>
<a href="#section-6.2">6.2</a>. IANA Considerations .......................................<a href="#page-15">15</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-16">16</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-17">17</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-17">17</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-18">18</a>
<a href="#appendix-A">Appendix A</a>. Differences from <a href="./rfc5120">RFC 5120</a> .............................<a href="#page-19">19</a>
Acknowledgements ..................................................<a href="#page-19">19</a>
Authors' Addresses ................................................<a href="#page-20">20</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies extensions to the IETF TRILL (Transparent
Interconnection of Lots of Links) protocol [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>]
[<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>] to support multi-topology routing for both unicast and
multi-destination traffic based on IS-IS (Intermediate System to
Intermediate System) [<a href="#ref-IS-IS" title=""Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)"">IS-IS</a>] multi-topology [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>].
Implementation and use of multi-topology are optional, and use
requires configuration. It is anticipated that not all TRILL
campuses will need or use multi-topology.
<span class="grey">Eastlake, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
Multi-topology creates different topologies or subsets from a single
physical TRILL campus topology. This is different from Data Labels
(VLANs and Fine-Grained Labels (FGLs) [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>]). Data Labels
specify communities of end stations and can be viewed as creating
virtual topologies of end station connectivity. However, in a single
topology TRILL campus, TRILL Data packets can use any part of the
physical topology of TRILL switches and links between TRILL switches,
regardless of the Data Label of that packet's payload. In a multi-
topology TRILL campus, TRILL data packets in a topology are
restricted to the TRILL switches and links that are in their
topology, regardless of the Data Label of their payload.
The essence of multi-topology behavior is that a multi-topology
router classifies packets as to the topology within which they should
be routed and uses logically different routing tables for different
topologies. If routers in the network do not agree on the topology
classification of packets or links, persistent routing loops can
occur. It is the responsibility of the network manager to
consistently configure multi-topology to avoid such routing loops.
The multi-topology TRILL extensions can be used for a wide variety of
purposes, such as maintaining separate routing domains for isolated
multicast or IPv6 islands, routing a class of traffic so that it
avoids certain TRILL switches that lack some characteristic needed by
that traffic, or making a class of traffic avoid certain links due to
security, reliability, or other concerns.
It is possible for a particular topology to not be fully connected,
either intentionally or due to node or link failures or incorrect
configuration. This results in two or more islands of that topology
that cannot communicate. In such a case, end stations connected in
that topology to different islands will be unable to communicate with
each other.
Multi-topology TRILL supports regions of topology-ignorant TRILL
switches as part of a multi-topology campus; however, such regions
can only ingress to, egress from, or transit TRILL Data packets in
the special base topology zero.
<span class="grey">Eastlake, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The terminology and abbreviations of [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] are used in this
document. Some of these are paraphrased below for convenience. Some
additional terms are also listed.
campus: The name for a TRILL network, like "bridged LAN" is a name
for a bridged network. It does not have any academic
implication.
DRB: Designated RBridge [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>].
FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained
Label [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>]. By implication, an "FGL TRILL switch" does
not support Multi-Topology (MT).
IS: Intermediate System [<a href="#ref-IS-IS" title=""Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)"">IS-IS</a>].
LSP: Link State PDU (Protocol Data Unit) [<a href="#ref-IS-IS" title=""Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)"">IS-IS</a>]. For TRILL, this
includes Level 1 LSPs and Extended Level 1 Flooding Scope LSPs
[<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>].
MT: Multi-Topology [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>].
MT TRILL Switch: A TRILL switch supporting the multi-topology
feature specified in this document. An MT TRILL switch MUST
support FGL in the sense that it MUST be FGL safe [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>].
RBridge: Routing Bridge; an alternative name for a TRILL switch.
TRILL: Transparent Interconnection of Lots of Links or Tunneled
Routing in the Link Layer [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>].
TRILL Switch: A device implementing the TRILL protocol. TRILL
switches are Intermediate Systems (routers) [<a href="#ref-IS-IS" title=""Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)"">IS-IS</a>].
VL: VLAN Labeling or VLAN Labeled or VLAN Label [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>]. By
implication, a "VL RBridge" or "VL TRILL switch" does not
support FGL or MT.
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
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="grey">Eastlake, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Topologies</span>
In TRILL multi-topology, a topology is a subset of the TRILL switches
and of the links between TRILL switches in the TRILL campus. TRILL
Data packets are constrained to the subset of switches and links
corresponding to the packet's topology. TRILL multi-topology is
based on IS-IS multi-topology [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>]. See <a href="#appendix-A">Appendix A</a> for
differences between TRILL multi-topology and [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>].
The zero topology is special, as described in <a href="#section-2.1">Section 2.1</a>. Sections
2.2, 2.3, and 2.4 discuss the topology of links, TRILL switches, and
TRILL Data packets, respectively.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Special Topology Zero</span>
The zero topology is special as the default base topology. All TRILL
switches and links are considered to be in, and MUST support,
topology zero. Thus, for example, topology zero can be used for
general TRILL switch access within a campus for management messages,
Bidirectional Forwarding Detection (BFD) messages [<a href="./rfc7175" title=""Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support"">RFC7175</a>], RBridge
Channel messages [<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>], and the like.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Links and Multi-Topology</span>
Multi-topology TRILL switches advertise the topologies for which they
are willing to send and receive TRILL Data packets on a port by
listing those topologies in one or more MT TLVs [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>] appearing
in every TRILL Hello [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>] they send out that port, except that
they MUST handle topology zero, which it is optional to list.
A link is usable for TRILL Data packets in non-zero topology T only
if:
(1) all TRILL switch ports on the link advertise topology T support
in their Hellos, and
(2) if any TRILL switch port on the link requires explicit TRILL Data
packet topology labeling (see <a href="#section-2.4">Section 2.4</a>) every other TRILL
switch port on the link is capable of generating explicit packet
topology labeling.
<span class="grey">Eastlake, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. TRILL Switches and Multi-Topology</span>
A TRILL switch advertises the topologies that it supports by listing
them in one or more MT TLVs [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>] in its LSP, except that it MUST
support topology zero, which is optional to list. For robust and
rapid flooding, MT TLV(s) SHOULD be advertised in core LSP fragment
zero.
There is no "MT capability bit". A TRILL switch advertises that it
is MT capable by advertising in its LSP support for any topology or
topologies with the MT TLV, even if it just explicitly advertises
support for topology zero.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. TRILL Data Packets and Multi-Topology</span>
The topology of a TRILL Data packet is commonly determined from
either (1) some field or fields present in the packet itself or (2)
the port on which the packet was received; however, optional explicit
topology labeling of TRILL Data packets is also proved. This can be
included in the data labeling area of TRILL Data packets as specified
below.
Examples of fields that might be used to determine topology are
values or ranges of values of the payload VLAN or FGL [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>],
packet priority, IP version (IPv6 versus IPv4) or IP protocol,
Ethertype, unicast versus multi-destination payload, IP
Differentiated Services Code Point (DSCP) bits, or the like.
Multi-topology does not apply to TRILL IS-IS packets or to link level
control frames. Those messages are link local and can be thought of
as being above all topologies. Multi-topology only applies to TRILL
Data packets.
<span class="grey">Eastlake, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h4"><a class="selflink" id="section-2.4.1" href="#section-2.4.1">2.4.1</a>. Explicit Topology Labeling Support</span>
Support of the topology label is optional. Support could depend on
port hardware and is indicated by a 2-bit capability field in the
Port TRILL Version sub-TLV [<a href="./rfc7176" title=""Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS"">RFC7176</a>] appearing in the Port
Capabilities TLV in Hellos. If there is no Port TRILL Capabilities
sub-TLV in a Hello, then it is assumed that explicit topology
labeling is not supported on that port. See the table below for the
meaning of values of the Explicit Topology capability field:
Value Meaning
----- -------
0 No support. Cannot send TRILL Data packets with an
explicit topology label and will likely treat as
erroneous and discard any TRILL Data packet received with
a topology label. Such a port is assumed to have the
ability and configuration to correctly classify TRILL
Data packets into all topologies for which it is
advertising support in its Hellos, either by examining
those packets or because they are arriving at that port.
1 Capable of inserting an explicit topology label in TRILL
Data packets sent and tolerant of such labels in received
TRILL Data packets. Such a port is capable, for all of
the topologies it supports, of determining TRILL Data
packet topology without an explicit label. Thus, it does
not require such a label in received TRILL Data packets.
On receiving a packet whose explicit topology label
differs from the port's topology determination for that
packet, the TRILL switch MUST discard the packet.
2 & 3 Require an explicit topology label in received TRILL Data
packets except for topology zero. Any TRILL Data packets
received without such a label are classified as being in
topology zero. Also capable of inserting an explicit
topology label in TRILL Data packets sent. (Values 2 and
3 are treated the same, which is the same as saying that
if the 2 bit is on, the 1 bit is ignored.)
In a Hello on Port P, a TRILL switch advertising support for topology
T but not advertising that it requires explicit topology labeling is
assumed to have the ability and configuration to correctly classify
TRILL Data packets into topology T by examination of those TRILL Data
packets and/or by using the fact that they are arriving at port P.
When a TRILL switch transmits a TRILL Data packet onto a link, if any
other TRILL switch on that link requires explicit topology labeling,
an explicit topology label MUST be included unless the TRILL Data
<span class="grey">Eastlake, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
packet is in topology zero, in which case, an explicit topology label
MAY be included. If a topology label is not so required, but all
other TRILL switches on that link support explicit topology labeling,
then such a label MAY be included.
<span class="h4"><a class="selflink" id="section-2.4.2" href="#section-2.4.2">2.4.2</a>. The Explicit Topology Label</span>
This section specifies the explicit topology label. Its use by TRILL
is specified in <a href="#section-2.4.3">Section 2.4.3</a>. This label may be used by other
technologies besides TRILL. The MT Label is structured as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype 0x9A22 | V | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MT Label
Where the fields are as follows:
MT Ethertype: The MT Label Ethertype (see <a href="#section-6.1">Section 6.1</a>).
V: The version number of the MT Label. This document specifies
version zero.
R: A 2-bit reserved field that MUST be sent as zero and ignored on
receipt.
MT-ID: The 12-bit topology using the topology number space of the MT
TLV [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>].
<span class="h4"><a class="selflink" id="section-2.4.3" href="#section-2.4.3">2.4.3</a>. TRILL Use of the MT Label</span>
With the addition of the version zero MT Label, the four standardized
content varieties for the TRILL Data packet data labeling area (the
area after the Inner.MacSA -- or Flag Word if the Flag Word is
present [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>] -- and before the payload) are as show below.
TRILL Data packets received with any other data labeling are
discarded. {PRI, D} is a 3-bit priority and a drop eligibility
indicator bit [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>].
All MT TRILL switches MUST support FGL, in the sense of being FGL
safe [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>]; thus, they MUST support all four data labeling area
contents shown below. (This requirement is imposed, rather than
having FGL support and MT support be independent, to reduce the
number of variations in RBridges and simplify testing.)
<span class="grey">Eastlake, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
1. C-VLAN [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VLAN = 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. FGL [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. MT C-VLAN [<a href="./rfc8377">RFC8377</a>]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VLAN = 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. MT FGL [<a href="./rfc8377">RFC8377</a>] [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inclusion or use of S-VLAN or further stacked tags are beyond the
scope of this document, but, as stated in [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>], are obvious
extensions.
<span class="grey">Eastlake, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. TRILL Multi-Topology Adjacency and Routing</span>
Routing calculations in IS-IS are based on adjacency. <a href="#section-3.1">Section 3.1</a>
specifies multi-topology TRILL adjacency. <a href="#section-3.2">Section 3.2</a> describes the
handling of nicknames. Sections <a href="#section-3.3">3.3</a> and <a href="#section-3.4">3.4</a> specify how unicast and
multi-destination TRILL multi-topology routing differ from the TRILL
base protocol routing.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Adjacency</span>
There is no change in the determination or announcement of adjacency
for topology zero, which is as specified in [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>]. When a
topology zero adjacency reaches the Report state, as specified in
[<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>], the adjacency is announced in core LSPs using the Extended
Intermediate System Reachability TLV (#22). This will be compatible
with any legacy topology-ignorant RBridges that might not support E-
L1FS FS-LSPs [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>].
Adjacency is announced for non-zero topologies in LSPs using the MT
Reachable Intermediate Systems TLV (#222) as specified in [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>].
A TRILL switch reports adjacency for non-zero topology T if and only
if that adjacency is in the Report state [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>] and the two
conditions listed in <a href="#section-2.2">Section 2.2</a> are true, namely:
1. All the ports on the link are announcing support of topology T.
2. If any port announces that it requires explicit topology labeling
(Explicit Topology capability field value 2 or 3), all other ports
advertise that they are capable of producing such labeling
(Explicit Topology capability field value of 1, 2, or 3).
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. TRILL Switch Nicknames</span>
TRILL switches are usually identified within the TRILL protocol (for
example, in the TRILL Header) by nicknames [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>]. Such
nicknames can be viewed as simply 16-bit abbreviation for a TRILL
switch's (or pseudo-node's) 7-byte IS-IS System ID. A TRILL switch
or pseudo-node can have more than one nickname, each of which
identifies it.
Nicknames are common across all topologies, just as IS-IS System IDs
are. Nicknames are determined as specified in [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] and
[<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>] using only the Nickname sub-TLVs appearing in Router
Capabilities TLVs (#242) advertised by TRILL switches. In
particular, the nickname allocation algorithm ignores Nickname sub-
TLVs that appear in MT Router Capability TLVs (#144). (However,
<span class="grey">Eastlake, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
Nickname sub-TLVs that appear in MT Router Capability TLVs with a
non-zero topology do affect the choice of distribution tree roots as
described in <a href="#section-3.4.1">Section 3.4.1</a>.)
To minimize transient inconsistencies, all Nickname sub-TLVs
advertised by a TRILL switch for a particular nickname, whether in
Router Capability or MT Router Capability TLVs, SHOULD appear in the
same LSP PDU. If that is not the case, then all LSP PDUs in which
they do occur SHOULD be flooded as an atomic action.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. TRILL Unicast Routing</span>
TRILL Data packets being TRILL unicast (those with TRILL Header M bit
= 0) are routed based on the egress nickname using logically separate
forwarding tables per topology T, where each such table has been
calculated based on least cost routing within T: that is, only using
links and nodes that support T. Thus, the next hop when forwarding
TRILL Data packets is determined by a lookup logically based on
{topology, egress nickname}.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. TRILL Multi-Destination Routing</span>
TRILL sends multi-destination data packets (those packets with TRILL
Header M bit = 1) over a distribution tree. Trees are designated by
nicknames that appear in the "egress nickname" field of multi-
destination TRILL Data packet TRILL Headers. To constrain multi-
destination packets to a topology T and still distribute them
properly requires the use of a distribution tree constrained to T.
Handling such TRILL Data packets and distribution trees in TRILL MT
is as described in the subsections below.
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Distribution Trees</span>
General provisions for distribution trees and how those trees are
determined are as specified in [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>], [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>], and [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>].
The distribution trees for topology zero are determined as specified
in those references and are the same as they would be with topology-
ignorant TRILL switches.
The TRILL distribution tree construction and packet handling for some
non-zero topology T are determined as specified in [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>],
[<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>], and [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>] with the following changes:
o As specified in [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>], only links usable with topology T
TRILL Data packets are considered when building a distribution
tree for topology T. As a result, such trees are automatically
limited to and separately span every internally connected
<span class="grey">Eastlake, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
island of topology T. In other words, if non-zero topology T
consists of disjoint islands, each distribution tree
construction for topology T is local to one such island.
o Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub-
TLV, and Trees Used sub-TLV occurring in an MT Router
Capabilities TLV (#144) specifying topology T are used in
determining the tree root(s), if any, for a connected area of
non-zero topology T.
+ There may be non-zero topologies with no multi-destination
traffic or, as described in [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>], even topologies with
no traffic at all. For example, if only known destination
unicast IPv6 TRILL Data packets were in topology T and all
multi-destination IPv6 TRILL Data packets were in some other
topology, there would be no need for a distribution tree for
topology T. For this reason, a Number of Trees to Compute
field value of zero in the Trees sub-TLV for the TRILL
switch holding the highest priority to be a tree root for a
non-zero topology T is honored and causes no distribution
trees to be calculated for non-zero topology T. This is
different from the base topology zero where, as specified in
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>], a zero Number of Trees to Compute field value
causes one tree to be computed.
o Nicknames are allocated as described in <a href="#section-3.2">Section 3.2</a>. If a
TRILL switch advertising that it provides topology T service
holds nickname N, the priority of N to be a tree root is given
by the tree root priority field of the Nickname sub-TLV that
has N in its nickname field and occurs in a topology T MT
Router Capabilities TLV advertised by that TRILL switch. If no
such Nickname sub-TLV can be found, the priority of N to be a
tree root is the default for an FGL TRILL switch as specified
in [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>].
+ There could be multiple topology T Nickname sub-TLVs for N
being advertised for a particular RBridge or pseudo-node,
due to transient conditions or errors. In that case, any
advertised in a core LSP PDU are preferred to those
advertised in an E-L1FS FS-LSP PDU. Within those
categories, the one in the lowest numbered fragment is used
and if there are multiple in that fragment, the one with the
smallest offset from the beginning of the PDU is used.
o Tree pruning for topology T uses only the Interested VLANs sub-
TLVs and Interested Labels sub-TLVs [<a href="./rfc7176" title=""Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS"">RFC7176</a>] advertised in MT
Router Capabilities TLVs for topology T.
<span class="grey">Eastlake, et al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
An MT TRILL switch MUST have logically separate routing tables per
topology for the forwarding of multi-destination traffic.
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Multi-Access Links</span>
Multi-destination TRILL Data packets are forwarded on broadcast
(multi-access) links in such a way as to be received by all other
TRILL switch ports on the link. For example, on Ethernet links they
are sent with a multicast Outer.MacDA [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>]. Care must be taken
that a TRILL Data packet in a non-zero topology is only forwarded by
an MT TRILL switch.
For this reason, a non-zero topology TRILL Data packet MUST NOT be
forwarded onto a link unless the link meets the requirements
specified in <a href="#section-2.2">Section 2.2</a> for use in that topology even if there are
one or more MT TRILL switch ports on the link.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Mixed Links</span>
There might be any combination of MT, FGL, or even VL TRILL switches
[<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>] on a link. DRB (Designated RBridge) election and Forwarder
appointment on the link work as previously specified in [<a href="./rfc8139" title=""Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders"">RFC8139</a>] and
[<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>]. It is up to the network manager to configure and manage
the TRILL switches on a link so that the desired switch is DRB and
the desired switch is the Appointed Forwarder for the appropriate
VLANs.
Frames ingressed by MT TRILL switches can potentially be in any
topology recognized by the switch and permitted on the ingress port.
Frames ingressed by VL or FGL TRILL switches can only be in the base
zero topology. Because FGL and VL TRILL switches do not understand
topologies, all occurrences of the following sub-TLVs MUST occur only
in MT Port Capability TLVs with a zero MT-ID. Any occurrence of
these sub-TLVs in an MT Port Capability TLV with a nonzero MT-ID is
ignored.
Special VLANs and Flags Sub-TLV
Enabled-VLANs Sub-TLV
Appointed Forwarders Sub-TLV
VLANs Appointed Sub-TLV
Native frames cannot be explicitly labeled (see <a href="#section-2.4">Section 2.4</a>) as to
their topology.
<span class="grey">Eastlake, et al. Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Other Multi-Topology Considerations</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Address Learning</span>
The learning of end station Media Access Control (MAC) addresses is
per topology as well as per label (VLAN or FGL). The same MAC
address can occur within a TRILL campus for different end stations
that differ only in topology without confusion.
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Data Plane Learning</span>
End station MAC addresses learned from ingressing native frames or
egressing TRILL Data packets are, for MT TRILL switches, qualified by
topology. That is, either the topology into which that TRILL switch
classified the ingressed native frame or the topology that the
egressed TRILL Data frame was in.
<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. Multi-Topology ESADI</span>
In an MT TRILL switch, End Station Address Distribution Information
(ESADI) [<a href="./rfc7357" title=""Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol"">RFC7357</a>] operates per label (VLAN or FGL) per topology.
Since ESADI messages appear, to transit TRILL switches, like normal
multi-destination TRILL Data packets, ESADI link state databases and
ESADI protocol operation are per topology as well as per label and
local to each area of multi-destination TRILL data connectivity for
that topology.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Legacy Stubs</span>
Areas of topology-ignorant TRILL switches can be connected to and
become part of an MT TRILL campus but will only be able to ingress
to, transit, or egress from topology zero TRILL Data packets.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. RBridge Channel Messages</span>
RBridge Channel messages [<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>], such as BFD over TRILL [<a href="./rfc7175" title=""Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support"">RFC7175</a>]
appear, to transit TRILL switches, like normal multi-destination
TRILL Data packets. Thus, they have a topology and, if that topology
is non-zero, are constrained by topology like other TRILL Data
packets. Generally, when sent for network management purposes, they
are sent in topology zero to avoid such constraint.
<span class="grey">Eastlake, et al. Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Implementations Considerations</span>
MT is an optional TRILL switch capability.
Experience with the actual deployment of Layer 3 IS-IS MT [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>]
indicates that a single router handling more than eight topologies is
rare. There may be many more than eight distinct topologies in a
routed area, such as a TRILL campus; in that case, many of these
topologies will be handled by disjoint sets of routers and/or links.
Based on this deployment experience, a TRILL switch capable of
handling eight or more topologies can be considered a full
implementation while a TRILL switch capable of handling four
topologies can be considered a minimal implementation but still
useful under some circumstances.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Allocation Considerations</span>
IEEE Registration Authority and IANA considerations are given below.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. IEEE Registration Authority Considerations</span>
The IEEE Registration Authority has allocated Ethertype 0x9A22 for
the MT Label (see <a href="#section-2.4">Section 2.4</a>).
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. IANA Considerations</span>
IANA has assigned a field of two adjacent bits (14-15) of the
Capabilities bits of the Port TRILL Version Sub-TLV for the Explicit
Topology capability field and updated the "PORT-TRILL-VER Sub-TLV
Capability Flags" registry as follows.
Bit Description Reference
----- ------------------------- ---------------
14-15 Topology labeling support. [<a href="./rfc8377">RFC8377</a>]
<span class="grey">Eastlake, et al. Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
IANA has created the informational "TRILL Ethertypes" subregistry in
the "Transparent Interconnection of Lots of Links (TRILL) Parameters"
registry.
Name: TRILL Ethertypes
Registration Procedure(s): Ethertypes are assigned by the IEEE
Registration Authority. Updates to this registry are coordinated
with the designated expert.
Reference: [<a href="./rfc8377">RFC8377</a>]
Note: This registry provides centralized documentation of
Ethertypes that were assigned by the IEEE for initial use
with TRILL. In some cases, particularly L2-IS-IS and MT,
they may be used with other protocols.
Value Mnemonic Explanation Reference
------ -------- --------------------- ---------
0x22F3 TRILL TRILL data [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>]
0x22F4 L2-IS-IS IS-IS [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>]
0x893B FGL Fine Grained Labeling [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>]
0x8946 - TRILL RBridge Channel [<a href="./rfc7178" title=""Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support"">RFC7178</a>]
0x9A22 MT Multi-Topology [<a href="./rfc8377">RFC8377</a>]
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
Multiple topologies are sometimes used for the isolation or security
of traffic. For example, if some links were more likely than others
to be subject to adversarial observation, it might be desirable to
classify certain sensitive traffic in a topology that excluded those
links.
Delivery of data originating in one topology outside of that topology
is generally a security policy violation to be avoided at all
reasonable costs. Using IS-IS security [<a href="./rfc5310" title=""IS-IS Generic Cryptographic Authentication"">RFC5310</a>] on all IS-IS PDUs
and link security appropriate to the link technology on all links
involved, particularly those between RBridges, supports the avoidance
of such violations.
For general TRILL security considerations, see [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>].
<span class="grey">Eastlake, et al. Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-IS-IS">IS-IS</a>] ISO/IEC 10589:2002, Second Edition, "Intermediate System
to Intermediate System Intra-Domain Routeing Exchange
Protocol for use in Conjunction with the Protocol for
Providing the Connectionless-mode Network Service (ISO
8473)", 2002.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5120">RFC5120</a>] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", <a href="./rfc5120">RFC 5120</a>,
DOI 10.17487/RFC5120, February 2008,
<<a href="https://www.rfc-editor.org/info/rfc5120">https://www.rfc-editor.org/info/rfc5120</a>>.
[<a id="ref-RFC5310">RFC5310</a>] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", <a href="./rfc5310">RFC 5310</a>, DOI 10.17487/RFC5310, February
2009, <<a href="https://www.rfc-editor.org/info/rfc5310">https://www.rfc-editor.org/info/rfc5310</a>>.
[<a id="ref-RFC6325">RFC6325</a>] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", <a href="./rfc6325">RFC 6325</a>, DOI 10.17487/RFC6325, July 2011,
<<a href="https://www.rfc-editor.org/info/rfc6325">https://www.rfc-editor.org/info/rfc6325</a>>.
[<a id="ref-RFC7172">RFC7172</a>] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", <a href="./rfc7172">RFC 7172</a>,
DOI 10.17487/RFC7172, May 2014,
<<a href="https://www.rfc-editor.org/info/rfc7172">https://www.rfc-editor.org/info/rfc7172</a>>.
[<a id="ref-RFC7176">RFC7176</a>] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS", <a href="./rfc7176">RFC 7176</a>,
DOI 10.17487/RFC7176, May 2014,
<<a href="https://www.rfc-editor.org/info/rfc7176">https://www.rfc-editor.org/info/rfc7176</a>>.
[<a id="ref-RFC7177">RFC7177</a>] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", <a href="./rfc7177">RFC 7177</a>, DOI 10.17487/RFC7177, May
2014, <<a href="https://www.rfc-editor.org/info/rfc7177">https://www.rfc-editor.org/info/rfc7177</a>>.
<span class="grey">Eastlake, et al. Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
[<a id="ref-RFC7178">RFC7178</a>] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
Ward, "Transparent Interconnection of Lots of Links
(TRILL): RBridge Channel Support", <a href="./rfc7178">RFC 7178</a>,
DOI 10.17487/RFC7178, May 2014,
<<a href="https://www.rfc-editor.org/info/rfc7178">https://www.rfc-editor.org/info/rfc7178</a>>.
[<a id="ref-RFC7357">RFC7357</a>] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
Stokes, "Transparent Interconnection of Lots of Links
(TRILL): End Station Address Distribution Information
(ESADI) Protocol", <a href="./rfc7357">RFC 7357</a>, DOI 10.17487/RFC7357,
September 2014, <<a href="https://www.rfc-editor.org/info/rfc7357">https://www.rfc-editor.org/info/rfc7357</a>>.
[<a id="ref-RFC7780">RFC7780</a>] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", <a href="./rfc7780">RFC 7780</a>, DOI 10.17487/RFC7780, February 2016,
<<a href="https://www.rfc-editor.org/info/rfc7780">https://www.rfc-editor.org/info/rfc7780</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC7175">RFC7175</a>] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
"Transparent Interconnection of Lots of Links (TRILL):
Bidirectional Forwarding Detection (BFD) Support", <a href="./rfc7175">RFC</a>
<a href="./rfc7175">7175</a>, DOI 10.17487/RFC7175, May 2014, <<a href="https://www.rfc-editor.org/info/rfc7175">https://www.rfc-</a>
<a href="https://www.rfc-editor.org/info/rfc7175">editor.org/info/rfc7175</a>>.
[<a id="ref-RFC8139">RFC8139</a>] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F.
Hu, "Transparent Interconnection of Lots of Links (TRILL):
Appointed Forwarders", <a href="./rfc8139">RFC 8139</a>, DOI 10.17487/RFC8139,
June 2017, <<a href="https://www.rfc-editor.org/info/rfc8139">https://www.rfc-editor.org/info/rfc8139</a>>.
<span class="grey">Eastlake, et al. Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Differences from <a href="./rfc5120">RFC 5120</a></span>
TRILL multi-topology, as specified in this document, differs from <a href="./rfc5120">RFC</a>
<a href="./rfc5120">5120</a> as follows:
1. [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>] provides for unicast multi-topology. This document
extends that to cover multi-destination TRILL data distribution
(see <a href="#section-3.4">Section 3.4</a>).
2. [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>] assumes the topology of data packets is always
determined implicitly, that is, based on the port over which the
packets are received and/or preexisting fields within the packet.
This document supports such implicit determination, but it extends
this by providing for optional explicit topology labeling of data
packets (see <a href="#section-2.4">Section 2.4</a>).
3. [<a href="./rfc5120" title=""M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"">RFC5120</a>] makes support of the default topology zero optional for
MT routers and links. For simplicity and ease in network
management, this document requires all TRILL switches and links
between TRILL switches to support topology zero (see <a href="#section-2.1">Section 2.1</a>).
Acknowledgements
The comments and contributions of the following are gratefully
acknowledged:
Vishwas Manral and Martin Vigoureux
<span class="grey">Eastlake, et al. Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc8377">RFC 8377</a> TRILL: Multi-Topology July 2018</span>
Authors' Addresses
Donald Eastlake 3rd
Huawei Technologies
1424 Pro Shop Court
Davenport, FL 33896
United States of America
Phone: +1-508-333-2270
Email: [email protected]
Mingui Zhang
Huawei Technologies Co., Ltd.
HuaWei Building, No.3 Xinxi Rd., Shang-Di
Information Industry Base, Hai-Dian District,
Beijing, 100085
China
Email: [email protected]
Ayan Banerjee
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: [email protected]
Eastlake, et al. Standards Track [Page 20]
Annotations
Select text to annotate