<pre>Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 8139                                         Y. Li
Obsoletes: <a href="./rfc6439">6439</a>                                                   Huawei
Updates: <a href="./rfc6325">6325</a>, <a href="./rfc7177">7177</a>                                             M. Umair
Category: Standards Track                                    IP Infusion
ISSN: 2070-1721                                              A. Banerjee
                                                                   Cisco
                                                                   F. Hu
                                                                     ZTE
                                                               June 2017


         <span class="h1">Transparent Interconnection of Lots of Links (TRILL):</span>
                          <span class="h1">Appointed Forwarders</span>

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 <a href="./rfc6325">RFC 6325</a>,
   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 <a href="./rfc6439">RFC 6439</a>.

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 <a href="./rfc7841#section-2">Section&nbsp;2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc8139">http://www.rfc-editor.org/info/rfc8139</a>.










<span class="grey">Eastlake, et al.             Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.





































<span class="grey">Eastlake, et al.             Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Appointed Forwarders and Active-Active .....................<a href="#page-5">5</a>
      <a href="#section-1.2">1.2</a>. Terminology and Abbreviations ..............................<a href="#page-6">6</a>
   <a href="#section-2">2</a>. Appointed Forwarders and Their Appointment ......................<a href="#page-7">7</a>
      <a href="#section-2.1">2.1</a>. The Appointment Databases and DRB Actions ..................<a href="#page-8">8</a>
      <a href="#section-2.2">2.2</a>. Appointment Effects of DRB Elections ......................<a href="#page-10">10</a>
           <a href="#section-2.2.1">2.2.1</a>. Processing Forwarder Appointments in Hellos ........<a href="#page-11">11</a>
           <a href="#section-2.2.2">2.2.2</a>. Frequency of Hello Appointments ....................<a href="#page-13">13</a>
           <a href="#section-2.2.3">2.2.3</a>. Appointed Forwarders Hello Limit ...................<a href="#page-13">13</a>
      <a href="#section-2.3">2.3</a>. Effects of Local Configuration Actions on Appointments ....<a href="#page-14">14</a>
      <a href="#section-2.4">2.4</a>. Overload and Appointed Forwarders .........................<a href="#page-14">14</a>
      <a href="#section-2.5">2.5</a>. VLAN Mapping within a Link ................................<a href="#page-15">15</a>
   <a href="#section-3">3</a>. The Inhibition Mechanism .......................................<a href="#page-15">15</a>
      <a href="#section-3.1">3.1</a>. Inhibited Appointed Forwarder Behavior ....................<a href="#page-18">18</a>
      <a href="#section-3.2">3.2</a>. Root Bridge Change Inhibition Optimizations ...............<a href="#page-18">18</a>
           <a href="#section-3.2.1">3.2.1</a>. Optimization for Change to Lower Priority ..........<a href="#page-19">19</a>
           <a href="#section-3.2.2">3.2.2</a>. Optimization for Change to Priority Only ...........<a href="#page-19">19</a>
           <a href="#section-3.2.3">3.2.3</a>. Optimizing the Detection of Completed Settling .....<a href="#page-19">19</a>
   <a href="#section-4">4</a>. Optional TRILL Hello Reduction .................................<a href="#page-20">20</a>
   <a href="#section-5">5</a>. Multiple Ports on the Same Link ................................<a href="#page-22">22</a>
   <a href="#section-6">6</a>. Port-Shutdown Messages .........................................<a href="#page-23">23</a>
      <a href="#section-6.1">6.1</a>. Planned Shutdown and Hellos ...............................<a href="#page-23">23</a>
      <a href="#section-6.2">6.2</a>. Port-Shutdown Message Structure ...........................<a href="#page-23">23</a>
      <a href="#section-6.3">6.3</a>. Port-Shutdown Message Transmission ........................<a href="#page-24">24</a>
      <a href="#section-6.4">6.4</a>. Port-Shutdown Message Reception ...........................<a href="#page-25">25</a>
      <a href="#section-6.5">6.5</a>. Port-Shutdown Message Security ............................<a href="#page-25">25</a>
      <a href="#section-6.6">6.6</a>. Port-Shutdown Configuration ...............................<a href="#page-26">26</a>
   <a href="#section-7">7</a>. FGL-VLAN Mapping Consistency Checking ..........................<a href="#page-26">26</a>
   <a href="#section-8">8</a>. Support of E-L1CS ..............................................<a href="#page-27">27</a>
      <a href="#section-8.1">8.1</a>. Backward Compatibility ....................................<a href="#page-27">27</a>
   <a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-28">28</a>
   <a href="#section-10">10</a>. Code Points and Data Structures ...............................<a href="#page-28">28</a>
      <a href="#section-10.1">10.1</a>. IANA Considerations ......................................<a href="#page-28">28</a>
      <a href="#section-10.2">10.2</a>. AppointmentBitmap APPsub-TLV .............................<a href="#page-29">29</a>
      <a href="#section-10.3">10.3</a>. AppointmentList APPsub-TLV ...............................<a href="#page-30">30</a>
      <a href="#section-10.4">10.4</a>. FGL-VLAN-Bitmap APPsub-TLV ...............................<a href="#page-31">31</a>
      <a href="#section-10.5">10.5</a>. FGL-VLAN-Pairs APPsub-TLV ................................<a href="#page-32">32</a>
   <a href="#section-11">11</a>. Management Considerations .....................................<a href="#page-33">33</a>
   <a href="#section-12">12</a>. References ....................................................<a href="#page-34">34</a>
      <a href="#section-12.1">12.1</a>. Normative References .....................................<a href="#page-34">34</a>
      <a href="#section-12.2">12.2</a>. Informative References ...................................<a href="#page-36">36</a>
   <a href="#appendix-A">Appendix A</a>. VLAN Inhibition Example ...............................<a href="#page-37">37</a>
   <a href="#appendix-B">Appendix B</a>. Multi-Link VLAN Mapping Loop Example ..................<a href="#page-38">38</a>
   <a href="#appendix-C">Appendix C</a>. Changes to RFCs 6325, 6439, and 7177 ..................<a href="#page-39">39</a>
   Acknowledgments ...................................................<a href="#page-40">40</a>
   Authors' Addresses ................................................<a href="#page-41">41</a>



