Skip to main content

TRILL: Appointed Forwarders
draft-ietf-trill-rfc6439bis-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8139.
Authors Donald E. Eastlake 3rd , Yizhou Li , Mohammed Umair , Ayan Banerjee , fangwei hu
Last updated 2017-01-19 (Latest revision 2017-01-10)
Replaces draft-eastlake-trill-rfc6439bis
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Susan Hares
Shepherd write-up Show Last changed 2016-08-26
IESG IESG state Became RFC 8139 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Alia Atlas
Send notices to "Susan Hares" <shares@ndzh.com.>
IANA IANA review state IANA OK - Actions Needed
draft-ietf-trill-rfc6439bis-04
TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                                 Yizhou Li
Intended status: Proposed Standard                                Huawei
Obsoletes: 6439                                           Mohammed Umair
Updates: 6325, 7177                                           IPinfusion
                                                           Ayan Banerjee
                                                                   Cisco
                                                              Fangwei Hu
                                                                     ZTE
Expires: July 9, 2017                                   January 10, 2017

                      TRILL: Appointed Forwarders
                  <draft-ietf-trill-rfc6439bis-04.txt>

Abstract

   TRILL 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", 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 RFC 6325, updates RFC 7177, and
   obsoletes RFC 6439.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  Distribution of this document is
   unlimited. Comments should be sent to the TRILL working group mailing
   list <trill@ietf.org>.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
   Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

D. Eastlake, et al                                              [Page 1]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Table of Contents

      1.  Introduction...........................................4
      1.1 Appointed Forwarders and Active-Active.................5
      1.2 Terminology and Acronyms...............................5

      2. Appointed Forwarders and Their Appointment..............7
      2.1 The Appointment Databases and DRB Actions..............8
      2.2 Appointment Effects of DRB Elections...................9
      2.2.1 Processing Forwarder Appointments in Hellos.........10
      2.2.2 Frequency of Hello Appointments.....................12
      2.2.3 Appointed Forwarders Hello Limit....................12
      2.3 Local Configuration Actions Appointment Effects.......13
      2.4 Overload and Appointed Forwarders.....................13
      2.5 VLAN Mapping within a Link............................14

      3. The Inhibition Mechanism...............................15
      3.1 Inhibited Appointed Forwarder Behavior................17
      3.2 Root Change Inhibition Optimizations..................17
      3.2.1 Change Optimization One.............................18
      3.2.2 Change Optimization Two.............................18
      3.2.3 Settling Detection Optimization.....................18

      4. Optional TRILL Hello Reduction.........................20
      5. Multiple Ports on the Same Link........................22

      6. Port-Shutdown Messages.................................23
      6.1 Planned Shutdown and Hellos...........................23
      6.2 Port-Shutdown Message Structure.......................23
      6.3 Port-Shutdown Message Transmission....................24
      6.4 Port-Shutdown Message Reception.......................25
      6.5 Port-Shutdown Message Security........................25
      6.6 Port-Shutdown Configuration...........................25

      7. FGL-VLAN Mapping Consistency Checking..................27

      8. Support of E-L1CS......................................28
      8.1 Backwards Compatibility...............................28

      9. Security Considerations................................29

      10. Code Points and Data Structures.......................30
      10.1 IANA Considerations..................................30
      10.2 Appointment Bitmap APPsub-TLV........................30
      10.3 Appointment List APPsub-TLV..........................31
      10.4 FGL-VLAN Mapping Bitmap APPsub-TLV...................32
      10.5 FGL-VLAN Mapping Pairs APPsub-TLV....................34

      Normative References......................................35
      Informative References....................................36

D. Eastlake, et al                                              [Page 2]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Table of Contents (continued)

      Acknowledgements..........................................37
      Authors' Addresses........................................38

      Appendix A: VLAN Inhibition Example.......................39
      Appendix B: Changes to RFCs 6325, 6439, 7177..............40
      Appendix C: Multi-Link VLAN Mapping Loop Example..........41
      Appendix Z: Change Record.................................43

D. Eastlake, et al                                              [Page 3]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

1.  Introduction

   The IETF TRILL protocol [RFC6325] [RFC7780] provides optimal pair-
   wise 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 this by
   using IS-IS (Intermediate System to Intermediate System) [IS-IS]
   [RFC7176] link state routing and encapsulating traffic using a header
   that includes a hop count.  The design supports VLANs, 24-bit fine
   grained labels [RFC7172], and optimization of the distribution of
   multi-destination frames based on VLANs and multicast groups.
   Devices that implement TRILL are called TRILL switches or "RBridges"
   (Routing Bridges).

   Section 2 of [RFC7177] discusses the environment for which the TRILL
   protocol is designed and the differences between that environment and
   the typical Layer 3 routing environment.

   TRILL supports multi-access LAN (Local Area Network) links that can
   have multiple end stations and TRILL switches attached.  Where
   multiple TRILL switches are attached to a link, native traffic to and
   from end stations on that link is handled by a subset of those
   switches called "Appointed Forwarders", 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 PDU. This is accomplished by requiring support of link
   scoped FS-LSPs (Section 7) and proving for appointment information to
   be sent in those LSPs. In addition this document provides a number of
   optional features to (1) detect inconsistent VLAN to FGL [RFC7172]
   mappings among the TRILL switch ports on a link as discussed in
   Section 7, (2) expedite notification of ports going down so that
   Appointed Forwarders can be adjusted as discussed in Section 6, and
   (3) reduce or eliminate the need for "inhibition" of ports for loop
   safety as discussed in Section 3.2. This documents obsoletes
   [RFC6439], updates [RFC6325], and updates [RFC7177], as described in
   Appendix B. It also 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

D. Eastlake, et al                                              [Page 4]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   are enabled on that port.)

   The Appointed Forwarder mechanism has no effect on the formation of
   adjacencies, the election of the Designated RBridge (DRB) for a link,
   MTU matching, or pseudonode formation.  Those topics are covered in
   [RFC7177].  Furthermore, Appointed Forwarder status has no effect on
   the forwarding of TRILL Data frames; it only affects the handling of
   native frames to and from end stations.

   For other aspects of the TRILL base protocol, see [RFC6325],
   [RFC7177], and [RFC7780].  In case of conflict between this document
   and [RFC6325] or [RFC7177], this document prevails.

