doc: Add RFC documents

1 files changed, 2299 insertions, 0 deletions

diff --git a/doc/rfc/rfc8139.txt b/doc/rfc/rfc8139.txt
new file mode 100644
index 0000000..70277c3
--- /dev/null
+++ b/doc/rfc/rfc8139.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
+Request for Comments: 8139                                         Y. Li
+Obsoletes: 6439                                                   Huawei
+Updates: 6325, 7177                                             M. Umair
+Category: Standards Track                                    IP Infusion
+ISSN: 2070-1721                                              A. Banerjee
+                                                                   Cisco
+                                                                   F. Hu
+                                                                     ZTE
+                                                               June 2017
+
+
+         Transparent Interconnection of Lots of Links (TRILL):
+                          Appointed Forwarders
+
+Abstract
+
+   TRILL (Transparent Interconnection of Lots of Links) supports multi-
+   access LAN (Local Area Network) links where a single link can have
+   multiple end stations and TRILL switches attached.  Where multiple
+   TRILL switches are attached to a link, native traffic to and from end
+   stations on that link is handled by a subset of those TRILL switches
+   called "Appointed Forwarders" as originally specified in RFC 6325,
+   with the intent that native traffic in each VLAN be handled by at
+   most one TRILL switch.  This document clarifies and updates the
+   Appointed Forwarder mechanism.  It updates RFCs 6325 and 7177 and
+   obsoletes RFC 6439.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8139.
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 1]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 2]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Appointed Forwarders and Active-Active .....................5
+      1.2. Terminology and Abbreviations ..............................6
+   2. Appointed Forwarders and Their Appointment ......................7
+      2.1. The Appointment Databases and DRB Actions ..................8
+      2.2. Appointment Effects of DRB Elections ......................10
+           2.2.1. Processing Forwarder Appointments in Hellos ........11
+           2.2.2. Frequency of Hello Appointments ....................13
+           2.2.3. Appointed Forwarders Hello Limit ...................13
+      2.3. Effects of Local Configuration Actions on Appointments ....14
+      2.4. Overload and Appointed Forwarders .........................14
+      2.5. VLAN Mapping within a Link ................................15
+   3. The Inhibition Mechanism .......................................15
+      3.1. Inhibited Appointed Forwarder Behavior ....................18
+      3.2. Root Bridge Change Inhibition Optimizations ...............18
+           3.2.1. Optimization for Change to Lower Priority ..........19
+           3.2.2. Optimization for Change to Priority Only ...........19
+           3.2.3. Optimizing the Detection of Completed Settling .....19
+   4. Optional TRILL Hello Reduction .................................20
+   5. Multiple Ports on the Same Link ................................22
+   6. Port-Shutdown Messages .........................................23
+      6.1. Planned Shutdown and Hellos ...............................23
+      6.2. Port-Shutdown Message Structure ...........................23
+      6.3. Port-Shutdown Message Transmission ........................24
+      6.4. Port-Shutdown Message Reception ...........................25
+      6.5. Port-Shutdown Message Security ............................25
+      6.6. Port-Shutdown Configuration ...............................26
+   7. FGL-VLAN Mapping Consistency Checking ..........................26
+   8. Support of E-L1CS ..............................................27
+      8.1. Backward Compatibility ....................................27
+   9. Security Considerations ........................................28
+   10. Code Points and Data Structures ...............................28
+      10.1. IANA Considerations ......................................28
+      10.2. AppointmentBitmap APPsub-TLV .............................29
+      10.3. AppointmentList APPsub-TLV ...............................30
+      10.4. FGL-VLAN-Bitmap APPsub-TLV ...............................31
+      10.5. FGL-VLAN-Pairs APPsub-TLV ................................32
+   11. Management Considerations .....................................33
+   12. References ....................................................34
+      12.1. Normative References .....................................34
+      12.2. Informative References ...................................36
+   Appendix A. VLAN Inhibition Example ...............................37
+   Appendix B. Multi-Link VLAN Mapping Loop Example ..................38
+   Appendix C. Changes to RFCs 6325, 6439, and 7177 ..................39
+   Acknowledgments ...................................................40
+   Authors' Addresses ................................................41
+
+
+
+Eastlake, et al.             Standards Track                    [Page 3]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+1.  Introduction
+
+   The IETF TRILL (Transparent Interconnection of Lots of Links)
+   protocol [RFC6325] [RFC7780] provides optimal pairwise data frame
+   forwarding without configuration in multi-hop networks with arbitrary
+   topology and link technology, safe forwarding even during periods of
+   temporary loops, and support for multipathing of both unicast and
+   multicast traffic.  TRILL accomplishes these by using IS-IS
+   (Intermediate System to Intermediate System) [IS-IS] [RFC7176]
+   link-state routing and encapsulating traffic using a header that
+   includes a hop count.  The design supports VLANs, FGLs (Fine-Grained
+   Labels) [RFC7172], and optimization of the distribution of
+   multi-destination frames based on VLANs and multicast groups.
+   Devices that implement TRILL are called TRILL switches or "RBridges"
+   (Routing Bridges).
+
+   Section 2 of [RFC7177] discusses the environment for which the TRILL
+   protocol is designed and the differences between that environment and
+   the typical Layer 3 routing environment.
+
+   TRILL supports multi-access LAN (Local Area Network) links that can
+   have multiple end stations and TRILL switches attached.  Where
+   multiple TRILL switches are attached to a link, native traffic to and
+   from end stations on that link is handled by a subset of those
+   switches called "Appointed Forwarders" as originally specified in
+   [RFC6325], with the intent that native traffic in each VLAN be
+   handled by at most one switch.  A TRILL switch can be Appointed
+   Forwarder for many VLANs.
+
+   The purpose of this document is to update and improve the Appointed
+   Forwarder mechanism and free it from the limitations imposed by the
+   requirement in its initial design that all appointments fit within a
+   TRILL Hello Protocol Data Unit (PDU).  This is accomplished by
+   requiring support of link-scoped FS-LSPs (Flooding Scope Link State
+   PDUs) (Section 8) and providing the option to send appointment
+   information in those LSPs.  In addition, this document provides a
+   number of other optional features to
+
+   1. detect inconsistent VLAN-ID-to-FGL [RFC7172] mappings among the
+      TRILL switch ports on a link, as discussed in Section 7,
+
+   2. expedite notification of ports going down so that Appointed
+      Forwarders can be adjusted, as discussed in Section 6, and
+
+   3. reduce or eliminate the need for "inhibition" of ports for loop
+      safety, as discussed in Section 3.2.
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 4]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   This document replaces and obsoletes [RFC6439], incorporating the
+   former material in [RFC6439] with these additions.  The various
+   optimizations are orthogonal and optional.  Implementers can choose
+   to provide all, some, or none of them, and TRILL switches will still
+   be interoperable.  In accordance with the TRILL design philosophy,
+   these optimizations require zero or minimal configuration, but there
+   are a couple of configurable parameters, as summarized in Section 11.
+
+   As described in Appendix C, this document updates [RFC6325] by
+   mandating support of E-L1CS FS-LSPs and provides backward
+   compatibility in the presence of legacy TRILL switches that do not
+   provide this support.  It also updates [RFC7177] by providing, as an
+   optional optimization, that receipt of the Port-Shutdown message
+   specified herein be treated as an event in the state machine
+   specified in [RFC7177].
+
+   This document includes reference implementation details.  Alternative
+   implementations that interoperate on the wire are permitted.
+
+   The Appointed Forwarder mechanism is irrelevant to any link on which
+   end-station service is not offered.  This includes links configured
+   as point-to-point IS-IS links and any link with all TRILL switch
+   ports on that link configured as trunk ports.  (In TRILL,
+   configuration of a port as a "trunk port" just means that no
+   end-station service will be provided.  It does not imply that all
+   VLANs are enabled on that port.)
+
+   The Appointed Forwarder mechanism has no effect on the formation of
+   adjacencies, the election of the Designated RBridge (DRB) [RFC7177]
+   for a link, MTU matching, or pseudonode formation.  Those topics are
+   covered in [RFC7177].  Furthermore, Appointed Forwarder status has
+   no effect on the forwarding of TRILL Data frames; it only affects the
+   handling of native frames to and from end stations.
+
+   For other aspects of the TRILL base protocol, see [RFC6325],
+   [RFC7177], and [RFC7780].  In cases of conflict between this document
+   and [RFC6325] or [RFC7177], this document prevails.
+
+1.1.  Appointed Forwarders and Active-Active
+
+   As discussed in [RFC7379], TRILL active-active provides support for
+   end stations connected to multiple edge TRILL switches where these
+   connections are separate links.  Since TRILL Hellos are not forwarded
+   between these links, the Appointed Forwarder mechanism as described
+   herein operates separately on each such link.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 5]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+1.2.  Terminology and Abbreviations
+
+   This document uses the abbreviations and terms defined in [RFC6325],
+   some of which are repeated below for convenience, and additional
+   abbreviations and terms listed below.
+
+   Data Label mapping: The mapping from VLAN ID to FGL and from FGL to
+      VLAN ID.
+
+   DRB: Designated RBridge.  The RBridge on a link elected as specified
+      in [RFC7177] to handle certain decisions and tasks for that link,
+      including forwarder appointment as specified herein.
+
+   E-L1CS: Extended Level 1 Circuit Scope (Section 8).
+
+   FGL: Fine-Grained Label [RFC7172].
+
+   FS-LSP: Flooding Scope Link State PDU (Section 8).
+
+   Link: The means by which adjacent TRILL switches are connected.  A
+      TRILL link may be various technologies and, in the common case of
+      Ethernet, can be a "bridged LAN" -- that is to say, some
+      combination of Ethernet links with zero or more bridges, hubs,
+      repeaters, or the like.
+
+   LSDB: Link State Database.
+
+   PDU: Protocol Data Unit.
+
+   RBridge: An alternative name for a TRILL switch.
+
+   TRILL: Transparent Interconnection of Lots of Links or Tunneled
+      Routing in the Link Layer.
+
+   TRILL switch: A device implementing the TRILL protocol.  An
+      alternative name for an RBridge.
+
+   Trunk port: A TRILL switch port configured with the "end-station
+      service disable" bit on, as described in Section 4.9.1 of
+      [RFC6325].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 6]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+2.  Appointed Forwarders and Their Appointment
+
+   The Appointed Forwarder on a link for VLAN-x is the TRILL switch
+   (RBridge) that ingresses native frames from the link and egresses
+   native frames to the link in VLAN-x.  By default, the DRB (Designated
+   RBridge) on a link is in charge of native traffic for all VLANs on
+   the link.  The DRB may, if it wishes, act as Appointed Forwarder for
+   any VLAN, and it may appoint other TRILL switches that have ports on
+   the link as Appointed Forwarder for one or more VLANs.
+
+   By definition, the DRB considers the other ports on the link to be
+   the ports with which a DRB port has adjacency on that link [RFC7177].
+   If the DRB loses adjacency to a TRILL switch that it has appointed
+   as forwarder and the native traffic that was being handled by that
+   Appointed Forwarder is still to be ingressed and egressed, it SHOULD
+   immediately appoint another forwarder or itself become the forwarder
+   for that traffic.
+
+   It is important that there not be two Appointed Forwarders on a link
+   that are ingressing and egressing native frames for the same VLAN at
+   the same time.  Should this occur, it could form a loop where frames
+   are not protected by a TRILL Hop Count for part of the loop.  (Such a
+   condition can even occur through two Appointed Forwarders for two
+   different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the
+   link are configured to map frames between VLAN-x and VLAN-y as
+   discussed in Section 2.5.)  While TRILL tries to avoid such
+   situations, for loop safety there is also an "inhibition" mechanism
+   (see Section 3) that can cause a TRILL switch that is an Appointed
+   Forwarder not to ingress or egress native frames.  Appointed
+   Forwarder status and port "inhibition" have no effect on the
+   reception, transmission, or forwarding of TRILL Data or TRILL IS-IS
+   frames.  Appointed Forwarder status and inhibition only affect the
+   handling of native frames.
+
+   As discussed in Section 5, an RBridge may have multiple ports on a
+   link.  As discussed in [RFC7177], if there are multiple ports with
+   the same Media Access Control (MAC) address on the same link, all but
+   one will be suspended.  The case of multiple ports on a link for the
+   same TRILL switch and the case of multiple ports with the same MAC
+   address on a link, as well as combinations of these cases, are fully
+   accommodated; however, the case of multiple ports on a link for the
+   same TRILL switch is expected to be a rare condition, and the case of
+   duplicate MAC addresses is not recommended by either TRILL or
+   IEEE 802.1 standards.
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 7]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   There are six mechanisms by which an RBridge can be appointed or
+   unappointed as Appointed Forwarder:
+
+   1. assumption of appointment, when the DRB decides to act as
+      Appointed Forwarder for a VLAN,
+
+   2. E-L1CS appointment, as a result of appointments sent by the DRB in
+      E-L1CS FS-LSPs,
+
+   3. Hello appointment, as a result of appointments sent by the DRB in
+      TRILL Hellos,
+
+   4. as a result of the DRB elections [RFC7177] as discussed in
+      Section 2.2,
+
+   5. as a result of a Port-Shutdown message as discussed in Section 6,
+      and
+
+   6. as a result of a local configuration action as discussed in
+      Section 2.3.
+
+   Mechanisms 2 and 3 are covered in Section 2.1.
+
+2.1.  The Appointment Databases and DRB Actions
+
+   The DRB MAY appoint other RBridges on the link as Appointed
+   Forwarders through two mechanisms, "A" and "B", as described below.
+
+   Each RBridge maintains two databases of appointment information:
+   (1) its E-L1CS LSDB, which shows appointments that each RBridge on
+   the link would make using mechanism A if that RBridge were the DRB,
+   and (2) its Hello appointment database, which shows the appointments
+   most recently sent by the DRB in a TRILL Hello.  The E-L1CS LSDB is
+   semi-permanent and is only changed by E-L1CS FS-LSPs or IS-IS purges.
+   The Hello appointment database is more transient and is completely
+   reset by each Hello received from the DRB that contains any
+   appointments; this database is also cleared under other
+   circumstances, as described below.  An RBridge considers itself to be
+   the Appointed Forwarder for VLAN-x if this is indicated by either its
+   Hello appointment database or its E-L1CS LSDB entries from the DRB.
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 8]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   The two mechanisms by which the DRB can appoint other RBridges on a
+   link as Appointed Forwarders are as follows:
+
+   (A) The inclusion of one or more Appointed Forwarders sub-TLVs
+       [RFC7176], AppointmentBitmap APPsub-TLVs (Section 10.2), or
+       AppointmentList APPsub-TLVs (Section 10.3) in E-L1CS LSPs it
+       sends on a link.  Appointments sent using this method will not be
+       seen by legacy RBridges that do not support E-L1CS (Section 8).
+
+   (B) The inclusion of one or more Appointed Forwarders sub-TLVs
+       [RFC7176] in a TRILL Hello it sends on the Designated VLAN out of
+       the port that won the DRB election.  When the DRB sends any
+       appointments in a TRILL Hello, it must send all appointments it
+       is sending in Hellos for that link in that Hello.  Any previous
+       appointment it has sent in a Hello that is not included is
+       implicitly revoked.
+
+   To avoid the size limitations of the Hello PDU, it is RECOMMENDED
+   that the E-L1CS FS-LSP method be used to distribute forwarder
+   appointments and that all RBridges on a link use this method to
+   advertise the appointments they would make if they were the DRB.
+   However, if some RBridges on a link do not support E-L1CS FS-LSPs,
+   then Hello appointments must be used for the DRB to appoint such
+   legacy RBridges as Appointed Forwarders.
+
+   Although the DRB does not need to announce the VLANs for which it has
+   chosen to act as Appointed Forwarder by sending appointments for
+   itself, if the DRB wishes to revoke all appointments made in Hellos
+   for RBridges other than itself on the link, it can do so by sending a
+   TRILL Hello with just an appointment for itself for some VLAN.
+
+   How the DRB decides what other RBridges on the link, if any, to
+   appoint as forwarder for some VLAN or VLANs is beyond the scope of
+   this document.
+
+   Unnecessary changes in Appointed Forwarders SHOULD NOT be made, as
+   they may result in transient lack of end-station service.
+
+   Should the network manager have misconfigured the enabled VLANs and
+   Appointed Forwarders, resulting in two RBridges believing they are
+   Appointed Forwarders for the same VLAN, the scenario described in
+   item 4 in Section 3 will cause one or more of the RBridges to be
+   inhibited for that VLAN, thus avoiding persistent loops.
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 9]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   When forwarder appointments are being encoded for transmission,
+   different patterns of VLANs are most efficiently encoded in different
+   ways.  The following table gives advice regarding the most efficient
+   encoding for a given pattern:
+
+                            sub-TLV and Reference
+   Pattern of VLAN IDs          |enclosing TLV(s) and Reference
+   -------------------      ------------------------------------
+
+   Blocks of consecutive VLANs
+                            Appointed Forwarders sub-TLV [RFC7176]
+                                |Router CAPABILITY TLV [RFC7981]
+                                |or MT-Capability TLV [RFC6329]
+
+   Scattered VLANs within a small range
+                            AppointmentBitmap APPsub-TLV (Section 10.2)
+                                |TRILL GENINFO TLV [RFC7357]
+
+   Scattered VLANs over a large range
+                            AppointmentList APPsub-TLV (Section 10.3)
+                                |TRILL GENINFO TLV [RFC7357]
+
+2.2.  Appointment Effects of DRB Elections
+
+   When a TRILL switch port on a link wins the DRB election, there are
+   four possible cases:
+
+   1. A TRILL switch believes that it was the DRB and remains the DRB:
+      there is no change in Appointed Forwarder status.  This also
+      applies in the corner case where a TRILL switch has more than one
+      port on a link, one of which was previously the DRB election
+      winner but has just lost the DRB election to a different port of
+      the same TRILL switch on the same link (possibly due to management
+      configuration of port priorities).  In this case, there also is no
+      change in which TRILL switch is the DRB.
+
+   2. A TRILL switch believes that it was not the DRB but has now won
+      the DRB election and become the DRB on a link: by default, it can
+      act as Appointed Forwarder for any VLANs on that link that it
+      chooses, as long as its port is not configured as a trunk port and
+      has that VLAN enabled (or at least one of its ports meets these
+      criteria, if it has more than one port on the link).  It ignores
+      any previous forwarder appointment information it received from
+      other TRILL switches on the link.
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 10]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   3. A TRILL switch was not the DRB and does not become the DRB, but it
+      observes that the port winning the DRB election has changed: the
+      TRILL switch loses all Hello appointments.  In addition, there are
+      two subcases:
+
+      a. The new winning port and the old winner are ports of different
+         TRILL switches on the link.  In this case, it switches to using
+         the E-L1CS FS-LSP appointments for the winning TRILL switch.
+
+      b. The new winning port and the old winner are ports of the same
+         TRILL switch, which has two (or more) ports on the link:
+         although the Hello appointments are still discarded, since the
+         same TRILL switch is the DRB, the E-L1CS FS-LSP appointments
+         are unchanged.
+
+   4. The winning port is unchanged: as in case 1, there is no change in
+      Appointed Forwarder status.
+
+2.2.1.  Processing Forwarder Appointments in Hellos
+
+   When a non-DRB RBridge that can offer end-station service on a link
+   receives a TRILL Hello that is not discarded for one of the reasons
+   given in [RFC7177], it checks the source MAC address and the Port ID
+   and System ID in the Hello to determine if it is from the winning DRB
+   port.  If it is not from that port, any forwarder appointment
+   sub-TLVs in the Hello are ignored, and there is no change in the
+   receiving RBridge's Appointed Forwarder status due to that Hello.
+   Also, if no forwarder appointment sub-TLVs are present in the TRILL
+   Hello, there is no change in the receiver's Appointed Forwarder
+   status due to that Hello.
+
+   However, if the TRILL Hello is from the winning DRB port and the
+   Hello includes one or more forwarder appointment sub-TLVs, then the
+   receiving RBridge sets its Hello appointment database to be the set
+   of VLANs that have both of the following characteristics:
+
+   o  The VLAN is listed as an appointment for the receiving RBridge in
+      the Hello, and
+
+   o  The VLAN is enabled on the port where the Hello was received.
+
+   (If the appointment includes VLAN IDs 0x000 or 0xFFF, they are
+   ignored, but any other VLAN IDs are still effective.)  It then
+   becomes Appointed Forwarder for all the VLANs for which it is
+   appointed in either its Hello appointment database or its E-L1CS
+   FS-LSP appointment database from the DRB if the VLAN is enabled and
+   if the port is not configured as a trunk or IS-IS point-to-point
+   port.  If the receiver was Appointed Forwarder for any VLANs because
+
+
+
+Eastlake, et al.             Standards Track                   [Page 11]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   they were in the Hello appointment database and they are no longer in
+   the Hello appointment database, its Appointed Forwarder status for
+   such VLANs is revoked.  For example, if none of these sub-TLVs in a
+   Hello appoints the receiving RBridge, then it loses all Appointed
+   Forwarder status on the port where the Hello was received due to
+   Hello appointment database entries, but it retains Appointed
+   Forwarder status due to E-L1CS FS-LSP appointments.
+
+   The handling of one or more forwarder appointment sub-TLVs in a Hello
+   from the winning port that appoints the receiving RBridge is as
+   follows: an appointment in an Appointed Forwarders sub-TLV is for a
+   specific RBridge and a contiguous interval of VLAN IDs; however, as
+   stated above, it actually appoints that RBridge as forwarder only for
+   the VLAN or VLANs in that range that are enabled on one or more ports
+   that RBridge has on the link (ignoring any ports configured as
+   trunk ports or as IS-IS point-to-point ports).
+
+   There is no reason for an RBridge to remember that it received a
+   valid appointment Hello message for a VLAN that was ineffective
+   because the VLAN was not enabled on the port where the Hello was
+   received or because the port was a trunk or point-to-point port.  It
+   does not become Appointed Forwarder for such a VLAN just because that
+   VLAN is later enabled or the port is later reconfigured.
+
+   The limitations due to the size of the Hello PDU make it desirable to
+   use E-L1CS FS-LSPs for appointment.  But if Hellos need to be used,
+   due to TRILL switches on the link not supporting E-L1CS FS-LSPs, the
+   remainder of this section provides a method to maximize the use of
+   the limited space in Hellos for forwarder appointment.
+
+   It should be straightforward for the DRB to send, within one Hello,
+   the appointments for several dozen VLAN IDs or several dozen blocks
+   of contiguous VLAN IDs.  Should the VLANs that the DRB wishes to
+   appoint be inconveniently distributed (for example, the proverbial
+   case where a DRB (say RB1) wishes to appoint RB2 as forwarder for all
+   even-numbered VLANs and appoint RB3 as forwarder for all odd-numbered
+   VLANs), the following method may be used:
+
+      The network manager normally controls what VLANs are enabled on an
+      RBridge port.  Thus, the network manager can appoint an RBridge as
+      forwarder for an arbitrary set of scattered VLANs by enabling only
+      those VLANs on the relevant port (or ports) and then having the
+      DRB send an appointment that appears to appoint the target RBridge
+      as forwarder for all VLANs.  However, for proper operation and
+      inter-RBridge communication, the Designated VLAN for a link SHOULD
+      be enabled on all RBridge ports on that link, and it may not be
+      desired to appoint the RBridge as forwarder for the
+      Designated VLAN.  Thus, in the general case, two appointments
+
+
+
+Eastlake, et al.             Standards Track                   [Page 12]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+      would be required, although only one appointment would be required
+      if the Designated VLAN value were extremely low or high (such as
+      VLAN 0xFFE) or the default value (VLAN 1).
+
+   For example, assume that the DRB wants RB2 to be Appointed Forwarder
+   for all even-numbered VLANs and the Designated VLAN for the link is
+   VLAN 101.  The network manager could cause all even-numbered VLANs
+   plus VLAN 101 to be enabled on the relevant port of RB2 and then,
+   with the desired effect, cause the DRB to send appointments to RB2
+   appointing it forwarder for all VLANs from 1 through 100 and from 102
+   through 4,094.
+
+2.2.2.  Frequency of Hello Appointments
+
+   Appointments made through E-L1CS FS-LSPs use the same IS-IS timing
+   constants as those for LSP flooding.  The general IS-IS link-state
+   flooding mechanism is robust and includes acknowledgments so that it
+   automatically recovers from lost PDUs, rebooted TRILL switches, and
+   the like.
+
+   For Hello appointments, it is not necessary for the DRB to include
+   the Hello forwarder appointments in every TRILL Hello that it sends
+   on the Designated VLAN for a link.  For loop safety, every RBridge is
+   required to indicate, in every TRILL Hello it sends in VLAN-x on a
+   link, whether it is an Appointed Forwarder for VLAN-x for that link
+   (see item 4 in Section 3, but see also Section 4).  It is also
+   RECOMMENDED that the DRB have enabled all VLANs for which end-station
+   service will be offered on the link as well as the Designated VLAN.
+   Thus, the DRB will generally be informed by other RBridges on the
+   link of the VLANs for which they believe that they are the Appointed
+   Forwarder.  If this matches the appointments the DRB wishes to make,
+   it is not required to resend its forwarder appointments; however, for
+   robustness, especially in cases such as VLAN misconfigurations in a
+   bridged LAN link, it is RECOMMENDED that the DRB send its forwarder
+   appointments on the Designated VLAN at least once per its Holding
+   Time on the port that won the DRB election.
+
+2.2.3.  Appointed Forwarders Hello Limit
+
+   The Hello mechanism of DRB forwarder appointment and the limited
+   length of TRILL Hellos impose a limit on the number of RBridges on a
+   link that can be Appointed Forwarders when E-L1CS FS-LSP appointments
+   cannot be used due to the presence of legacy RBridges.  To obtain a
+   conservative estimate of this limit, assume that no more than
+   1,000 bytes are available in a TRILL Hello for such appointments.
+   Assume also that it is desired to appoint various RBridges on a link
+   as forwarder for arbitrary non-intersecting sets of VLANs.  Using the
+   technique discussed at the end of Section 2.2.1 would generally
+
+
+
+Eastlake, et al.             Standards Track                   [Page 13]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   require two appointments, or 12 bytes, per RBridge.  With allowance
+   for sub-TLV and TLV overhead, appointments for 83 RBridges would
+   fit in under 1,000 bytes.  Including the DRB, this implies a link
+   with 84 or more RBridges attached.  Links with more than a handful of
+   RBridges attached are expected to be rare, and in any case such
+   limitations are easily avoided by using E-L1CS FS-LSP appointment.
+
+2.3.  Effects of Local Configuration Actions on Appointments
+
+   Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder
+   status that RBridge has for VLAN-x, unless VLAN-x is enabled on some
+   other port that the RBridge has connected to the same link.
+   Configuring a port as a trunk port or point-to-point port revokes
+   any Appointed Forwarder status that depends on enabled VLANs at
+   that port.
+
+   Causing a port to no longer be configured as a trunk or
+   point-to-point port or enabling VLAN-x on a port does not necessarily
+   cause the RBridge to become an Appointed Forwarder for the link that
+   port is on.  However, such actions allow the port's RBridge to become
+   Appointed Forwarder by choice if it is the DRB or, if it is not the
+   DRB on the link, by appointment as indicated by the Hello appointment
+   database or the E-L1CS FS-LSP appointment database.
+
+2.4.  Overload and Appointed Forwarders
+
+   A TRILL switch in link-state overload [RFC7780] will, in general, do
+   a poorer job of forwarding frames than a TRILL switch not in
+   overload, because the TRILL switch not in overload has full knowledge
+   of the campus topology.  For example, as explained in [RFC7780], an
+   overloaded TRILL switch may not be able to distribute
+   multi-destination TRILL Data packets at all.
+
+   Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an
+   Appointed Forwarder, and if an Appointed Forwarder becomes
+   overloaded, the DRB SHOULD reassign VLANs from the overloaded RBridge
+   to another RBridge on the link that is not overloaded, if one is
+   available.
+
+   A counter-example where it would be best to appoint an RBridge in
+   overload as Appointed Forwarder would be if RB1 was in overload but
+   all end stations in the campus in VLAN-x were on links attached to
+   RB1.  In such a case, RB1 would never have to route VLAN-x
+   end-station traffic as TRILL Data packets but would always be
+   forwarding them locally as native frames.  In this case, RB1
+   SHOULD NOT be disadvantaged for selection as the VLAN-x Appointed
+   Forwarder on any such links, even if RB1 is in overload.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 14]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   There is also the case where it is unavoidable to appoint an RBridge
+   in overload as Appointed Forwarder, because all RBridges on the link
+   are in overload.
+
+   These cases do not violate the prohibition in the IS-IS standard
+   against routing through an overloaded node.  Designation as an
+   Appointed Forwarder has to do with the ingress and egress of native
+   frames and has nothing to do with the IS-IS routing of TRILL Data
+   packets through a TRILL switch.
+
+   Overload does not affect DRB election, but a TRILL switch in overload
+   MAY reduce its own priority to be the DRB.
+
+2.5.  VLAN Mapping within a Link
+
+   TRILL Hellos include a field that is set to the VLAN in which they
+   are sent when they are sent on a link technology such as Ethernet
+   that has outer VLAN labeling.  (For link technologies such as PPP
+   that do not have outer VLAN labeling, this Hello field is ignored.)
+   If a TRILL Hello arrives on a different VLAN than the VLAN on which
+   it was sent, then VLAN mapping is occurring within the link.  VLAN
+   mapping between VLAN-x and VLAN-y can lead to a loop if the Appointed
+   Forwarders for the VLANs are different.  If such mapping within a
+   link was allowed and occurred on two or more links so that there was
+   a cycle of VLAN mappings, a multi-destination frame would loop
+   forever.  Such a frame would be "immortal".  For a specific example,
+   see Appendix B.
+
+   To prevent this potential problem, if the DRB on a link detects VLAN
+   mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it
+   MUST make or revoke appointments so as to assure that the same TRILL
+   switch (possibly the DRB) is the Appointed Forwarder on the link for
+   both VLAN-x and VLAN-y.
+
+3.  The Inhibition Mechanism
+
+   A TRILL switch has, for every link on which it can offer end-station
+   service (that is, every link for which it can act as an Appointed
+   Forwarder), the following timers, denominated in seconds:
+
+   -  a DRB inhibition timer,
+
+   -  a root bridge change inhibition timer, and
+
+   -  up to 4,094 VLAN inhibition timers, one for each legal VLAN ID.
+
+   The DRB and root bridge change inhibition timers MUST be implemented.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 15]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   The loss of native traffic due to inhibition will be minimized by
+   logically implementing a VLAN inhibition timer per each VLAN for
+   which end-station service will ever be offered by the RBridge on the
+   link; this SHOULD be done.  (See Appendix A for an example
+   illustrating a potential problem that is solved by VLAN inhibition
+   timers.)  However, if implementation limitations make a full set of
+   such timers impractical, the VLAN inhibition timers for more than one
+   VLAN can, with care, be merged into one timer.  In particular, an
+   RBridge MUST NOT merge the VLAN inhibition timers for two VLANs if it
+   is the Appointed Forwarder for one but not for the other, as this can
+   lead to unnecessary indefinitely prolonged inhibition.  In a given
+   implementation limitation, there will be safe operations, albeit with
+   more loss of native frames than would otherwise be required, even if
+   only two VLAN inhibition timers are provided: one for the VLANs for
+   which the RBridge is the Appointed Forwarder and one for all other
+   VLANs.  Thus, at least two VLAN inhibition timers MUST be
+   implemented.  Where a VLAN inhibition timer represents more than one
+   VLAN, an update or test that would have been done to the timer for
+   any of the VLANs is performed on the merged timer.
+
+   These timers are set as follows:
+
+   1. On booting or management reset, each port will have its own set of
+      timers, even if two or more such ports are on the same link,
+      because the TRILL switch will not have had a chance yet to learn
+      that they are on the same link.  All inhibition timers are set to
+      "expired", except the DRB inhibition timer that is set in
+      accordance with item 2 below.  The DRB inhibition timer is handled
+      differently, because each port will initially believe that it is
+      the DRB.
+
+   2. When a TRILL switch decides that it has become the DRB on a link,
+      including when it is first booted or reset by management, it sets
+      the DRB inhibition timer to the Holding Time of its port on that
+      link that won the DRB election.
+
+   3. When a TRILL switch decides that it has lost DRB status on a link,
+      it sets the DRB inhibition timer to "expired".
+
+   Note: In the corner case where one port of a TRILL switch was the DRB
+   election winner but later lost the DRB election to a different port
+   of the same TRILL switch on that link (perhaps due to management
+   configuration of port priorities), neither item 2 nor item 3 above
+   applies, and the DRB timer is not changed.
+
+   4. When a TRILL switch RB1 receives a TRILL Hello asserting that the
+      sender is the Appointed Forwarder and that Hello either
+      (1) arrives on VLAN-x or (2) was sent on VLAN-x as indicated
+
+
+
+Eastlake, et al.             Standards Track                   [Page 16]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+      inside the Hello, RB1 uses as its VLAN-x inhibition timer for the
+      link (1) that timer's existing value or (2) the Holding Time in
+      the received Hello, whichever is longer.  A TRILL switch MUST
+      maintain VLAN inhibition timers covering a link to which it
+      connects if it can offer end-station service on that link, even if
+      it is not currently the Appointed Forwarder for any VLAN on that
+      link.
+
+   5. When a TRILL switch RB1 enables VLAN-x on a port connecting to a
+      link and VLAN-x was previously not enabled on any of RB1's ports
+      on that link, it sets its VLAN inhibition timer for VLAN-x for
+      that link to its Holding Time for that port.  This is done even if
+      the port is configured as a trunk or point-to-point port, as long
+      as there is some chance it might later be configured not to be a
+      trunk or point-to-point port.  Remember, inhibition has no effect
+      on TRILL Data or IS-IS packets; inhibition only affects native
+      frames.
+
+   6. When a TRILL switch detects a change in the common spanning tree
+      root bridge on a port, it sets its root bridge change inhibition
+      timer for the link to an amount of time that defaults to
+      30 seconds and is configurable to any value from 30 down to
+      0 seconds.  This condition will not occur unless the TRILL switch
+      is receiving Bridge PDUs (BPDUs) on the port from an attached
+      bridged LAN; if no BPDUs are being received, the root bridge
+      change inhibition timer will never be set.  It is safe to
+      configure this inhibition time to the settling time of an attached
+      bridged LAN.  For example, if it is known that the Rapid Spanning
+      Tree Protocol (RSTP) [802.1Q] is running throughout the attached
+      bridged LAN, it is safe to configure this inhibition time to
+      7 seconds or, if the attached bridges have been configured to have
+      a minimum Bridge Hello Timer, it is safe to configure it to
+      4 seconds.  Further optimizations are specified in Section 3.2.
+
+   7. When a TRILL switch decides that one of its ports (or a set of its
+      ports) P1 is on the same link as another one of its ports (or set
+      of its ports) P2, the inhibition timers are merged into a single
+      set of inhibition timers by using the longest value of the
+      corresponding timers as the initial value of the merged timers.
+
+   8. When an RBridge decides that a set of its ports that it had been
+      treating as being on the same link are no longer on the same link,
+      those ports will necessarily be on two or more links (up to one
+      link per port).  This is handled by cloning a copy of the timers
+      for each of the two or more links to which the TRILL switch has
+      decided these ports connect.
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 17]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+3.1.  Inhibited Appointed Forwarder Behavior
+
+   Inhibition has no effect on the receipt or forwarding of TRILL Data
+   packets or TRILL IS-IS packets.  It only affects ingressing and
+   egressing native frames.
+
+   An Appointed Forwarder for a link is inhibited for VLAN-x if:
+
+   1. its DRB inhibition timer for that link is not expired,
+
+   2. its root bridge change inhibition timer for that link is not
+      expired, or
+
+   3. its VLAN inhibition timer for that link covering VLAN-x is not
+      expired.
+
+   If a VLAN-x Appointed Forwarder for a link is inhibited and receives
+   a TRILL Data packet whose encapsulated frame would normally be
+   egressed to that link in VLAN-x, it decapsulates the native frame as
+   usual.  However, it does not output it to, or queue it for, that
+   link, although, if appropriate (for example, the frame is
+   multi-destination), it may output it to, or queue it for, other
+   links.
+
+   If a VLAN-x Appointed Forwarder for a link is inhibited and receives
+   a native frame in VLAN-x that would normally be ingressed from that
+   link, the native frame is ignored, except for address learning.
+
+   A TRILL switch with one or more unexpired inhibition timers, possibly
+   including an unexpired inhibition timer covering VLAN-x, is still
+   required to indicate in TRILL Hellos it sends on VLAN-x whether or
+   not it is Appointed Forwarder for VLAN-x for the port on which it
+   sends the Hello.
+
+3.2.  Root Bridge Change Inhibition Optimizations
+
+   The subsections below specify three optimizations that can reduce the
+   inhibition time of an RBridge port under certain circumstances for
+   changes in the root Bridge ID [802.1Q] being received by that port
+   and thus decrease any transient interruption in end-station service
+   due to inhibition.  TRILL switches MAY implement these optimizations.
+   In the first two optimizations, inhibition can be eliminated entirely
+   under some circumstances.  These optimizations are a bit heuristic in
+   that with some unlikely multiple changes in a bridged LAN that occur
+   simultaneously, or nearly so, the optimizations make transient
+   looping more likely.
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 18]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+3.2.1.  Optimization for Change to Lower Priority
+
+   Assume that the root Bridge ID being received on an RBridge port
+   changes to a new root Bridge ID with lower priority and a different
+   root Bridge MAC address due to a single change in the bridged LAN.
+   There are two possible reasons for this:
+
+   1. The bridged LAN to which the port is connected has partitioned
+      into two or more parts due to link failure or otherwise, and the
+      port is connected to a part that does not contain the original
+      root bridge.
+
+   2. The original root bridge has been reconfigured to have a lower
+      priority, and a new root has taken over.
+
+   Both of these scenarios are safe conditions that do not require
+   inhibition.
+
+3.2.2.  Optimization for Change to Priority Only
+
+   Assume that the root Bridge ID changes due to a single change in the
+   bridged LAN but only the explicit priority portion of it changes.
+   This means that the 48-bit MAC address portion of the root Bridge ID
+   is unchanged and the root bridge has been reconfigured to have a
+   different priority.  Thus, the same bridge is root, and a topology
+   change is not indicated.  Thus, it is safe to ignore this sort of
+   root Bridge ID change and not invoke the inhibition mechanism.
+
+3.2.3.  Optimizing the Detection of Completed Settling
+
+   A dangerous case is the merger of bridged LANs that had been separate
+   TRILL links in the same campus.  In general, these links may have had
+   different Appointed Forwarders on them for the same VLAN.  Without
+   inhibition, loops involving those VLANs could occur after the merger.
+
+   Only native frames egressed and ingressed by RBridges are a potential
+   problem.  TRILL Data packets are either
+
+   1. individually addressed (TRILL Header M bit = 0) and will be
+      ignored if delivered to any incorrect TRILL switch ports or
+
+   2. multicast (TRILL Header M bit = 1), in which case the Reverse Path
+      Forwarding Check discards any copies delivered to incorrect TRILL
+      switch ports.
+
+   Thus, there is no need for inhibition to affect the sending or
+   receiving of TRILL Data packets, and inhibition does not do so.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 19]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   However, root bridge change inhibition is only needed until TRILL
+   Hellos have been exchanged on the merged bridged LAN.  Hellos
+   indicate Appointed Forwarder status and, in general, after an
+   exchange of Hellos the new merged bridged LAN link will, if
+   necessary, be rendered TRILL loop safe by VLAN inhibition so that
+   root bridge change inhibition is no longer needed.
+
+   TRILL switches are required to advertise in their link state the IDs
+   of the root Bridge IDs they can see.  If an RBridge port sees a
+   change in root Bridge ID from Root1 to Root2, it is safe to terminate
+   root bridge change inhibition on that port as soon as Hellos have
+   been received on the port from all RBridges that can see Root1 or
+   Root2, except any such RBridge that is no longer reachable.
+
+   In further detail, when a change from Root1 to Root2 is noticed at a
+   port of RB1, RB1 associates with that port a list of all of the
+   reachable RBridges, other than itself, that had reported in their
+   LSPs that they could see either Root1 or Root2.  It then removes from
+   this list any RBridge that becomes unreachable from RB1 or from which
+   it has received a Hello on that port.  If there is a subsequent
+   change in root Bridge ID being received before this list is empty,
+   say to Root7, then those RBridges reporting in their LSPs that they
+   can see Root7 are added to the list.  Root bridge change inhibition
+   can be terminated for the port as soon as either the timeout is
+   reached or this list of RBridges is empty.
+
+   If the optimizations described in Sections 3.2.1 and/or 3.2.2 are in
+   effect at an RBridge port and indicate that no inhibition is needed,
+   then the mechanism described in this section is not needed either.
+
+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
+
+
+
+Eastlake, et al.             Standards Track                   [Page 20]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 21]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 22]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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].
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 23]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+      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.
+
+
+
+Eastlake, et al.             Standards Track                   [Page 24]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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].
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 25]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+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.
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 26]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 27]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+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]
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 28]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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.
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 29]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 30]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 31]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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)
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 32]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+      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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 33]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+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>.
+
+
+
+Eastlake, et al.             Standards Track                   [Page 34]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 35]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 36]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 37]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+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.
+
+
+
+Eastlake, et al.             Standards Track                   [Page 38]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 39]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+   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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 40]
+
+RFC 8139               TRILL: Appointed Forwarders             June 2017
+
+
+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
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 41]
+