Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8139

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

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

Top   ToC   RFC8139 - Page 1
Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 8139                                         Y. Li
Obsoletes: 6439                                                   Huawei
Updates: 6325, 7177                                             M. Umair
Category: Standards Track                                    IP Infusion
ISSN: 2070-1721                                              A. Banerjee
                                                                   Cisco
                                                                   F. Hu
                                                                     ZTE
                                                               June 2017


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

Abstract

TRILL (Transparent Interconnection of Lots of Links) supports multi- access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8139.
Top   ToC   RFC8139 - Page 2
Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC8139 - Page 3

Table of Contents

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

1. Introduction

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7780] provides optimal pairwise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes these by using IS-IS (Intermediate System to Intermediate System) [IS-IS] [RFC7176] link-state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs, FGLs (Fine-Grained Labels) [RFC7172], and optimization of the distribution of multi-destination frames based on VLANs and multicast groups. Devices that implement TRILL are called TRILL switches or "RBridges" (Routing Bridges). Section 2 of [RFC7177] discusses the environment for which the TRILL protocol is designed and the differences between that environment and the typical Layer 3 routing environment. TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those switches called "Appointed Forwarders" as originally specified in [RFC6325], with the intent that native traffic in each VLAN be handled by at most one switch. A TRILL switch can be Appointed Forwarder for many VLANs. The purpose of this document is to update and improve the Appointed Forwarder mechanism and free it from the limitations imposed by the requirement in its initial design that all appointments fit within a TRILL Hello Protocol Data Unit (PDU). This is accomplished by requiring support of link-scoped FS-LSPs (Flooding Scope Link State PDUs) (Section 8) and providing the option to send appointment information in those LSPs. In addition, this document provides a number of other optional features to 1. detect inconsistent VLAN-ID-to-FGL [RFC7172] mappings among the TRILL switch ports on a link, as discussed in Section 7, 2. expedite notification of ports going down so that Appointed Forwarders can be adjusted, as discussed in Section 6, and 3. reduce or eliminate the need for "inhibition" of ports for loop safety, as discussed in Section 3.2.
Top   ToC   RFC8139 - Page 5
   This document replaces and obsoletes [RFC6439], incorporating the
   former material in [RFC6439] with these additions.  The various
   optimizations are orthogonal and optional.  Implementers can choose
   to provide all, some, or none of them, and TRILL switches will still
   be interoperable.  In accordance with the TRILL design philosophy,
   these optimizations require zero or minimal configuration, but there
   are a couple of configurable parameters, as summarized in Section 11.

   As described in Appendix C, this document updates [RFC6325] by
   mandating support of E-L1CS FS-LSPs and provides backward
   compatibility in the presence of legacy TRILL switches that do not
   provide this support.  It also updates [RFC7177] by providing, as an
   optional optimization, that receipt of the Port-Shutdown message
   specified herein be treated as an event in the state machine
   specified in [RFC7177].

   This document includes reference implementation details.  Alternative
   implementations that interoperate on the wire are permitted.

   The Appointed Forwarder mechanism is irrelevant to any link on which
   end-station service is not offered.  This includes links configured
   as point-to-point IS-IS links and any link with all TRILL switch
   ports on that link configured as trunk ports.  (In TRILL,
   configuration of a port as a "trunk port" just means that no
   end-station service will be provided.  It does not imply that all
   VLANs are enabled on that port.)

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

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

1.1. Appointed Forwarders and Active-Active

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

1.2. Terminology and Abbreviations

