<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC6325 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6325.xml">zwsp "​"> <!ENTITYRFC7356 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7356.xml">nbhy "‑"> <!ENTITYRFC7357 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7357.xml"> <!ENTITY RFC7455 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7455.xml"> <!ENTITY RFC7780 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7780.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8397 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8397.xml"> <!ENTITY RFC5310 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"> <!ENTITY RFC8243 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8243.xml">wj "⁠"> ]> <rfcsubmissionType="IETF"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-trill-multilevel-single-nickname-17" number="9183" submissionType="IETF" 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"?>consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3"> <front> <titleabbrev="Transparent Interconnection of Lots of L">Transparentabbrev="Single Nickname for Area Border RBridge in Multilevel TRILL">Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)Single Area Border RBridge Nickname for Multilevel</title></title> <seriesInfo name="RFC" value="9183"/> <author initials="M." surname="Zhang" fullname="Mingui Zhang"> <organizationabbrev="Huawei">Huawei Technologies</organization> <address><postal> <street>No. 156 Beiqing Rd. Haidian District</street>abbrev="Independent">Independent</organization> <address> <postal> <city>Beijing</city><code>100095</code><country>China</country> </postal><email>zhangmingui@huawei.com</email><email>zhangmingui@qq.com</email> </address> </author> <author initials="D."surname="Eastlake"surname="Eastlake 3rd" fullname="Donald E. Eastlake, 3rd"> <organization abbrev="Futurewei">Futurewei Technologies</organization><address><postal><street>2386<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<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<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<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> <dateyear="2021" month="November" /> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><t>year="2022" month="February"/> <keyword>aggregated</keyword> <abstract> <t> A major issue in multilevel TRILL is how to manage RBridge nicknames. In this document, area border RBridges use a single nickname in both Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames.</t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="sect-1"><t>anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <t> TRILL (Transparent Interconnection of Lots ofLinksLinks) <xreftarget="RFC6325"/>target="RFC6325" format="default"/> <xreftarget="RFC7780"/>)target="RFC7780" format="default"/> multilevel techniques are designed to improve TRILL scalability issues.</t> <t> "<xref target="RFC8243" format="title"/>" <xreftarget="RFC8243"/> (Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL))target="RFC8243" format="default"/> is an educational document to explain multilevel TRILL and list possible concerns. It does not specify a protocol. As described in <xreftarget="RFC8243"/>,target="RFC8243" format="default"/>, there have been two proposed approaches. One approach, which is referred to as the "unique nickname" approach, gives unique nicknames to all the TRILL switches in the multilevelcampus,campus either by having the Level 1/Level 2 border TRILL switches advertise which nicknames are not available for assignment in thearea,area or by partitioning the 16-bit nickname into an "area" field and a "nickname inside the area" field. <xreftarget="RFC8397"/>target="RFC8397" format="default"/> is thestandards trackStandards Track document specifying a "unique nickname" flavor of TRILL multilevel. The other approach, which is referred to in <xreftarget="RFC8243"/>target="RFC8243" format="default"/> as the "aggregated nickname" approach, involves assigning nicknames to the areas, and allowing nicknames to be reused inside different areas, by having the border TRILL switches rewrite the nickname fields when entering or leaving an area. <xreftarget="RFC8243"/>target="RFC8243" format="default"/> makes the case that, while unique nickname multilevel solutions are simpler, aggregated nickname solutions scale better.</t> <t> The approach specified in thisstandards trackStandards Track document is somewhat similar to the "aggregated nickname" approach in <xreftarget="RFC8243"/>target="RFC8243" format="default"/> but with a very important difference. In this document, the nickname of an area border RBridge is used in both Level 1 (L1) and Level 2 (L2). No additional nicknames are assigned to represent L1 areas as such. Instead, multiple border RBridges are allowed and each L1 area is denoted by the set of all nicknames of those border RBridges of the area. For this approach, nicknames in the L2 areaMUST<bcp14>MUST</bcp14> be unique but nicknames inside an L1 area can be reused in other L1 areas that also use this approach. The use of the approach specified in this document in one L1 area does not prohibit the use of other approaches in other L1 areas in the same TRILL campus, for example the use of the unique nickname approach specified in <xreftarget="RFC8397"/>.target="RFC8397" format="default"/>. The TRILL packet format is unchanged by this document, but data plane processing is changed at Border RBridges and efficient high volume data flow at Border RBridges might require forwarding hardware change.</t> </section> <sectiontitle="Acronymsanchor="sect-2" numbered="true" toc="default"> <name>Acronyms and Terminology</name> <dl> <dt>Area Border RBridge: </dt> <dd>A border RBridge between a Level 1 area andTerminology" anchor="sect-2"><t> DataLevel 2. </dd> <dt>Data Label:VLAN</dt> <dd>VLAN orFGLFine-Grained Label(FGL).</t> <t> DBRB: Designated(FGL). </dd> <dt>DBRB: </dt> <dd>Designated BorderRBridge.</t> <t> IS-IS: IntermediateRBridge. </dd> <dt>IS-IS: </dt> <dd>Intermediate System to Intermediate System[IS-IS].</t> <t> Level: Similar<xref target="IS-IS"/>. </dd> <dt>Level: </dt> <dd>Similar to IS-IS, TRILL has Level 1 for intra-area andLevel 2Level 2 for inter-area. Routing information is exchanged between Level 1 RBridges within the same Level 1 area, and Level 2 RBridges can only form relationships and exchange information with other Level 2RBridges.</t>RBridges. </dd> </dl> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t> Familiarity with <xreftarget="RFC6325"/>target="RFC6325" format="default"/> is assumed in this document.</t> </section> <sectiontitle="Nicknameanchor="sect-3" numbered="true" toc="default"> <name>Nickname Handling on BorderRBridges" anchor="sect-3"><t>RBridges</name> <t> This section provides an illustrative example and description of the border learning border RBridge nicknames.</t> <figuretitle="Ananchor="fig-1"> <name>An Example Topology for TRILLMultilevel" anchor="fig-1"><artwork><![CDATA[Multilevel</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Area {2,20}levelLevel 2 Area {3,30} +-------------------+ +-----------------+ +--------------+ | | | | | | | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | | 27 | | 39 | | 44 | | ----RB20--- ----RB30--- | +-------------------+ +-----------------+ +--------------+ ]]></artwork> </figure> <t> InFigure 1,<xref target="fig-1"/>, RB2, RB20,RB3RB3, and RB30 are area border TRILL switches (RBridges). Their nicknames are 2, 20,33, and30 respectively30, respectively, and are used as TRILL switch identifiers in their areas <xreftarget="RFC6325"/>.target="RFC6325" format="default"/>. Area border RBridges use the set of border nicknames to denote the L1 area that they are attached to. For example, RB2 and RB20 use nicknames {2,20} to denote the L1 area on the left.</t> <t> A source S is attached to RB27 and a destination D is attached to RB44. RB27 has anickname, say 27,nickname (say, 27), and RB44 has anickname, say 44 (and innickname (say, 44). (In fact, they could even have the same nickname, since the TRILL switch nickname will not be visible outside these Level 1areas).</t>areas.)</t> <sectiontitle="Actionsanchor="sect-3.1" numbered="true" toc="default"> <name>Actions on UnicastPackets" anchor="sect-3.1"><t>Packets</name> <t> Let's say that S transmits a frame to destination D and let's say that D's location has been learned by the relevant TRILL switches already. These relevant switches have learned the following:</t><t><list style="format (%d)"> <t>RB27<ol spacing="normal" type="%d)"><li>RB27 has learned that D is connected to nickname3.</t> <t>RB33.</li> <li>RB3 has learned that D is attached to nickname44.</t> </list> </t>44.</li> </ol> <t> The following sequence of events will occur:<list style="symbols"> <t>S</t> <ol> <li>S transmits an Ethernet frame with source MAC = S and destination MAC =D.</t> <t>RB27D. </li> <li>RB27 encapsulates with a TRILL header with ingress RBridge =27,27 and egress RBridge = 3 producing a TRILL Datapacket.</t> <t>RB2packet. </li> <li>RB2 and RB20 have announced in the Level 1 IS-IS area designated{2,20},{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 toRB3).</t> <t>RB2,RB3). </li> <li>RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, replacing 27 with 2. Within Level 2, the ingress RBridge field in the TRILL header will therefore be 2, and the egress RBridge field will be 3. (The egress nicknameMAY<bcp14>MAY</bcp14> be replaced with any area nickname selected from {3,30} such as 30. SeeSection 4<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. RB2SHOULD<bcp14>SHOULD</bcp14> synchronize with RB20 usingESADIthe End Station Address Distribution Information (ESADI) protocol[RFC7357]<xref target="RFC7357"/> that MAC = S is attached to nickname27.</t> <t>The27. </li> <li>The packet is forwarded through Level 2, to RB3, which has advertised, in Level 2, its L2 nickname as3.</t> <t>RB3,3. </li> <li>RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with RB44's nickname (44) based on looking up D. (The ingress nicknameMAY<bcp14>MAY</bcp14> be replaced with any area nickname selected from {2,20}. SeeSection 4<xref target="sect-4"/> for the detail of the selection method. Here, suppose the ingress nickname remains 2.) So, within the destination area, the ingress nickname will be 2 and the egress nickname will be44.</t> <t>RB44,44. </li> <li>RB44, when decapsulating, learns that S is attached to nickname 2, which is one of the area nicknames of theingress.</t> </list> </t>ingress. </li> </ol> </section> <sectiontitle="Actionsanchor="sect-3.2" numbered="true" toc="default"> <name>Actions onMulti-Destination Packets" anchor="sect-3.2"><t>Multi-destination Packets</name> <t> Distribution trees for flooding of multi-destination packets are calculated separately within each L1 area and in L2. When amulti- destinationmulti-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-DBRBsMUST<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 areaMUST<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 <xreftarget="sect-4"/>target="sect-4" format="default"/> for load balancing.</t> <t> As per <xreftarget="RFC6325"/>,target="RFC6325" format="default"/>, multi-destination packets can be classified into three types: unicastpacketpackets with unknown destination MACaddressaddresses (unknown-unicastpacket),packets), multicastpacketpackets, and broadcastpacket.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,floodingwhich would flood the packet onthethat distributiontree, subjecttree (subject topossible pruning.</t>potential pruning). </t> <t> When the copies of the multi-destination packet arrive at area border RBridges, non-DBRBsMUST<bcp14>MUST</bcp14> drop the packet while theDBRB, say RB2,DBRB (say, RB2) needs to do the Level transition for the multi-destination packet. For an unknown-unicast packet, if the DBRB haslearntlearned the destination MAC address, itSHOULD<bcp14>SHOULD</bcp14> convert the packet to unicast and set its M bit to 0. Otherwise, the multi-destination packet will continue to be flooded as a multicast packet on the distribution tree. The DBRB chooses the new distribution tree by replacing the egress nickname with the new tree root RBridge nickname from the area the packet is entering. The following sequence of events will occur:</t><t><list style="symbols"><t>RB2,<ol> <li>RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, replacing 27 with 2. RB2 alsoMUST<bcp14>MUST</bcp14> replace the egress RBridge nickname with an L2 tree root RBridge nickname(say(say, 39). In order to accommodate return traffic, RB2 records that S is attached to nickname 27 andSHOULD<bcp14>SHOULD</bcp14> use the ESADI protocol <xreftarget="RFC7357"/>target="RFC7357" format="default"/> to synchronize this attachment information with other border RBridges(say(say, RB20) in thearea.</t> <t>RB20,area. </li> <li>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 thisarea.</t> <t>The multidestinationarea. </li> <li>The multi-destination packet is flooded on the Level 2 tree to reach all border routers for all L1 areas including both RB3 and RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will drop thepacket.</t> <t>RB3,packet. </li> <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-- say, 30. (Here, the ingress nicknameMAY<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 <xreftarget="sect-4"/>.)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 hasre-startedrestarted 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}.</t> <t>RB30,{3,30}. </li> <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 L2borderBorder RBridgenickname,Nickname, RB30 must not transition the packet back toL2.</t> <t>TheL2. </li> <li>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 theingress.</t> </list> </t>ingress. </li> </ol> <t> See alsoAppendix A.</t><xref target="sect-a"/>.</t> </section> </section> <sectiontitle="Per-flowanchor="sect-4" numbered="true" toc="default"> <name>Per-Flow LoadBalancing" anchor="sect-4"><t>Balancing</name> <t> Area border RBridges perform ingress/egress nickname replacement when they transition TRILLdataData 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 theper- flowper-flow loadbalancebalance, which is specified in the following subsections. The mechanism specified inSetion 4.1<xref target="sect-4.1"/> or that in4.2<xref target="sect-4.2"/> or both is necessary in general toload balanceload-balance traffic across L2 paths.</t> <sectiontitle="L2 to L1anchor="sect-4.1" numbered="true" toc="default"> <name>L2-to-L1 Ingress NicknameReplacement" anchor="sect-4.1"><t>Replacement</name> <t> When a TRILLdataData packet from other L1 areas arrives at an area border RBridge, this RBridgeMAY<bcp14>MAY</bcp14> select one area nickname of the ingress area to replace the ingress nickname of the packet so that the returning TRILLdataData packet can be forwarded to this selected nickname to helpload balanceload-balance return unicast traffic over multiple paths. The selection is simply based on a pseudorandom algorithm as discussed inSection 5.3 of<xreftarget="RFC7357"/>.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 areaMUST<bcp14>MUST</bcp14> agree on the same pseudorandom algorithm. The source MAC address, ingress area nicknames, egress areanicknamesnicknames, and the Data Label of the received TRILLdataData packet are candidate factors of the input of this pseudorandom algorithm. Note that the value of the destination MAC addressSHOULD<bcp14>SHOULD</bcp14> be excluded from the input of this pseudorandomalgorithm, otherwisealgorithm; otherwise, the egress RBridge could see one source MAC address flip-flopping among multiple ingress RBridges.</t> </section> <sectiontitle="L1 to L2anchor="sect-4.2" numbered="true" toc="default"> <name>L1-to-L2 Egress NicknameReplacement" anchor="sect-4.2"><t>Replacement</name> <t> When a unicast TRILLdataData packet originated from an L1 area arrives at an area border RBridge of that L1 area, that RBridgeMAY<bcp14>MAY</bcp14> select one area nickname of the egress area to replace the egress nickname of the packet. By default, itSHOULD<bcp14>SHOULD</bcp14> choose the egress area border RBridge with the least cost route to reach or, if there are multiple equal cost egress area border RBridges, use the pseudorandom algorithm as defined inSection 5.3 of<xreftarget="RFC7357"/>target="RFC7357" sectionFormat="of" section="5.3" format="default"/> to select one. The use of that algorithmMAY<bcp14>MAY</bcp14> be extended to selection among some stable set of egress area border RBridges that include non-least-cost alternatives if it is desired to obtain more load spreading at the cost of sometimes using a non-least-cost Level 2 route to forward the TRILLdataData packet to the egress area.</t> </section> </section> <sectiontitle="Protocolanchor="sect-5" numbered="true" toc="default"> <name>Protocol Extensions forDiscovery" anchor="sect-5"><t>Discovery</name> <t> The following topology change scenarios will trigger the discovery processes as defined in Sections5.1<xref target="sect-5.1" format="counter"/> and5.2:</t> <t><list style="symbols"><t>A<xref target="sect-5.2" format="counter"/>:</t> <ul spacing="normal"> <li>A new node comes up or recovers from a previousfailure.</t> <t>Afailure.</li> <li>A node goesdown.</t> <t>Adown.</li> <li>A link or node fails and causes partition of an L1/L2area.</t> <t>Aarea.</li> <li>A link or node whose failurehavehas caused partitioning of an L1/L2 area isrepaired.</t> </list> </t>repaired.</li> </ul> <sectiontitle="Discoveryanchor="sect-5.1" numbered="true" toc="default"> <name>Discovery of Border RBridges inL1" anchor="sect-5.1"><t>L1</name> <t> The following Level 1 Border RBridge APPsub-TLV will be included inanE-L1FS FS-LSP fragment zero <xreftarget="RFC7780"/>target="RFC7780" format="default"/> as an APPsub-TLV of the TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an area border RBridge discovers all other area border RBridges in this area.</t><figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = L1-BORDER-RBRIDGE | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure> <t><list style="symbols"><t>Type: Level<dl> <dt>Type: </dt> <dd>Level 1 Border RBridge (TRILL APPsub-TLV typetbd1)</t> <t>Length: 2</t> <t>Sender256) </dd> <dt>Length: </dt> <dd>2 </dd> <dt>Sender Nickname:The</dt> <dd>The nickname the originating IS will use as the L1 Border RBridgenickname.Nickname. This field is useful because the originating IS might own multiplenicknames.</t> </list> </t>nicknames. </dd> </dl> </section> <sectiontitle="Discoveryanchor="sect-5.2" numbered="true" toc="default"> <name>Discovery of Border RBridge Sets inL2" anchor="sect-5.2"><t>L2</name> <t> The following APPsub-TLV will be included in an E-L2FS FS-LSP fragment zero <xreftarget="RFC7780"/>target="RFC7780" format="default"/> as an APPsub-TLV of the TRILL GENINFO-TLV. Through listening to this APPsub-TLV in L2, an area border RBridge discovers all groups of L1 border RBridges and each such group identifies an area.</t><figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = L1-BORDER-RB-GROUP | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1 Border RBridge Nickname 1 | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L1 Border RBridge Nickname k | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure> <t><list style="symbols"><t>Type: Level<dl> <dt>Type: </dt> <dd>Level 1 Border RBridge Group (TRILL APPsub-TLV typetbd2)</t> <t>Length: 2257) </dd> <dt>Length: </dt> <dd>2 * k. If length is not a multiple of 2, the APPsub-TLV is corrupt andMUST<bcp14>MUST</bcp14> beignored.</t> <t>L1ignored. </dd> <dt>L1 Border RBridge Nickname:The</dt> <dd>The nickname that an area border RBridge uses as the L1 Border RBridgenickname.Nickname. TheL1-BORDER-RB- GROUPL1-BORDER-RB-GROUP TLV generated by an area border RBridgeMUST<bcp14>MUST</bcp14> include all L1 Border RBridgenicknamesNicknames of the area. It'sRECOMMENDED<bcp14>RECOMMENDED</bcp14> that these k nicknames are ordered in ascending order according to the 2-octet nickname considered as an unsignedinteger.</t> </list> </t>integer. </dd> </dl> <t> When an L1 area is partitioned <xreftarget="RFC8243"/>,target="RFC8243" format="default"/>, border RBridges willre- discoverre-discover each other in both L1 and L2 through exchanging LSPs. In L2, the set of border RBridge nicknames for this splitting area will change. Border RBridges that detect such a changeMUST<bcp14>MUST</bcp14> flush the reachability information associated to any RBridge nickname from this changing set.</t> </section> </section> <sectiontitle="Oneanchor="sect-6" numbered="true" toc="default"> <name>One Border RBridge Connects MultipleAreas" anchor="sect-6"><t>Areas</name> <t> It's possible that one border RBridge(say(say, RB1) connects multiple L1 areas. RB1SHOULD<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 multiplenicknames,nicknames -- forexampleexample, it might be the root of multiple L1 or multiple L2 distribution trees.</t> <t> Nicknames used within one of these L1 areas can be reused within other areas. It's important that packets destined to those duplicated nicknames are sent to the right area. Since these areas are connected to form a layer 2 network, duplicated {MAC, Data Label} across these areasSHOULD NOT<bcp14>SHOULD NOT</bcp14> occur (seeSection 4.2.6 of<xreftarget="RFC6325"/>target="RFC6325" section="4.2.6" sectionFormat="of" format="default"/> for tie breaking rules). Now suppose a TRILLdataData packet arrives at the area border nickname of RB1. For a unicast packet, RB1 can look up the {MAC, Data Label} entry in its MAC table to identify the right destination area (i.e., the outgoing interface) and the egress RBridge's nickname. For a multicast packet for each attached L1 area: either RB1 is not the DBRB and RB1 will not transition thepacketpacket, or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows the following rules:</t><t><list style="symbols"><t>if<ul spacing="normal"> <li>If this packet originated from an area out of the connected areas, RB1 replicates this packet and floods it on the proper Level 1 trees of all the areas in which it acts as theDBRB.</t> <t>ifDBRB.</li> <li>If the packet originated from one of the connected areas, RB1 replicates the packet it receives from the Level 1 tree and floods it on other proper Level 1 trees of all the areas in which it acts as the DBRB except the originating area (i.e., the area connected to the incoming interface). RB1 might also receive the replication of the packet from the Level 2 tree. This replicationMUST<bcp14>MUST</bcp14> be dropped by RB1. It recognizes such packets by their ingress nickname being the nickname of one of the border RBridges of an L1 area for which the receiving border RBridge isDBRB.</t> </list> </t>DBRB.</li> </ul> </section> <sectiontitle="E-L1FS/E-L2FSanchor="sect-7" numbered="true" toc="default"> <name>E-L1FS/E-L2FS BackwardsCompatibility" anchor="sect-7"><t>Compatibility</name> <t> All Level 2 RBridgesMUST<bcp14>MUST</bcp14> support E-L2FS <xreftarget="RFC7356"/>target="RFC7356" format="default"/> <xreftarget="RFC7780"/>.target="RFC7780" format="default"/>. The Extended TLVs defined in <xreftarget="sect-5"/>target="sect-5" format="default"/> are to be used in Extended Level 1/2 Flooding Scope (E-L1FS/E-L2FS)PDUs.Protocol Data Units (PDUs). Area border RBridgesMUST<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> <sectiontitle="Manageability Considerations" anchor="sect-8"><t>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 RBridge has both L1 and L2 adjacencies, the multilevel feature as specified in this document is turned on for that RBridge anditnormally uses an L2 nickname in both L1 and L2 although, as provided below, such an RBridge may have to fall back to multilevel unique nickname behavior <xreftarget="RFC8397"/>target="RFC8397" format="default"/>, in which case it uses this L1 nickname. In contrast, unique nickname multilevel as specified in <xreftarget="RFC8397"/>target="RFC8397" format="default"/> is enabled by the presence of L1 and L2 adjacencies without an L1 Border RBridge Nickname being configured. RBridges supporting only unique nickname multilevel do not support the configuration of an L2 Border RBridge Nickname. RBridges supporting only thesingle levelsingle-level TRILL base protocol specified in <xreftarget="RFC6325"/>target="RFC6325" format="default"/> do not support L2 adjacencies.</t> <t> RBridges that support and are configured to use single nickname multilevel as specified in this documentMUST<bcp14>MUST</bcp14> support unique nickname multilevel(<xref target="RFC8397"/>).<xref target="RFC8397" format="default"/>. If there are multiple border RBridges between an L1 area andL2L2, and one or more of them only support or are only configured for unique nickname multilevel(<xref target="RFC8397"/>),<xref target="RFC8397" format="default"/>, any of these border RBridges that are configured to use single nickname multilevelMUST<bcp14>MUST</bcp14> fall back to behaving as a unique nickname border RBridge for that L1 area. Because overlapping sets of RBridges may be the border RBridges for different L1 areas, an RBridge supporting single nicknameMUST<bcp14>MUST</bcp14> be able to simultaneously support single nickname for some of its L1 areas and unique nickname for others. For example, RB1 and RB2 might be border RBridges for L1 area A1 using single nickname while RB2 and RB3 are border RBridges for area A2. If RB3 only supports uniquenicknamesnicknames, then RB2 must fall back to unique nickname for area A2 but continue to support single nickname for area A1. OperatorsSHOULD<bcp14>SHOULD</bcp14> be notified when thisfall backfallback occurs. The presence of border RBridges using unique nickname multilevel can be detected because they advertise in L1 the blocks of nicknames available within that L1 area.</t> <t> In both the unique nickname approach specified in <xreftarget="RFC8397"/>target="RFC8397" format="default"/> and the single nickname aggregated approach specified in this document, an RBridge that has L1 and L2 adjacencies uses the same nickname in L1 and L2. If an RBridge is configured with an L1 Border RBridge Nickname for any a Level 1 area, it uses this nickname across the Level 2 area. This L1 Border RBridge Nickname cannot be used in any other Level 1 area except other Level 1 areas for which the same RBridge is a border RBridge with this L1 Border RBridge Nickname configured.</t> <t> In addition to the manageability considerations specified above, the manageability specifications in <xreftarget="RFC6325"/>target="RFC6325" format="default"/> still apply.</t> <t> Border RBridges replace ingress and/or egress nickname when a TRILLdataData packet traverses a TRILL L2 area. A TRILLOAMOperations, Administration, and Maintenance (OAM) message will be forwarded through the multilevel single nickname TRILL campus using a MAC address belonging to the destination RBridge <xreftarget="RFC7455"/>.</t>target="RFC7455" format="default"/>.</t> </section> <sectiontitle="Security Considerations" anchor="sect-9"><t>anchor="sect-9" numbered="true" toc="default"> <name>Security Considerations</name> <t> For general TRILL Security Considerations, see <xreftarget="RFC6325"/>.</t>target="RFC6325" format="default"/>.</t> <t> The newly defined TRILL APPsub-TLVs in <xreftarget="sect-5"/>target="sect-5" format="default"/> are transported in IS-IS PDUs whose authenticity can be enforced using regular IS-IS security mechanism[IS-IS]<xreftarget="RFC5310"/>.target="IS-IS"/> <xref target="RFC5310" format="default"/>. Malicious devices may also fake the APPsub-TLVs to attract TRILLdataData packets, interfere with multilevel TRILL operation, induce excessive state in TRILL switches (or in any bridges that may be part of the TRILL campus), etc. For this reason, RBridgesSHOULD<bcp14>SHOULD</bcp14> be configured to use the IS-IS Authentication TLV (10) in their IS-IS PDUs so that IS-IS security <xreftarget="RFC5310"/>target="RFC5310" format="default"/> can be used to authenticate those PDUs and discard them if they are forged.</t> <t> Using a variation of aggregated nicknames, and the resulting possible duplication of nicknames between areas, increases the possibility of a TRILL Data packet being delivered to the wrong egress RBridge if areas are unexpectedly merged as compared with a schemewerewhere all nicknames in the TRILL campus are, except as a transient condition, unique such as the scheme in <xreftarget="RFC8397"/>.target="RFC8397" format="default"/>. However, in manycasescases, the data would be discarded at that egress RBridge because it would not match a known end stationdata label/MACData Label / MAC address.</t> </section> <sectiontitle="IANA Considerations" anchor="sect-10"><t>anchor="sect-10" numbered="true" toc="default"> <name>IANA Considerations</name> <t> IANAis requested to allocatehas allocated two new types under the TRILL GENINFO TLV <xreftarget="RFC7357"/>target="RFC7357" format="default"/> from the range allocated bystandards actionStandards Action <xref target="RFC8126"/> for the TRILL APPsub-TLVs defined in <xreftarget="sect-5"/>.target="sect-5" format="default"/>. The following entriesarehave been added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"Registryregistry 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><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> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC6325; &RFC7356; &RFC7357; &RFC7455; &RFC7780; &RFC8174; &RFC8397;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6325.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7356.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7357.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7455.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7780.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8397.xml"/> </references><references title="Informative References"> <!-- draft-ietf-trill-multilevel-single-nickname-17-manual.txt(612): Warning: Failed parsing a reference. Are all elements separated by commas (not periods, not just spaces)?: [IS-IS] International Organization for Standardization, ISO/IEC 10589:2002, "Information<references> <name>Informative References</name> <reference anchor="IS-IS"> <front> <title>Information technology--- Telecommunications and information exchange between systems--- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode networkservice", ISO 8473, Second Edition, November 2002. --> &RFC5310; &RFC8243;service (ISO 8473)</title> <author> <organization>International Organization for Standardization</organization> </author> <date year="2002" month="November"/> </front> <refcontent>ISO 8473</refcontent> <refcontent>ISO/IEC 10589:2002</refcontent> <refcontent>Second Edition</refcontent> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8243.xml"/> </references> </references> <sectiontitle="Levelanchor="sect-a" numbered="true" toc="default"> <name>Level TransitionClarification" anchor="sect-a"><t>Clarification</name> <t> It's possible that an L1 RBridge is only reachable from a non-DBRB border RBridge. If this non-DBRB RBridge refrains from Level transition, the question is, how can a multicast packet reach this L1 RBridge? The answer is, it will be reached after the DBRB performs the Level transition and floods the packet using an L1 distribution tree.</t> <t> Take the following figure as an example. RB77 is reachable from the border RBridge RB30 while RB3 is the DBRB. RB3 transitions the multicast packet into L1 and floods the packet on the distribution tree rooted from RB3. This packet is finally flooded to RB77 via RB30.</t><figure><artwork><![CDATA[<artwork name="" type="" align="center" alt=""><![CDATA[ Area{3,30} +--------------+ (root) RB3 o | | \ -RB3 | | o RB30 | | | / -RB30-RB77 | RB77 o +--------------+ Example Topology L1 Tree ]]></artwork></figure><t> In the above example, the multicast packet is forwarded along anon- optimalnon-optimal path. A possible improvement is to have RB3 configured not to belong to this area. In this way, RB30 will surely act as the DBRB to do the Level transition.</t> </section> </back> </rfc>