1.1 Appointed Forwarders and Active-Active

   As discussed in [RFC7379], TRILL active-active provides support for
   end stations connected to multiple edge TRILL switches where these
   connections are separate links. Since TRILL Hellos are not forwarded
   between these links, the Appointed Forwarder mechanism as described
   herein operates separately on each such link.

1.2 Terminology and Acronyms

   This document uses the acronyms and terms defined in [RFC6325], some
   of which are repeated below for convenience, and additional acronyms
   and terms listed below.

   DRB: Designated RBridge. The RBridge on a link elected as specified
         in [RFC7177] to handle certain decisions and tasks for that
         link including forwarder appointent as specified herein.

   E-L1CS: Extended Level 1 Circuit Scoped (Section 8).

   FGL: Fine Grained Label [RFC7172].

   FS-LSP: Flooding Scoped - Link State PDU (Section 8).

   Link: The means by which adjacent TRILL switches are connected. A
         TRILL link may be various technologies and, in the common case
         of Ethernet, can be a "bridged LAN", that is to say, some
         combination of Ethernet links with zero or more bridges, hubs,
         repeaters, or the like.

   LSDB: Link State Data Base.

   RBridge: An alternative name for a TRILL switch.

D. Eastlake, et al                                              [Page 5]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   TRILL: Transparent Interconnection of Lots of Links or Tunneled
         Routing in the Link Layer.

   TRILL switch: A device implementing the TRILL protocol. An
         alternative name for an RBridge.

   Trunk port: A TRILL switch port configured with the "end station
         service disable" bit on, as described in Section 4.9.1 of
         [RFC6325].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

D. Eastlake, et al                                              [Page 6]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

2. Appointed Forwarders and Their Appointment

   The Appointed Forwarder on a link for VLAN-x is the TRILL switch
   (RBridge) that ingresses native frames from the link and egresses
   native frames to the link in VLAN-x.  By default, the DRB (Designated
   RBridge) on a link is in charge of native traffic for all VLANs on
   the link.  The DRB may, if it wishes, act as Appointed Forwarder for
   any VLAN and it may appoint other TRILL switches that have ports on
   the link as Appointed Forwarder for one or more VLANs.

   By definition, the DRB considers the other ports on the link to be
   the ports with which a DRB port has adjacency on that link [RFC7177].
   If the DRB loses adjacency to a TRILL switch that it has appointed a
   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 forwarder for
   that traffic.

   It is important that there not be two Appointed Forwarders on a link
   that are ingressing and egressing native frames for the same VLAN at
   the same time.  Should this occur, it could form a loop where frames
   are not protected by a TRILL Hop Count for part of the loop.  (Such a
   condition can even occur through two Appointed Forwarders for two
   different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the
   link are configured to map frames between VLAN-x and VLAN-y as
   discussed in Section 2.5.)  While TRILL tries to avoid such
   situations, for loop safety there is also an "inhibition" mechanism
   (see Section 3) that can cause a TRILL switch that is an Appointed
   Forwarder to not ingress or egress native frames.  Appointed
   Forwarder status and port "inhibition" have no effect on the
   reception, transmission, or forwarding of TRILL Data or TRILL IS-IS
   frames.  Appointed Forwarder status and inhibition only affect the
   handling of native frames.

   As discussed in Section 5, an RBridge may have multiple ports on a
   link.  As discussed in [RFC7177], if there are multiple ports with
   the same Media Access Control (MAC) address on the same link, all but
   one will be suspended.  The case of multiple ports on a link for the
   same TRILL switch and the case of multiple ports with the same MAC
   address on a link and combinations of these cases are fully
   accommodated; however, multiple ports on a link for the same TRILL
   switch is expected to be a rare condition and duplicate MAC addresses
   is not recommended by either TRILL or IEEE 802.1 standards.

   There are six mechanisms by which an RBridge can be appointed or un-
   appointed as Appointed Forwarder: (1) assumption of appointment, when
   the DRB decides to act as Appointed Forwarder for a VLAN, (2) Hello
   appointment, as a result of appointments sent by the DRB in TRILL
   Hellos, (3) E-L1CS appointment, as a result of appointments sent by
   the DRB in E-L1CS FS-LSPs, (4) as a result of the DRB elections

D. Eastlake, et al                                              [Page 7]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   [RFC7177] as discussed in Section 2.2, (5) as a result of a Port-
   Shutdown message as discussed in Section 6, and (6) as a result of a
   local configuration action as discussed in Section 2.3. Mechanisms 2
   and 3 are covered in Section 2.1.

2.1 The Appointment Databases and DRB Actions

   The DRB MAY appoint other RBridges on the link as Appointed
   Forwarders through the mechanisms A and B described below.

   Each RBridge maintains two databases of appointment information: (1)
   its E-L1CS LSDB that shows appointments each RBridge on the link
   would make using mechanism A if it were the DRB, and (2) its Hello
   appointment database that 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 and 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.

   The two mechanisms by which the DRB can appoint other RBridges on a
   link Appointed Forwarders are as follows:

   (A) The inclusion of one or more Appointed Forwarders sub-TLVs
       [RFC7176], Appointment Bitmap APPsub-TLVs (Section 10.2), or
       Appointment List APPsub-TLVs (Section 10.3) in E-L1CS LSPs it
       sends on a link. Appointments sent with this method will not be
       seen by legacy RBridges that do not support E-L1CS (Section 8).

   (B) The inclusion of one or more Appointed Forwarders sub-TLVs
       [RFC7176] in a TRILL Hello it sends on the Designated VLAN out
       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 advertise by this method
   the appointments they would make if they were 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
   an Appointed Forwarder.

