rfc9183xml2.original.xml   rfc9183.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbsp "&#160;">
C.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC6325 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.6325.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC7356 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7356.xml">
<!ENTITY RFC7357 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7357.xml">
<!ENTITY RFC7455 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7455.xml">
<!ENTITY RFC7780 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7780.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8397 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8397.xml">
<!ENTITY RFC5310 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5310.xml">
<!ENTITY RFC8243 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8243.xml">
]> ]>
<rfc submissionType="IETF" docName="draft-ietf-trill-multilevel-single-nickname-
17" category="std" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2021-11-17T00:47:52Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc toc="yes"?>
<front>
<title abbrev="Transparent Interconnection of Lots of L">Transparent Inte
rconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Mul
tilevel</title>
<author initials="M." surname="Zhang" fullname="Mingui Zhang">
<organization abbrev="Huawei">Huawei Technologies</organization>
<address><postal>
<street>No. 156 Beiqing Rd. Haidian District</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>zhangmingui@huawei.com</email>
</address>
</author>
<author initials="D." surname="Eastlake" fullname="Donald E. Eastlake, 3r <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-trill-multil
d"> evel-single-nickname-17" number="9183" submissionType="IETF" category="std" cons
<organization abbrev="Futurewei">Futurewei Technologies</organization> ensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="tr
<address><postal><street>2386 Panoramic Circle</street> ue" sortRefs="true" tocInclude="true" version="3">
<city>Apopka</city>
<region>FL</region>
<code>32703</code>
<country>United States of America</country>
</postal>
<phone>+1-508-333-2270</phone>
<email>d3e3e3@gmail.com</email>
</address>
</author>
<author initials="R." surname="Perlman" fullname="Radia Perlman">
<organization>EMC</organization>
<address><postal><street>2010 256th Avenue NE, #200</street>
<city>Bellevue</city>
<region>WA</region>
<code>98007</code>
<country>United States of America</country>
</postal>
<email>radia@alum.mit.edu</email>
</address>
</author>
<author initials="M." surname="Cullen" fullname="Margaret Cullen">
<organization>Painless Security</organization>
<address><postal><street>356 Abbott Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>United States of America</country>
</postal>
<phone>+1-781-405-7464</phone>
<email>margaret@painless-security.com</email>
<uri>https://www.painless-security.com</uri>
</address>
</author>
<author initials="H." surname="Zhai" fullname="Hongjun Zhai"> <front>
<organization abbrev="JIT">Jinling Institute of Technology</organization> <title abbrev="Single Nickname for Area Border RBridge in Multilevel
<address><postal><street>99 Hongjing Avenue, Jiangning District</street> TRILL">Single Nickname for an Area Border RBridge in Multilevel
<city>Nanjing</city> Transparent Interconnection of Lots of Links (TRILL)
<region>Jiangsu</region> </title>
<code>211169</code> <seriesInfo name="RFC" value="9183"/>
<country>China</country> <author initials="M." surname="Zhang" fullname="Mingui Zhang">
</postal> <organization abbrev="Independent">Independent</organization>
<email>honjun.zhai@tom.com</email> <address>
</address> <postal>
</author>
<date year="2021" month="November" /> <city>Beijing</city>
<!-- [rfced] Please insert any keywords (beyond those that appear in the title) <country>China</country>
for use on https://www.rfc-editor.org/search. --> </postal>
<email>zhangmingui@qq.com</email>
</address>
</author>
<author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake, 3
rd">
<organization abbrev="Futurewei">Futurewei Technologies</organization>
<address>
<postal>
<street>2386 Panoramic Circle</street>
<city>Apopka</city>
<region>FL</region>
<code>32703</code>
<country>United States of America</country>
</postal>
<phone>+1-508-333-2270</phone>
<email>d3e3e3@gmail.com</email>
</address>
</author>
<author initials="R." surname="Perlman" fullname="Radia Perlman">
<organization>EMC</organization>
<address>
<postal>
<street>2010 256th Avenue NE, #200</street>
<city>Bellevue</city>
<region>WA</region>
<code>98007</code>
<country>United States of America</country>
</postal>
<email>radia@alum.mit.edu</email>
</address>
</author>
<author initials="M." surname="Cullen" fullname="Margaret Cullen">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city>
<region>MA</region>
<code>01845</code>
<country>United States of America</country>
</postal>
<phone>+1-781-405-7464</phone>
<email>margaret@painless-security.com</email>
<uri>https://www.painless-security.com</uri>
</address>
</author>
<author initials="H." surname="Zhai" fullname="Hongjun Zhai">
<organization abbrev="JIT">Jinling Institute of Technology</organization>
<address>
<postal>
<street>99 Hongjing Avenue, Jiangning District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>211169</code>
<country>China</country>
</postal>
<email>honjun.zhai@tom.com</email>
</address>
</author>
<date year="2022" month="February"/>
<keyword>example</keyword> <keyword>aggregated</keyword>
<abstract><t> <abstract>
<t>
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 nicknames
but RBridges in different Level 1 areas may have the same nicknames.</t> but RBridges in different Level 1 areas may have the same nicknames.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
TRILL (Transparent Interconnection of Lots of Links <xref target="RFC6325"/> TRILL (Transparent Interconnection of Lots of Links) <xref target="RFC6325" f
<xref target="RFC7780"/>) multilevel techniques are designed to improve TRILL ormat="default"/>
<xref target="RFC7780" format="default"/> multilevel techniques are desi
gned to improve TRILL
scalability issues.</t> scalability issues.</t>
<t>
<t> "<xref target="RFC8243" format="title"/>" <xref target="RFC8243" format="defa
<xref target="RFC8243"/> (Alternatives for Multilevel Transparent Interconnec ult"/> is an educational
tion of document to explain multilevel TRILL and list possible concerns. It does
Lots of Links (TRILL)) is an educational document to explain not specify a protocol. As described in <xref target="RFC8243"
multilevel TRILL and list possible concerns. It does not specify a format="default"/>, there have been two proposed approaches. One approach,
protocol. As described in <xref target="RFC8243"/>, there have been two propo which is referred to as the "unique nickname" approach, gives unique
sed nicknames to all the TRILL switches in the multilevel campus either by
approaches. One approach, which is referred to as the "unique nickname" appro having the Level 1/Level 2 border TRILL switches advertise which nicknames
ach, gives unique nicknames to all the TRILL switches are not available for assignment in the area or by partitioning the 16-bit
in the multilevel campus, either by having the Level 1/Level 2 border nickname into an "area" field and a "nickname inside the area" field. <xref
TRILL switches advertise which nicknames are not available for target="RFC8397" format="default"/> is the Standards Track document
assignment in the area, or by partitioning the 16-bit nickname into specifying a "unique nickname" flavor of TRILL multilevel. The other
an "area" field and a "nickname inside the area" field. <xref target="RFC8397 approach, which is referred to in <xref target="RFC8243" format="default"/>
"/> is as the "aggregated nickname" approach, involves assigning nicknames to the
the standards track document specifying a "unique nickname" flavor of areas, and allowing nicknames to be reused inside different areas, by
TRILL multilevel. The other approach, which is referred to in having the border TRILL switches rewrite the nickname fields when entering
<xref target="RFC8243"/> as the "aggregated nickname" approach, involves assi or leaving an area. <xref target="RFC8243" format="default"/> makes the
gning
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. <xref target="RFC8243"/> ma
kes the
case that, while unique nickname multilevel solutions are simpler, case that, while unique nickname multilevel solutions are simpler,
aggregated nickname solutions scale better.</t> aggregated nickname solutions scale better.</t>
<t>
<t> 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 <xref target="RFC8243" forma
similar to the "aggregated nickname" approach in <xref target="RFC8243"/> but t="default"/> but with a
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 <bcp14>MUST</bcp14> be uniq ue 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 document
in one L1 area does not prohibit the use of other approaches in other 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 L1 areas in the same TRILL campus, for example the use of the unique
nickname approach specified in <xref target="RFC8397"/>. The TRILL packet for mat is nickname approach specified in <xref target="RFC8397" format="default"/>. The TRILL packet format is
unchanged by this document, but data plane processing is changed at unchanged by this document, but data plane processing is changed at
Border RBridges and efficient high volume data flow at Border Border RBridges and efficient high volume data flow at Border
RBridges might require forwarding hardware change.</t> RBridges might require forwarding hardware change.</t>
</section>
<section anchor="sect-2" numbered="true" toc="default">
</section> <name>Acronyms and Terminology</name>
<section title="Acronyms and Terminology" anchor="sect-2"><t>
Data Label: VLAN or FGL Fine-Grained Label (FGL).</t>
<t> <dl>
DBRB: Designated Border RBridge.</t> <dt>Area Border RBridge:
</dt>
<dd>A border RBridge between a Level 1 area and Level 2.
</dd>
<dt>Data Label:
</dt>
<dd>VLAN or Fine-Grained Label (FGL).
</dd>
<t> <dt>DBRB:
IS-IS: Intermediate System to Intermediate System [IS-IS].</t> </dt>
<dd>Designated Border RBridge.
</dd>
<t> <dt>IS-IS:
Level: Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 </dt>
for inter-area. Routing information is exchanged between Level 1 <dd>Intermediate System to Intermediate System <xref target="IS-IS"/>.
RBridges within the same Level 1 area, and Level 2 RBridges can only </dd>
form relationships and exchange information with other Level 2
RBridges.</t>
<t> <dt>Level:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", </dt>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <dd>Similar to IS-IS, TRILL has Level 1 for intra-area and Level&nbsp;2 f
"OPTIONAL" in this document are to be interpreted as described in BCP or
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the inter-area. Routing information is exchanged between Level 1 RBridges
y appear in all within the same Level 1 area, and Level 2 RBridges can only form
capitals, as shown here.</t> relationships and exchange information with other Level 2 RBridges.
</dd>
<t> </dl>
Familiarity with <xref target="RFC6325"/> is assumed in this document.</t>
</section> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Nickname Handling on Border RBridges" anchor="sect-3"><t> <t>
Familiarity with <xref target="RFC6325" format="default"/> is assumed in this
document.</t>
</section>
<section anchor="sect-3" numbered="true" toc="default">
<name>Nickname Handling on Border RBridges</name>
<t>
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.</t> border learning border RBridge nicknames.</t>
<figure anchor="fig-1">
<figure title="An Example Topology for TRILL Multilevel" anchor="fig-1">< <name>An Example Topology for TRILL Multilevel</name>
artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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--- |
+-------------------+ +-----------------+ +--------------+ +-------------------+ +-----------------+ +--------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In Figure 1, RB2, RB20, RB3 and RB30 are area border TRILL switches In <xref target="fig-1"/>, RB2, RB20, RB3, and RB30 are area border TRILL swi
(RBridges). Their nicknames are 2, 20, 3 and 30 respectively and are tches
used as TRILL switch identifiers in their areas <xref target="RFC6325"/>. Are (RBridges). Their nicknames are 2, 20, 3, and 30, respectively, and are
a used as TRILL switch identifiers in their areas <xref target="RFC6325" format
="default"/>. 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.</t> {2,20} to denote the L1 area on the left.</t>
<t>
<t>
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, 44).
(and in fact, they could even have the same nickname, since the TRILL (In fact, they could even have the same nickname, since the TRILL
switch nickname will not be visible outside these Level 1 areas).</t> switch nickname will not be visible outside these Level 1 areas.)</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<section title="Actions on Unicast Packets" anchor="sect-3.1"><t> <name>Actions on Unicast Packets</name>
<t>
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:</t> already. These relevant switches have learned the following:</t>
<ol spacing="normal" type="%d)"><li>RB27 has learned that D is connected
to nickname 3.</li>
<li>RB3 has learned that D is attached to nickname 44.</li>
</ol>
<t>
The following sequence of events will occur:
<t><list style="format (%d)"> </t>
<t>RB27 has learned that D is connected to nickname 3.</t>
<t>RB3 has learned that D is attached to nickname 44.</t> <ol>
</list> <li>S transmits an Ethernet frame with source MAC = S and destination MAC =
</t> D.
</li>
<t> <li>RB27 encapsulates with a TRILL header with ingress RBridge = 27 and
The following sequence of events will occur: egress RBridge = 3 producing a TRILL Data packet.
</li>
<list style="symbols"> <li>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).
</li>
<t>S transmits an Ethernet frame with source MAC = S and destination <li>RB2, when transitioning the packet from Level 1 to Level 2, replaces
MAC = D.</t> 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 <bcp14>MAY</bcp14> be replaced with any area nickname selected
from {3,30} such as 30. See <xref target="sect-4"/> 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 <bcp14>SHOULD</bcp14> synchronize with RB20 using the
End Station Address Distribution Information (ESADI) protocol <xref
target="RFC7357"/> that MAC = S is attached to nickname 27.
</li>
<t>RB27 encapsulates with a TRILL header with ingress RBridge = 27, <li>The packet is forwarded through Level 2, to RB3, which has
and egress RBridge = 3 producing a TRILL Data packet.</t> advertised, in Level 2, its L2 nickname as 3.
</li>
<t>RB2 and RB20 have announced in the Level 1 IS-IS area designated <li>RB3, when forwarding into area {3,30}, replaces the egress nickname
{2,20}, that they are attached to the nicknames of all the border in the TRILL header with RB44's nickname (44) based on looking up
RBridges in the Level 2 area including RB3 and RB30. Therefore, IS-IS D. (The ingress nickname <bcp14>MAY</bcp14> be replaced with any area
routes the packet to RB2 (or RB20, if RB20 on the least-cost route from nickname selected from {2,20}. See <xref target="sect-4"/> for the
RB27 to RB3).</t> 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.
</li>
<t>RB2, when transitioning the packet from Level 1 to Level 2, replaces <li>RB44, when decapsulating, learns that S is attached to
the ingress TRILL switch nickname with its own nickname, replacing 27 nickname 2, which is one of the area nicknames of the
with 2. Within Level 2, the ingress RBridge field in the TRILL header ingress.
will therefore be 2, and the egress RBridge field will be 3. (The egress </li>
nickname MAY be replaced with any area nickname selected from {3,30} such
as 30. See Section 4 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 ESADI protocol [RFC7357] that MAC = S
is attached to nickname 27.</t>
<t>The packet is forwarded through Level 2, to RB3, which has advertised, </ol>
in Level 2, its L2 nickname as 3.</t>
<t>RB3, when forwarding into area {3,30}, replaces the egress nickname in </section>
the TRILL header with RB44's nickname (44) based on looking up D. (The <section anchor="sect-3.2" numbered="true" toc="default">
ingress nickname MAY be replaced with any area nickname selected from <name>Actions on Multi-destination Packets</name>
{2,20}. See Section 4 for the detail of the selection method. Here, <t>
suppose the ingress nickname remains 2.) So, within the destination Distribution trees for flooding of multi-destination packets are calculated
area, the ingress nickname will be 2 and the egress nickname will be 44.</t 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 <bcp14>MUST</bcp14> 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
<bcp14>MUST</bcp14> 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 <xref target="sect-4"
format="default"/> for load balancing.</t>
<t>
As per <xref target="RFC6325" format="default"/>,
<t>RB44, when decapsulating, learns that S is attached to nickname 2, multi-destination packets can be classified into three types: unicast
which is one of the area nicknames of the ingress.</t> 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).
</list>
</t> </t>
</section> <t>
<section title="Actions on Multi-Destination Packets" anchor="sect-3.2"><
t>
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 <xref target="sect-4"/>
for
load balancing.</t>
<t>
As per <xref target="RFC6325"/>, multi-destination packets can be classified
into
three types: unicast packet with unknown destination MAC address
(unknown-unicast packet), multicast packet and broadcast packet. 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, flooding the packet on the distribution
tree, subject to possible pruning.</t>
<t>
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 <bcp14>MUST</bcp14> 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 destination
MAC address, it SHOULD convert the packet to unicast and set its M MAC address, it <bcp14>SHOULD</bcp14> convert the packet to unicast and set i
ts M
bit to 0. Otherwise, the multi-destination packet will continue to be bit to 0. Otherwise, the multi-destination packet will continue to be
flooded as multicast packet on the distribution tree. The DBRB flooded as a multicast packet on the distribution tree. The DBRB
chooses the new distribution tree by replacing the egress nickname chooses the new distribution tree by replacing the egress nickname
with the new tree root RBridge nickname from the area the packet is with the new tree root RBridge nickname from the area the packet is
entering. The following sequence of events will occur:</t> entering. The following sequence of events will occur:</t>
<t><list style="symbols"><t>RB2, when transitioning the packet from Level <ol>
1 to Level 2, <li>RB2, when transitioning the packet from Level 1 to Level 2, replaces
replaces the ingress TRILL switch nickname with its own nickname, the ingress TRILL switch nickname with its own nickname, replacing 27
replacing 27 with 2. RB2 also MUST replace the egress RBridge with 2. RB2 also <bcp14>MUST</bcp14> replace the egress RBridge nickname
nickname with an L2 tree root RBridge nickname (say 39). In order with an L2 tree root RBridge nickname (say, 39). In order to accommodate
to accommodate return traffic, RB2 records that S is attached to return traffic, RB2 records that S is attached to nickname 27 and
nickname 27 and SHOULD use the ESADI protocol <xref target="RFC7357"/> to <bcp14>SHOULD</bcp14> use the ESADI protocol <xref target="RFC7357"
synchronize this attachment information with other border RBridges format="default"/> to synchronize this attachment information with other
(say RB20) in the area.</t> border RBridges (say, RB20) in the area.
</li>
<t>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.</t>
<t>The multidestination 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.</t>
<t>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 <xref target="sect-4"/>.) 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 re-started or some other reason. In that case, RB3 must turn
the packet into a multi-destination packet and floods it on a
distribution tree in the L1 area {3,30}.</t>
<t>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.</t>
<t>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.</t>
</list> <li>RB20 will receive the packet flooded on the L2 tree by RB2. It
</t> 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.
</li>
<t> <li>The multi-destination packet is flooded on the Level 2 tree
See also Appendix A.</t> 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.
</li>
</section> <li>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 <bcp14>MAY</bcp14> be
replaced with a different area nickname selected from
{2,20}, the set of border RBridges to the ingress area, as
specified in <xref target="sect-4" format="default"/>.)
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}.
</li>
</section> <li>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.
</li>
<section title="Per-flow Load Balancing" anchor="sect-4"><t> <li>The multicast listener RB44, when
Area border RBridges perform ingress/egress nickname replacement when decapsulating the received packet, learns that S
they transition TRILL data packets between Level 1 and Level 2. The is attached to nickname 2, which is one of the
egress nickname will again be replaced when the packet transitions area nicknames of the ingress.
from Level 2 to Level 1. This nickname replacement enables the per- </li>
flow load balance which is specified in the following subsections. </ol>
The mechanism specified in Setion 4.1 or that in 4.2 or both is
necessary in general to load balance traffic across L2 paths.</t>
<section title="L2 to L1 Ingress Nickname Replacement" anchor="sect-4.1" <t>
><t> See also <xref target="sect-a"/>.</t>
When a TRILL data packet from other L1 areas arrives at an area </section>
border RBridge, this RBridge MAY select one area nickname of the </section>
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 Section 5.3 of <xref target="RFC7357"/>. With the random ingress
nickname replacement, the border RBridge actually achieves a per-flow
load balance for returning traffic.</t>
<t> <section anchor="sect-4" numbered="true" toc="default">
All area border RBridges for an L1 area MUST agree on the same <name>Per-Flow Load Balancing</name>
<t>
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
<xref target="sect-4.1"/> or that in <xref target="sect-4.2"/> or both is nec
essary in general to load-balance traffic
across L2 paths.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<name>L2-to-L1 Ingress Nickname Replacement</name>
<t>
When a TRILL Data packet from other L1 areas arrives at an area border
RBridge, this RBridge <bcp14>MAY</bcp14> 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 <xref
target="RFC7357" sectionFormat="of" section="5.3" format="default"/>. With
the random ingress nickname replacement, the border RBridge actually
achieves a per-flow load balance for returning traffic.</t>
<t>
All area border RBridges for an L1 area <bcp14>MUST</bcp14> 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 <bcp14>SHOULD</bcp14> 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.</t> address flip-flopping among multiple ingress RBridges.</t>
</section>
</section> <section anchor="sect-4.2" numbered="true" toc="default">
<name>L1-to-L2 Egress Nickname Replacement</name>
<section title="L1 to L2 Egress Nickname Replacement" anchor="sect-4.2">< <t>
t> When a unicast TRILL Data packet originated from an L1 area arrives at an
When a unicast TRILL data packet originated from an L1 area arrives area border RBridge of that L1 area, that RBridge <bcp14>MAY</bcp14> 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 of the
one area nickname of the egress area to replace the egress nickname packet. By default, it <bcp14>SHOULD</bcp14> 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 equal
RBridge with the least cost route to reach or, if there are multiple cost egress area border RBridges, use the pseudorandom algorithm as defined
equal cost egress area border RBridges, use the pseudorandom in <xref target="RFC7357" sectionFormat="of" section="5.3"
algorithm as defined in Section 5.3 of <xref target="RFC7357"/> to select one format="default"/> to select one. The use of that algorithm
. The <bcp14>MAY</bcp14> be extended to selection among some stable set of egress
use of that algorithm MAY be extended to selection among some stable area border RBridges that include non-least-cost alternatives if it is
set of egress area border RBridges that include non-least-cost desired to obtain more load spreading at the cost of sometimes using a
alternatives if it is desired to obtain more load spreading at the non-least-cost Level 2 route to forward the TRILL Data packet to the egress
cost of sometimes using a non-least-cost Level 2 route to forward the area.</t>
TRILL data packet to the egress area.</t> </section>
</section>
</section> <section anchor="sect-5" numbered="true" toc="default">
<name>Protocol Extensions for Discovery</name>
</section> <t>
<section title="Protocol Extensions for Discovery" anchor="sect-5"><t>
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:</t> processes as defined in Sections <xref target="sect-5.1" format="counter"/> a
nd <xref target="sect-5.2" format="counter"/>:</t>
<t><list style="symbols"><t>A new node comes up or recovers from a previo <ul spacing="normal">
us failure.</t> <li>A new node comes up or recovers from a previous failure.</li>
<li>A node goes down.</li>
<t>A node goes down.</t> <li>A link or node fails and causes partition of an L1/L2 area.</li>
<li>A link or node whose failure has caused partitioning of an L1/L2
<t>A link or node fails and causes partition of an L1/L2 area.</t> area is repaired.</li>
</ul>
<t>A link or node whose failure have caused partitioning of an L1/L2 <section anchor="sect-5.1" numbered="true" toc="default">
area is repaired.</t> <name>Discovery of Border RBridges in L1</name>
<t>
</list> The following Level 1 Border RBridge APPsub-TLV will be included in E-L1FS
</t> FS-LSP fragment zero <xref target="RFC7780" format="default"/> as an
APPsub-TLV of the TRILL GENINFO-TLV. Through listening for this APPsub-TLV,
<section title="Discovery of Border RBridges in L1" anchor="sect-5.1"><t> an area border RBridge discovers all other area border RBridges in this
The following Level 1 Border RBridge APPsub-TLV will be included in area.</t>
an E-L1FS FS-LSP fragment zero <xref target="RFC7780"/> as an APPsub-TLV of t <artwork name="" type="" align="left" alt=""><![CDATA[
he
TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an area
border RBridge discovers all other area border RBridges in this area.</t>
<figure><artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>
<t><list style="symbols"><t>Type: Level 1 Border RBridge (TRILL APPsub-TL
V type tbd1)</t>
<t>Length: 2</t> <dl>
<dt>Type:
<t>Sender Nickname: The nickname the originating IS will use as the </dt>
L1 Border RBridge nickname. This field is useful because the <dd>Level 1 Border RBridge (TRILL APPsub-TLV type 256)
originating IS might own multiple nicknames.</t> </dd>
</list> <dt>Length:
</t> </dt>
<dd>2
</dd>
</section> <dt>Sender Nickname:
</dt>
<dd>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.
</dd>
</dl>
<section title="Discovery of Border RBridge Sets in L2" anchor="sect-5.2" </section>
><t> <section anchor="sect-5.2" numbered="true" toc="default">
<name>Discovery of Border RBridge Sets in L2</name>
<t>
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 <xref target="RFC7780"/> as an APPsub-TLV of the TRILL GENINFO- TLV. fragment zero <xref target="RFC7780" format="default"/> as an APPsub-TLV of t he 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.</t> identifies an area.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>
<t><list style="symbols"><t>Type: Level 1 Border RBridge Group (TRILL APP
sub-TLV type tbd2)</t>
<t>Length: 2 * k. If length is not a multiple of 2, the APPsub-TLV is <dl>
corrupt and MUST be ignored.</t> <dt>Type:
</dt>
<t>L1 Border RBridge Nickname: The nickname that an area border <dd>Level 1 Border RBridge Group (TRILL APPsub-TLV type 257)
RBridge uses as the L1 Border RBridge nickname. The L1-BORDER-RB- </dd>
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.</t>
</list>
</t>
<t> <dt>Length:
When an L1 area is partitioned <xref target="RFC8243"/>, border RBridges will </dt>
re- <dd>2 * k. If length is not a multiple of 2, the APPsub-TLV is corrupt and
discover each other in both L1 and L2 through exchanging LSPs. In L2, <bcp14>MUST</bcp14> be ignored.
the set of border RBridge nicknames for this splitting area will </dd>
change. Border RBridges that detect such a change MUST flush the
reachability information associated to any RBridge nickname from this
changing set.</t>
</section> <dt>L1 Border RBridge Nickname:
</dt>
<dd>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
<bcp14>MUST</bcp14> include all L1 Border RBridge Nicknames of the area. It's
<bcp14>RECOMMENDED</bcp14> that these k nicknames are ordered in ascending
order according to the 2-octet nickname considered as an unsigned integer.
</dd>
</section> </dl>
<section title="One Border RBridge Connects Multiple Areas" anchor="sect- <t>
6"><t> When an L1 area is partitioned <xref target="RFC8243" format="default"/>,
It's possible that one border RBridge (say RB1) connects multiple L1 border RBridges will re-discover each other in both L1 and L2 through
areas. RB1 SHOULD use a single area nickname for itself for all these exchanging LSPs. In L2, the set of border RBridge nicknames for this
areas to minimize nickname consumption and the number of nicknames splitting area will change. Border RBridges that detect such a change
being advertised in L2; however, such a border RBridge might have to <bcp14>MUST</bcp14> flush the reachability information associated to any
hold multiple nicknames, for example it might the root of multiple L1 RBridge nickname from this changing set.</t>
or multiple L2 distribution trees.</t> </section>
</section>
<section anchor="sect-6" numbered="true" toc="default">
<name>One Border RBridge Connects Multiple Areas</name>
<t>
It's possible that one border RBridge (say, RB1) connects multiple L1
areas. RB1 <bcp14>SHOULD</bcp14> 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.</t>
<t> <t>
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
other areas. It's important that packets destined to those duplicated areas. It's important that packets destined to those duplicated nicknames
nicknames are sent to the right area. Since these areas are connected are sent to the right area. Since these areas are connected to form a layer
to form a layer 2 network, duplicated {MAC, Data Label} across these 2 network, duplicated {MAC, Data Label} across these areas <bcp14>SHOULD
areas SHOULD NOT occur (see Section 4.2.6 of <xref target="RFC6325"/> for tie NOT</bcp14> occur (see <xref target="RFC6325" section="4.2.6"
breaking rules). Now suppose a TRILL data packet arrives at the area sectionFormat="of" format="default"/> for tie breaking rules). Now suppose
border nickname of RB1. For a unicast packet, RB1 can look up the a TRILL Data packet arrives at the area border nickname of RB1. For a
{MAC, Data Label} entry in its MAC table to identify the right unicast packet, RB1 can look up the {MAC, Data Label} entry in its MAC
destination area (i.e., the outgoing interface) and the egress table to identify the right destination area (i.e., the outgoing interface)
RBridge's nickname. For a multicast packet for each attached L1 and the egress RBridge's nickname. For a multicast packet for each
area: either RB1 is not the DBRB and RB1 will not transition the attached L1 area: either RB1 is not the DBRB and RB1 will not transition
packet or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows the the packet, or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows the
following rules:</t> following rules:</t>
<ul spacing="normal">
<t><list style="symbols"><t>if this packet originated from an area out of <li>If this packet originated from an area out of the connected areas,
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.</t> trees of all the areas in which it acts as the DBRB.</li>
<li>If the packet originated from one of the connected areas, RB1
<t>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 replication
of the packet from the Level 2 tree. This replication MUST be of the packet from the Level 2 tree. This replication <bcp14>MUST</bcp14> be
dropped by RB1. It recognizes such packets by their ingress dropped by RB1. It recognizes such packets by their ingress
nickname being the nickname of one of the border RBridges of an L1 nickname being the nickname of one of the border RBridges of an L1
area for which the receiving border RBridge is DBRB.</t> area for which the receiving border RBridge is DBRB.</li>
</ul>
</list> </section>
</t>
</section>
<section title="E-L1FS/E-L2FS Backwards Compatibility" anchor="sect-7"><t
>
All Level 2 RBridges MUST support E-L2FS <xref target="RFC7356"/> <xref targe
t="RFC7780"/>. The
Extended TLVs defined in <xref target="sect-5"/> are to be used in Extended L
evel
1/2 Flooding Scope (E-L1FS/E-L2FS) 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.</t>
</section> <section anchor="sect-7" numbered="true" toc="default">
<name>E-L1FS/E-L2FS Backwards Compatibility</name>
<section title="Manageability Considerations" anchor="sect-8"><t> <t>
All Level 2 RBridges <bcp14>MUST</bcp14> support E-L2FS <xref
target="RFC7356" format="default"/> <xref target="RFC7780"
format="default"/>. The Extended TLVs defined in <xref target="sect-5"
format="default"/> are to be used in Extended Level 1/2 Flooding Scope
(E-L1FS/E-L2FS) Protocol Data Units (PDUs). Area border RBridges
<bcp14>MUST</bcp14> 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.</t>
</section>
<section anchor="sect-8" numbered="true" toc="default">
<name>Manageability Considerations</name>
<t>
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
specified in this document is turned on for that RBridge and it in this document is turned on for that RBridge and normally uses an L2
normally uses an L2 nickname in both L1 and L2 although, as provided nickname in both L1 and L2 although, as provided below, such an RBridge may
below, such an RBridge may have to fall back to multilevel unique have to fall back to multilevel unique nickname behavior <xref
nickname behavior <xref target="RFC8397"/> in which case it uses this L1 nick target="RFC8397" format="default"/>, in which case it uses this L1 nickname.
name. In contrast, unique nickname multilevel as specified in <xref
In contrast, unique nickname multilevel as specified in <xref target="RFC8397 target="RFC8397" format="default"/> is enabled by the presence of L1 and L2
"/> is adjacencies without an L1 Border RBridge Nickname being configured.
enabled by the presence of L1 and L2 adjacencies without an L1 Border RBridges supporting only unique nickname multilevel do not support the
RBridge Nickname being configured. RBridges supporting only unique configuration of an L2 Border RBridge Nickname. RBridges supporting only
nickname multilevel do not support the configuration of an L2 Border the single-level TRILL base protocol specified in <xref target="RFC6325"
RBridge Nickname. RBridges supporting only the single level TRILL format="default"/> do not support L2 adjacencies.</t>
base protocol specified in <xref target="RFC6325"/> do not support L2 adjacen
cies.</t>
<t> <t>
RBridges that support and are configured to use single nickname RBridges that support and are configured to use single nickname multilevel
multilevel as specified in this document MUST support unique nickname as specified in this document <bcp14>MUST</bcp14> support unique nickname
multilevel (<xref target="RFC8397"/>). If there are multiple border RBridges multilevel <xref target="RFC8397" format="default"/>. If there are
between an L1 area and L2 and one or more of them only support or are multiple border RBridges between an L1 area and L2, and one or more of them
only configured for unique nickname multilevel (<xref target="RFC8397"/>), an only support or are only configured for unique nickname multilevel <xref
y of target="RFC8397" format="default"/>, any of these border RBridges that are
these border RBridges that are configured to use single nickname configured to use single nickname multilevel <bcp14>MUST</bcp14> fall back
multilevel MUST fall back to behaving as a unique nickname border to behaving as a unique nickname border RBridge for that L1 area. Because
RBridge for that L1 area. Because overlapping sets of RBridges may be overlapping sets of RBridges may be the border RBridges for different L1
the border RBridges for different L1 areas, an RBridge supporting areas, an RBridge supporting single nickname <bcp14>MUST</bcp14> be able to
single nickname MUST be able to simultaneously support single simultaneously support single nickname for some of its L1 areas and unique
nickname for some of its L1 areas and unique nickname for others. For nickname for others. For example, RB1 and RB2 might be border RBridges for
example, RB1 and RB2 might be border RBridges for L1 area A1 using L1 area A1 using single nickname while RB2 and RB3 are border RBridges for
single nickname while RB2 and RB3 are border RBridges for area A2. If area A2. If RB3 only supports unique nicknames, then RB2 must fall back to
RB3 only supports unique nicknames then RB2 must fall back to unique unique nickname for area A2 but continue to support single nickname for
nickname for area A2 but continue to support single nickname for area area A1. Operators <bcp14>SHOULD</bcp14> be notified when this fallback
A1. Operators SHOULD be notified when this fall back occurs. The occurs. The presence of border RBridges using unique nickname multilevel
presence of border RBridges using unique nickname multilevel can be 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.</t> available within that L1 area.</t>
<t>
<t> In both the unique nickname approach specified in <xref target="RFC8397"
In both the unique nickname approach specified in <xref target="RFC8397"/> an format="default"/> and the single nickname aggregated approach specified in
d the this document, an RBridge that has L1 and L2 adjacencies uses the same
single nickname aggregated approach specified in this document, an nickname in L1 and L2. If an RBridge is configured with an L1 Border
RBridge that has L1 and L2 adjacencies uses the same nickname in L1 RBridge Nickname for any a Level 1 area, it uses this nickname across the
and L2. If an RBridge is configured with an L1 Border RBridge Level 2 area. This L1 Border RBridge Nickname cannot be used in any other
Nickname for any a Level 1 area, it uses this nickname across the Level 1 area except other Level 1 areas for which the same RBridge is a
Level 2 area. This L1 Border RBridge Nickname cannot be used in any border RBridge with this L1 Border RBridge Nickname configured.</t>
other Level 1 area except other Level 1 areas for which the same <t>
RBridge is a border RBridge with this L1 Border RBridge Nickname
configured.</t>
<t>
In addition to the manageability considerations specified above, the In addition to the manageability considerations specified above, the
manageability specifications in <xref target="RFC6325"/> still apply.</t> manageability specifications in <xref target="RFC6325" format="default"/>
still apply.</t>
<t> <t>
Border RBridges replace ingress and/or egress nickname when a TRILL Border RBridges replace ingress and/or egress nickname when a TRILL Data
data packet traverses TRILL L2 area. A TRILL OAM message will be packet traverses a TRILL L2 area. A TRILL Operations, Administration, and
forwarded through the multilevel single nickname TRILL campus using a Maintenance (OAM) message will be forwarded through the multilevel single
MAC address belonging to the destination RBridge <xref target="RFC7455"/>.</t nickname TRILL campus using a MAC address belonging to the destination
> RBridge <xref target="RFC7455" format="default"/>.</t>
</section>
</section> <section anchor="sect-9" numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations" anchor="sect-9"><t> <t>
For general TRILL Security Considerations, see <xref target="RFC6325"/>.</t> For general TRILL Security Considerations, see <xref target="RFC6325"
format="default"/>.</t>
<t> <t>
The newly defined TRILL APPsub-TLVs in <xref target="sect-5"/> are transporte The newly defined TRILL APPsub-TLVs in <xref target="sect-5"
d in format="default"/> are transported in IS-IS PDUs whose authenticity can be
IS-IS PDUs whose authenticity can be enforced using regular IS-IS enforced using regular IS-IS security mechanism <xref target="IS-IS"/>
security mechanism [IS-IS] <xref target="RFC5310"/>. Malicious devices may al <xref target="RFC5310" format="default"/>. Malicious devices may also fake
so fake the APPsub-TLVs to attract TRILL Data packets, interfere with multilevel
the APPsub-TLVs to attract TRILL data packets, interfere with TRILL operation, induce excessive state in TRILL switches (or in any
multilevel TRILL operation, induce excessive state in TRILL switches bridges that may be part of the TRILL campus), etc. For this reason,
(or in any bridges that may be part of the TRILL campus), etc. For RBridges <bcp14>SHOULD</bcp14> 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 <xref
Authentication TLV (10) in their IS-IS PDUs so that IS-IS security target="RFC5310" format="default"/> can be used to authenticate those PDUs
<xref target="RFC5310"/> can be used to authenticate those PDUs and discard t and discard them if they are forged.</t>
hem if <t>
they are forged.</t>
<t>
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
a TRILL Data packet being delivered to the wrong egress RBridge if TRILL Data packet being delivered to the wrong egress RBridge if areas are
areas are unexpectedly merged as compared with a scheme were all unexpectedly merged as compared with a scheme where all nicknames in the
nicknames in the TRILL campus are, except as a transient condition, TRILL campus are, except as a transient condition, unique such as the
unique such as the scheme in <xref target="RFC8397"/>. However, in many cases scheme in <xref target="RFC8397" format="default"/>. However, in many
the cases, the data would be discarded at that egress RBridge because it would
data would be discarded at that egress RBridge because it would not not match a known end station Data Label / MAC address.</t>
match a known end station data label/MAC address.</t> </section>
<section anchor="sect-10" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<t>
<section title="IANA Considerations" anchor="sect-10"><t> IANA has allocated two new types under the TRILL GENINFO TLV
IANA is requested to allocate two new types under the TRILL GENINFO <xref target="RFC7357" format="default"/> from the range allocated by
TLV <xref target="RFC7357"/> from the range allocated by standards action for Standards Action <xref target="RFC8126"/> for the TRILL APPsub-TLVs defined i
the n <xref target="sect-5"
TRILL APPsub-TLVs defined in <xref target="sect-5"/>. The following entries a format="default"/>. The following entries have been added to the "TRILL
re APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on
added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifi the TRILL Parameters IANA web page.</t>
er 1" Registry on the TRILL Parameters IANA web page.</t>
<figure><artwork><![CDATA[
Type Name Reference
--------- ---- ---------
tbd1[256] L1-BORDER-RBRIDGE [This document]
tbd2[257] L1-BORDER-RB-GROUP [This document]
]]></artwork>
</figure>
</section>
</middle> <table anchor="IANA">
<name></name>
<thead>
<tr>
<th>Type</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>256</td>
<td>L1-BORDER-RBRIDGE</td>
<td>RFC 9183</td>
</tr>
<tr>
<td>257</td>
<td>L1-BORDER-RB-GROUP</td>
<td>RFC 9183</td>
</tr>
</tbody>
</table>
<back> </section>
<references title="Normative References"> </middle>
&RFC2119; <back>
&RFC6325; <references>
&RFC7356; <name>References</name>
&RFC7357; <references>
&RFC7455; <name>Normative References</name>
&RFC7780; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8174; FC.2119.xml"/>
&RFC8397; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</references> FC.6325.xml"/>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7356.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7357.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7455.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7780.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8397.xml"/>
</references>
<references>
<name>Informative References</name>
<!-- <reference anchor="IS-IS">
draft-ietf-trill-multilevel-single-nickname-17-manual.txt(612): Warning: Fail <front>
ed <title>Information technology -- Telecommunications and
parsing a reference. Are all elements separated by commas (not periods, not information exchange between systems -- Intermediate System to
just spaces)?: Intermediate System intra-domain routeing information exchange
[IS-IS] International Organization for Standardization, ISO/IEC protocol for use in conjunction with the protocol for providing
10589:2002, "Information technology - Telecommunications the connectionless-mode network service (ISO 8473)</title>
and information exchange between systems - Intermediate <author>
System to Intermediate System intra-domain routeing <organization>International Organization
information exchange protocol for use in conjunction with for Standardization</organization>
the protocol for providing the connectionless-mode network </author>
service", ISO 8473, Second Edition, November 2002. <date year="2002" month="November"/>
--> </front>
<refcontent>ISO 8473</refcontent>
<refcontent>ISO/IEC 10589:2002</refcontent>
<refcontent>Second Edition</refcontent>
</reference>
&RFC5310; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
&RFC8243; C.5310.xml"/>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<section title="Level Transition Clarification" anchor="sect-a"><t> FC.8243.xml"/>
</references>
</references>
<section anchor="sect-a" numbered="true" toc="default">
<name>Level Transition Clarification</name>
<t>
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.</t> tree.</t>
<t>
<t>
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.</t> RB30.</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
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
]]></artwork> ]]></artwork>
</figure> <t>
In the above example, the multicast packet is forwarded along a non-optimal
<t> path. A possible improvement is to have RB3 configured not to belong to
In the above example, the multicast packet is forwarded along a non- this area. In this way, RB30 will surely act as the DBRB to do the Level
optimal path. A possible improvement is to have RB3 configured not to transition.</t>
belong to this area. In this way, RB30 will surely act as the DBRB to </section>
do the Level transition.</t>
</section>
</back>
</rfc> </back>
</rfc>
 End of changes. 90 change blocks. 
627 lines changed or deleted 660 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/