Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8139

Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders

Pages: 41
Proposed Standard
Obsoletes:  6439
Updates:  63257177
Part 2 of 2 – Pages 20 to 41
First   Prev   None

Top   ToC   RFC8139 - Page 20   prevText

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
Top   ToC   RFC8139 - Page 21
   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.
Top   ToC   RFC8139 - Page 22
   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.
Top   ToC   RFC8139 - Page 23
   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].
Top   ToC   RFC8139 - Page 24
      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.
Top   ToC   RFC8139 - Page 25
   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].
Top   ToC   RFC8139 - Page 26

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 milliseconds

7. 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.
Top   ToC   RFC8139 - Page 27

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.
Top   ToC   RFC8139 - Page 28

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]
Top   ToC   RFC8139 - Page 29
   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.
Top   ToC   RFC8139 - Page 30
   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.
Top   ToC   RFC8139 - Page 31
   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.
Top   ToC   RFC8139 - Page 32
   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) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
Top   ToC   RFC8139 - Page 33
      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.
Top   ToC   RFC8139 - Page 34

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>.
Top   ToC   RFC8139 - Page 35
   [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>.
Top   ToC   RFC8139 - Page 36

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>.
Top   ToC   RFC8139 - Page 37

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.
Top   ToC   RFC8139 - Page 38

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.
Top   ToC   RFC8139 - Page 39
   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.
Top   ToC   RFC8139 - Page 40
   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].
Top   ToC   RFC8139 - Page 41

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