D. Eastlake, et al                                              [Page 8]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   Although the DRB does not need to announce the VLANs for which it has
   chosen to act as Appointed Forwarder by sending appoints 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 forwarder for which 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, then item 4 in Section 3 will
   cause one or more of the RBridges to be inhibited for that VLAN thus
   avoiding persistent loops.

   When forwarder appointments are being encoded for transmission,
   different patterns of VLANs are most efficiently encoded in different
   ways.  The following table gives advice for the most efficient
   encoding:

                            sub-TLV and Reference
     Pattern of VLAN IDs        |enclosing TLV(s) and Reference
     -----------------      ------------------------------------

     Blocks of consecutive VLANs
                            Appointed Forwarders sub-TLV [RFC7176]
                                |Router Capabilities TLV [RFC7981]
                                |or MT Capabilities TLV [RFC6329]

     Scattered VLANs within a small range
                            Appointment Bitmap APPsub-TLV (Section 10.2)
                                |TRILL GENINFO TLV [RFC7357]

     Scattered VLANs over a large range
                            Appointment List APPsub-TLV (Section 10.3)
                                |TRILL GENINFO TLV [RFC7357]

2.2 Appointment Effects of DRB Elections

   When a TRILL switch port on a link wins the DRB election, there are
   four possible cases:

   1. A TRILL switch believes it was the DRB and remains the DRB: There
      is no change in Appointed Forwarder status. This also applies in

D. Eastlake, et al                                              [Page 9]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

      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.

   3. A TRILL switch was not DRB and does not become 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:
      3.a The new winning port and the old winner are ports of different
          TRILL switches on the link. It this case, it switches to using
          the E-L1CS FS-LSP appointments for the winning TRILL switch.
      3.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 DRB, the E-L1CS FS-LSP appointments are
          unchanged.

   4. The winning port is unchanged: As in case 1, there is no change in
      Appointed Forwarder status.

2.2.1 Processing Forwarder Appointments in Hellos

   When a non-DRB RBridge that can offer end station service on a link
   receives a TRILL Hello that is not discarded for one of the reasons
   given in [RFC7177], it checks the source MAC address and the Port ID
   and System ID in the Hello to determine if it is from the winning DRB
   port.  If it is not from that port, any forwarder appointment sub-
   TLVs in the Hello are ignored, and there is no change in the
   receiving RBridge's Appointed Forwarder status due to that Hello.
   Also, if no forwarder appointment sub-TLVs are present in the TRILL
   Hello, there is no change in the receiver's Appointed Forwarder
   status due to that Hello.

   However, if the TRILL Hello is from the winning DRB port and the
   Hello includes one or more forwarder appointment sub-TLVs, then the
   receiving RBridge sets its Hello appointment database to be the VLANs