This document uses the abbreviations and terms defined in [RFC6325], some of which are repeated below for convenience, and additional abbreviations and terms listed below. Data Label mapping: The mapping from VLAN ID to FGL and from FGL to VLAN ID. DRB: Designated RBridge. The RBridge on a link elected as specified in [RFC7177] to handle certain decisions and tasks for that link, including forwarder appointment as specified herein. E-L1CS: Extended Level 1 Circuit Scope (Section 8). FGL: Fine-Grained Label [RFC7172]. FS-LSP: Flooding Scope Link State PDU (Section 8). Link: The means by which adjacent TRILL switches are connected. A TRILL link may be various technologies and, in the common case of Ethernet, can be a "bridged LAN" -- that is to say, some combination of Ethernet links with zero or more bridges, hubs, repeaters, or the like. LSDB: Link State Database. PDU: Protocol Data Unit. RBridge: An alternative name for a TRILL switch. TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer. TRILL switch: A device implementing the TRILL protocol. An alternative name for an RBridge. Trunk port: A TRILL switch port configured with the "end-station service disable" bit on, as described in Section 4.9.1 of [RFC6325]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Top   ToC   RFC8139 - Page 7

2. Appointed Forwarders and Their Appointment

The Appointed Forwarder on a link for VLAN-x is the TRILL switch (RBridge) that ingresses native frames from the link and egresses native frames to the link in VLAN-x. By default, the DRB (Designated RBridge) on a link is in charge of native traffic for all VLANs on the link. The DRB may, if it wishes, act as Appointed Forwarder for any VLAN, and it may appoint other TRILL switches that have ports on the link as Appointed Forwarder for one or more VLANs. By definition, the DRB considers the other ports on the link to be the ports with which a DRB port has adjacency on that link [RFC7177]. If the DRB loses adjacency to a TRILL switch that it has appointed as forwarder and the native traffic that was being handled by that Appointed Forwarder is still to be ingressed and egressed, it SHOULD immediately appoint another forwarder or itself become the forwarder for that traffic. It is important that there not be two Appointed Forwarders on a link that are ingressing and egressing native frames for the same VLAN at the same time. Should this occur, it could form a loop where frames are not protected by a TRILL Hop Count for part of the loop. (Such a condition can even occur through two Appointed Forwarders for two different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the link are configured to map frames between VLAN-x and VLAN-y as discussed in Section 2.5.) While TRILL tries to avoid such situations, for loop safety there is also an "inhibition" mechanism (see Section 3) that can cause a TRILL switch that is an Appointed Forwarder not to ingress or egress native frames. Appointed Forwarder status and port "inhibition" have no effect on the reception, transmission, or forwarding of TRILL Data or TRILL IS-IS frames. Appointed Forwarder status and inhibition only affect the handling of native frames. As discussed in Section 5, an RBridge may have multiple ports on a link. As discussed in [RFC7177], if there are multiple ports with the same Media Access Control (MAC) address on the same link, all but one will be suspended. The case of multiple ports on a link for the same TRILL switch and the case of multiple ports with the same MAC address on a link, as well as combinations of these cases, are fully accommodated; however, the case of multiple ports on a link for the same TRILL switch is expected to be a rare condition, and the case of duplicate MAC addresses is not recommended by either TRILL or IEEE 802.1 standards.
Top   ToC   RFC8139 - Page 8
   There are six mechanisms by which an RBridge can be appointed or
   unappointed as Appointed Forwarder:

   1. assumption of appointment, when the DRB decides to act as
      Appointed Forwarder for a VLAN,

   2. E-L1CS appointment, as a result of appointments sent by the DRB in
      E-L1CS FS-LSPs,

   3. Hello appointment, as a result of appointments sent by the DRB in
      TRILL Hellos,

   4. as a result of the DRB elections [RFC7177] as discussed in
      Section 2.2,

   5. as a result of a Port-Shutdown message as discussed in Section 6,
      and

   6. as a result of a local configuration action as discussed in
      Section 2.3.

   Mechanisms 2 and 3 are covered in Section 2.1.

2.1. The Appointment Databases and DRB Actions

