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