D. Eastlake, et al                                             [Page 10]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   that are both listed for it in the Hello and are enabled on the
   receiving port.  (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
   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 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 Forwarder sub-TLV is for a
   specific RBridge and a contiguous interval of VLAN IDs; however, as
   stated above, it actually appoints that RBridge forwarder only for
   the VLAN(s) 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 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 gives 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 the DRB RB1 wishes to appoint RB2 forwarder for all even-
   numbered VLANs and appoint RB3 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
      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

D. Eastlake, et al                                             [Page 11]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

      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 forwarder for the Designated VLAN.
      Thus, in the general case, it would require two appointments,
      although it would still only require one appointment if the
      Designated VLAN were an extreme low or high value such as VLAN
      0xFFE or the default VLAN 1.

   For example, assume the DRB wants RB2 to be Appointed Forwarder for
   all even-numbered VLANs and the Designated VLAN for the link is VLAN
   101.  The network manager could cause all even-numbered VLANs plus
   VLAN 101 to be enabled on the relevant port of RB2 and then, with the
   desired effect, cause the DRB to send appointments to RB2 appointing
   it forwarder for all VLANs from 1 through 100 and from 102 through
   4,094.

2.2.2 Frequency of Hello Appointments

   Appointments made though E-L1CS FS-LSPs use the same IS-IS timing
   constants as for LSP flooding. The general IS-IS link state flooding
   mechanism is robust and includes acknowledgements so that it
   automatically recovers from lost PDUs, re-booted TRILL switches, and
   the like.

   For Hello appointments, it is not necessary for the DRB to include
   the Hello forwarder appointments in every TRILL Hello that it sends
   on the Designated VLAN for a link.  For loop safety, every RBridge is
   required to indicate, in every TRILL Hello it sends in VLAN-x on a
   link, whether it is an Appointed Forwarder for VLAN-x for that link
   (see item 4 in Section 3 but see also Section 4).  It is also
   RECOMMENDED that the DRB have enabled all VLANs for which end station
   service will be offered on the link as well as the Designated VLAN.
   Thus, the DRB will generally be informed by other RBridges on the
   link of the VLANs for which they believe they are Appointed
   Forwarder.  If this matches the appointments the DRB wishes to make,
   it is not required to re-send its forwarder appointments; however,
   for robustness, especially in cases such as VLAN misconfigurations in
   a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder
   appointments on the Designated VLAN at least once per its Holding
   Time on the port that won the DRB election.

2.2.3 Appointed Forwarders Hello Limit

   The Hello mechanism of DRB forwarder appointment and the limited
   length of TRILL Hellos impose a limit on the number of RBridges on a

D. Eastlake, et al                                             [Page 12]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   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 1000
   bytes are available in a TRILL Hello for such appointments.  Assume
   it is desired to appoint various RBridges on a link forwarder for
   arbitrary non-intersecting sets of VLANs.  Using the technique
   discussed at the end of Section 2.2.1 would generally require two
   appointments, or 12 bytes, per RBridge.  With allowance for sub-TLV
   and TLV overhead, appointments for 83 RBridges would fit in under
   1000 bytes.  Including the DRB, this implies a link with 84 or more
   RBridges attached.  Links with more than a handful of RBridges
   attached are expected to be rare. And in any case such limitations
   are easily avoided by using E-L1CS FS-LSP appointment.

2.3 Local Configuration Actions Appointment Effects

   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 or E-L1CS
   FS-LSP appointment databases.

2.4 Overload and Appointed Forwarders

   A TRILL switch in link state overload [RFC7780] will, in general, do
   a poorer job of forwarding frames than a TRILL switch not in overload
   because the TRILL switch not in overload has full knowledge of the
   campus topology.  For example, as explained in [RFC7780], an
   overloaded TRILL switch may not be able to distribute multi-
   destination TRILL Data packets at all.

   Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an
   Appointed Forwarder and, if an Appointed Forwarder becomes
   overloaded, the DRB SHOULD re-assign VLANs from the overloaded
   RBridge to another RBridge on the link that is not overloaded, if one
   is available.

D. Eastlake, et al                                             [Page 13]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   A counter-example would be if RB1 was in overload but could act as
   the Appointed Forwarder for all campus end stations in VLAN-x because
   all such end stations were on links attached to RB1.  In such a case,
   RB1 would never have to forward VLAN-x end station traffic as a TRILL
   Data packet but would always be forwarding it locally as a native
   frame. In this case, RB1 SHOULD NOT be disadvantaged for selection as
   the VLAN-x Appointed Forwarder on any such links.

   Overload does not affect DRB election but a TRILL switch in overload
   MAY reduce its own priority to be DRB.

2.5 VLAN Mapping within a Link

   TRILL Hellos include a field that is set to the VLAN in which they
   are sent when they are sent on a link technology such as Ethernet
   that has outer VLAN labeling.  (For link technologies such as PPP
   that do not have outer VLAN labeling, this Hello field is ignored.)
   If a TRILL Hello arrives on a different VLAN than it was sent on,
   then VLAN mapping is occurring within the link. VLAN mapping between
   VLAN-x and VLAN-y can lead to a loop if the Appointed Forwarders for
   the VLANs are different.  If such mapping within a link was allowed
   and occurred on two or more links so that there was a cycle of VLAN
   mappings, a multi-destination frame would loop forever. Such a frame
   would be immortal. For a specific example, see Appendix C.

   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.

D. Eastlake, et al                                             [Page 14]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

3. The Inhibition Mechanism

   A TRILL switch has, for every link on which it can offer end station
   service (that is every link for which it can act as an Appointed
   Forwarder), the following timers denominated in seconds:

      - a DRB inhibition timer,

      - a root change inhibition timer, and

      - up to 4,094 VLAN inhibition timers, one for each legal VLAN ID.

   The DRB and root change inhibition timers MUST be implemented.

   The loss of native traffic due to inhibition will be minimized by
   logically implementing a VLAN inhibition timer per each VLAN for
   which end station service will ever be offered by the RBridge on the
   link; this SHOULD be done.  (See Appendix A for an example motivating
   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
   together for two VLANs if it is the Appointer Forwarder for one and
   not for the other, as this can lead to unnecessary indefinitely
   prolonged inhibition.  In the limit, there will be safe operations,
   albeit with more native frame loss 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
      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 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,

D. Eastlake, et al                                             [Page 15]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

      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 2 nor 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 inside
      the Hello, then RB1 sets its VLAN-x inhibition timer for the link
      to the maximum of that timer's existing value and the Holding Time
      in the received Hello. 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
      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 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 zero seconds.  This
      condition will not occur unless the TRILL switch is receiving
      Bridge PDU (BPDUs) on the port from an attached bridged LAN; if no
      BPDUs are being received, the root 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 Rapid Spanning Tree Protocol (RSTP [802.1Q]) is running
      throughout the attached bridged LAN, it is safe to configure this
      inhibition time to 7 seconds or, if the attached bridges have been
      configured to have a minimum Bridge Hello Timer, safe to configure
      it to 4 seconds. Further optimizations are specified in Section
      3.2.

   7. When a TRILL switch decides that one of its ports (or a set of its
      ports) P1 is on the same link as another of its ports (or set of
      its ports) P2, then the inhibition timers are merged to a single
      set of inhibition timers by using the maximum value of the
      corresponding timers as the initial value of the merged timers.

D. Eastlake, et al                                             [Page 16]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   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 (one link per
      port in the limit).  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.

3.1 Inhibited Appointed Forwarder Behavior

   Inhibition has no effect on the receipt or forwarding of TRILL Data
   packets or TRILL IS-IS packets. It only affects ingressing and
   egressing native frames.

   An Appointed Forwarder for a link is inhibited for VLAN-x if:

   1. its DRB inhibition timer for that link is not expired, or

   2. its root 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.

   An TRILL switch with one or more unexpired inhibition timers,
   possibly including an unexpired inhibition timer covering VLAN-x, is
   still required to indicate in TRILL Hellos it sends on VLAN-x whether
   or not it is Appointed Forwarder for VLAN-x for the port on which it
   sends the Hello.

3.2 Root Change Inhibition Optimizations

   The subsections below specify three optimizations that can reduce
   inhibition time of an RBridge port under certain circumstances for
   changes in the root Bridge ID 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

D. Eastlake, et al                                             [Page 17]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   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.

3.2.1 Change Optimization One

   Assume 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 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 are safe conditions that do not require inhibition.

3.2.2 Change Optimization Two

   Assume 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 is unchanged so the
   root bridge has been reconfigured to have a different priority but
   the same bridge is root and there has been no topology change.  Thus,
   it is safe to ignore this sort of root Bridge ID change and not
   invoke the inhibition mechanism.

3.2.3 Settling Detection Optimization

   The 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, after the merger, you could have loops involving
   those VLANs.

   (Only native frames egressed and ingressed by RBridges are a
   potential problem. TRILL data packets are either individually
   addressed (TRILL Header M bit = 0) and will be ignored if delivered
   to any incorrect TRILL switch ports, or 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 sending or receiving TRILL data packets
   and inhibition does not do so.)

D. Eastlake, et al                                             [Page 18]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   However, root 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 change
   inhibition is not 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 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 LSP
   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 LSP 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 reach or
   this list of RBridges is empty.

   If the optimizations in Sections 3.2.1 and/or 3.2.2 are in effect at
   an RBridge port and indicate that no inhibition is needed, then the
   mechanism in this section is not needed either.

D. Eastlake, et al                                             [Page 19]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

4. Optional TRILL Hello Reduction

   If a network manager has sufficient confidence that they know the
   configuration of bridges, ports, and the like, within an Ethernet
   link, they may be able to reduce the number of TRILL Hellos sent on
   that link by sending Hellos in fewer VLANs; for example, if all TRILL
   switches on the link will see all Hellos without VLAN constraints.
   However, because adjacencies are established in the Designated VLAN,
   an RBridge MUST always attempt to send Hellos in the Designated VLAN.

   Hello reduction makes TRILL less robust in the face of decreased VLAN
   connectivity within a link, such as partitioned VLANs, VLANs disabled
   on ports, or disagreement over the Designated VLAN; however, as long
   as all RBridge ports on the link are configured for the same Desired
   Designated VLAN, can see each other's frames in that VLAN, and
   utilize the mechanisms specified below to update VLAN inhibition
   timers, operations will be safe.  (These considerations do not arise
   on links between RBridges that are configured as point-to-point
   since, in that case, each RBridge sends point-to-point Hellos, other
   TRILL IS-IS PDUs, and TRILL Data frames only in what it believes to
   be the Designated VLAN of the link (although it may send them un-
   tagged) and no native frame end-station service is provided. Thus,
   for such links, there is no reason to send Hellos in any other VLAN
   than the Designated VLAN.)

   The provision for a configurable set of "Announcing VLANs", as
   described in Section 4.4.3 of [RFC6325], provides a mechanism in the
   TRILL base protocol for a reduction in TRILL Hellos.

   To maintain loop safety in the face of occasional lost frames,
   RBridge failures, link failures, new RBridges coming up on a link,
   and the like, the inhibition mechanism specified in Section 3 is
   still required. Strictly following Section 3, a VLAN inhibition timer
   can only be set by the receipt of a Hello sent or received in that
   VLAN. Thus, to safely send a reduced number of TRILL Hellos on a
   reduced number of VLANs requires additional mechanisms to set the
   VLAN inhibition timers at an RBridge, thus extending Section 3. Two
   such mechanisms are specified below. Support for both of these
   mechanisms is indicated by a capability bit in the PORT-TRILL-VER
   sub-TLV (Section 5.4 of [RFC7176]). It may be unsafe for an RBridge
   to send TRILL Hellos on fewer VLANs than the set of VLANs recommended
   in [RFC6325] on a link unless all its adjacencies on that link
   (excluding those in the Down state [RFC7177]) indicate support of
   these mechanisms and these mechanisms are in use.

   1. An RBridge RB2 MAY include in any TRILL Hello an Appointed
      Forwarders sub-TLV [RFC7176] appointing itself for one or more
      ranges of VLANs.  The Appointee Nickname field(s) in the self-
      appointment Appointed Forwarder sub-TLV MUST be the same as the
      Sender Nickname in the Special VLANs and Flags sub-TLV in the

D. Eastlake, et al                                             [Page 20]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

      TRILL Hellos sent by RB2.  This indicates the sending RBridge
      believes it is Appointed Forwarder for those VLANs.  An RBridge
      receiving such a sub-TLV sets each of its VLAN inhibition timers
      for every VLAN in the block or blocks listed in the Appointed
      Forwarders sub-TLV to the maximum of its current value and the
      Holding Time of the Hello containing the sub-TLV.  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 (Designated RBridge)
      sending Hellos on the Designated VLAN. If RB2 is DRB, it MUST
      include in the Hello all forwarder appointments, if any, for
      RBridges other than itself on the link.

   2. An RBridge MAY use the VLANs Appointed sub-TLV [RFC7176].  When
      RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2
      on any VLAN, RB1 updates the VLAN inhibition timers for all the
      VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is
      Appointed Forwarder.  Each such timer is updated to the maximum of
      its current value and the Holding Time of the TRILL Hello
      containing the VLANs Appointed sub-TLV.  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 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 it is Appointed Forwarder in a Hello sent on the Designated
   VLAN three times per Holding Time.

D. Eastlake, et al                                             [Page 21]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

5. Multiple Ports on the Same Link

   A TRILL switch may have multiple ports on the same link.  Some of
   these ports may be suspended due to MAC address duplication as
   described in [RFC7177].  Suspended ports never ingress or egress
   native frames.

   If a TRILL switch has one or more non-suspended ports on a link and
   those ports offer end station service, that is, those ports are not
   configured as point-to-point or trunk ports, then that TRILL switch
   is eligible to be an Appointed Forwarder for that link.  It can
   become Appointed Forwarder in the ways discussed in Section 2.

   If a TRILL switch that is the Appointed Forwarder for VLAN-x on a
   link has multiple non-suspended ports on that link, it may load share
   the task of ingressing and egressing VLAN-x native frames across
   those ports however it chooses, as long as there is no case in which
   a frame it egresses onto the link from one port can be ingressed on
   another 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.

D. Eastlake, et al                                             [Page 22]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

6. Port-Shutdown Messages

   A TRILL switch may note that one of its ports has failed or it may be
   about to shut down that port. If the port is on a link along with
   ports of other TRILL switches, those TRILL switches will not notice
   the port shutdown or failure using TRILL base protocol mechanisms
   until there is a failure to receive a number of Hellos from that
   port. This can take many seconds.  Network topology (adjacencies) and
   forwarder appointments can react more rapidly to port shutdown or
   failure through explicit notification.  As discussed below, this
   notification SHOULD be provided through the Port-Shutdown message.

6.1 Planned Shutdown and Hellos

   A TRILL switch that is shutting down one of its ports P1 soon SHOULD
   reduce its Holding Time on that port, so that the shutdown will be
   more rapidly noticed by adjacent RBridges that might not support the
   Port Shutdown message.

6.2 Port-Shutdown Message Structure

   The Port-Shutdown Message is an RBridge Channel Message [RFC7178]
   using RBridge Channel protocol number tbd5. The Channel Protocol
   specific payload consists of a list of Port IDs (see Section 4.4.2 of
   [RFC6325]) for the port or ports that have failed or are being
   shutdown as shown below. Support for the Port Shutdown message is
   advertised by simply advertising support for its RBridge Channel
   protocol in the RBridge Channel Protocols Sub-TLV [RFC7176].

D. Eastlake, et al                                             [Page 23]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

      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=tbd5 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Flags        | ERR=0 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Information specific to the Port-Shutdown Channel Protocol:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Port ID 1                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Port ID 2                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Port ID K                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3 Port-Shutdown Message Transmission

   For robustness, a TRILL switch sends a number of copies of a Port-
   Shutdown messages configurable from one to three, which defaults to
   two copies, at a configurable interval, which defaults to 20
   milliseconds (see Section 6.6). As with any adjacency critical
   message, the Port-Shutdown Message SHOULD be sent with highest
   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 is sequentially unicast through
   the rest of the TRILL campus to all RBridges with which P1 had an
   adjacency and which are advertising support for the Port-Shutdown
   RBridge Channel protocol.

   If a port shutdown is planned within one second, then the TRILL

D. Eastlake, et al                                             [Page 24]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   switch ceases to send Hellos out 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 through the
   port as follows:
        - The Outer.MacDA is the All-RBridges multicast address.
      - If an outer VLAN tag is present, it specified 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 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 "cancelled".  This is
   indicated by simply sending Hellos out port P1.

6.4 Port-Shutdown Message Reception

   When a TRILL switch RB1 receives a Port-Shutdown message RB1 checks
   that 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 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 an Appointed Forwarder
   or appoints some new TRILL switch with which it has adjacency as
   Appointed Forwarder.

6.5 Port-Shutdown Message Security

   Port-Shutdown messages can be secured through use of the Channel
   Tunnel security features [RFC7978].

6.6 Port-Shutdown Configuration

   There are two Port-Shutdown configuration parameters (see Section
   6.3):

D. Eastlake, et al                                             [Page 25]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

      Parameter         Default    Range
      ---------        ---------  -------
      PShutdownRepeat        2      1-3
      PShutdownDelay      20ms      0-1000 milliseconds

D. Eastlake, et al                                             [Page 26]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

7. FGL-VLAN Mapping Consistency Checking

   TRILL switches support 24-bit Fine Grained Labels as specified in
   [RFC7172]. Basically a VLAN ID in native traffic between an edge
   TRILL switch and an end station is mapped from/to an FGL as an
   Inner.Label in TRILL Data packets. Since the Appointed Forwarder for
   a VLAN will be ingressing and egressing such native traffic, the
   mapping configured at the Appointed Forwarder is the mapping
   performed.

   However, the Appointed Forwarder for VLAN-x on a link can change for
   reasons discussed elsewhere in this document. Thus all TRILL switches
   on a link that are configured with a FGL-VLAN mapping SHOULD be
   configured with the same mapping. Otherwise traffic might
   unpredictably jump from one FGL to another when the Appointed
   Forwarder changes. TRILL switches SHOULD advertise their mapping on
   the link using the FGL-VLAN-Bitmap and FGL-VLAN-Pairs APPsub-TLVs
   (Sections 10.4 and 10.5) so that consistency checking can be
   automated.

   A TRILL switch SHOULD compare the FGL-VLAN mappings that it sees
   advertised by other TRILL switches on a link with its own and alert
   the network operator if they are inconsistent. Inconsistent means
   that (1) one TRILL switch maps FGL-z to VLAN-x while another maps
   FGL-z to VLAN-y or (2) one TRILL switch maps VLAN-x to FGL-w while
   another maps VLAN-x to FGL-z, all on the same link.

   Depending on how the network is being managed, a transient
   inconsistency may not be a problem. Thus the network operator SHOULD
   NOT be alerted unless the inconsistency persists for a period of time
   which defaults to the TRILL switch's Holding Time and is configurable
   to between zero and 2**16 - 1 seconds where 2**16 - 1 is a special
   value and indicates that such alerts are disabled.

D. Eastlake, et al                                             [Page 27]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

8. Support of E-L1CS

   All TRILL switches MUST support the E-L1CS flooding scope [RFC7356],
   E-L1FS flooding scope [RFC7780], and base LSPs [IS-IS].  It will be
   apparent to any TRILL switch on a link if any other TRILL switch on
   the link is a legacy implementation not supporting E-L1CS because, as
   stated in [RFC7780], all TRILL switches MUST include a Scoped
   Flooding Support TLV [RFC7356] in all TRILL Hellos they send. This
   support of E-L1CS increases the amount of information from each TRILL
   switch that can be synchronized on the link, compared with the
   information capacity of Hellos, by several orders of magnitude.

   For robustness, E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs, and
   E-L1CS FS-PSNPs) MUST NOT exceed 1470 bytes in length; however, any
   such E-L1CS PDU that is received that is longer than 1470 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 a E-L1CS
   PDU. Thus a TRILL switch RB1 with more than one non-suspended port on
   a link (Section 5) transmitting such a PDU MAY transmit it out any
   one or more of such ports. RB1 will generally receive such a PDU that
   other TRILL switches send on all of RB1's ports on the link. In
   addition, with multiple ports on the link, it will receive any such
   PDU that it sends on the ports it has on the link other than the
   transmitting port.

8.1 Backwards Compatibility

   Future TRILL specifications making use of E-L1CS MUST specify how
   situations involving a TRILL link will be handled when one or more
   TRILL switches attached to that link support E-L1CS and one or more
   do not.

D. Eastlake, et al                                             [Page 28]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

9. Security Considerations

   This memo provides improved documentation of the TRILL Appointed
   Forwarder mechanism.  It does not change the security considerations
   of the TRILL base protocol as described in Section 6 of [RFC6325].

   The Port-Shutdown messages specified in Section 6 are sent using the
   RBridge Channel facility [RFC7178]. Such messages SHOULD be secured
   through use of the RBridge Channel Header Extension [RFC7978].

   The E-L1CS FS-LSPs added by Section 6 are a type of IS-IS PDU
   [RFC7356].  As such, they are securable through the addition to those
   PDUs Authentication TLVs [RFC5310] in the same way as Hellos or other
   IS-IS PDUs.

D. Eastlake, et al                                             [Page 29]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

10. Code Points and Data Structures

   This section provides IANA Considerations for this document and
   specifies the structure of the Appointment Bitmap, Appointment List,
   VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs.
   These APPsub-TLVs appears within a TRILL GENINFO TLV [RFC7357] in E-
   L1CS FS-LSPs [RFC7356].

10.1 IANA Considerations

   IANA is requested to assign four new APPsub-TLV type codes from the
   range below 255 and enter them in the "TRILL APPsub-TLV Types under
   IS-IS TLV 251 Application Identifier 1" Registry as follows:

      Type    Name                Reference
      ----   -----------------   ---------------
      tbd1   AppointmentBitmap   [this document]
      tbd2   AppointmentList     [this document]
      tbd3   FGL-VLAN-Bitmap     [this document]
      tbd4   FGL-VLAN-Pairs      [this document]

   IANA is requested to assign a new RBridge Channel protocol number in
   the range assigned by Standards Action and update the "RBridge
   Channel Protocols" registry as follows:

      Protocol  Description     Reference
      --------  --------------  ---------
       tbd5     Port Shut-Down  [this document]

   IANA is requested to update the reference for the "Hello reduction
   support" bit in the "PORT-TRILL-VER Sub-TLV Capability Flags"
   registry on the TRILL Parameters IANA web page to refer to this
   document.

10.2 Appointment Bitmap APPsub-TLV

   The Appointment Bitmap 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
   appointment is only effective when the appointing TRILL switch is
   DRB.

D. Eastlake, et al                                             [Page 30]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

                           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 tbd1.

      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 a 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 the forwarder. The size of the bit
      map is length minus 4. If the size of the bit map is zero, no
      appointments are made.

   Each bit in the Bit Map corresponds to a VLAN ID. Bit 0 is for the
   VLAN whose ID appears in the Starting VLAN 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 Appointment Bitmap APPsub-TLV is originated by the DRB on a
   link, it appoints the TRILL switch whose nickname appears in the
   Appointee Nickname field for the VLAN IDs corresponding to 1 bits in
   the Bit Map and revokes any Hello appointment of that TRILL switch
   for VLANs corresponding to 0 bits in the Bit Map.

10.3 Appointment List APPsub-TLV

   The Appointment List APPsub-TLV provides a convenient method for a
   TRILL switch to indicate which TRILL switches it appoints as

D. Eastlake, et al                                             [Page 31]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   forwarders for which VLAN IDs. Such appointment is only effective
   when the appointing TRILL switch is 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 tbd2.

      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 a forwarder.

      o  RESV: 4 bits that MUST be sent as zero and ignored on receipt.

      o  VLAN ID: A 12-bit VLAN ID for which appointee is being
      appointed the forwarder.

   Type and Length are 2 bytes because these are extended FS-LSPs.

   This APPsub-TLV, when originated by the DRB, appoints the TRILL
   switch with Appointee Nickname to be the Appointed Forwarder for the
   VLAN IDs listed.

10.4 FGL-VLAN Mapping Bitmap APPsub-TLV

   The FGL-VLAN Mapping Bitmap APPsub-TLV provides a method for a TRILL
   switch to indicate the FGL to VLAN ID mappings it is configured to
   perform when egressing and ingressing native frames. The coding is
   efficient when the VLAN IDs are compact, that is, they do not span a
   large numeric range, and the FGLs and VLANs are paired in a
   monotonically increasing fashion.

D. Eastlake, et al                                             [Page 32]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

                           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 tbd3.

      o  Length: 5 + size of bit map in bytes. If Length is less than 5,
      the APPsub-TLV is corrupt and MUST be ignored.

      o  RESV: 4 bits that MUST be sent as zero and ignored on receipt.

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

      o  Starting FGL: Fine Grained Label [RFC7172]

      o  Bit Map: Map of bits for VLANs 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 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 VLAN ID to FGL mapping. 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 corresponds to an
   illegal VLAN ID or illegal FGL is ignored.

D. Eastlake, et al                                             [Page 33]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

10.5 FGL-VLAN Mapping Pairs APPsub-TLV

   The FGL-VLAN Mapping Pairs APPsub-TLV provides a method for a TRILL
   switch to indicate a list of FGL to VLAN ID mappings it is configured
   to perform when egressing and ingressing native frames.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Type                    |                 (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length                  |                 (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      |   Mapping RECORD 1                            | (5 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      |   Mapping RECORD 2                            | (5 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      |      ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
      |   Mapping RECORD k                            | (5 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+

      Where a Mapping RECORD has the following structure:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  RESV |   VLAN ID             |                 (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       FGL                                     | (3 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o  Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV tbd4.

      o  Length: 5*k. If Length is not a multiple of 5, the APPsub-TLV
      is corrupt and MUST be ignored.

      o  RESV: 4 bits that MUST be sent as zero and ignored on receipt.

      o  VLAN ID: 12-bit VLAN label.

      o  FGL: Fine Grained Label [RFC7172]

   Each Mapping RECORD indicates that the originating TRILL switch is
   configured to map between the FGL and VLAN given on egressing and
   ingressing native frames.  However, VLAN ID 0x000 and VLAN ID 0xFFF
   are invalid; any Mapping RECORD that corresponds to an illegal VLAN
   ID is ignored.

D. Eastlake, et al                                             [Page 34]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Normative References

   [802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
         networks - Virtual Bridged Local Area Networks", IEEE Std
         802.1Q-2014, 19 December 2014.

   [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to
         Intermediate System Intra-Domain Routeing Exchange Protocol for
         use in Conjunction with the Protocol for Providing the
         Connectionless-mode Network Service (ISO 8473)", 2002.

   [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997,
         <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
         Ghanwani, "Routing Bridges (RBridges): Base Protocol
         Specification", RFC 6325, July 2011, <http://www.rfc-
         editor.org/info/rfc6325>.

   [RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
         A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq
         Shortest Path Bridging", RFC 6329, April 2012, <http://www.rfc-
         editor.org/info/rfc6329>.

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

   [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
         D., and A. Banerjee, "Transparent Interconnection of Lots of
         Links (TRILL) Use of IS-IS", RFC 7176, May 2014,
         <http://www.rfc-editor.org/info/rfc7176>.

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

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

   [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
         Scope Link State PDUs (LSPs)", RFC 7356, September 2014,
         <http://www.rfc-editor.org/info/rfc7356>.

D. Eastlake, et al                                             [Page 35]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
         Stokes, "Transparent Interconnection of Lots of Links (TRILL):
         End Station Address Distribution Information (ESADI) Protocol",
         RFC 7357, September 2014, <http://www.rfc-
         editor.org/info/rfc7357>.

   [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
         Ghanwani, A., and S. Gupta, "Transparent Interconnection of
         Lots of Links (TRILL): Clarifications, Corrections, and
         Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
         <http://www.rfc-editor.org/info/rfc7780>.

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

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

Informative References

   [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
         and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
         5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.

   [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
         Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC
         6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.

   [RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
         "Problem Statement and Goals for Active-Active Connection at
         the Transparent Interconnection of Lots of Links (TRILL) Edge",
         RFC 7379, October 2014, <http://www.rfc-
         editor.org/info/rfc7379>

D. Eastlake, et al                                             [Page 36]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Acknowledgements

   The following are hereby thanked for their contributions to this
   document:

      Joel Halpern, Sue Hares, Gayle Noble, Mingui Zhang

   The following were acknowledged and thanked by in [RFC6439] or were
   an author of [RFC6439], the predecessor to this document:

      Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik
      Nordmark, Radia Perlman, Dan Romascanu, and Mike Shand.

D. Eastlake, et al                                             [Page 37]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Authors' Addresses

   Donald Eastlake 3rd
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA

   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
   IPinfusion

   EMail: mohammed.umair2@ipinfusion.com

   Ayan Banerjee
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134 USA

   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

D. Eastlake, et al                                             [Page 38]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Appendix A: VLAN Inhibition Example

   The per-VLAN inhibition timers (or the equivalent) are needed to be
   loop safe in the case of misconfigured bridges on a link.

   For a simple example, assume that RB1 and RB2 are the only RBridges
   on the link, that RB1 is higher priority to be the DRB, and that they
   both want VLAN 1 (the default) to be the Designated VLAN.  However,
   there is a bridge between them configured so that RB1 can see all the
   frames sent by RB2 but none of the frames from RB1 can get through to
   RB2.

   Both will think they are the DRB.  RB1 because it is higher priority
   even though it sees the Hellos from RB2, and RB2 because it doesn't
   see the Hellos from RB1 and therefore thinks it is highest priority.

   Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while
   RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4.  There
   is no problem with VLANs 2 and 4 but if you do not do something about
   it, you could have a loop involving VLAN 3.  RB1 will see the Hellos
   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, or 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.

D. Eastlake, et al                                             [Page 39]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Appendix B: Changes to RFCs 6325, 6439, 7177

   This document updates [RFC6325], obsoletes [RFC6439], and updates
   [RFC7177].

   Change to [RFC6325], the TRILL base protocol, is as follows:

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

   Changes from [RFC6439], which this document obsoletes, are as
   follows:

      1. Specify APPsub-TLVs and procedures to be used in E-L1CS FS-LSP
         forwarder appointments.

      2. Incorporate updates to [RFC6439] that appeared in Section 10 of
         RFC 7180 which has been obsoleted by [RFC7780]. They appear
         primarily in Section 4 of this document.

      3. Add optional FGL-VLAN consistency check feature including
         specification of APPsub-TLVs.

      4. Delete references to draft-ietf-trill-rbridge-vlan-mapping
         which has been dropped by the TRILL WG.

      5. Addition of the Port Shutdown message.

      6. Eliminate 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 to optimize (reduce)
         inhibition time under various circumstances.

      8. Editorial changes.

   Changes to [RFC7177] are as follows:

      As provided in Section 6, TRILL switches SHOULD treat the
      reception of a Port-Shutdown RBridge Channel message from RB1
      listing port P1 as if it were an event A3 as specified in
      [RFC7177] resulting in transition of any adjacency to P1 to the
      Detect state.

D. Eastlake, et al                                             [Page 40]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Appendix C: Multi-Link VLAN Mapping Loop Example

   Assume that RBridges RB1 and RB2 have ports P1 and P2, respectively,
   that are both on link L1 and that RBridges RB3 and RB4 have ports P3
   and P4, respectively, that are both on Link L2. Assume further that
   P1 and P3 are Appointed Forwarder for VLAN-x and P2 and P4 are
   Appointed Forwarder 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 L1 and L2 are each bridged LANs that include a device
   M, presumably a bridge, that maps VLAN-x into VLAN-y and VLAN-y into
   VLAN-x.

   If end station ES1 originated a broadcast or other multi-destination
   frame in VLAN-y, it would be ingressed by RB2. (The frame would also
   be mapped to VLAN-x and ingressed by RB1 but we initially ignore
   that.)  RB2 will flood the resulting TRILL Data packet through the
   campus and, at least in the broadcast and unknown unicast cases, it
   will get to RB4 where it will be egressed to L2. Inside L2, this
   broadcast frame is mapped to VLAN-x and then ingressed by RB3. RB3
   then floods the resulting TRILL Data packet through the campus, this
   time with an Inner.VLAN of VLAN-x, as a result of which it will be
   egressed by RB1 into L1. Inside L1, it will be mapped back to VLAN-y
   and then ingressed by RB2 completing the loop. The packet will loop
   indefinitely, because in native form on L1 and L2 it has no TRILL hop
   count, and an indefinitely large number of copies will be delivered
   to ES1 and any other end station so situated. The same problem would
   occur even if P1 and P2 were on the same RBridge and/or P3 and P4
   were on the same RBridge. Actually, because the original frame was
   also mapped to VLAN-x inside L1 and ingressed by RB1, there are two
   copies looping around in opposite directions.

   The use of Fine Grained Labels [RFC7172] complicates but does not

D. Eastlake, et al                                             [Page 41]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

   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.

D. Eastlake, et al                                             [Page 42]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Appendix Z: Change Record

   This appendix summarizes changes between versions of this draft.

   RFC Editor: Please delete this Appendix before publication.

Initial WG version -00

From -00 to -01

   Primarily editorial changes based on review by Gayle Noble.

From -01 to -02

   Primarily editorial changes based on RTGDIR QA review by Joel
   Halpern.

From -03 to -04

   Update references and incorporate changes from SECDIR review.

D. Eastlake, et al                                             [Page 43]
INTERNET-DRAFT                               TRILL: Appointed Forwarders

Copyright and IPR Provisions

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.

D. Eastlake, et al                                             [Page 44]