doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc7177.txt b/doc/rfc/rfc7177.txt
new file mode 100644
index 0000000..28b4fc5
--- /dev/null
+++ b/doc/rfc/rfc7177.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
+Request for Comments: 7177                                        Huawei
+Obsoletes: 6327                                               R. Perlman
+Updates: 6325                                                 Intel Labs
+Category: Standards Track                                    A. Ghanwani
+ISSN: 2070-1721                                                     Dell
+                                                                 H. Yang
+                                                                   Cisco
+                                                               V. Manral
+                                                             Ionos Corp.
+                                                                May 2014
+
+
+    Transparent Interconnection of Lots of Links (TRILL): Adjacency
+
+Abstract
+
+   The IETF Transparent Interconnection of Lots of Links (TRILL)
+   protocol supports arbitrary link technologies between TRILL switches,
+   including point-to-point links and multi-access Local Area Network
+   (LAN) links that can have multiple TRILL switches and end stations
+   attached.  TRILL uses Intermediate System to Intermediate System
+   (IS-IS) routing.  This document specifies the establishment,
+   reporting, and termination of IS-IS adjacencies between TRILL
+   switches, also known as RBridges (Routing Bridges).  It also concerns
+   four other link-local aspects of TRILL: Designated RBridge (DRB)
+   selection, MTU (Maximum Transmission Unit) testing, pseudonode
+   creation, and BFD (Bidirectional Forwarding Detection) session
+   bootstrapping in connection with adjacency.  State diagrams are
+   included where appropriate.  This document obsoletes RFC 6327 and
+   updates RFC 6325.
+
+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 5741.
+
+   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/rfc7177.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 1]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 2]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Content and Precedence .....................................5
+      1.2. Terminology and Acronyms ...................................5
+   2. The TRILL Hello Environment and Purposes ........................6
+      2.1. RBridge Interconnection by Ethernet ........................6
+      2.2. Handling Native Frames .....................................7
+      2.3. Zero or Minimal Configuration ..............................8
+      2.4. MTU Robustness .............................................8
+      2.5. Purposes of the TRILL Hello Protocol .......................9
+   3. Adjacency State Machinery ......................................10
+      3.1. TRILL Hellos, Ports, and VLANs ............................10
+      3.2. Adjacency Table Entries and States ........................11
+      3.3. Adjacency and Hello Events ................................12
+      3.4. Adjacency State Diagram and Table .........................15
+      3.5. Multiple Parallel Links ...................................17
+      3.6. Insufficient Space in Adjacency Table .....................17
+   4. LAN Ports and DRB State ........................................17
+      4.1. Port Table Entries and DRB Election State .................18
+      4.2. DRB Election Events .......................................19
+           4.2.1. DRB Election Details ...............................20
+           4.2.2. Change in DRB ......................................20
+           4.2.3. Change in Designated VLAN ..........................21
+      4.3. Port State Table and Diagram ..............................21
+   5. MTU Matching ...................................................22
+   6. BFD-Enabled TLV and BFD Session Bootstrapping ..................24
+   7. Pseudonodes ....................................................25
+   8. More TRILL Hello Details .......................................26
+      8.1. Contents of TRILL Hellos ..................................27
+      8.2. Transmitting TRILL Hellos .................................27
+           8.2.1. TRILL Neighbor TLVs ................................28
+      8.3. Receiving TRILL Hellos ....................................29
+   9. Multiple Ports on the Same Broadcast Link ......................29
+   10. IANA Considerations ...........................................30
+   11. Security Considerations .......................................30
+   Appendix A. Changes from RFC 6327 .................................31
+   Appendix B. Changes to RFC 6325 ...................................31
+   Normative References...............................................32
+   Informative References.............................................33
+   Acknowledgements...................................................34
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 3]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+1.  Introduction
+
+   The IETF Transparent Interconnection of Lots of Links (TRILL)
+   protocol [RFC6325] provides optimal pair-wise data frame forwarding
+   without configuration, safe forwarding even during transient loops,
+   and support for transmission of both unicast and multicast traffic
+   taking advantage of multiple paths in multi-hop networks with
+   arbitrary topology.  End stations are connected to TRILL switches
+   with Ethernet, but TRILL switches can be interconnected with
+   arbitrary link technology.  TRILL accomplishes this by using [IS-IS]
+   (Intermediate System to Intermediate System) link-state routing
+   [RFC1195] [RFC7176] and a header in TRILL Data packets that includes
+   a hop count.  The design supports data labeling by Virtual Local Area
+   Networks (VLANs) and fine-grained labels [RFC7172] as well as
+   optimization of the distribution of multi-destination frames based on
+   data label and multicast groups.  Devices that implement TRILL are
+   called TRILL switches or RBridges (Routing Bridges).
+
+   This document provides detailed specifications for five of the link-
+   local aspects of the TRILL protocol used on broadcast links (also
+   called LAN or multi-access links) and for the three of these aspects
+   that are also used on point-to-point (P2P) links.  It includes state
+   diagrams and implementation details where appropriate.  Alternative
+   implementations that interoperate on the wire are permitted.
+
+   The scope of this document is limited to the following aspects of the
+   TRILL protocol; their applicability, along with the most relevant
+   section of this document, are as shown here:
+
+     LAN  P2P  Section  Link-Local Aspect
+     ---  ---  -------  ----------------------------------------------
+
+      X    X      3     Adjacency formation and dissolution
+      X           4     DRB (Designated RBridge) election
+      X    X      5     MTU (Maximum Transmission Unit) matching
+      X    X      6     1-hop BFD (Bidirectional Forwarding Detection)
+                           for adjacency
+      X           7     Creation and use of pseudonodes [IS-IS]
+
+                      Table 1: LAN/P2P Applicability
+
+   There is no DRB (also known as DIS (Designated Intermediate System))
+   election and no pseudonode creation on links configured as point-to-
+   point.
+
+   For other aspects of the TRILL base protocol, see [RFC6325],
+   [RFC6439], [RFC7180], and [ESADI].
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 4]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   This document obsoletes [RFC6327].  See Appendix A for a summary of
+   changes from [RFC6327].  This document updates [RFC6325] as described
+   in Appendix B.
+
+1.1.  Content and Precedence
+
+   In cases of conflict between this document and [RFC6325], this
+   document prevails.
+
+   Section 2 below explains the rationale for the differences between
+   the TRILL Hello protocol and the Layer 3 IS-IS Hello protocol in
+   light of the environment for which the TRILL protocol is designed.
+   It also describes the purposes of the TRILL Hello protocol.
+
+   Section 3 describes the adjacency state machine, its states, and its
+   relevant events.
+
+   Section 4 describes the Designated RBridge (DRB) election state
+   machine for RBridge LAN ports, its states, and its relevant events.
+
+   Section 5 describes MTU testing and matching on a TRILL link.
+
+   Section 6 discusses one-hop BFD session bootstrapping in connection
+   with adjacency.
+
+   Section 7 discusses pseudonode creation and use on LAN links.
+
+   Section 8 provides more details on the reception and transmission of
+   TRILL Hellos.
+
+   Section 9 discusses the case of multiple ports from one RBridge on
+   the same link.
+
+1.2.  Terminology and Acronyms
+
+   This document uses the acronyms defined in [RFC6325], supplemented by
+   the following additional acronyms:
+
+      BFD - Bidirectional Forwarding Detection [RFC7175].
+
+      SNPA - Subnetwork Point of Attachment [IS-IS].
+
+      TRILL switch - an alternative name for an RBridge.
+
+   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].
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 5]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+2.  The TRILL Hello Environment and Purposes
+
+   [IS-IS] has subnetwork-independent functions and subnetwork-dependent
+   functions.  Currently, Layer 3 use of IS-IS supports two types of
+   subnetworks: (1) point-to-point link subnetworks between routers and
+   (2) general broadcast (LAN) subnetworks.  Because of the differences
+   between the environment of Layer 3 routers and the environment of
+   TRILL RBridges, instead of the subnetwork-dependent functions used at
+   Layer 3, which are specified in Sections 8.2 and 8.4 of [IS-IS], the
+   TRILL protocol uses modified subnetwork-dependent functions for
+   point-to-point subnetworks and broadcast (LAN) subnetworks.  The
+   differences between the TRILL and Layer 3 environments are described
+   in Sections 2.1 through 2.4 followed by a summation, in Section 2.5,
+   of the purposes of the TRILL Hello protocol.
+
+2.1.  RBridge Interconnection by Ethernet
+
+   TRILL supports the interconnection of RBridges by multi-access LAN
+   links such as Ethernet.  Because this includes general bridged LANs
+   [802.1Q], the links between RBridges may contain devices or services
+   that can restrict VLAN connectivity, such as [802.1Q] bridges or
+   carrier Ethernet services.  In addition, RBridge Ethernet ports, like
+   [802.1Q] ports, can be configured to restrict input/output on a VLAN
+   basis.
+
+   For this reason, TRILL Data and TRILL IS-IS packets are sent on
+   Ethernet links in a Designated VLAN that is assumed to provide
+   connectivity between all RBridges on the link.  The Designated VLAN
+   is dictated for a LAN link by the elected Designated RBridge on that
+   link (DRB, equivalent to the Designated Intermediate System at
+   Layer 3).  On an RBridge Ethernet port configured as point-to-point,
+   TRILL Data and IS-IS packets are sent in that port's Desired
+   Designated VLAN, regardless of the state of any other ports on the
+   link.  Connectivity on an Ethernet link configured as point-to-point
+   generally depends on both ends being configured with the same Desired
+   Designated VLAN.  Because TRILL Data packets flow between RBridges on
+   an Ethernet link only in the link's Designated VLAN, adjacency for
+   routing calculations is based only on connectivity characteristics in
+   that VLAN.
+
+   (Non-Ethernet links, such as PPP [RFC6361] generally do not have any
+   Outer.VLAN labeling, so the Designated VLAN for such links has no
+   effect.)
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 6]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+2.2.  Handling Native Frames
+
+   This section discusses the handling of "native" frames as defined in
+   Section 1.4 of [RFC6325].  As such, this section is not applicable to
+   point-to-point links between TRILL switches or any link where all the
+   TRILL switch ports on the link have been configured as "trunk ports"
+   by setting the end-station service disable bit for the port (see
+   Section 4.9.1 of [RFC6325]).
+
+   Layer 3 data packets, such as IP packets, are already "tamed" when
+   they are originated by an end station: they include a hop count and
+   Layer 3 source and destination address fields.  Furthermore, for
+   ordinary data packets, there is no requirement to preserve any outer
+   Layer 2 addressing, and, if the packets are unicast, they are
+   explicitly addressed to their first-hop router.
+
+   In contrast, TRILL switches must accept, transport, and deliver
+   "untamed" native frames: native frames that lack a hop count field
+   usable by TRILL and have Layer 2 MAC (Media Access Control) addresses
+   that indicate their source and destination.  These Layer 2 addresses
+   must be preserved for delivery to the native frame's Layer 2
+   destination.  One resulting difference is that RBridge ports
+   providing native frame service must receive in promiscuous MAC
+   address mode, while Layer 3 router ports typically receive in a
+   selective MAC address mode.
+
+   TRILL handles these requirements by having, on the link where an end
+   station originates a native frame, one RBridge "ingress" such a
+   locally originated native frame by adding a TRILL Header that
+   includes a hop count, thus converting it to a TRILL Data packet.
+   This augmented packet is then routed to one RBridge on the link
+   having the destination end station for the frame (or one RBridge on
+   each such link if it is a multi-destination frame).  Such final
+   RBridges perform an "egress" function, removing the TRILL Header and
+   delivering the original frame to its destination(s).  (For the
+   purposes of TRILL, a Layer 3 router is an end station.)
+
+   Care must be taken to avoid a loop that would involve egressing a
+   native frame and then re-ingressing it because, while it is in native
+   form, it would not be protected by a hop count and could loop
+   forever.  Such a loop could, for multi-destination frames, even
+   involve multiplication of the number of frames each time around and
+   would likely saturate all links involved within milliseconds.  For
+   TRILL, safety against such loops for a link is more important than
+   transient loss of data connectivity on that link.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 7]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   The primary TRILL defense mechanism against such loops, which is
+   mandatory, is to assure that, as far as practically possible, there
+   is only a single RBridge that is in charge of ingressing and
+   egressing native frames from and to a link where TRILL is offering
+   end-station service.  This is the Designated RBridge and Appointed
+   Forwarder mechanism initially specified in the TRILL base protocol
+   [RFC6325], discussed in Section 2.5 below, and further specified in
+   both Section 4 below and [RFC6439].
+
+2.3.  Zero or Minimal Configuration
+
+   TRILL provides connectivity and least-cost paths with zero
+   configuration.  For additional services, it strives to require only
+   minimal configuration; however, services that require configuration
+   when offered by [802.1Q] bridges, such as non-default VLANs or
+   priority, will require configuration.  This differs from Layer 3
+   routing where routers typically need to be configured as to the
+   subnetworks connected to each port, etc., to provide service.
+
+2.4.  MTU Robustness
+
+   TRILL IS-IS needs to be robust against links with reasonably
+   restricted MTUs, including links that accommodate only the classic
+   Ethernet frame size, despite the addition of reasonable headers such
+   as VLAN tags.  Such robustness is particularly required for TRILL
+   Hellos to assure correct adjacency and the election of a unique DRB
+   on LAN links.
+
+   TRILL will also be used inside data centers where it is common for
+   all or most of the links and switches to support frames substantially
+   larger than the classic Ethernet maximum size.  For example, they may
+   have an MTU adequate to comfortably handle Fiber Channel over
+   Ethernet frames, for which T11 recommends a 2,500-byte MTU [FCoE], or
+   even 9K byte jumbo frames.  It would be beneficial for a TRILL campus
+   with such a large MTU to be able to safely make use of it.
+
+   These needs are met by a mandatory maximum on the size of TRILL
+   Hellos and by the optional use of MTU testing as described below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 8]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+2.5.  Purposes of the TRILL Hello Protocol
+
+   There are three purposes for the TRILL Hello protocol.  They are
+   listed below, along with a reference to the section of this document
+   in which each is discussed:
+
+   1. To determine which RBridge neighbors have acceptable connectivity
+      to be reported as part of the topology (Section 3)
+
+   2. To elect a unique Designated RBridge on broadcast (LAN) links
+      (Section 4)
+
+   3. To determine the MTU with which it is possible to safely
+      communicate with each RBridge neighbor (Section 5)
+
+   In Layer 3 IS-IS, all three of these functions are combined.  Hellos
+   may be padded to the maximum length (see [RFC3719], Section 6) so
+   that a router neighbor is not discovered if it is impossible to
+   communicate with it using maximum-sized Layer 3 IS-IS packets.  Also,
+   even if Hellos from a neighbor R2 are received by R1, if connectivity
+   to R2 is not 2-way (i.e., R2 does not list R1 in R2's Hello), then R1
+   does not consider R2 as a Designated Intermediate System (Designated
+   Router) candidate.  Because of this logic, it is possible at Layer 3
+   for multiple Designated Routers to be elected on a LAN, with each
+   representing the LAN as a pseudonode.  It appears to the topology as
+   if the LAN is now two or more separate LANs.  Although this is
+   surprising, this does not cause problems for Layer 3.
+
+   In contrast, this behavior is not acceptable for TRILL, since in
+   TRILL it is important that all RBridges on a link know about each
+   other, and on broadcast (LAN) links that they choose a single RBridge
+   to be the DRB to control the native frame ingress and egress.
+   Otherwise, multiple RBridges might ingress/egress the same native
+   frame, forming loops that are not protected by the hop count in the
+   TRILL Header as discussed above.
+
+   The TRILL Hello protocol is best understood by focusing separately on
+   each of these three functions listed above, which we do in
+   Sections 3, 4, and 5.
+
+   One other issue with TRILL LAN Hellos is to ensure that subsets of
+   the information can appear in any single message, and be processable,
+   in the spirit of IS-IS Link State PDUs (LSPs) and Complete Sequence
+   Number PDUs (CSNPs).  LAN TRILL Hello packets, even though they are
+   not padded, can become very large.  An example where this might be
+   the case is when some sort of backbone technology interconnects
+   hundreds of TRILL sites over what would appear to TRILL to be a giant
+   Ethernet, where the RBridges connected to that cloud will perceive
+
+
+
+Eastlake, et al.             Standards Track                    [Page 9]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   that backbone to be a single link with hundreds of neighbors.  Thus,
+   the TRILL LAN Hello uses a different Neighbor TLV [RFC7176] that
+   lists neighbors seen for a range of MAC (SNPA) addresses.
+
+3.  Adjacency State Machinery
+
+   Each RBridge port has associated with it a port state, as discussed
+   in Section 4, and a table of zero or more adjacencies (if the port is
+   configured as point-to-point, zero, or one) as discussed in this
+   section.  The states such adjacencies can have, the events that cause
+   adjacency state changes, the actions associated with those state
+   changes, a state table, and a state diagram are given below.
+
+3.1.  TRILL Hellos, Ports, and VLANs
+
+   The determination of adjacencies on links is made using TRILL Hellos
+   (see Section 8), an optional MTU test (see Section 5), and,
+   optionally, BFD (see Section 6) and/or other connectivity tests.  If
+   the MAC (SNPA) addresses of more than one RBridge port on a broadcast
+   link are the same, all but one of such ports are put in the Suspended
+   state (see Section 4) and do not participate in the link, except to
+   monitor whether they should stay suspended.  If the two ports on a
+   point-to-point link have MAC (SNPA) addresses, it does not affect
+   TRILL operation if they are the same.  (PPP ports, for example, do
+   not have MAC addresses [RFC6361].)
+
+   The following items MUST be the same for all TRILL Hellos issued by
+   an RBridge on a particular Ethernet port, regardless of the VLAN in
+   which the Hello is sent:
+
+   - Source MAC address,
+
+   - Priority to be the DRB,
+
+   - Desired Designated VLAN,
+
+   - Port ID, and,
+
+   - if included, BFD-Enabled TLV [RFC6213] and PORT-TRILL-VER
+     sub-TLV [RFC7176].
+
+   Of course, the priority, Desired Designated VLAN, and possibly the
+   inclusion or value of the PORT-TRILL-VER sub-TLV, and/or BFD-Enabled
+   TLV can change on occasion, but then the new value(s) must similarly
+   be used in all TRILL Hellos on the LAN port, regardless of VLAN.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 10]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   On broadcast links:
+
+      Because bridges acting as glue on an Ethernet broadcast link might
+      be configured in such a way that some VLANs are partitioned, it is
+      necessary for RBridges to transmit Hellos on Ethernet links with
+      multiple VLAN tags.  The conceptually simplest solution may have
+      been to have RBridges transmit up to 4,094 times as many Hellos,
+      one with each legal VLAN ID enabled at each port, but this would
+      obviously have deleterious performance implications.  So, the
+      TRILL protocol specifies that if RB1 knows it is not the DRB, it
+      transmits its Hellos on only a limited set of VLANs.  Only an
+      RBridge that believes itself to be the DRB on a broadcast Ethernet
+      link "sprays" its TRILL Hellos on all of its enabled VLANs at the
+      port.  And in both cases, an RBridge can be configured to send
+      Hellos on only a subset of those VLANs.  The details are given in
+      [RFC6325], Section 4.4.3.
+
+   On point-to-point links:
+
+      If the link technology is VLAN sensitive, such as Ethernet, an
+      RBridge sends TRILL Hellos only in the Desired Designated VLAN for
+      which it is configured.
+
+3.2.  Adjacency Table Entries and States
+
+   Every adjacency is in one of four states, whether it is one of the
+   adjacencies on a broadcast link or the one possible adjacency on a
+   point-to-point link.  An RBridge participates in LSP synchronization
+   at a port as long as it has one or more adjacencies out of that port
+   that are in the 2-Way or Report state.
+
+   Down: This is a virtual state for convenience in creating state
+      diagrams and tables.  It indicates that the adjacency is
+      nonexistent, and there is no entry in the adjacency table for it.
+
+   Detect: A neighbor RBridge has been detected through receipt of a
+      TRILL Hello, but either 2-way connectivity has not been confirmed
+      or the detection was on an Ethernet link in a VLAN other than the
+      Designated VLAN.
+
+   2-Way: 2-way connectivity to the neighbor has been found and, if the
+      link is Ethernet, it was found on the Designated VLAN, but some
+      enabled test, such as the link MTU meeting the minimum campus
+      requirement or BFD confirming link connectivity, has not yet
+      succeeded.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 11]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   Report: There is 2-way connectivity to the neighbor (on the
+      Designated VLAN if an Ethernet link); all enabled tests have
+      succeeded, including, if enabled, MTU and/or BFD testing.  This
+      state will cause adjacency to be reported in an LSP (with
+      appropriate provision for a pseudonode, if any, as described in
+      Section 7).
+
+   For an adjacency in any of the three non-Down states (Detect, 2-Way,
+   or Report), there will be an adjacency table entry.  That entry will
+   give the state of the adjacency and will also include the information
+   listed below.
+
+   o  The address, if any, of the neighbor, the Port ID, and the System
+      ID in the received Hellos.  Together, these three quantities
+      uniquely identify the adjacency on a broadcast link.
+
+   o  One or more Hello holding timers.  For a point-to-point adjacency,
+      there is a single Hello holding timer.  For a broadcast LAN
+      adjacency, there are exactly two Hello holding timers: a
+      Designated VLAN holding timer and a non-Designated VLAN holding
+      timer.  Each timer consists of a 16-bit unsigned integer number
+      of seconds.
+
+   o  If the adjacency is on a broadcast link, the 7-bit unsigned
+      priority of the neighbor to be the DRB.
+
+   o  The 5 bytes of data from the PORT-TRILL-VER received in the most
+      recent TRILL Hello from the neighbor RBridge.
+
+   o  The VLAN that the neighbor RBridge wants to be the Designated VLAN
+      on the link, called the Desired Designated VLAN.
+
+   o  For an adjacency table at an RBridge that supports BFD, a flag
+      indicating whether the last received TRILL Hello from the neighbor
+      RBridge contained a BFD-Enabled TLV (see Section 6).
+
+3.3.  Adjacency and Hello Events
+
+   The following events can change the state of an adjacency:
+
+   A0. Receive a TRILL Hello for a broadcast LAN adjacency whose source
+       MAC address (SNPA) is equal to that of the port on which it is
+       received.  This is a special event that cannot occur on a port
+       configured as point-to-point and is handled as described
+       immediately after this list of events.  It does not appear in the
+       state transition table or diagram.
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 12]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   A1. Receive a TRILL Hello (other than an A0 event) such that:
+
+       - If received on an Ethernet port, it was received in the
+         Designated VLAN.
+
+       - If received for a broadcast LAN adjacency, it contains a TRILL
+         Neighbor TLV that explicitly lists the receiving port's (SNPA)
+         address.
+
+       - If received for a point-to-point adjacency, it contains a
+         Three-Way Handshake TLV with the receiver's System ID and
+         Extended Circuit ID.
+
+   A2. Event A2 is not possible for a port configured as point-to-point.
+       Receive a TRILL Hello (other than an A0 event) such that either
+
+       - The port is Ethernet and the Hello was not on the Designated
+         VLAN (any TRILL Neighbor TLV in such a Hello is ignored), or
+
+       - The Hello does not contain a TRILL Neighbor TLV covering an
+         address range that includes the receiver's (SNPA) address.
+
+   A3. Receive a TRILL Hello (other than an A0 event) such that:
+
+       - If received on an Ethernet port, it was received in the
+         Designated VLAN.
+
+       - If received for a broadcast LAN adjacency, it contains one or
+         more TRILL Neighbor TLVs covering an address range that
+         includes the receiver's (SNPA) address and none of which list
+         the receiver.
+
+       - If received for a point-to-point adjacency, it contains a
+         Three-Way Handshake TLV with either the System ID or Extended
+         Circuit ID or both not equal to that of the receiver.
+
+   A4. Either
+
+       (1) the Hello holding timer expires on a point-to-point
+           adjacency, or
+
+       (2) on a broadcast LAN adjacency,
+
+           (2a) both Hello timers expire simultaneously or
+
+           (2b) one Hello timer expires when the other Hello timer is
+                already in the expired state.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 13]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   A5. For a broadcast LAN adjacency, the Designated VLAN Hello holding
+       timer expires, but the non-Designated VLAN Hello holding timer
+       still has time left until it expires.  This event cannot occur
+       for a point-to-point adjacency.
+
+   A6. MTU if enabled, BFD if enabled, and all other enabled
+       connectivity tests successful.
+
+   A7. MTU if enabled, BFD if enabled, and all other enabled
+       connectivity tests were successful but one or more now fail.
+
+   A8. The RBridge port goes operationally down.
+
+   For the special A0 event, the Hello is examined to determine if it
+   has a higher priority than the port on which it is received such that
+   the sending port should be the DRB as described in Section 4.2.1.  If
+   the Hello is of lower priority than the receiving port, it is
+   discarded with no further action.  If it is of higher priority than
+   the receiving port, then any adjacencies for the receiving port are
+   discarded (transitioned to the Down state), and the port is suspended
+   as described in Section 4.2.
+
+   The receipt of a TRILL Hello that is not an event A0 causes the
+   following actions (except where the Hello would have created a new
+   adjacency table entry but both the adjacency table is full and the
+   Hello is too low priority to displace an existing entry as described
+   in Section 3.6).  The Designated VLAN referred to is the Designated
+   VLAN dictated by the DRB determined without taking the received TRILL
+   LAN Hello into account (see Section 4) for a broadcast LAN and the
+   local Desired Designated VLAN for a port configured as point-to-
+   point.
+
+   o  If the receipt of a Hello creates a new adjacency table entry, the
+      neighbor RBridge MAC (SNPA) address (if any), Port ID, and System
+      ID are set from the Hello.
+
+   o  For a point-to-point adjacency, the Hello holding timer is set
+      from the Holding Time field of the Hello.  For a broadcast link
+      adjacency, the appropriate Hello holding timer for that adjacency,
+      depending on whether or not the Hello was received in the
+      Designated VLAN, is set to the Holding Time field of the Hello and
+      if the receipt of the LAN Hello is creating a new adjacency table
+      entry, the other timer is set to expired.
+
+   o  For a broadcast link adjacency, the priority of the neighbor
+      RBridge to be the DRB is set to the priority field of the LAN
+      Hello.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 14]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   o  For a broadcast link adjacency, the VLAN that the neighbor RBridge
+      wants to be the Designated VLAN on the link is set from the Hello.
+
+   o  The 5 bytes of PORT-TRILL-VER data are set from that sub-TLV in
+      the Hello or set to zero if that sub-TLV does not occur in the
+      Hello.
+
+   o  For a broadcast link, if the creation of a new adjacency table
+      entry or the priority update above changes the results of the DRB
+      election on the link, the appropriate RBridge port event (D2 or
+      D3) occurs, after the above actions, as described in Section 4.2.
+
+   o  For a broadcast link adjacency, if there is no change in the DRB,
+      but the neighbor Hello is from the DRB and has a changed
+      Designated VLAN from the previous Hello received from the DRB, the
+      result is a change in Designated VLAN for the link as specified in
+      Section 4.2.3.
+
+   An event A4 resulting in the adjacency transitioning to the Down
+   state may also result in an event D3 as described in Section 4.2.
+
+   Concerning events A6 and A7, if none of MTU, BFD, or other testing is
+   enabled, A6 is considered to occur immediately upon the adjacency
+   entering the 2-Way state, and A7 cannot occur.
+
+   See further TRILL Hello receipt details in Section 8.
+
+3.4.  Adjacency State Diagram and Table
+
+   The table below shows the transitions between the states defined
+   above, based on the events defined above:
+
+               | Event |  Down  | Detect | 2-Way  | Report |
+               +-------+--------+--------+--------+--------+
+               |  A1   | 2-Way  | 2-Way  | 2-Way  | Report |
+               |  A2   | Detect | Detect | 2-Way  | Report |
+               |  A3   | Detect | Detect | Detect | Detect |
+               |  A4   |  N/A   | Down   | Down   | Down   |
+               |  A5   |  N/A   | Detect | Detect | Detect |
+               |  A6   |  N/A   |  N/A   | Report | Report |
+               |  A7   |  N/A   |  N/A   | 2-Way  | 2-Way  |
+               |  A8   | Down   | Down   | Down   | Down   |
+
+                      Table 2: Adjacency State Table
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 15]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   "N/A" indicates that the event to the left is not applicable in the
+   state at the top of the column.  These events affect only a single
+   adjacency.  The special A0 event transitions all adjacencies to Down,
+   as explained immediately after the list of adjacency events in
+   Section 3.3.
+
+   The diagram below presents the same information as that in the state
+   table:
+
+                         +---------------+
+                         |     Down      |<--------+
+                         +---------------+         |
+                           |     |  ^  |           |
+                      A2,A3|     |A8|  |A1         |
+                           |     +--+  |           |
+                           |           +-----------|---+
+                           V                       |   |
+                         +----------------+ A4,A8  |   |
+                  +----->|      Detect    |------->|   |
+                  |      +----------------+        |   |
+                  |        |  |         ^          |   |
+                  |      A1|  |A2,A3,A5 |          |   |
+                  |        |  +---------+          |   |
+                  |        |                       |   |
+                  |        |          +------------|---+
+                  |        |          |            |
+                  |        V          V            |
+                  |A3,A5 +----------------+ A4,A8  |
+                  |<-----|     2-Way      |------->|
+                  |      +----------------+        |
+                  |       |   ^ |        ^         |
+                  |     A6|   | |A1,A2,A7|         |
+                  |       |   | +--------+         |
+                  |       |   |                    |
+                  |       |   |A7                  |
+                  |       V   |                    |
+                  |A3,A5 +-------------+ A4,A8     |
+                  |<-----|   Report    |---------->|
+                         +-------------+
+                           |         ^
+                           |A1,A2,A6 |
+                           +---------+
+
+                     Figure 1: Adjacency State Diagram
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 16]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+3.5.  Multiple Parallel Links
+
+   There can be multiple parallel adjacencies between neighbor RBridges
+   that are visible to TRILL.  (Multiple low-level links that have been
+   bonded together by technologies such as link aggregation [802.1AX]
+   appear to TRILL as a single link over which only a single TRILL
+   adjacency can be established.)
+
+   Any such links that have pseudonodes (see Section 7) are
+   distinguished in the topology; such adjacencies, if they are in the
+   Report state, appear in LSPs as per Section 7.  However, there can be
+   multiple parallel adjacencies without pseudonodes because they are
+   point-to-point adjacencies or LAN adjacencies for which a pseudonode
+   is not being created.  Such parallel, non-pseudonode adjacencies in
+   the Report state appear in LSPs as a single adjacency.  The cost of
+   such an adjacency MAY be adjusted downwards to account for the
+   parallel paths.  Multipathing across such parallel connections can be
+   freely done for unicast TRILL Data traffic on a per-flow basis but is
+   restricted for multi-destination traffic, as described in
+   Section 4.5.2 (point 3) of [RFC6325] and Appendix C of [RFC6325].
+
+3.6.  Insufficient Space in Adjacency Table
+
+   If the receipt of a TRILL Hello would create a new adjacency table
+   entry (that is, would transition an adjacency out of the Down state),
+   there may be no space for the new entry.  For ports that are
+   configured as point-to-point and can thus only have zero or one
+   adjacency not in the Down state, it is RECOMMENDED that space be
+   reserved for one adjacency so that this condition cannot occur.
+
+   When there is adjacency table space exhaustion, the DRB election
+   priority (see Section 4.2.1) of the new entry that would be created
+   is compared with the DRB election priority for the existing entries.
+   If the new entry is higher priority than the lowest priority existing
+   entry, it replaces the lowest priority existing entry, which is
+   transitioned to the Down state.
+
+4.  LAN Ports and DRB State
+
+   This section specifies the DRB election process in TRILL at a
+   broadcast (LAN) link port.  Since there is no such election when a
+   port is configured as point-to-point, this section does not apply in
+   that case.
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 17]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   The information at an RBridge associated with each of its broadcast
+   LAN ports includes the following:
+
+   o  Enablement bit, which defaults to enabled.
+
+   o  The 5 bytes of PORT-TRILL-VER sub-TLV data used in TRILL Hellos
+      sent on the port.
+
+   o  SNPA address (commonly a 48-bit MAC address) of the port.
+
+   o  Port ID, used in TRILL Hellos sent on the port.
+
+   o  The Holding Time, used in TRILL Hellos sent on the port.
+
+   o  The priority to be the DRB, used in TRILL LAN Hellos sent on the
+      port.
+
+   o  BFD support.  If the port supports BFD, a BFD Enabled flag that
+      controls whether or not a BFD-Enabled TLV is included in TRILL
+      Hellos sent on the port.
+
+   o  The DRB state of the port, determined as specified below.
+
+   o  A 16-bit unsigned Suspension Timer, measured in seconds.
+
+   o  The Desired Designated VLAN.  The VLAN this RBridge wants to be
+      the Designated VLAN for the link out of this port, used in TRILL
+      Hellos sent on the port if the link is Ethernet.
+
+   o  A table of zero or more adjacencies (see Section 3).
+
+4.1.  Port Table Entries and DRB Election State
+
+   The TRILL equivalent of the DIS (Designated Intermediate System) on a
+   broadcast link is the DRB or Designated RBridge.  The DRB election
+   state machinery is described below.
+
+   Each RBridge port that is not configured as point-to-point is in one
+   of the following four DRB states:
+
+   Down: The port is operationally down.  It might be administratively
+      disabled or down at the link layer.  In this state, there will be
+      no adjacencies for the port, and no TRILL Hellos or other TRILL
+      IS-IS PDUs or TRILL Data packets are accepted or transmitted.
+
+   Suspended: Operation of the port is suspended because there is a
+      higher priority port on the link with the same MAC (SNPA) address.
+      This is the same as the Down state, with the exception that TRILL
+
+
+
+Eastlake, et al.             Standards Track                   [Page 18]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+      Hellos are accepted for the sole purpose of determining whether to
+      change the value of the Suspension Timer for the port as described
+      below.
+
+   DRB: The port is the DRB and can receive and transmit TRILL Data
+      packets.
+
+   Not DRB: The port is deferring to another port on the link, which it
+      believes is the DRB, but can still receive and transmit TRILL Data
+      packets.
+
+4.2.  DRB Election Events
+
+   The following events can change the DRB state of a port.  Note that
+   this is only applicable to broadcast links.  There is no DRB state or
+   election at a port configured to be point-to-point.
+
+   D1. The port becomes enabled or the Suspension Timer expires while
+       the port is in the Suspended state.
+
+   D2. The adjacency table for the port changes, and there are now
+       entries for one or more other RBridge ports on the link that
+       appear to be higher priority to be the DRB than the local port.
+
+   D3. The port is not Down or Suspended, and the adjacency table for
+       the port changes, so there are now no entries for other RBridge
+       ports on the link that appear to be higher priority to be the DRB
+       than the local port.
+
+   D4. A TRILL LAN Hello is received that has the same MAC address
+       (SNPA) as the receiving port and higher priority to be the DRB as
+       described for event A0.
+
+   D5. The port becomes operationally down.
+
+   Event D1 is considered to occur on RBridge boot if the port is
+   administratively and link-layer enabled.
+
+   Event D4 causes the port to enter the Suspended state and all
+   adjacencies for the port to be discarded (transitioned to the Down
+   state).  If the port was in some state other than Suspended, the
+   Suspension Timer is set to the Holding Time in the Hello that causes
+   event D4.  If it was in the Suspended state, the Suspension Timer is
+   set to the maximum of its current value and the Holding Time in the
+   Hello that causes event D4.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 19]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+4.2.1.  DRB Election Details
+
+   Events D2 and D3 constitute losing and winning the DRB election at
+   the port, respectively.
+
+   The candidates for election are the local RBridge and all RBridges
+   with which there is an adjacency on the port in an adjacency state
+   other than the Down state.  The winner is the RBridge with highest
+   priority to be the DRB, as determined from the 7-bit priority field
+   in that RBridge's Hellos received and the local port's priority to be
+   the DRB field, with MAC (SNPA) address as a tiebreaker, Port ID as a
+   secondary tiebreaker, and System ID as a tertiary tiebreaker.  These
+   fields are compared as unsigned integers, with the larger magnitude
+   being considered higher priority.
+
+   Resorting to the secondary and tertiary tiebreakers should only be
+   necessary in rare circumstances when multiple ports have the same
+   priority and MAC (SNPA) address and some of them are not yet
+   suspended.  For example, RB1, which has low priority to be the DRB on
+   the link, could receive Hellos from two other ports on the link that
+   have the same MAC address as each other and are higher priority to be
+   the DRB.  One of these two ports with the same MAC address will be
+   suspended and cease sending Hellos, and the Hello from it received by
+   RB1 will eventually time out.  But, in the meantime, RB1 can use the
+   tiebreakers to determine which port is the DRB and thus which port's
+   Hello to believe for such purposes as setting the Designated VLAN on
+   the link.
+
+4.2.2.  Change in DRB
+
+   Events D2 and D3 result from a change in the apparent DRB on the
+   link.  Unnecessary DRB changes should be avoided, especially on links
+   offering native frame service, as a DRB change will generally cause a
+   transient interruption to native frame service.
+
+   If a change in the DRB on the link changes the Designated VLAN on an
+   Ethernet link, the actions specified in Section 4.2.3 are taken.
+
+   If an RBridge changes in either direction between being the DRB and
+   not being the DRB at a port, this will generally change the VLANs on
+   which that RBridge sends Hellos through that port, as specified in
+   Section 4.4.3 of [RFC6325].
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 20]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+4.2.3.  Change in Designated VLAN
+
+   Unnecessary changes in the Designated VLAN on an Ethernet link should
+   be avoided because a change in the Designated VLAN can cause a
+   transient interruption to adjacency and thus to TRILL Data forwarding
+   on the link.  When practical, all RBridge ports on a link should be
+   configured with the same Desired Designated VLAN so that if the
+   winner of the DRB election changes for any reason, the Designated
+   VLAN will remain the same.
+
+   If an RBridge detects a change in Designated VLAN on an Ethernet
+   link, then, for all adjacency table entries for a port to that link,
+   the RBridge takes the following steps, in the order given.
+
+   o  The non-Designated VLAN Hello holding timer is set to the maximum
+      of its time to expiration and the current time to expiration of
+      the Designated VLAN Hello holding timer.
+
+   o  The Designated VLAN Hello holding timer is then set to expired (if
+      necessary), and an event A5 occurs for the adjacency (see
+      Section 3.3).
+
+   If the Designated VLAN for a link changes, this will generally change
+   the VLANs on which Hellos are sent by an RBridge port on that link as
+   specified in Section 4.4.3 of [RFC6325].
+
+4.3.  Port State Table and Diagram
+
+   The table below shows the transitions between the DRB states defined
+   above, based on the events defined above:
+
+         | Event | Down   | Suspended |    DRB    |  Not DRB  |
+         +-------+--------+-----------+-----------+-----------+
+         |  D1   | DRB    | DRB       |  N/A      |  N/A      |
+         |  D2   |  N/A   |  N/A      | Not DRB   | Not DRB   |
+         |  D3   |  N/A   |  N/A      | DRB       | DRB       |
+         |  D4   |  N/A   | Suspended | Suspended | Suspended |
+         |  D5   | Down   | Down      | Down      | Down      |
+
+                         Table 3: Port State Table
+
+   "N/A" indicates that the event to the left is not applicable in the
+   state at the top of the column.
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 21]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   The diagram below presents the same information as in the state
+   table:
+
+              +-------------+
+              |  Down       |<--------------+
+              +-+---+-------+     ^         |
+                |   |   ^         |         |
+              D1|   |D5 |         |         |
+                |   +---+         |D5       |
+                |                 |         |
+                |        +--------+----+    |
+                |        |  Suspended  |<---|---+
+                |        +-+-----+-----+    |   |
+                |        D1|  ^  |   ^      |   |
+                |          |  |  |D4 |      |   |
+                |          |  |  +---+      |   |
+                |          |  |             |   |
+                |          |  |D4           |   |
+                V          V  |             |   |
+              +---------------+-+ D5        |   |
+              |          DRB    |---------->|   |
+              +--------+--+-----+           |   |
+                  ^    |  |  ^              |   |
+                  |  D2|  |D3|              |   |
+                  |    |  +--+              |   |
+                  |    |         D4         |   |
+                  |D3  |  +-----------------|---+
+                  |    V  |                 |
+             +----+-------+-+ D5            |
+             |   Not DRB    |-------------->|
+             +----+---------+
+                  |    ^
+                  |D2  |
+                  +----+
+
+                       Figure 2: Port State Diagram
+
+5.  MTU Matching
+
+   The purpose of MTU testing is to ensure that the links used in the
+   campus topology can pass TRILL IS-IS packets, particularly LSP PDUs,
+   at the TRILL campus MTU.  The LSP PDUs generated at a TRILL switch
+   could, as part of the flooding process, be sent over any adjacency in
+   the campus.  To assure correct operation of IS-IS, an LSP PDU must be
+   able to reach every RBridge in the IS-IS reachable campus; this might
+   be impossible if the PDU exceeded the MTU of an adjacency that was
+   part of the campus topology.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 22]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   An RBridge, RB1, determines the desired campus link MTU by
+   calculating the minimum of its originatingL1LSPBufferSize and the
+   originatingL1LSPBufferSize of other RBridges in the campus, as
+   advertised in the link-state database, but not less than 1,470 bytes.
+   Although originatingL1LSPBufferSize in Layer 3 [IS-IS] is limited to
+   the range 512 to 1,492 bytes inclusive, in TRILL it is limited to the
+   range 1,470 to 65,535 bytes inclusive.  (See Section 5 of [RFC7180].)
+
+   Although MTU testing is optional, it is mandatory for an RBridge to
+   respond to an MTU-probe PDU with an MTU-ack PDU [RFC6325] [RFC7176].
+   The use of multicast or unicast for MTU-probe and MTU-ack is an
+   implementation choice.  However, the burden on the link is generally
+   minimized by the following: (1) multicasting MTU-probes when a
+   response from all other RBridges on the link is desired, such as when
+   initializing or reconfirming MTU, (2) unicasting MTU-probes when a
+   response from a single RBridge is desired, such as one that has just
+   been detected on the link, and (3) unicasting all MTU-ack packets.
+
+   RB1 can test the MTU size to RB2 as described in Section 4.3.2 of
+   [RFC6325].  For this purpose, MTU testing is only done in the
+   Designated VLAN.  An adjacency that fails the MTU test at the campus
+   MTU will not enter the Report state, or, if the adjacency is in that
+   state, it leaves that state.  Thus, an adjacency failing the MTU test
+   at the campus minimum MTU will not be reported by the RBridge
+   performing the test.  Since inclusion in least-cost route computation
+   requires the adjacency to be reported by both ends, as long as the
+   RBridge at either end of the adjacency notices the MTU failure, it
+   will not be so used.
+
+   If RB1 tests MTU size, it reports the largest size for which the MTU
+   test succeeds or a flag indicating that it fails at the campus MTU.
+   This report always appears with the neighbor in RB1's TRILL Neighbor
+   TLV.  RB1 MAY also report this with the adjacency in an Extended
+   Reachability TLV in RB1's LSP.  RB1 MAY choose to test MTU sizes
+   greater than the desired campus MTU as well as the desired
+   campus MTU.
+
+   Most types of TRILL IS-IS packets, such as LSPs, can make use of the
+   campus MTU.  The exceptions are TRILL Hellos, which must be kept
+   small for loop safety, and the MTU PDUs, whose size must be adjusted
+   appropriately for the tests being performed.
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 23]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+6.  BFD-Enabled TLV and BFD Session Bootstrapping
+
+   When the adjacency between RBridges reaches the 2-Way state, TRILL
+   Hellos will already have been exchanged.  If an RBridge supports BFD
+   [RFC7175], it will have learned whether the other RBridge has BFD
+   enabled by whether or not a BFD-Enabled TLV [RFC6213] was included in
+   its Hellos.  In addition, TRILL Hellos include a nickname of the
+   sending RBridge [RFC7176] so that information will be available to
+   the receiving RBridge.
+
+   The BFD-Enabled TLVs in TRILL Hellos will look like the following:
+
+         +-+-+-+-+-+-+-+-+
+         | Type=148      |                   (1 byte)
+         +-+-+-+-+-+-+-+-+
+         | Length=3*n    |                   (1 byte)
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         | RESV  |        MT ID=0        |   (2 bytes)
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         | NLPID=0xC0    |                   (1 byte)
+         +-+-+-+-+-+-+-+-+-+-+-...
+         | possible additional               (3*(n-1) bytes)
+         | topology/NLPID pairs
+         +-+-+-+-+-+-+-...
+
+                 Figure 3: BFD-Enabled TLV Example/Format
+
+         Type = 148 for BFD Enabled [RFC6213].
+
+         Length will be 3 times the number of topology and protocol
+         pairs in the TLV.
+
+         MT ID is a topology ID [RFC5120] that will be zero unless
+         multi-topology is being supported [MT].
+
+         NLPID is a Network Layer Protocol ID [RFC6328] and will be 0xC0
+         for TRILL, but additional topology and protocol pairs could
+         conceivably be listed.
+
+   An RBridge port initiates a one-hop BFD session with another RBridge
+   if the following conditions are met: (1) it has BFD enabled, (2) it
+   has an adjacency to another RBridge in the 2-Way or Report state, and
+   (3) the Hellos it receives indicate that the other RBridge also has
+   BFD enabled.  Either (a) BFD was enabled on both RBridge ports when
+   the adjacency changed to the 2-Way or Report state, (b) the adjacency
+   was already in the 2-Way or Report state and BFD was enabled on one
+   RBridge port when BFD had been enabled on the other, or (c) BFD was
+   simultaneously enabled on both RBridge ports.
+
+
+
+Eastlake, et al.             Standards Track                   [Page 24]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   In such a BFD session, BFD is encapsulated as specified in [RFC7175].
+   The egress nickname to be used will have been learned from received
+   Hellos.  On a point-to-point link, the Any-RBridge nickname [RFC7180]
+   can also be used as egress, since support of that nickname is
+   required by support of RBridge Channel [RFC7178] and support of
+   RBridge Channel is required for support of BFD over TRILL.
+
+   The rare case of transient nickname conflict (due to the network
+   operator configuring a conflict, new connectivity to a previously
+   isolated RBridge, or the like) can cause transient failure of an
+   ongoing BFD session.  This can be avoided in the one-hop point-to-
+   point case by using the Any-RBridge egress nickname.  In cases where
+   Any-RBridge cannot be used as the egress nickname and a transient
+   nickname conflict is detected for the intended destination of a BFD
+   session, initiation of the session SHOULD be delayed until the
+   conflict is resolved.
+
+   If a one-hop BFD session is initiated when the adjacency is in the
+   2-Way state, the adjacency MUST NOT advance to the Report state until
+   BFD and any other enabled connectivity tests (including MTU, if
+   enabled) have succeeded, as specified in Section 3.
+
+   If a one-hop BFD session is established when the adjacency is in the
+   Report state, due to enablement at the RBridges, then, to minimize
+   unnecessary topology changes, the adjacency MUST remain in the Report
+   state unless and until the BFD session (or some other enabled
+   connectivity test) fails.
+
+7.  Pseudonodes
+
+   This section only applies to broadcast links, as there is no DRB and
+   there cannot be a pseudonode [IS-IS] for a link configured as point-
+   to-point.  The Designated RBridge (DRB), determined as described
+   above, controls whether a pseudonode will be used on a link.
+
+   If the DRB sets the bypass pseudonode bit in its TRILL LAN Hellos,
+   the RBridges on the link (including the DRB) just directly report all
+   their adjacencies on the LAN that are in the Report state.  If the
+   DRB does not set the bypass pseudonode bit in its TRILL Hellos, then
+   (1) the DRB reports in its LSP its adjacency to the pseudonode, (2)
+   the DRB sends LSPs on behalf of the pseudonode in which it reports
+   adjacency to all other RBridges on the link where it sees that
+   adjacency in the Report state, and (3) all other RBridges on the link
+   report their adjacency to the pseudonode if they see their adjacency
+   to the DRB as being in the Report state and do not report any other
+   adjacencies on the link.  Setting the bypass pseudonode bit has no
+   effect on how LSPs are flooded on a link.  It only affects what LSPs
+   are generated.
+
+
+
+Eastlake, et al.             Standards Track                   [Page 25]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   It is anticipated that many links between RBridges will actually be
+   point-to-point even in cases where the link technology supports
+   operation as a multi-access broadcast link, in which case using a
+   pseudonode merely adds to the complexity.  For example, if RB1 and
+   RB2 are the only RBridges on the link, and RB1 is the DRB, then if
+   RB1 creates a pseudonode -- for example, RB1.25 -- that is used,
+   there are then 3 LSPs: RB1.25, RB1, and RB2, where RB1.25 reports
+   connectivity to RB1 and RB2, and RB1 and RB2 each just say they are
+   connected to RB1.25.  However, if DRB RB1 sets the bypass pseudonode
+   bit in its Hellos, then there will be only 2 LSPs: RB1 and RB2, each
+   reporting connectivity to each other.
+
+   A DRB SHOULD set the bypass pseudonode bit in its Hellos if it has
+   not seen at least two simultaneous adjacencies in the Report state
+   since it last rebooted or was reset by network management.
+
+8.  More TRILL Hello Details
+
+   This section provides further details on the receipt, transmission,
+   and content of TRILL Hellos.  Unless otherwise stated, it applies to
+   both LAN and point-to-point Hellos.
+
+   TRILL Hellos, like all TRILL IS-IS packets, are primarily
+   distinguished from Layer 3 IS-IS packets on Ethernet by being sent to
+   the All-IS-IS-RBridges multicast address (01-80-C2-00-00-41).  TRILL
+   IS-IS packets on Ethernet also have the L2-IS-IS Ethertype (0x22F4)
+   and are Ethertype encoded.
+
+   Although future extensions to TRILL may include the use of Level 2
+   IS-IS, [RFC6325] specifies TRILL using a single Level 1 Area using
+   the fixed Area Address zero (see Section 4.2 of [RFC7176]).
+
+   IS-IS Layer 3 routers are frequently connected to other Layer 3
+   routers that are part of a different routing domain.  In that case,
+   the externalDomain flag (see [IS-IS]) is normally set for the port
+   through which such a connection is made.  The setting of this flag to
+   "true" causes no IS-IS PDUs to be sent out of the port and any IS-IS
+   PDUs received to be discarded, including Hellos.  RBridges operate in
+   a different environment where all neighbor RBridges merge into a
+   single campus.  For loop safety, RBridges do not implement the
+   externalDomain flag or implement it with the fixed value "false".
+   They send and can receive TRILL Hellos on every port that is not
+   disabled.
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 26]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+8.1.  Contents of TRILL Hellos
+
+   The table below lists mandatory (M) and optional (O) content TLVs for
+   TRILL Hellos that are particularly relevant to this document,
+   distinguishing between TRILL LAN Hellos and TRILL P2P Hellos.  A "-"
+   indicates that an occurrence would be ignored.  There are additional
+   TLVs and sub-TLVs that can occur in TRILL Hellos [RFC7176].
+
+     LAN  P2P  Number  Content Item
+     ---  ---  ------  ----------------------------------------------
+
+      M    M     1     Area Addresses TLV with Area Address zero only
+      M    M     1     MT Port Capabilities TLV containing a
+                       VLAN-FLAGs sub-TLV
+      O    O    0-n    Other MT Port Capability TLVs
+      M    -    0-n    TRILL Neighbor TLV (see Section 8.2.1)
+      -    M     1     Three-Way Handshake TLV
+      O    O    0-n    Protocols Supported TLV -- MUST list the
+                       TRILL NLPID (0xC0) [RFC6328]
+      O    O    0-1    BFD-Enabled TLV
+      O    O    0-1    Authentication TLV
+      -    -    0-n    Padding TLV -- SHOULD NOT be included
+
+                       Table 4: TRILL Hello Contents
+
+   A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS
+   Hello.  As with all IS-IS PDUs, TLVs that are unsupported/unknown in
+   TRILL Hellos are ignored.
+
+8.2.  Transmitting TRILL Hellos
+
+   TRILL Hellos are sent with the same timing as Layer 3 IS-IS Hellos
+   [IS-IS]; however, no Hellos are sent if a port is in the Suspended or
+   Down state or if the port is disabled.
+
+   TRILL Hello PDUs SHOULD NOT be padded and MUST NOT be sent if they
+   exceed 1,470 bytes; however, a received TRILL Hello longer than
+   1,470 bytes is processed normally.
+
+   TRILL Hello PDU headers MUST conform to the following:
+
+   o  Maximum Area Addresses equal to 1.
+
+   o  Circuit Type equal to 1.
+
+   See Section 8.1 for mandatory Hello TLV contents and some optional
+   Hello TLV contents.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 27]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+8.2.1.  TRILL Neighbor TLVs
+
+   A TRILL Neighbor TLV SHOULD NOT be included in TRILL point-to-point
+   Hellos, as it MUST be ignored in that context and wastes space.
+
+   TRILL Neighbor TLVs sent in a LAN Hello on an Ethernet link MUST show
+   the neighbor information, as sensed by the transmitting RBridge, for
+   the VLAN on which the Hello is sent.  Since implementations
+   conformant to this document maintain such information on a per-VLAN
+   basis only for the Designated VLAN, such implementations only send
+   the TRILL Neighbor TLV in TRILL LAN Hellos in the Designated VLAN.
+
+   It is RECOMMENDED that, if there is sufficient room, a TRILL Neighbor
+   TLV or TLVs, as described in Section 4.4.2.1 of [RFC6325], covering
+   the entire range of MAC addresses and listing all adjacencies with a
+   non-zero Designated VLAN Hello Holding Time, or an empty list of
+   neighbors if there are no such adjacencies, be in TRILL Hellos sent
+   on the Designated VLAN.  If this is not possible, then TRILL Neighbor
+   TLVs covering sub-ranges of MAC addresses should be sent so that the
+   entire range is covered reasonably promptly.  Delays in sending TRILL
+   Neighbor TLVs will delay the advancement of adjacencies to the Report
+   state and the discovery of some link failures.  Rapid (for example,
+   sub-second) detection of link or node failures is best addressed with
+   a protocol designed for that purpose, such as BFD (see Section 6).
+
+   To ensure that any RBridge RB2 can definitively determine whether RB1
+   can hear RB2, RB1's neighbor list MUST eventually cover every
+   possible range of IDs, that is, within a period that depends on RB1's
+   policy and not necessarily within any specific period such as its
+   Holding Time.  In other words, if X1 is the smallest ID reported in
+   one of RB1's neighbor lists, and the "smallest" flag is not set, then
+   X1 MUST appear in a different neighbor list as well, as the largest
+   ID reported in that fragment.  Or lists may overlap, as long as there
+   is no gap, such that some range, say, between Xi and Xj, would never
+   appear in any list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 28]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+8.3.  Receiving TRILL Hellos
+
+   Assuming that a packet is labeled as TRILL IS-IS -- for example, on
+   Ethernet it has the L2-IS-IS Ethertype and the All-IS-IS-RBridges
+   destination multicast address or is so marked by the appropriate code
+   point on other link types such as PPP [RFC6361] or a pseudowire
+   [RFC7173] -- it will be examined to see if it appears to be an IS-IS
+   PDU.  If so, and it appears to be a TRILL Hello PDU, the following
+   tests are performed:
+
+   o  The type of Hello PDU (LAN or P2P) is compared with the port
+      configuration.  If a LAN Hello is received on a port configured to
+      be point-to-point or a P2P Hello is received on a port not
+      configured to be point-to-point, it is discarded.
+
+   o  If the Circuit Type field is not 1, the PDU is discarded.
+
+   o  If the PDU does not contain an Area Address TLV or it contains an
+      Area Address TLV that is not the single Area Address zero, it is
+      discarded.
+
+   o  If the Hello includes a Protocols Supported TLV that does not list
+      the TRILL NLPID (0xC0), it is discarded.  It is acceptable if
+      there is no Protocols Supported TLV present.
+
+   o  If the Hello does not contain an MT Port Capabilities TLV
+      containing a VLAN-FLAGS sub-TLV [RFC7176], it is discarded.
+
+   o  If the maximumAreaAddresses field of the PDU is not 1, it is
+      discarded.
+
+   o  If IS-IS authentication is in use on the link and either the PDU
+      has no Authentication TLV or validation of the PDU's
+      Authentication TLV fails, it is discarded.
+
+   If none of the rules in the list above cause the packet to be
+   discarded and the packet is parseable, it is assumed to be a
+   well-formed TRILL Hello received on the link.  It is treated as an
+   event A0, A1, A2, or A3, based on the criteria listed in Section 3.3.
+
+9.  Multiple Ports on the Same Broadcast Link
+
+   It is possible for an RBridge RB1 to have multiple ports on the same
+   broadcast (LAN) link that are not in the Suspended state.  It is
+   important for RB1 to recognize which of its ports are on the same
+   link.  RB1 can detect this condition based on receiving TRILL Hello
+   messages with the same LAN ID on multiple ports.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 29]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   The DRB election is port-based (see Section 4), and only the Hellos
+   from the elected port can perform certain functions such as dictating
+   the Designated VLAN or whether a pseudonode will be used; however,
+   the election also designates the RBridge with that port as the DRB
+   for the link.  An RBridge may choose to load split some tasks among
+   its ports on the link if it has more than one.  Section 4.4.4 of
+   [RFC6325] describes when it is safe to do so.
+
+10.  IANA Considerations
+
+   This document serves as a reference for 'Fail' (Failed MTU test),
+   value 0, in the "TRILL Neighbor TLV NEIGHBOR RECORD Flags" registry.
+   IANA has updated that reference to point to this RFC.
+
+11.  Security Considerations
+
+   This memo provides improved documentation of some aspects of the
+   TRILL base protocol standard, particularly five aspects of the TRILL
+   adjacency establishment and Hello protocol as listed in Section 1.
+   It does not change the security considerations of the TRILL base
+   protocol as detailed in Section 6 of [RFC6325].
+
+   See [RFC7175] for security considerations for BFD, whose use in
+   connection with TRILL adjacency is discussed in this document,
+   particularly Section 6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 30]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+Appendix A.  Changes from RFC 6327
+
+   This document has the following changes from [RFC6327].  It obsoletes
+   [RFC6327].
+
+   1. This document extends the TRILL Hello size limit, MTU testing, and
+      state machine to point-to-point links.
+
+   2. This document incorporates the updates to [RFC6327] from
+      [RFC7180].
+
+   3. The bulk of [RFC6327] was written from the point of view that
+      links between TRILL switches would only be Ethernet.  In fact,
+      they could be any technology, such as PPP [RFC6361], pseudowire
+      [RFC7173], or IP [TrillIP].  This replacement document generalizes
+      [RFC6327] to cover such link types.
+
+   4. This document includes a specification of one-hop BFD session
+      establishment in connection with adjacency.
+
+   5. Numerous editorial changes were incorporated.
+
+Appendix B.  Changes to RFC 6325
+
+   Section 2 of this document replaces Section 4.4.1 of [RFC6325].
+   Section 8 of this document replaces Section 4.4.2 of [RFC6325],
+   except for Section 4.4.2.1.  The changes in [RFC6325] made by this
+   document include
+
+   - Prohibiting the sending of TRILL Hellos out of a port while it is
+     in the Suspended state, and the specification of the Suspended
+     state.  ([RFC6325] specifies that Hellos be sent with the same
+     timing as [IS-IS].)
+
+   - Permitting the inclusion of the Three-Way-Handshake TLV,
+     BFD-Enabled TLV, and other TLVs in TRILL Hellos when these were
+     omitted in TRILL Hello contents lists in Section 4.4.2 of
+     [RFC6325].
+
+   - Extending the TRILL Hello protocol to support point-to-point and
+     non-Ethernet links.
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 31]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+Normative References
+
+   [IS-IS]    ISO/IEC 10589:2002, Second Edition, "Information
+              technology -- Telecommunications and information exchange
+              between systems -- Intermediate System to Intermediate
+              System intra-domain routeing information exchange protocol
+              for use in conjunction with the protocol for providing the
+              connectionless-mode network service (ISO 8473)", 2002.
+
+   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+              dual environments", RFC 1195, December 1990.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
+              Topology (MT) Routing in Intermediate System to
+              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
+
+   [RFC6213]  Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV",
+              RFC 6213, April 2011.
+
+   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
+              Ghanwani, "Routing Bridges (RBridges): Base Protocol
+              Specification", RFC 6325, July 2011.
+
+   [RFC6328]  Eastlake 3rd, D., "IANA Considerations for Network Layer
+              Protocol Identifiers", BCP 164, RFC 6328, July 2011.
+
+   [RFC7175]  Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
+              "Transparent Interconnection of Lots of Links (TRILL):
+              Bidirectional Forwarding Detection (BFD) Support",
+              RFC 7175, May 2014.
+
+   [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.
+
+   [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.
+
+   [RFC7180]  Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
+              A. Banerjee, "Transparent Interconnection of Lots of Links
+              (TRILL): Clarifications, Corrections, and Updates",
+              RFC 7180, May 2014.
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 32]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+Informative References
+
+   [802.1AX]  "IEEE Standard for Local and metropolitan area networks--
+              Link Aggregation", 802.1AX-2008, January 2008.
+
+   [802.1Q]   "IEEE Standard for Local and metropolitan area networks--
+              Media Access Control (MAC) Bridges and Virtual Bridged
+              Local Area Networks", 802.1Q-2011, August 2011.
+
+   [ESADI]    Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
+              Stokes, "TRILL: ESADI (End Station Address Distribution
+              Information) Protocol", Work in Progress, April 2014.
+
+   [FCoE]     Excerpt of discussion of "FCoE Max Size" generated from
+              T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU",
+              <www.t11.org>.
+
+   [MT]       Eastlake, D., Zhang, M., Banerjee, A., and V. Manral,
+              "TRILL: Multi-Topology", Work in Progress, September 2013.
+
+   [RFC3719]  Parker, J., Ed., "Recommendations for Interoperable
+              Networks using Intermediate System to Intermediate System
+              (IS-IS)", RFC 3719, February 2004.
+
+   [RFC6327]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and
+              V. Manral, "Routing Bridges (RBridges): Adjacency",
+              RFC 6327, July 2011.
+
+   [RFC6361]  Carlson, J. and D. Eastlake 3rd, "PPP Transparent
+              Interconnection of Lots of Links (TRILL) Protocol Control
+              Protocol", RFC 6361, August 2011.
+
+   [RFC6439]  Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
+              Hu, "Routing Bridges (RBridges): Appointed Forwarders",
+              RFC 6439, November 2011.
+
+   [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.
+
+   [RFC7173]  Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson,
+              "Transparent Interconnection of Lots of Links (TRILL)
+              Transport Using Pseudowires", RFC 7173, May 2014.
+
+   [TrillIP]  Wasserman, M., Eastlake, D., and D. Zhang, "Transparent
+              Interconnection of Lots of Links (TRILL) over IP", Work in
+              Progress, March 2014.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 33]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+Acknowledgements
+
+   The suggestions and comments of the following are gratefully
+   acknowledged:
+
+      Stewart Bryant, Elwyn Davies, Adrian Farrel, Brian Haberman, Jon
+      Hudson, Arnel Lim, and Gayle Noble.
+
+   The authors of [RFC6327] included Dinesh Dutt.  The acknowledgements
+   section of [RFC6327] includes the following, listed in alphabetic
+   order: Jari Arkko, Ayan Banerjee, Les Ginsberg, Sujay Gupta, David
+   Harrington, Pete McCann, Erik Nordmark, and Mike Shand.
+
+Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   Huawei Technologies
+   155 Beaver Street
+   Milford, MA  01757
+   USA
+
+   Phone: +1-508-333-2270
+   EMail: d3e3e3@gmail.com
+
+
+   Radia Perlman
+   Intel Labs
+   2200 Mission College Blvd.
+   Santa Clara, CA  95054
+   USA
+
+   Phone: +1-408-765-8080
+   EMail: Radia@alum.mit.edu
+
+
+   Anoop Ghanwani
+   Dell
+   5450 Great America Parkway
+   Santa Clara, CA  95054
+   USA
+
+   EMail: anoop@alumni.duke.edu
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 34]
+
+RFC 7177                    TRILL: Adjacency                    May 2014
+
+
+   Howard Yang
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   EMail: howardy@cisco.com
+
+
+   Vishwas Manral
+   Ionos Corp.
+   4100 Moorpark Ave.
+   San Jose, CA  95117
+   USA
+
+   EMail: vishwas@ionosnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 35]
+