tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8139

 
 
 

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

Part 2 of 2, p. 20 to 41
Prev Section

 


prevText      Top      ToC       Page 20 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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