<span class="grey">Eastlake, et al.             Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] [<a href="./rfc7780" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates&quot;">RFC7780</a>] 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) [<a href="#ref-IS-IS" title="&quot;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)&quot;">IS-IS</a>] [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>]
   link-state routing and encapsulating traffic using a header that
   includes a hop count.  The design supports VLANs, FGLs (Fine-Grained
   Labels) [<a href="./rfc7172" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling&quot;">RFC7172</a>], 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).

   <a href="./rfc7177#section-2">Section&nbsp;2 of [RFC7177]</a> 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
   [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>], 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) (<a href="#section-8">Section 8</a>) 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 [<a href="./rfc7172" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling&quot;">RFC7172</a>] mappings among the
      TRILL switch ports on a link, as discussed in <a href="#section-7">Section 7</a>,

   2. expedite notification of ports going down so that Appointed
      Forwarders can be adjusted, as discussed in <a href="#section-6">Section 6</a>, and

   3. reduce or eliminate the need for "inhibition" of ports for loop
      safety, as discussed in <a href="#section-3.2">Section 3.2</a>.





<span class="grey">Eastlake, et al.             Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   This document replaces and obsoletes [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>], incorporating the
   former material in [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>] 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 <a href="#section-11">Section 11</a>.

   As described in <a href="#appendix-C">Appendix C</a>, this document updates [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] 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 [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>] 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 [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>].

   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) [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>]
   for a link, MTU matching, or pseudonode formation.  Those topics are
   covered in [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>].  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 [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>],
   [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>], and [<a href="./rfc7780" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates&quot;">RFC7780</a>].  In cases of conflict between this document
   and [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] or [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>], this document prevails.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Appointed Forwarders and Active-Active</span>

   As discussed in [<a href="./rfc7379" title="&quot;Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge&quot;">RFC7379</a>], 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.






<span class="grey">Eastlake, et al.             Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Terminology and Abbreviations</span>

   This document uses the abbreviations and terms defined in [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>],
   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 [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>] to handle certain decisions and tasks for that link,
      including forwarder appointment as specified herein.

   E-L1CS: Extended Level 1 Circuit Scope (<a href="#section-8">Section 8</a>).

   FGL: Fine-Grained Label [<a href="./rfc7172" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling&quot;">RFC7172</a>].

   FS-LSP: Flooding Scope Link State PDU (<a href="#section-8">Section 8</a>).

   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 <a href="./rfc6325#section-4.9.1">Section&nbsp;4.9.1 of
      [RFC6325]</a>.

   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
   <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>] [<a href="./rfc8174" title="&quot;Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words&quot;">RFC8174</a>] when, and only when, they appear in all
   capitals, as shown here.





<span class="grey">Eastlake, et al.             Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Appointed Forwarders and Their Appointment</span>

   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 [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>].
   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 <a href="#section-2.5">Section 2.5</a>.)  While TRILL tries to avoid such
   situations, for loop safety there is also an "inhibition" mechanism
   (see <a href="#section-3">Section 3</a>) 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 <a href="#section-5">Section 5</a>, an RBridge may have multiple ports on a
   link.  As discussed in [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>], 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.







<span class="grey">Eastlake, et al.             Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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 [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>] as discussed in
      <a href="#section-2.2">Section 2.2</a>,

   5. as a result of a Port-Shutdown message as discussed in <a href="#section-6">Section 6</a>,
      and

   6. as a result of a local configuration action as discussed in
      <a href="#section-2.3">Section 2.3</a>.

   Mechanisms 2 and 3 are covered in <a href="#section-2.1">Section 2.1</a>.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  The Appointment Databases and DRB Actions</span>

   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.











<span class="grey">Eastlake, et al.             Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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
       [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>], AppointmentBitmap APPsub-TLVs (<a href="#section-10.2">Section 10.2</a>), or
       AppointmentList APPsub-TLVs (<a href="#section-10.3">Section 10.3</a>) 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 (<a href="#section-8">Section 8</a>).

   (B) The inclusion of one or more Appointed Forwarders sub-TLVs
       [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>] 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 <a href="#section-3">Section 3</a> will cause one or more of the RBridges to be
   inhibited for that VLAN, thus avoiding persistent loops.








<span class="grey">Eastlake, et al.             Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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 [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>]
                                |Router CAPABILITY TLV [<a href="./rfc7981" title="&quot;IS-IS Extensions for Advertising Router Information&quot;">RFC7981</a>]
                                |or MT-Capability TLV [<a href="./rfc6329" title="&quot;IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging&quot;">RFC6329</a>]

   Scattered VLANs within a small range
                            AppointmentBitmap APPsub-TLV (<a href="#section-10.2">Section 10.2</a>)
                                |TRILL GENINFO TLV [<a href="./rfc7357" title="&quot;Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol&quot;">RFC7357</a>]

   Scattered VLANs over a large range
                            AppointmentList APPsub-TLV (<a href="#section-10.3">Section 10.3</a>)
                                |TRILL GENINFO TLV [<a href="./rfc7357" title="&quot;Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol&quot;">RFC7357</a>]

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Appointment Effects of DRB Elections</span>

   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.







<span class="grey">Eastlake, et al.             Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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.

<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>.  Processing Forwarder Appointments in Hellos</span>

   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 [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>], 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



<span class="grey">Eastlake, et al.             Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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



<span class="grey">Eastlake, et al.             Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


      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.

<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>.  Frequency of Hello Appointments</span>

   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 <a href="#section-3">Section 3</a>, but see also <a href="#section-4">Section 4</a>).  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.