The DRB MAY appoint other RBridges on the link as Appointed Forwarders through two mechanisms, "A" and "B", as described below. Each RBridge maintains two databases of appointment information: (1) its E-L1CS LSDB, which shows appointments that each RBridge on the link would make using mechanism A if that RBridge were the DRB, and (2) its Hello appointment database, which shows the appointments most recently sent by the DRB in a TRILL Hello. The E-L1CS LSDB is semi-permanent and is only changed by E-L1CS FS-LSPs or IS-IS purges. The Hello appointment database is more transient and is completely reset by each Hello received from the DRB that contains any appointments; this database is also cleared under other circumstances, as described below. An RBridge considers itself to be the Appointed Forwarder for VLAN-x if this is indicated by either its Hello appointment database or its E-L1CS LSDB entries from the DRB.
Top   ToC   RFC8139 - Page 9
   The two mechanisms by which the DRB can appoint other RBridges on a
   link as Appointed Forwarders are as follows:

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

   (B) The inclusion of one or more Appointed Forwarders sub-TLVs
       [RFC7176] in a TRILL Hello it sends on the Designated VLAN out of
       the port that won the DRB election.  When the DRB sends any
       appointments in a TRILL Hello, it must send all appointments it
       is sending in Hellos for that link in that Hello.  Any previous
       appointment it has sent in a Hello that is not included is
       implicitly revoked.

   To avoid the size limitations of the Hello PDU, it is RECOMMENDED
   that the E-L1CS FS-LSP method be used to distribute forwarder
   appointments and that all RBridges on a link use this method to
   advertise the appointments they would make if they were the DRB.
   However, if some RBridges on a link do not support E-L1CS FS-LSPs,
   then Hello appointments must be used for the DRB to appoint such
   legacy RBridges as Appointed Forwarders.

   Although the DRB does not need to announce the VLANs for which it has
   chosen to act as Appointed Forwarder by sending appointments for
   itself, if the DRB wishes to revoke all appointments made in Hellos
   for RBridges other than itself on the link, it can do so by sending a
   TRILL Hello with just an appointment for itself for some VLAN.

   How the DRB decides what other RBridges on the link, if any, to
   appoint as forwarder for some VLAN or VLANs is beyond the scope of
   this document.

   Unnecessary changes in Appointed Forwarders SHOULD NOT be made, as
   they may result in transient lack of end-station service.

   Should the network manager have misconfigured the enabled VLANs and
   Appointed Forwarders, resulting in two RBridges believing they are
   Appointed Forwarders for the same VLAN, the scenario described in
   item 4 in Section 3 will cause one or more of the RBridges to be
   inhibited for that VLAN, thus avoiding persistent loops.
Top   ToC   RFC8139 - Page 10
   When forwarder appointments are being encoded for transmission,
   different patterns of VLANs are most efficiently encoded in different
   ways.  The following table gives advice regarding the most efficient
   encoding for a given pattern:

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

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

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

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

2.2. Appointment Effects of DRB Elections

When a TRILL switch port on a link wins the DRB election, there are four possible cases: 1. A TRILL switch believes that it was the DRB and remains the DRB: there is no change in Appointed Forwarder status. This also applies in the corner case where a TRILL switch has more than one port on a link, one of which was previously the DRB election winner but has just lost the DRB election to a different port of the same TRILL switch on the same link (possibly due to management configuration of port priorities). In this case, there also is no change in which TRILL switch is the DRB. 2. A TRILL switch believes that it was not the DRB but has now won the DRB election and become the DRB on a link: by default, it can act as Appointed Forwarder for any VLANs on that link that it chooses, as long as its port is not configured as a trunk port and has that VLAN enabled (or at least one of its ports meets these criteria, if it has more than one port on the link). It ignores any previous forwarder appointment information it received from other TRILL switches on the link.
Top   ToC   RFC8139 - Page 11
   3. A TRILL switch was not the DRB and does not become the DRB, but it
      observes that the port winning the DRB election has changed: the
      TRILL switch loses all Hello appointments.  In addition, there are
      two subcases:

      a. The new winning port and the old winner are ports of different
         TRILL switches on the link.  In this case, it switches to using
         the E-L1CS FS-LSP appointments for the winning TRILL switch.

      b. The new winning port and the old winner are ports of the same
         TRILL switch, which has two (or more) ports on the link:
         although the Hello appointments are still discarded, since the
         same TRILL switch is the DRB, the E-L1CS FS-LSP appointments
         are unchanged.

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

