RFC6325], can see each other's frames in that VLAN, and utilize the mechanisms specified below to update VLAN inhibition timers, operations will be safe. (These considerations
do not arise on links between RBridges that are configured as point to point, since, in that case, each RBridge sends point-to-point Hellos, other TRILL IS-IS PDUs, and TRILL Data frames only in what it believes to be the Designated VLAN of the link (although it may send them untagged) and no native frame end-station service is provided. Thus, for such links, there is no reason to send Hellos in any VLAN other than the Designated VLAN.) The provision for a configurable set of "Announcing VLANs", as described in Section 4.4.3 of [RFC6325], provides a mechanism in the TRILL base protocol for a reduction in TRILL Hellos. To maintain loop safety in the face of occasional lost frames, RBridge failures, link failures, new RBridges coming up on a link, and the like, the inhibition mechanism specified in Section 3 is still required. Strictly following Section 3, a VLAN inhibition timer can only be set by the receipt of a Hello sent or received in that VLAN. Thus, to safely send a reduced number of TRILL Hellos on a reduced number of VLANs requires additional mechanisms to set the VLAN inhibition timers at an RBridge. Two such mechanisms, specified below, expand upon the mechanisms provided in Section 3. Support for both of these mechanisms is indicated by a capability bit in the PORT-TRILL-VER sub-TLV (Section 5.4 of [RFC7176]). It may be unsafe for an RBridge to send TRILL Hellos on fewer VLANs than the set of VLANs recommended in [RFC6325] on a link unless all its adjacencies on that link (excluding those in the Down state [RFC7177]) indicate support of these mechanisms and these mechanisms are in use. 1. An RBridge RB2 MAY include in any TRILL Hello an Appointed Forwarders sub-TLV [RFC7176] appointing itself for one or more ranges of VLANs. The Appointee Nickname field(s) in the self-appointment Appointed Forwarders sub-TLV MUST be the same as the Sender Nickname in the Special VLANs and Flags sub-TLV in the TRILL Hellos sent by RB2. This indicates that the sending RBridge believes that it is Appointed Forwarder for those VLANs. For each of an RBridge's VLAN inhibition timers for every VLAN in the block or blocks listed in the Appointed Forwarders sub-TLV, the RBridge sets that timer to either (1) its current value or (2) the Holding Time of the Hello containing the sub-TLV, whichever is longer. This is backward compatible. That is, such sub-TLVs will have no effect on any legacy receiving RBridge not implementing this mechanism unless RB2, the sending RBridge, is the DRB sending Hellos on the Designated VLAN. If RB2 is the DRB, it MUST include in the Hello all forwarder appointments, if any, for RBridges other than itself on the link.
2. An RBridge MAY use the VLANs Appointed sub-TLV [RFC7176]. When RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2 on any VLAN, RB1 updates the VLAN inhibition timers for all the VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is Appointed Forwarder. Each such timer is updated to (1) its current value or (2) the Holding Time of the TRILL Hello containing the VLANs Appointed sub-TLV, whichever is longer. This sub-TLV will be an unknown sub-TLV to RBridges not implementing it, and such RBridges will ignore it. Even if a TRILL Hello sent by the DRB on the Designated VLAN includes one or more VLANs Appointed sub-TLVs, as long as no Appointed Forwarders sub-TLVs appear, the Hello is not required to indicate all forwarder appointments. Two different encodings are provided above to optimize the listing of VLANs. Large blocks of contiguous VLANs are more efficiently encoded with the Appointed Forwarders sub-TLV, and scattered VLANs are more efficiently encoded with the VLANs Appointed sub-TLV. These encodings may be mixed in the same Hello. The use of these sub-TLVs does not affect the requirement that the AF bit in the Special VLANs and Flags sub-TLV MUST be set if the originating RBridge believes that it is Appointed Forwarder for the VLAN in which the Hello is sent. If the above mechanisms are used on a link, then each RBridge on the link MUST send Hellos in one or more VLANs with such VLANs Appointed sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s), and the AF bit is appropriately set such that no VLAN inhibition timer will improperly expire unless three or more Hellos are lost. For example, an RBridge could announce all VLANs for which it believes that it is Appointed Forwarder in a Hello sent on the Designated VLAN three times per Holding Time. RFC7177]. Suspended ports never ingress or egress native frames. If a TRILL switch has one or more non-suspended ports on a link and those ports offer end-station service -- that is, those ports are not configured as point-to-point or trunk ports -- then that TRILL switch is eligible to be an Appointed Forwarder for that link. It can become Appointed Forwarder in the ways discussed in Section 2.
If a TRILL switch that is the Appointed Forwarder for VLAN-x on a link has multiple non-suspended ports on that link, it may load-share the task of ingressing and egressing VLAN-x native frames across those ports however it chooses, as long as there is no case in which a frame it egresses onto the link from one port can be ingressed on another one of its ports, creating a loop. If the TRILL switch is the Appointed Forwarder for multiple VLANs, a straightforward thing to do would be to partition those VLANs among the ports it has on the link. RFC7178] using RBridge Channel Protocol number 0x006. The payload specific to the Channel Protocol consists of a list of Port IDs (see Section 4.4.2 of [RFC6325]) for the port or ports that have failed or are being shut down, as shown in the diagram below. Support for the Port-Shutdown message is advertised by simply advertising support for its RBridge Channel Protocol in the RBridge Channel Protocols sub-TLV [RFC7176].
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |A|C|M| RESV |F| Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Nickname | Ingress Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Special Inner.MacDA = All-Egress-RBridges | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Special Inner.MacDA (cont.) | Inner.MacSA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner.MacSA (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN Tag Ethertype=0x8100 | Priority=7, DEI=0, VLAN ID=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RBridge Channel Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RBridge-Chan. Ethertype=0x8946| CHV=0 | Channel Protocol=0x006| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | ERR=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Information specific to the Port-Shutdown Channel Protocol: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port ID K | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 6.6). As with any "adjacency critical" message, the Port-Shutdown message SHOULD be sent with the highest priority, which is priority 7, and SHOULD NOT be marked as "drop eligible". If a failure of port P1 on RBridge RB2 is detected by RB2, then the Port-Shutdown message announcing this failure is sequentially unicast through the rest of the TRILL campus to all RBridges (1) with which P1 had an adjacency and (2) that are advertising support for the Port-Shutdown RBridge Channel Protocol.
If a port shutdown is planned within 1 second, then the TRILL switch ceases to send Hellos out of the port being shut down and either (1) sends the Port-Shutdown message to RBridge ports on the link advertising support of the Port-Shutdown RBridge Channel Protocol or (2) broadcasts the Port-Shutdown message announcing this event through the port as follows: - The Outer.MacDA is the All-RBridges multicast address. - If an outer VLAN tag is present, it specifies the Designated VLAN for the link, SHOULD specify priority 7, and SHOULD NOT specify "drop eligible". - In the TRILL Header, the egress nickname is All-RBridges, and the M bit in the TRILL Header is set to 0. - In the RBridge Channel Header, the MH and NA bits are zero. There is no need for a special message to indicate that a port P1 has come back up or that a shutdown has been "canceled". This is indicated by simply sending Hellos out of port P1. RFC7978].
Section 6.3 provides details regarding their use. Parameter Default Range --------------- ---------------- --------------------- PShutdownRepeat 2 1-3 PShutdownDelay 20 milliseconds 0-1,000 milliseconds RFC7172]. Basically, a VLAN ID in native traffic between an edge TRILL switch and an end station is mapped from/to an FGL as an Inner.Label in TRILL Data packets. Since the Appointed Forwarder for a VLAN will be ingressing and egressing such native traffic, the mapping configured at the Appointed Forwarder is the mapping performed. However, the Appointed Forwarder for VLAN-x on a link can change for reasons discussed elsewhere in this document. Thus, all TRILL switches on a link that are configured with an FGL-VLAN mapping SHOULD be configured with the same mapping. Otherwise, traffic might unpredictably jump from one FGL to another when the Appointed Forwarder changes. TRILL switches SHOULD advertise their mapping on the link using the FGL-VLAN-Bitmap and FGL-VLAN-Pairs APPsub-TLVs (Sections 10.4 and 10.5) so that consistency checking can be automated. A TRILL switch SHOULD compare the FGL-VLAN mappings that it sees advertised by other TRILL switches on a link with its own and alert the network operator if they are inconsistent. "Inconsistent" means that (1) one TRILL switch maps FGL-z to VLAN-x while another maps FGL-z to VLAN-y or (2) one TRILL switch maps VLAN-x to FGL-w while another maps VLAN-x to FGL-z, all on the same link. Depending on how the network is being managed, a transient inconsistency may not be a problem. Thus, the network operator SHOULD NOT be alerted unless the inconsistency persists for a period of time that defaults to the TRILL switch's Holding Time and is configurable to between 0 seconds and 2**16 - 1 seconds, where 2**16 - 1 is a special value and indicates that such alerts are disabled.
RFC7356], Extended Level 1 Flooding Scope (E-L1FS) [RFC7780], and base LSPs [IS-IS]. It will be apparent to any TRILL switch on a link if any other TRILL switch on the link is a legacy implementation not supporting E-L1CS because, as stated in [RFC7780], all TRILL switches MUST include a Scope Flooding Support TLV [RFC7356] in all TRILL Hellos they send. This support of E-L1CS increases the amount of information from each TRILL switch that can be synchronized on the link, compared with the information capacity of Hellos, by several orders of magnitude. For robustness, E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs (Flooding Scope Complete Sequence Number PDUs) [RFC7356], and E-L1CS FS-PSNPs (Flooding Scope Partial Sequence Number PDUs) [RFC7356]) MUST NOT exceed 1,470 bytes in length; however, any such E-L1CS PDU that is received that is longer than 1,470 bytes is processed normally. As with any type of IS-IS LSP, FS-LSPs are identified by the System ID of the originating router (TRILL switch) and the fragment number. In particular, there is no port identifier in the header of an E-L1CS PDU. Thus, a TRILL switch RB1 with more than one non-suspended port on a link (Section 5) transmitting such a PDU MAY transmit it out of any one or more of such ports. RB1 will generally receive such a PDU that other TRILL switches send on all of RB1's ports on the link. In addition, with multiple ports on the link, it will receive any such PDU that it sends on the ports it has on the link other than the transmitting port.
Section 6 of [RFC6325]. The Port-Shutdown messages specified in Section 6 are sent using the RBridge Channel facility [RFC7178]. Such messages SHOULD be secured through the use of the RBridge Channel Header Extension [RFC7978]. If they are not adequately secured, they are a potential denial-of-service vector. The E-L1CS FS-LSPs added by Section 8 are a type of IS-IS PDU [RFC7356]. As such, they are securable through the addition of Authentication TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs. RFC7357] in E-L1CS FS-LSPs [RFC7356]. RFC5226] and updated the "RBridge Channel Protocols" registry as follows: Protocol Description Reference -------- -------------- --------- 0x006 Port-Shutdown [RFC8139]
IANA has updated the reference for the "Hello reduction support" bit in the "PORT-TRILL-VER Sub-TLV Capability Flags" registry to refer to this document.
Each bit in the Bit Map corresponds to a VLAN ID. Bit 0 is for the VLAN whose ID appears in the Starting VLAN ID field. Bit 1 is for that VLAN ID plus 1 (treating VLAN IDs as unsigned integers) and so on, with Bit N generally being Starting VLAN ID plus N. VLAN 0x000 and VLAN 0xFFF, or any larger ID, are invalid and are ignored. If the AppointmentBitmap APPsub-TLV is originated by the DRB on a link, it appoints the TRILL switch whose nickname appears in the Appointee Nickname field for the VLAN IDs corresponding to 1 bits in the Bit Map and revokes any Hello appointment of that TRILL switch for VLANs corresponding to 0 bits in the Bit Map.
o RESV: 4 bits that MUST be sent as zero and ignored on receipt. o VLAN ID: A 12-bit VLAN ID for which the appointee is being appointed as the forwarder. Type and Length are 2 bytes, because these are extended FS-LSPs. This APPsub-TLV, when originated by the DRB, appoints the TRILL switch with Appointee Nickname to be the Appointed Forwarder for the VLAN IDs listed.
o Starting VLAN ID: Initial VLAN ID for the mapping information as discussed below. o Starting FGL: Fine-Grained Label [RFC7172]. o Bit Map: Map of bits for VLAN-ID-to-FGL mappings. The size of the bit map is Length minus 5. If the size of the bit map is zero, no mappings are indicated. Each bit in the Bit Map corresponds to a VLAN ID and to an FGL. Bit 0 is for the VLAN whose ID appears in the Starting VLAN ID field and the Fine-Grained Label that appears in the FGL field. Bit 1 is for that VLAN ID plus 1 and that FGL plus 1 (treating VLAN IDs and FGLs as unsigned integers) and so on, with Bit N generally being Starting VLAN ID plus N and FGL plus N. If a Bit Map bit is a 1, it indicates that the advertising TRILL switch will map between the corresponding VLAN ID and FGL on ingressing native frames and egressing TRILL Data packets if it is Appointed Forwarder for the VLAN. If a Bit Map bit is a 0, it does not indicate any configured mapping of the VLAN ID to the FGL. However, VLAN ID 0x000 and VLAN ID 0xFFF or any larger ID are invalid, and FGLs larger than 0xFFFFFF are invalid; any Bit Map bits that correspond to an illegal VLAN ID or an illegal FGL are ignored.
Where a Mapping RECORD has the following structure: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FGL | (3 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV 20. o Length: 5 * k. If Length is not a multiple of 5, the APPsub-TLV is corrupt and MUST be ignored. o RESV: 4 bits that MUST be sent as zero and ignored on receipt. o VLAN ID: 12-bit VLAN label. o FGL: Fine-Grained Label [RFC7172]. Each Mapping RECORD indicates that the originating TRILL switch is configured to map between the FGL and VLAN given on egressing and ingressing native frames. However, VLAN ID 0x000 and VLAN ID 0xFFF are invalid; any Mapping RECORD that corresponds to an illegal VLAN ID is ignored. Section 6.6. TRILL switch support of SNMPv3 is provided in the TRILL base protocol document [RFC6325]. MIBs have been specified in [RFC6850] and [RFC7784], but they do not include the configurable parameters specified herein. It is anticipated that YANG modules will be specified for TRILL.
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE Std 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, <http://ieeexplore.ieee.org/ servlet/opac?punumber=6991460>. [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", November 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://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, <http://www.rfc-editor.org/info/rfc6325>. [RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>. [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>. [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>. [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>. [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://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, <http://www.rfc-editor.org/info/rfc7357>. [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, <http://www.rfc-editor.org/info/rfc7780>. [RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <http://www.rfc-editor.org/info/rfc7978>. [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <http://www.rfc-editor.org/info/rfc7981>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [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, <http://www.rfc-editor.org/info/rfc5310>. [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>. [RFC6850] Rijhsinghani, A. and K. Zebrose, "Definitions of Managed Objects for Routing Bridges (RBridges)", RFC 6850, DOI 10.17487/RFC6850, January 2013, <http://www.rfc-editor.org/info/rfc6850>. [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>. [RFC7784] Kumar, D., Salam, S., and T. Senevirathne, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB", RFC 7784, DOI 10.17487/RFC7784, February 2016, <http://www.rfc-editor.org/info/rfc7784>.
figure below. + - - - - - - - - - - - - - - - - - - - - - + | | | TRILL network | | | | +---+ +---+ +---+ +---+ | + -|RB1|- -|RB2|- - - - - - -|RB3|- -|RB4|- + +---+ +---+ +---+ +---+ P1| P2| P3| P4| | | | | |x |y |x |y | +-+ | | +-+ | L1 ---+---|M|---+--+--- L2 ---+---|M|---+--- +-+ | +-+ +---+ |ES1| +---+ Further assume that L1 and L2 are each bridged LANs that include a device M, presumably a bridge, that maps VLAN-x into VLAN-y and VLAN-y into VLAN-x. If end station ES1 originated a broadcast or other multi-destination frame in VLAN-y, it would be ingressed by RB2. (The frame would also be mapped to VLAN-x and ingressed by RB1, but we initially ignore that.) RB2 will flood the resulting TRILL Data packet through the campus, and, at least in the broadcast and unknown unicast cases, it will get to RB4, where it will be egressed to L2. Inside L2, this broadcast frame is mapped to VLAN-x and then ingressed by RB3. RB3 then floods the resulting TRILL Data packet through the campus, this time with an Inner.VLAN of VLAN-x, as a result of which it will be egressed by RB1 into L1. Inside L1, it will be mapped back to VLAN-y and then ingressed by RB2, completing the loop. The packet will loop indefinitely, because in native form on L1 and L2 it has no TRILL Hop Count, and an indefinitely large number of copies will be delivered to ES1 and any other end station so situated. The same problem would occur even if P1 and P2 were on the same RBridge and/or P3 and P4 were on the same RBridge. Actually, because the original frame was also mapped to VLAN-x inside L1 and ingressed by RB1, there are two copies looping around in opposite directions.
The use of Fine-Grained Labels [RFC7172] complicates but does not essentially change the potential problem. This example shows why VLAN mapping between Appointed Forwarder ports on a TRILL link is loop unsafe. When such a situation is detected, the DRB on the link changes Appointed Forwarders as necessary to assure that a single RBridge port is Appointed Forwarder for all VLANs involved in mapping. This change makes the situation loop safe. RFC6325], obsoletes [RFC6439], and updates [RFC7177]. The change to [RFC6325], the TRILL base protocol, is as follows: Addition of mandatory support for E-L1CS FS-LSPs. Changes to [RFC6439], which this document obsoletes, are as follows: 1. Specification of APPsub-TLVs and procedures to be used in E-L1CS FS-LSP forwarder appointments. 2. Incorporation of updates to [RFC6439] that appeared in Section 10 of RFC 7180, which has been obsoleted by [RFC7780]. They appear primarily in Section 4 of this document. 3. Addition of an optional FGL-VLAN consistency check feature, including specification of APPsub-TLVs. 4. Deletion of references to the October 2011 version of the document "RBridges: Campus VLAN and Priority Regions" (draft-ietf-trill-rbridge-vlan-mapping), which has been dropped by the TRILL WG. 5. Addition of the Port-Shutdown message. 6. Elimination of the requirement that the DRB not send appointments in Hellos until its DRB inhibition timer has expired. This was an unnecessary safety precaution that is pointless, given that appointments in E-L1CS FS-LSPs are immediately visible. 7. Addition of three optional methods (Section 3.2) to optimize (reduce) inhibition time under various circumstances. 8. Editorial changes.
Changes to [RFC7177] are as follows: As provided in Section 6, TRILL switches SHOULD treat the reception of a Port-Shutdown RBridge Channel message from RB1 listing port P1 as if it were an event A3 as specified in [RFC7177], resulting in transition of any adjacency to P1 to the Detect state. RFC6439], the predecessor to this document: Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan Romascanu, and Mike Shand. We also thank Radia Perlman, who coauthored [RFC6439].