<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a>.  Appointed Forwarders Hello Limit</span>

   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 <a href="#section-2.2.1">Section 2.2.1</a> would generally



<span class="grey">Eastlake, et al.             Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Effects of Local Configuration Actions on Appointments</span>

   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.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Overload and Appointed Forwarders</span>

   A TRILL switch in link-state overload [<a href="./rfc7780" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates&quot;">RFC7780</a>] 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 [<a href="./rfc7780" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates&quot;">RFC7780</a>], 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.




<span class="grey">Eastlake, et al.             Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>.  VLAN Mapping within a Link</span>

   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 <a href="#appendix-B">Appendix B</a>.

   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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  The Inhibition Mechanism</span>

   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.




<span class="grey">Eastlake, et al.             Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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 <a href="#appendix-A">Appendix A</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



<span class="grey">Eastlake, et al.             Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


      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) [<a href="#ref-802.1Q" title="&quot;IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks&quot;">802.1Q</a>] 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 <a href="#section-3.2">Section 3.2</a>.

   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.





<span class="grey">Eastlake, et al.             Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Inhibited Appointed Forwarder Behavior</span>

   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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Root Bridge Change Inhibition Optimizations</span>

   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 [<a href="#ref-802.1Q" title="&quot;IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks&quot;">802.1Q</a>] 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.