2.2.1. Processing Forwarder Appointments in Hellos

When a non-DRB RBridge that can offer end-station service on a link receives a TRILL Hello that is not discarded for one of the reasons given in [RFC7177], it checks the source MAC address and the Port ID and System ID in the Hello to determine if it is from the winning DRB port. If it is not from that port, any forwarder appointment sub-TLVs in the Hello are ignored, and there is no change in the receiving RBridge's Appointed Forwarder status due to that Hello. Also, if no forwarder appointment sub-TLVs are present in the TRILL Hello, there is no change in the receiver's Appointed Forwarder status due to that Hello. However, if the TRILL Hello is from the winning DRB port and the Hello includes one or more forwarder appointment sub-TLVs, then the receiving RBridge sets its Hello appointment database to be the set of VLANs that have both of the following characteristics: o The VLAN is listed as an appointment for the receiving RBridge in the Hello, and o The VLAN is enabled on the port where the Hello was received. (If the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored, but any other VLAN IDs are still effective.) It then becomes Appointed Forwarder for all the VLANs for which it is appointed in either its Hello appointment database or its E-L1CS FS-LSP appointment database from the DRB if the VLAN is enabled and if the port is not configured as a trunk or IS-IS point-to-point port. If the receiver was Appointed Forwarder for any VLANs because
Top   ToC   RFC8139 - Page 12
   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
Top   ToC   RFC8139 - Page 13
      would be required, although only one appointment would be required
      if the Designated VLAN value were extremely low or high (such as
      VLAN 0xFFE) or the default value (VLAN 1).

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

2.2.2. Frequency of Hello Appointments

Appointments made through E-L1CS FS-LSPs use the same IS-IS timing constants as those for LSP flooding. The general IS-IS link-state flooding mechanism is robust and includes acknowledgments so that it automatically recovers from lost PDUs, rebooted TRILL switches, and the like. For Hello appointments, it is not necessary for the DRB to include the Hello forwarder appointments in every TRILL Hello that it sends on the Designated VLAN for a link. For loop safety, every RBridge is required to indicate, in every TRILL Hello it sends in VLAN-x on a link, whether it is an Appointed Forwarder for VLAN-x for that link (see item 4 in Section 3, but see also Section 4). It is also RECOMMENDED that the DRB have enabled all VLANs for which end-station service will be offered on the link as well as the Designated VLAN. Thus, the DRB will generally be informed by other RBridges on the link of the VLANs for which they believe that they are the Appointed Forwarder. If this matches the appointments the DRB wishes to make, it is not required to resend its forwarder appointments; however, for robustness, especially in cases such as VLAN misconfigurations in a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder appointments on the Designated VLAN at least once per its Holding Time on the port that won the DRB election.

2.2.3. Appointed Forwarders Hello Limit

The Hello mechanism of DRB forwarder appointment and the limited length of TRILL Hellos impose a limit on the number of RBridges on a link that can be Appointed Forwarders when E-L1CS FS-LSP appointments cannot be used due to the presence of legacy RBridges. To obtain a conservative estimate of this limit, assume that no more than 1,000 bytes are available in a TRILL Hello for such appointments. Assume also that it is desired to appoint various RBridges on a link as forwarder for arbitrary non-intersecting sets of VLANs. Using the technique discussed at the end of Section 2.2.1 would generally
Top   ToC   RFC8139 - Page 14
   require two appointments, or 12 bytes, per RBridge.  With allowance
   for sub-TLV and TLV overhead, appointments for 83 RBridges would
   fit in under 1,000 bytes.  Including the DRB, this implies a link
   with 84 or more RBridges attached.  Links with more than a handful of
   RBridges attached are expected to be rare, and in any case such
   limitations are easily avoided by using E-L1CS FS-LSP appointment.

