RFC 8139
Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders
4. Optional TRILL Hello Reduction
If a network manager has sufficient confidence that they know the configuration of bridges, ports, and the like, within an Ethernet link, they may be able to reduce the number of TRILL Hellos sent on that link by sending Hellos in fewer VLANs -- for example, if all TRILL switches on the link will see all Hellos without VLAN constraints. However, because adjacencies are established in the Designated VLAN, an RBridge MUST always attempt to send Hellos in the Designated VLAN. Hello reduction makes TRILL less robust in the face of decreased VLAN connectivity within a link, such as partitioned VLANs, VLANs disabled on ports, or disagreement over the Designated VLAN; however, as long as all RBridge ports on the link are configured for the same Desired Designated VLAN [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.5. Multiple Ports on the Same Link
A TRILL switch may have multiple ports on the same link. Some of these ports may be suspended due to MAC address duplication, as described in [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.6. Port-Shutdown Messages
A TRILL switch may note that one of its ports has failed, or it may be about to shut down that port. If the port is on a link along with ports of other TRILL switches, those TRILL switches will not notice the port shutdown or failure using TRILL base protocol mechanisms until there is a failure to receive a number of Hellos from that port. This can take many seconds. Network topology (adjacencies) and forwarder appointments can react more rapidly to port shutdown or failure through explicit notification. As discussed below, this notification SHOULD be provided through the Port-Shutdown message.6.1. Planned Shutdown and Hellos
A TRILL switch that is shutting down one of its ports (say P1) soon SHOULD reduce its Holding Time on that port, so that the shutdown will be more rapidly noticed by adjacent RBridges that might not support the Port-Shutdown message.6.2. Port-Shutdown Message Structure
The Port-Shutdown message is an RBridge Channel message [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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3. Port-Shutdown Message Transmission
For robustness, a TRILL switch sends a configurable number of copies
of Port-Shutdown messages separated by a configurable time interval.
The default number of copies is two, although this can be configured
as one copy or as three copies, and the default interval is
20 milliseconds (see 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.
6.4. Port-Shutdown Message Reception
When a TRILL switch RB1 receives a Port-Shutdown message, RB1 checks
to see if the ingress nickname specifies some TRILL switch RB2 with
which RB1 has one or more adjacencies. If so, it drops those
adjacencies that are to RB2 ports whose Port IDs are listed in the
Port-Shutdown message. There could be more than one if RB2 had
multiple ports on the link that are going down.
If RB1 is the DRB and this eliminates all adjacencies on a link
between the DRB and RB2, then, for all VLANs whose ingress/egress was
being handled by RB2, the DRB either starts acting as Appointed
Forwarder or appoints some new TRILL switch with which it has
adjacency as Appointed Forwarder.
6.5. Port-Shutdown Message Security
Port-Shutdown messages can be secured through the use of the RBridge
Channel Header Extension security feature [RFC7978].
6.6. Port-Shutdown Configuration
There are two Port-Shutdown configuration parameters, as listed below. Section 6.3 provides details regarding their use. Parameter Default Range --------------- ---------------- --------------------- PShutdownRepeat 2 1-3 PShutdownDelay 20 milliseconds 0-1,000 milliseconds7. FGL-VLAN Mapping Consistency Checking
TRILL switches support 24-bit Fine-Grained Labels as specified in [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.
8. Support of E-L1CS
All TRILL switches MUST support the E-L1CS flooding scope [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.8.1. Backward Compatibility
Future TRILL specifications making use of E-L1CS MUST specify how situations involving a TRILL link will be handled when one or more TRILL switches attached to that link support E-L1CS and one or more do not.
9. Security Considerations
This document provides improved documentation of the TRILL Appointed Forwarder mechanism. It does not change the security considerations of the TRILL base protocol as described in 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.10. Code Points and Data Structures
This section provides IANA considerations for this document and specifies the structures of the AppointmentBitmap, AppointmentList, VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs. These APPsub-TLVs appear within a TRILL GENINFO TLV [RFC7357] in E-L1CS FS-LSPs [RFC7356].10.1. IANA Considerations
IANA has assigned four new APPsub-TLV type codes from the range below 255 and entered them in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry as follows: Type Name Reference ---- ----------------- --------- 17 AppointmentBitmap [RFC8139] 18 AppointmentList [RFC8139] 19 FGL-VLAN-Bitmap [RFC8139] 20 FGL-VLAN-Pairs [RFC8139] IANA has assigned a new RBridge Channel Protocol number in the range assigned by Standards Action [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.10.2. AppointmentBitmap APPsub-TLV
The AppointmentBitmap APPsub-TLV provides an efficient method for a TRILL switch to indicate which TRILL switches it appoints as forwarders for which VLAN IDs when those VLAN IDs are relatively compact (that is, they do not span a large numeric range). Such an appointment is only effective when the appointing TRILL switch is the DRB. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Appointee Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | Starting VLAN ID | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bit Map ... (variable) +-+-+-+-+-+-+-+-... o Type: APPsub-TLV type, set to AppointmentBitmap sub-TLV 17. o Length: 4 + size of bit map in bytes. If Length is less than 4, the APPsub-TLV is corrupt and MUST be ignored. o Appointee Nickname: The nickname of the TRILL switch being appointed as forwarder. o RESV: 4 bits that MUST be sent as zero and ignored on receipt. o Starting VLAN ID: The smallest VLAN ID to which the bits in the Bit Map correspond. o Bit Map: A bit map of the VLANs for which the TRILL switch with Appointee Nickname is appointed as the forwarder. The size of the bit map is length minus 4. If the size of the bit map is zero, no appointments are made.
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.10.3. AppointmentList APPsub-TLV
The AppointmentList APPsub-TLV provides a convenient method for a TRILL switch to indicate which TRILL switches it appoints as forwarders for which VLAN IDs. Such an appointment is only effective when the appointing TRILL switch is the DRB. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Appointee Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN ID 1 | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN ID 2 | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESV | VLAN ID k | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: APPsub-TLV type, set to AppointmentList sub-TLV 18. o Length: 2 + 2 * k. If Length is not an even number, the APPsub-TLV is corrupt and MUST be ignored. o Appointee Nickname: The nickname of the TRILL switch being appointed as forwarder.
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.
10.4. FGL-VLAN-Bitmap APPsub-TLV
The FGL-VLAN-Bitmap APPsub-TLV provides a method for a TRILL switch
to indicate mappings of FGLs to VLAN IDs that it is configured to
perform when egressing and ingressing native frames.
The coding is efficient when both of the following apply:
- the VLAN IDs are compact (that is, they do not span a large
numeric range), and
- the FGLs and VLAN IDs are paired in a monotonically increasing
fashion.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
o Type: APPsub-TLV type, set to VLAN-FGL-Bitmap sub-TLV 19.
o Length: 5 + size of bit map in bytes. If Length is less than 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 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.
10.5. FGL-VLAN-Pairs APPsub-TLV
The FGL-VLAN-Pairs APPsub-TLV provides a method for a TRILL switch to
indicate a list of the mappings of FGLs to VLAN IDs that it is
configured to perform when egressing and ingressing native frames.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 1 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 2 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD k | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
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.
11. Management Considerations
This document primarily adds optional enhancements or optimizations.
The only configuration parameters specified in this document are the
number and frequency of copies of Port-Shutdown messages sent, as
specified in 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.
12. References
12.1. Normative References
[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>.
12.2. Informative References
[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>.
Appendix A. VLAN Inhibition Example
The per-VLAN inhibition timers (or the equivalent) are needed to be loop safe in the case of misconfigured bridges on a link. For a simple example, assume that RB1 and RB2 are the only RBridges on the link, that RB1 is higher priority to be the DRB, and that they both want VLAN 1 (the default) to be the Designated VLAN. However, there is a bridge between them configured so that RB1 can see all the frames sent by RB2 but none of the frames from RB1 can get through to RB2. Both will think they are the DRB: RB1 because it is higher priority even though it sees the Hellos from RB2, and RB2 because it doesn't see the Hellos from RB1 and therefore thinks it is highest priority. Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There is no problem with VLANs 2 and 4, but if you do not do something about it, you could have a loop involving VLAN 3. RB1 will see the Hellos that RB2 issues on VLAN 3 declaring itself Appointed Forwarder, so RB1 will be inhibited on VLAN 3. RB2 does not see the Hellos issued by RB1 on VLAN 3, so RB2 will become uninhibited and will handle VLAN 3 native traffic. However, this situation may change. RB2 might crash, the bridge might crash, RB2 might be reconfigured so it no longer tried to act as Appointed Forwarder for VLAN 3, or other issues may occur. So, RB1 has to maintain a VLAN 3 inhibition timer, and if it sees no Hellos from any other RBridge on the link claiming to be Appointed Forwarder for VLAN 3 for a long enough time, then RB1 becomes uninhibited for that VLAN on the port in question and can handle end-station traffic in VLAN 3.
Appendix B. Multi-Link VLAN Mapping Loop Example
Assume that RBridges RB1 and RB2 have ports P1 and P2, respectively, that are both on Link L1 and that RBridges RB3 and RB4 have ports P3 and P4, respectively, that are both on Link L2. Assume further that P1 and P3 are Appointed Forwarders for VLAN-x and P2 and P4 are Appointed Forwarders for VLAN-y. This situation is shown in the 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.Appendix C. Changes to RFCs 6325, 6439, and 7177
This document updates [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.Acknowledgments
The following are hereby thanked for their contributions to this document: Spencer Dawkins, Shawn M. Emery, Stephen Farrell, Joel Halpern, Sue Hares, Christer Holmberg, Gayle Noble, Alvaro Retana, Dan Romascanu, and Mingui Zhang. The following are thanked for their contributions to [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].
Authors' Addresses
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China Phone: +86-25-56622310 Email: liyizhou@huawei.com Mohammed Umair IP Infusion Email: mohammed.umair2@ipinfusion.com Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States of America Phone: +1-408-333-7149 Email: ayabaner@cisco.com Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai 201203 China Phone: +86-21-68896273 Email: hu.fangwei@zte.com.cn