<span class="grey">Eastlake, et al.             Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Optimization for Change to Lower Priority</span>

   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.

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Optimization for Change to Priority Only</span>

   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.

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  Optimizing the Detection of Completed Settling</span>

   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.




<span class="grey">Eastlake, et al.             Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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 <a href="#section-3.2.1">3.2.1</a> 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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Optional TRILL Hello Reduction</span>

   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 [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>], 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



<span class="grey">Eastlake, et al.             Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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 <a href="./rfc6325#section-4.4.3">Section&nbsp;4.4.3 of [RFC6325]</a>, 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 <a href="#section-3">Section 3</a> is
   still required.  Strictly following <a href="#section-3">Section 3</a>, 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 <a href="#section-3">Section 3</a>.  Support for
   both of these mechanisms is indicated by a capability bit in the
   PORT-TRILL-VER sub-TLV (<a href="./rfc7176#section-5.4">Section&nbsp;5.4 of [RFC7176]</a>).  It may be unsafe
   for an RBridge to send TRILL Hellos on fewer VLANs than the set of
   VLANs recommended in [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>] on a link unless all its adjacencies
   on that link (excluding those in the Down state [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>]) 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 [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>] 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.






<span class="grey">Eastlake, et al.             Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   2. An RBridge MAY use the VLANs Appointed sub-TLV [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>].  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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Multiple Ports on the Same Link</span>

   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 [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>].  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 <a href="#section-2">Section 2</a>.






<span class="grey">Eastlake, et al.             Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Port-Shutdown Messages</span>

   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.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Planned Shutdown and Hellos</span>

   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.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Port-Shutdown Message Structure</span>

   The Port-Shutdown message is an RBridge Channel message [<a href="./rfc7178" title="&quot;Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support&quot;">RFC7178</a>]
   using RBridge Channel Protocol number 0x006.  The payload specific to
   the Channel Protocol consists of a list of Port IDs (see
   <a href="./rfc6325#section-4.4.2">Section&nbsp;4.4.2 of [RFC6325]</a>) 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
   [<a href="./rfc7176" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS&quot;">RFC7176</a>].











<span class="grey">Eastlake, et al.             Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


      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                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Port-Shutdown Message Transmission</span>

   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 <a href="#section-6.6">Section 6.6</a>).  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.