2.3. Effects of Local Configuration Actions on Appointments

Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder status that RBridge has for VLAN-x, unless VLAN-x is enabled on some other port that the RBridge has connected to the same link. Configuring a port as a trunk port or point-to-point port revokes any Appointed Forwarder status that depends on enabled VLANs at that port. Causing a port to no longer be configured as a trunk or point-to-point port or enabling VLAN-x on a port does not necessarily cause the RBridge to become an Appointed Forwarder for the link that port is on. However, such actions allow the port's RBridge to become Appointed Forwarder by choice if it is the DRB or, if it is not the DRB on the link, by appointment as indicated by the Hello appointment database or the E-L1CS FS-LSP appointment database.

2.4. Overload and Appointed Forwarders

A TRILL switch in link-state overload [RFC7780] will, in general, do a poorer job of forwarding frames than a TRILL switch not in overload, because the TRILL switch not in overload has full knowledge of the campus topology. For example, as explained in [RFC7780], an overloaded TRILL switch may not be able to distribute multi-destination TRILL Data packets at all. Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an Appointed Forwarder, and if an Appointed Forwarder becomes overloaded, the DRB SHOULD reassign VLANs from the overloaded RBridge to another RBridge on the link that is not overloaded, if one is available. A counter-example where it would be best to appoint an RBridge in overload as Appointed Forwarder would be if RB1 was in overload but all end stations in the campus in VLAN-x were on links attached to RB1. In such a case, RB1 would never have to route VLAN-x end-station traffic as TRILL Data packets but would always be forwarding them locally as native frames. In this case, RB1 SHOULD NOT be disadvantaged for selection as the VLAN-x Appointed Forwarder on any such links, even if RB1 is in overload.
Top   ToC   RFC8139 - Page 15
   There is also the case where it is unavoidable to appoint an RBridge
   in overload as Appointed Forwarder, because all RBridges on the link
   are in overload.

   These cases do not violate the prohibition in the IS-IS standard
   against routing through an overloaded node.  Designation as an
   Appointed Forwarder has to do with the ingress and egress of native
   frames and has nothing to do with the IS-IS routing of TRILL Data
   packets through a TRILL switch.

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

2.5. VLAN Mapping within a Link

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

3. The Inhibition Mechanism

A TRILL switch has, for every link on which it can offer end-station service (that is, every link for which it can act as an Appointed Forwarder), the following timers, denominated in seconds: - a DRB inhibition timer, - a root bridge change inhibition timer, and - up to 4,094 VLAN inhibition timers, one for each legal VLAN ID. The DRB and root bridge change inhibition timers MUST be implemented.
Top   ToC   RFC8139 - Page 16
   The loss of native traffic due to inhibition will be minimized by
   logically implementing a VLAN inhibition timer per each VLAN for
   which end-station service will ever be offered by the RBridge on the
   link; this SHOULD be done.  (See Appendix A for an example
   illustrating a potential problem that is solved by VLAN inhibition
   timers.)  However, if implementation limitations make a full set of
   such timers impractical, the VLAN inhibition timers for more than one
   VLAN can, with care, be merged into one timer.  In particular, an
   RBridge MUST NOT merge the VLAN inhibition timers for two VLANs if it
   is the Appointed Forwarder for one but not for the other, as this can
   lead to unnecessary indefinitely prolonged inhibition.  In a given
   implementation limitation, there will be safe operations, albeit with
   more loss of native frames than would otherwise be required, even if
   only two VLAN inhibition timers are provided: one for the VLANs for
   which the RBridge is the Appointed Forwarder and one for all other
   VLANs.  Thus, at least two VLAN inhibition timers MUST be
   implemented.  Where a VLAN inhibition timer represents more than one
   VLAN, an update or test that would have been done to the timer for
   any of the VLANs is performed on the merged timer.

   These timers are set as follows:

   1. On booting or management reset, each port will have its own set of
      timers, even if two or more such ports are on the same link,
      because the TRILL switch will not have had a chance yet to learn
      that they are on the same link.  All inhibition timers are set to
      "expired", except the DRB inhibition timer that is set in
      accordance with item 2 below.  The DRB inhibition timer is handled
      differently, because each port will initially believe that it is
      the DRB.

   2. When a TRILL switch decides that it has become the DRB on a link,
      including when it is first booted or reset by management, it sets
      the DRB inhibition timer to the Holding Time of its port on that
      link that won the DRB election.

   3. When a TRILL switch decides that it has lost DRB status on a link,
      it sets the DRB inhibition timer to "expired".

   Note: In the corner case where one port of a TRILL switch was the DRB
   election winner but later lost the DRB election to a different port
   of the same TRILL switch on that link (perhaps due to management
   configuration of port priorities), neither item 2 nor item 3 above
   applies, and the DRB timer is not changed.

   4. When a TRILL switch RB1 receives a TRILL Hello asserting that the
      sender is the Appointed Forwarder and that Hello either
      (1) arrives on VLAN-x or (2) was sent on VLAN-x as indicated