<span class="grey">Eastlake, et al.             Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  Port-Shutdown Message Reception</span>

   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.

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Port-Shutdown Message Security</span>

   Port-Shutdown messages can be secured through the use of the RBridge
   Channel Header Extension security feature [<a href="./rfc7978" title="&quot;Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension&quot;">RFC7978</a>].










<span class="grey">Eastlake, et al.             Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Port-Shutdown Configuration</span>

   There are two Port-Shutdown configuration parameters, as listed
   below.  <a href="#section-6.3">Section 6.3</a> provides details regarding their use.

      Parameter            Default                 Range
      ---------------   ----------------   ---------------------
      PShutdownRepeat     2                 1-3
      PShutdownDelay     20 milliseconds    0-1,000 milliseconds

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  FGL-VLAN Mapping Consistency Checking</span>

   TRILL switches support 24-bit Fine-Grained Labels as specified in
   [<a href="./rfc7172" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling&quot;">RFC7172</a>].  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 <a href="#section-10.4">10.4</a> and <a href="#section-10.5">10.5</a>) 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.







<span class="grey">Eastlake, et al.             Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Support of E-L1CS</span>

   All TRILL switches MUST support the E-L1CS flooding scope [<a href="./rfc7356" title="&quot;IS-IS Flooding Scope Link State PDUs (LSPs)&quot;">RFC7356</a>],
   Extended Level 1 Flooding Scope (E-L1FS) [<a href="./rfc7780" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates&quot;">RFC7780</a>], and base LSPs
   [<a href="#ref-IS-IS" title="&quot;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)&quot;">IS-IS</a>].  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 [<a href="./rfc7780" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates&quot;">RFC7780</a>], all TRILL switches
   MUST include a Scope Flooding Support TLV [<a href="./rfc7356" title="&quot;IS-IS Flooding Scope Link State PDUs (LSPs)&quot;">RFC7356</a>] 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) [<a href="./rfc7356" title="&quot;IS-IS Flooding Scope Link State PDUs (LSPs)&quot;">RFC7356</a>], and E-L1CS
   FS-PSNPs (Flooding Scope Partial Sequence Number PDUs) [<a href="./rfc7356" title="&quot;IS-IS Flooding Scope Link State PDUs (LSPs)&quot;">RFC7356</a>])
   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 (<a href="#section-5">Section 5</a>) 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.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Backward Compatibility</span>

   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.














<span class="grey">Eastlake, et al.             Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   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 <a href="./rfc6325#section-6">Section&nbsp;6 of [RFC6325]</a>.

   The Port-Shutdown messages specified in <a href="#section-6">Section 6</a> are sent using the
   RBridge Channel facility [<a href="./rfc7178" title="&quot;Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support&quot;">RFC7178</a>].  Such messages SHOULD be secured
   through the use of the RBridge Channel Header Extension [<a href="./rfc7978" title="&quot;Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension&quot;">RFC7978</a>].
   If they are not adequately secured, they are a potential
   denial-of-service vector.

   The E-L1CS FS-LSPs added by <a href="#section-8">Section 8</a> are a type of IS-IS PDU
   [<a href="./rfc7356" title="&quot;IS-IS Flooding Scope Link State PDUs (LSPs)&quot;">RFC7356</a>].  As such, they are securable through the addition of
   Authentication TLVs [<a href="./rfc5310" title="&quot;IS-IS Generic Cryptographic Authentication&quot;">RFC5310</a>] in the same way as Hellos or other
   IS-IS PDUs.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Code Points and Data Structures</span>

   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 [<a href="./rfc7357" title="&quot;Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol&quot;">RFC7357</a>] in
   E-L1CS FS-LSPs [<a href="./rfc7356" title="&quot;IS-IS Flooding Scope Link State PDUs (LSPs)&quot;">RFC7356</a>].

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  IANA Considerations</span>

   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    [<a href="./rfc8139">RFC8139</a>]
      18     AppointmentList      [<a href="./rfc8139">RFC8139</a>]
      19     FGL-VLAN-Bitmap      [<a href="./rfc8139">RFC8139</a>]
      20     FGL-VLAN-Pairs       [<a href="./rfc8139">RFC8139</a>]

   IANA has assigned a new RBridge Channel Protocol number in the range
   assigned by Standards Action [<a href="./rfc5226" title="">RFC5226</a>] and updated the "RBridge
   Channel Protocols" registry as follows:

      Protocol  Description     Reference
      --------  --------------  ---------
       0x006    Port-Shutdown   [<a href="./rfc8139">RFC8139</a>]






<span class="grey">Eastlake, et al.             Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  AppointmentBitmap APPsub-TLV</span>

   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.







<span class="grey">Eastlake, et al.             Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-10.3" href="#section-10.3">10.3</a>.  AppointmentList APPsub-TLV</span>

   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.






<span class="grey">Eastlake, et al.             Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   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.

<span class="h3"><a class="selflink" id="section-10.4" href="#section-10.4">10.4</a>.  FGL-VLAN-Bitmap APPsub-TLV</span>

   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.






<span class="grey">Eastlake, et al.             Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   o  Starting VLAN ID: Initial VLAN ID for the mapping information as
      discussed below.

   o  Starting FGL: Fine-Grained Label [<a href="./rfc7172" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling&quot;">RFC7172</a>].

   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.

<span class="h3"><a class="selflink" id="section-10.5" href="#section-10.5">10.5</a>.  FGL-VLAN-Pairs APPsub-TLV</span>

   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)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+







<span class="grey">Eastlake, et al.             Standards Track                   [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


      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 [<a href="./rfc7172" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling&quot;">RFC7172</a>].

   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.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Management Considerations</span>

   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 <a href="#section-6.6">Section 6.6</a>.

   TRILL switch support of SNMPv3 is provided in the TRILL base protocol
   document [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>].  MIBs have been specified in [<a href="./rfc6850" title="&quot;Definitions of Managed Objects for Routing Bridges (RBridges)&quot;">RFC6850</a>] and
   [<a href="./rfc7784" title="&quot;Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB&quot;">RFC7784</a>], but they do not include the configurable parameters
   specified herein.  It is anticipated that YANG modules will be
   specified for TRILL.














<span class="grey">Eastlake, et al.             Standards Track                   [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  References</span>

<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>.  Normative References</span>

   [<a id="ref-802.1Q">802.1Q</a>]   IEEE, "IEEE Standard for Local and metropolitan area
              networks--Bridges and Bridged Networks",
              IEEE Std 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462,
              &lt;<a href="http://ieeexplore.ieee.org/servlet/opac?punumber=6991460">http://ieeexplore.ieee.org/</a>
              <a href="http://ieeexplore.ieee.org/servlet/opac?punumber=6991460">servlet/opac?punumber=6991460</a>&gt;.

   [<a id="ref-IS-IS">IS-IS</a>]    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.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
              DOI 10.17487/RFC2119, March 1997,
              &lt;<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>&gt;.

   [<a id="ref-RFC6325">RFC6325</a>]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", <a href="./rfc6325">RFC 6325</a>, DOI 10.17487/RFC6325, July 2011,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6325">http://www.rfc-editor.org/info/rfc6325</a>&gt;.

   [<a id="ref-RFC6329">RFC6329</a>]  Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
              A., and P. Unbehagen, "IS-IS Extensions Supporting
              IEEE 802.1aq Shortest Path Bridging", <a href="./rfc6329">RFC 6329</a>,
              DOI 10.17487/RFC6329, April 2012,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6329">http://www.rfc-editor.org/info/rfc6329</a>&gt;.

   [<a id="ref-RFC7172">RFC7172</a>]  Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
              D. Dutt, "Transparent Interconnection of Lots of Links
              (TRILL): Fine-Grained Labeling", <a href="./rfc7172">RFC 7172</a>,
              DOI 10.17487/RFC7172, May 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7172">http://www.rfc-editor.org/info/rfc7172</a>&gt;.

   [<a id="ref-RFC7176">RFC7176</a>]  Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
              D., and A. Banerjee, "Transparent Interconnection of Lots
              of Links (TRILL) Use of IS-IS", <a href="./rfc7176">RFC 7176</a>,
              DOI 10.17487/RFC7176, May 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7176">http://www.rfc-editor.org/info/rfc7176</a>&gt;.

   [<a id="ref-RFC7177">RFC7177</a>]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
              V. Manral, "Transparent Interconnection of Lots of Links
              (TRILL): Adjacency", <a href="./rfc7177">RFC 7177</a>, DOI 10.17487/RFC7177,
              May 2014, &lt;<a href="http://www.rfc-editor.org/info/rfc7177">http://www.rfc-editor.org/info/rfc7177</a>&gt;.



<span class="grey">Eastlake, et al.             Standards Track                   [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   [<a id="ref-RFC7178">RFC7178</a>]  Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
              Ward, "Transparent Interconnection of Lots of Links
              (TRILL): RBridge Channel Support", <a href="./rfc7178">RFC 7178</a>,
              DOI 10.17487/RFC7178, May 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7178">http://www.rfc-editor.org/info/rfc7178</a>&gt;.

   [<a id="ref-RFC7356">RFC7356</a>]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
              Scope Link State PDUs (LSPs)", <a href="./rfc7356">RFC 7356</a>,
              DOI 10.17487/RFC7356, September 2014,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7356">http://www.rfc-editor.org/info/rfc7356</a>&gt;.

   [<a id="ref-RFC7357">RFC7357</a>]  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", <a href="./rfc7357">RFC 7357</a>, DOI 10.17487/RFC7357,
              September 2014, &lt;<a href="http://www.rfc-editor.org/info/rfc7357">http://www.rfc-editor.org/info/rfc7357</a>&gt;.

   [<a id="ref-RFC7780">RFC7780</a>]  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", <a href="./rfc7780">RFC 7780</a>, DOI 10.17487/RFC7780, February 2016,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7780">http://www.rfc-editor.org/info/rfc7780</a>&gt;.

   [<a id="ref-RFC7978">RFC7978</a>]  Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent
              Interconnection of Lots of Links (TRILL): RBridge Channel
              Header Extension", <a href="./rfc7978">RFC 7978</a>, DOI 10.17487/RFC7978,
              September 2016, &lt;<a href="http://www.rfc-editor.org/info/rfc7978">http://www.rfc-editor.org/info/rfc7978</a>&gt;.

   [<a id="ref-RFC7981">RFC7981</a>]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Information", <a href="./rfc7981">RFC 7981</a>,
              DOI 10.17487/RFC7981, October 2016,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7981">http://www.rfc-editor.org/info/rfc7981</a>&gt;.

   [<a id="ref-RFC8174">RFC8174</a>]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              <a href="./rfc2119">RFC 2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>,
              DOI 10.17487/RFC8174, May 2017,
              &lt;<a href="http://www.rfc-editor.org/info/rfc8174">http://www.rfc-editor.org/info/rfc8174</a>&gt;.














<span class="grey">Eastlake, et al.             Standards Track                   [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>.  Informative References</span>

   [<a id="ref-RFC5226">RFC5226</a>]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
              DOI 10.17487/RFC5226, May 2008,
              &lt;<a href="http://www.rfc-editor.org/info/rfc5226">http://www.rfc-editor.org/info/rfc5226</a>&gt;.

   [<a id="ref-RFC5310">RFC5310</a>]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", <a href="./rfc5310">RFC 5310</a>, DOI 10.17487/RFC5310,
              February 2009, &lt;<a href="http://www.rfc-editor.org/info/rfc5310">http://www.rfc-editor.org/info/rfc5310</a>&gt;.

   [<a id="ref-RFC6439">RFC6439</a>]  Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
              Hu, "Routing Bridges (RBridges): Appointed Forwarders",
              <a href="./rfc6439">RFC 6439</a>, DOI 10.17487/RFC6439, November 2011,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6439">http://www.rfc-editor.org/info/rfc6439</a>&gt;.

   [<a id="ref-RFC6850">RFC6850</a>]  Rijhsinghani, A. and K. Zebrose, "Definitions of Managed
              Objects for Routing Bridges (RBridges)", <a href="./rfc6850">RFC 6850</a>,
              DOI 10.17487/RFC6850, January 2013,
              &lt;<a href="http://www.rfc-editor.org/info/rfc6850">http://www.rfc-editor.org/info/rfc6850</a>&gt;.

   [<a id="ref-RFC7379">RFC7379</a>]  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", <a href="./rfc7379">RFC 7379</a>, DOI 10.17487/RFC7379,
              October 2014, &lt;<a href="http://www.rfc-editor.org/info/rfc7379">http://www.rfc-editor.org/info/rfc7379</a>&gt;.

   [<a id="ref-RFC7784">RFC7784</a>]  Kumar, D., Salam, S., and T. Senevirathne, "Transparent
              Interconnection of Lots of Links (TRILL) Operations,
              Administration, and Maintenance (OAM) MIB", <a href="./rfc7784">RFC 7784</a>,
              DOI 10.17487/RFC7784, February 2016,
              &lt;<a href="http://www.rfc-editor.org/info/rfc7784">http://www.rfc-editor.org/info/rfc7784</a>&gt;.


















<span class="grey">Eastlake, et al.             Standards Track                   [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  VLAN Inhibition Example</span>

   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.


















<span class="grey">Eastlake, et al.             Standards Track                   [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Multi-Link VLAN Mapping Loop Example</span>

   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.



<span class="grey">Eastlake, et al.             Standards Track                   [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   The use of Fine-Grained Labels [<a href="./rfc7172" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling&quot;">RFC7172</a>] 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.

<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>.  Changes to RFCs 6325, 6439, and 7177</span>

   This document updates [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>], obsoletes [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>], and updates
   [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>].

   The change to [<a href="./rfc6325" title="&quot;Routing Bridges (RBridges): Base Protocol Specification&quot;">RFC6325</a>], the TRILL base protocol, is as follows:

      Addition of mandatory support for E-L1CS FS-LSPs.

   Changes to [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>], 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 [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>] that appeared in <a href="./rfc7180#section-10">Section&nbsp;10
      of RFC 7180</a>, which has been obsoleted by [<a href="./rfc7780" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates&quot;">RFC7780</a>].  They appear
      primarily in <a href="#section-4">Section 4</a> 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"
      (<a href="./draft-ietf-trill-rbridge-vlan-mapping">draft-ietf-trill-rbridge-vlan-mapping</a>), 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 (<a href="#section-3.2">Section 3.2</a>) to optimize
      (reduce) inhibition time under various circumstances.

   8. Editorial changes.




<span class="grey">Eastlake, et al.             Standards Track                   [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


   Changes to [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>] are as follows:

      As provided in <a href="#section-6">Section 6</a>, 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
      [<a href="./rfc7177" title="&quot;Transparent Interconnection of Lots of Links (TRILL): Adjacency&quot;">RFC7177</a>], 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 [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>], 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 [<a href="./rfc6439" title="&quot;Routing Bridges (RBridges): Appointed Forwarders&quot;">RFC6439</a>].



























<span class="grey">Eastlake, et al.             Standards Track                   [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc8139">RFC 8139</a>               TRILL: Appointed Forwarders             June 2017</span>


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]
</pre>