Top   ToC   RFC8139 - Page 17
      inside the Hello, RB1 uses as its VLAN-x inhibition timer for the
      link (1) that timer's existing value or (2) the Holding Time in
      the received Hello, whichever is longer.  A TRILL switch MUST
      maintain VLAN inhibition timers covering a link to which it
      connects if it can offer end-station service on that link, even if
      it is not currently the Appointed Forwarder for any VLAN on that
      link.

   5. When a TRILL switch RB1 enables VLAN-x on a port connecting to a
      link and VLAN-x was previously not enabled on any of RB1's ports
      on that link, it sets its VLAN inhibition timer for VLAN-x for
      that link to its Holding Time for that port.  This is done even if
      the port is configured as a trunk or point-to-point port, as long
      as there is some chance it might later be configured not to be a
      trunk or point-to-point port.  Remember, inhibition has no effect
      on TRILL Data or IS-IS packets; inhibition only affects native
      frames.

   6. When a TRILL switch detects a change in the common spanning tree
      root bridge on a port, it sets its root bridge change inhibition
      timer for the link to an amount of time that defaults to
      30 seconds and is configurable to any value from 30 down to
      0 seconds.  This condition will not occur unless the TRILL switch
      is receiving Bridge PDUs (BPDUs) on the port from an attached
      bridged LAN; if no BPDUs are being received, the root bridge
      change inhibition timer will never be set.  It is safe to
      configure this inhibition time to the settling time of an attached
      bridged LAN.  For example, if it is known that the Rapid Spanning
      Tree Protocol (RSTP) [802.1Q] is running throughout the attached
      bridged LAN, it is safe to configure this inhibition time to
      7 seconds or, if the attached bridges have been configured to have
      a minimum Bridge Hello Timer, it is safe to configure it to
      4 seconds.  Further optimizations are specified in Section 3.2.

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

   8. When an RBridge decides that a set of its ports that it had been
      treating as being on the same link are no longer on the same link,
      those ports will necessarily be on two or more links (up to one
      link per port).  This is handled by cloning a copy of the timers
      for each of the two or more links to which the TRILL switch has
      decided these ports connect.
Top   ToC   RFC8139 - Page 18

3.1. Inhibited Appointed Forwarder Behavior

Inhibition has no effect on the receipt or forwarding of TRILL Data packets or TRILL IS-IS packets. It only affects ingressing and egressing native frames. An Appointed Forwarder for a link is inhibited for VLAN-x if: 1. its DRB inhibition timer for that link is not expired, 2. its root bridge change inhibition timer for that link is not expired, or 3. its VLAN inhibition timer for that link covering VLAN-x is not expired. If a VLAN-x Appointed Forwarder for a link is inhibited and receives a TRILL Data packet whose encapsulated frame would normally be egressed to that link in VLAN-x, it decapsulates the native frame as usual. However, it does not output it to, or queue it for, that link, although, if appropriate (for example, the frame is multi-destination), it may output it to, or queue it for, other links. If a VLAN-x Appointed Forwarder for a link is inhibited and receives a native frame in VLAN-x that would normally be ingressed from that link, the native frame is ignored, except for address learning. A TRILL switch with one or more unexpired inhibition timers, possibly including an unexpired inhibition timer covering VLAN-x, is still required to indicate in TRILL Hellos it sends on VLAN-x whether or not it is Appointed Forwarder for VLAN-x for the port on which it sends the Hello.

3.2. Root Bridge Change Inhibition Optimizations

The subsections below specify three optimizations that can reduce the inhibition time of an RBridge port under certain circumstances for changes in the root Bridge ID [802.1Q] being received by that port and thus decrease any transient interruption in end-station service due to inhibition. TRILL switches MAY implement these optimizations. In the first two optimizations, inhibition can be eliminated entirely under some circumstances. These optimizations are a bit heuristic in that with some unlikely multiple changes in a bridged LAN that occur simultaneously, or nearly so, the optimizations make transient looping more likely.
Top   ToC   RFC8139 - Page 19

3.2.1. Optimization for Change to Lower Priority

Assume that the root Bridge ID being received on an RBridge port changes to a new root Bridge ID with lower priority and a different root Bridge MAC address due to a single change in the bridged LAN. There are two possible reasons for this: 1. The bridged LAN to which the port is connected has partitioned into two or more parts due to link failure or otherwise, and the port is connected to a part that does not contain the original root bridge. 2. The original root bridge has been reconfigured to have a lower priority, and a new root has taken over. Both of these scenarios are safe conditions that do not require inhibition.

3.2.2. Optimization for Change to Priority Only

Assume that the root Bridge ID changes due to a single change in the bridged LAN but only the explicit priority portion of it changes. This means that the 48-bit MAC address portion of the root Bridge ID is unchanged and the root bridge has been reconfigured to have a different priority. Thus, the same bridge is root, and a topology change is not indicated. Thus, it is safe to ignore this sort of root Bridge ID change and not invoke the inhibition mechanism.

3.2.3. Optimizing the Detection of Completed Settling

A dangerous case is the merger of bridged LANs that had been separate TRILL links in the same campus. In general, these links may have had different Appointed Forwarders on them for the same VLAN. Without inhibition, loops involving those VLANs could occur after the merger. Only native frames egressed and ingressed by RBridges are a potential problem. TRILL Data packets are either 1. individually addressed (TRILL Header M bit = 0) and will be ignored if delivered to any incorrect TRILL switch ports or 2. multicast (TRILL Header M bit = 1), in which case the Reverse Path Forwarding Check discards any copies delivered to incorrect TRILL switch ports. Thus, there is no need for inhibition to affect the sending or receiving of TRILL Data packets, and inhibition does not do so.
Top   ToC   RFC8139 - Page 20
   However, root bridge change inhibition is only needed until TRILL
   Hellos have been exchanged on the merged bridged LAN.  Hellos
   indicate Appointed Forwarder status and, in general, after an
   exchange of Hellos the new merged bridged LAN link will, if
   necessary, be rendered TRILL loop safe by VLAN inhibition so that
   root bridge change inhibition is no longer needed.

   TRILL switches are required to advertise in their link state the IDs
   of the root Bridge IDs they can see.  If an RBridge port sees a
   change in root Bridge ID from Root1 to Root2, it is safe to terminate
   root bridge change inhibition on that port as soon as Hellos have
   been received on the port from all RBridges that can see Root1 or
   Root2, except any such RBridge that is no longer reachable.

   In further detail, when a change from Root1 to Root2 is noticed at a
   port of RB1, RB1 associates with that port a list of all of the
   reachable RBridges, other than itself, that had reported in their
   LSPs that they could see either Root1 or Root2.  It then removes from
   this list any RBridge that becomes unreachable from RB1 or from which
   it has received a Hello on that port.  If there is a subsequent
   change in root Bridge ID being received before this list is empty,
   say to Root7, then those RBridges reporting in their LSPs that they
   can see Root7 are added to the list.  Root bridge change inhibition
   can be terminated for the port as soon as either the timeout is
   reached or this list of RBridges is empty.

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



(page 20 continued on part 2)

Next Section