doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc7357.txt b/doc/rfc/rfc7357.txt
new file mode 100644
index 0000000..fe91fda
--- /dev/null
+++ b/doc/rfc/rfc7357.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           H. Zhai
+Request for Comments: 7357                                         F. Hu
+Updates: 6325                                                        ZTE
+Category: Standards Track                                     R. Perlman
+ISSN: 2070-1721                                               Intel Labs
+                                                         D. Eastlake 3rd
+                                                                  Huawei
+                                                               O. Stokes
+                                                        Extreme Networks
+                                                          September 2014
+
+
+         Transparent Interconnection of Lots of Links (TRILL):
+     End Station Address Distribution Information (ESADI) Protocol
+
+Abstract
+
+   The IETF TRILL (Transparent Interconnection of Lots of Links)
+   protocol provides least-cost pair-wise data forwarding without
+   configuration in multi-hop networks with arbitrary topologies and
+   link technologies.  TRILL supports multipathing of both unicast and
+   multicast traffic.  Devices that implement the TRILL protocol are
+   called TRILL switches or RBridges (Routing Bridges).
+
+   ESADI (End Station Address Distribution Information) is an optional
+   protocol by which a TRILL switch can communicate, in a Data Label
+   (VLAN or fine-grained label) scoped way, end station address and
+   reachability information to TRILL switches participating in ESADI for
+   the relevant Data Label.  This document updates RFC 6325,
+   specifically the documentation of the ESADI protocol, and is not
+   backwards compatible.
+
+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/rfc7357.
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                    [Page 1]
+
+RFC 7357                      TRILL: ESADI                September 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                    [Page 2]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Content and Precedence .....................................5
+      1.2. Terminology ................................................5
+   2. ESADI Protocol Overview .........................................6
+      2.1. ESADI Virtual Link ........................................10
+      2.2. ESADI Neighbor Determination ..............................10
+      2.3. ESADI Payloads ............................................11
+   3. ESADI DRB (Designated RBridge) Determination ...................11
+   4. ESADI PDU Processing ...........................................12
+      4.1. Unicasting ESADI PDUs .....................................12
+      4.2. General Transmission of ESADI PDUs ........................13
+      4.3. General Receipt of ESADI PDUs .............................14
+      4.4. ESADI Reliable Flooding ...................................14
+   5. End Station Addresses ..........................................15
+      5.1. Learning Confidence Level .................................15
+      5.2. Forgetting End Station Addresses ..........................16
+      5.3. Duplicate MAC Address .....................................16
+   6. ESADI-LSP Contents .............................................18
+      6.1. ESADI Parameter Data ......................................19
+      6.2. MAC-Reachability TLV ......................................20
+      6.3. Default Authentication ....................................21
+   7. IANA Considerations ............................................21
+      7.1. ESADI Participation and Capability Flags ..................22
+      7.2. TRILL GENINFO TLV .........................................23
+   8. Security Considerations ........................................24
+      8.1. Privacy Considerations ....................................25
+   9. Acknowledgements ...............................................26
+   10. References ....................................................26
+      10.1. Normative References .....................................26
+      10.2. Informative References ...................................28
+   Appendix A. Interoperability and Changes to RFC 6325 ..............29
+      A.1. ESADI PDU Changes .........................................29
+      A.2. Unicasting Changes ........................................30
+      A.3. Message Timing Changes and Suggestions ....................30
+      A.4. Duplicate Address Reachability ............................30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                    [Page 3]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+1.  Introduction
+
+   The TRILL (Transparent Interconnection of Lots of Links) protocol
+   [RFC6325] provides least-cost pair-wise data forwarding without
+   configuration in multi-hop networks with arbitrary topologies and
+   link technologies, safe forwarding even during periods of temporary
+   loops, and support for multipathing of both unicast and multicast
+   traffic.  TRILL accomplishes this with the IS-IS (Intermediate System
+   to Intermediate System) [IS-IS] [RFC1195] [RFC7176] link-state
+   routing protocol using a header with a hop count.  The design
+   supports optimization of the distribution of multi-destination frames
+   and two types of data labeling: VLANs (Virtual Local Area Networks)
+   [RFC6325] and FGLs (fine-grained labels) [RFC7172].  Devices that
+   implement TRILL are called TRILL switches or RBridges (Routing
+   Bridges).
+
+   There are five ways a TRILL switch can learn end station addresses,
+   as described in Section 4.8 of [RFC6325].  One of these is the ESADI
+   (End Station Address Distribution Information) protocol, which is an
+   optional Data Label scoped way by which TRILL switches can
+   communicate with each other information such as end station addresses
+   and their TRILL switch of attachment.  A TRILL switch that is
+   announcing interest in a Data Label MAY use the ESADI protocol to
+   announce the end station address of some or all of its attached end
+   stations in that Data Label to other TRILL switches that are running
+   ESADI for that Data Label.  (In the future, ESADI may also be used
+   for other address and reachability information.)
+
+   By default, TRILL switches with connected end stations learn
+   addresses from the data plane when ingressing and egressing native
+   frames, although such learning can be disabled.  The ESADI protocol's
+   potential advantages over data plane learning include the following:
+
+   1. Security advantages:
+
+      a) The ESADI protocol can be used to announce end stations with an
+         authenticated enrollment (for example, enrollment authenticated
+         by cryptographically based EAP (Extensible Authentication
+         Protocol) [RFC3748] methods via [802.1X]).
+
+      b) The ESADI protocol supports cryptographic authentication of its
+         message payloads for more secure transmission.
+
+   2. Fast update advantages: The ESADI protocol provides a fast update
+      of end station MAC (Media Access Control) addresses and their
+      TRILL switch of attachment.  If an end station is unplugged from
+      one TRILL switch and plugged into another, ingressed frames with
+      that end station's MAC address as their destination can be
+
+
+
+Zhai, et al.                 Standards Track                    [Page 4]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+      black-holed.  That is, they can be sent just to the older egress
+      TRILL switch that the end station was connected to until cached
+      address information at some remote ingress TRILL switch times out,
+      possibly for tens of seconds [RFC6325].
+
+   MAC address reachability information, some ESADI parameters, and
+   optional authentication information are carried in ESADI packets
+   rather than in the TRILL IS-IS protocol.  As specified below, ESADI
+   is, for each Data Label, a virtual logical topology overlay in the
+   TRILL topology.  An advantage of using ESADI over using TRILL IS-IS
+   is that the end station attachment information is not flooded to all
+   TRILL switches but only to TRILL switches advertising ESADI
+   participation for the Data Label in which those end stations occur.
+
+1.1.  Content and Precedence
+
+   This document updates [RFC6325], the TRILL base protocol
+   specification, replacing the description of the TRILL ESADI protocol
+   (Section 4.2.5 of [RFC6325], including all subsections), providing
+   more detail on ESADI, updating other ESADI-related sections of
+   [RFC6325], and prevailing over [RFC6325] in any case where they
+   conflict.  For this reason, familiarity with [RFC6325] is
+   particularly assumed.  These changes include a change to the format
+   of ESADI-LSPs (ESADI Link State Protocol Data Units) that is not
+   backwards compatible; this change is justified by the substantially
+   increased amount of information that can be carried and in light of
+   the very limited, if any, deployment of RFC 6325 ESADI.  These
+   changes are further discussed in Appendix A.
+
+   Section 2 of this document is the ESADI protocol overview.  Section 3
+   specifies ESADI DRB (Designated RBridge) determination.  Section 4
+   discusses the processing of ESADI PDUs.  Section 5 discusses
+   interaction with other modes of end station address learning.
+   Section 6 describes the ESADI-LSP and its contents.
+
+1.2.  Terminology
+
+   This document uses the acronyms defined in [RFC6325], in addition to
+   the following:
+
+      Data Label:      VLAN or FGL.
+
+      ESADI RBridge:   An RBridge that is participating in ESADI for one
+                       or more Data Labels.
+
+      FGL:             Fine-Grained Label [RFC7172].
+
+      LSP:             Link State PDU [IS-IS].
+
+
+
+Zhai, et al.                 Standards Track                    [Page 5]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+      LSP number zero: A Link State PDU with fragment number equal to
+                       zero.
+
+      PDU:             Protocol Data Unit.
+
+      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].
+
+   Capitalized IANA-related terms such as "IETF Review" are to be
+   interpreted as described in [RFC5226].
+
+2.  ESADI Protocol Overview
+
+   ESADI is a Data Label scoped way for TRILL switches (also known as
+   RBridges) to announce and learn end station addresses rapidly and
+   securely.  An RBridge that is announcing participation in ESADI for
+   one or more Data Labels is called an ESADI RBridge.
+
+   ESADI is an optional protocol that is separate from the mandatory
+   TRILL IS-IS implemented by all RBridges in a campus.  There is a
+   separate ESADI instance for each Data Label (VLAN or FGL) if ESADI is
+   being used for that Data Label.  In essence, for each such Data
+   Label, there is a modified instance of the IS-IS reliable flooding
+   mechanism in which ESADI RBridges may choose to participate.  (These
+   are not the instances specified in [RFC6822].)  Multiple ESADI
+   instances may share implementation components within an RBridge as
+   long as that sharing preserves the independent operation of each
+   instance of the ESADI protocol.  For example, the ESADI link state
+   database could be a single database with a field in each record
+   indicating the Data Label to which it applies, or it could be a
+   separate database per Data Label.  However, the ESADI update process
+   operates separately for each ESADI instance and independently from
+   the TRILL IS-IS update process.
+
+   ESADI does no routing calculations, so there is no reason for
+   pseudonodes in ESADI and none are created.  (Pseudonodes [IS-IS] are
+   a construct for optimizing routing calculations.)  Furthermore, a
+   relatively large amount of ESADI data will have to be distributed,
+   under some circumstances, using ESADI mechanisms; this would require
+   a large number of ESADI-LSP fragments.  ESADI-LSP, ESADI-CSNP, and
+   ESADI-PSNP (ESADI Link State PDU, Complete Sequence Number PDU, and
+   Partial Sequence Number PDU) payloads are therefore formatted as
+   Extended Level 1 Circuit Scope (E-L1CS) PDUs [RFC7356] (see also
+   Section 6).  This allows up to 2**16 fragments but does not support
+   link state data associated with pseudonodes.
+
+
+
+Zhai, et al.                 Standards Track                    [Page 6]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   After the TRILL Header, ESADI packets have an inner Ethernet header
+   with the Inner.MacDA of "All-Egress-RBridges" (formerly called
+   "All-ESADI-RBridges"), an inner Data Label specifying the VLAN or FGL
+   of interest, and the "L2-IS-IS" Ethertype followed by the ESADI
+   payload, as shown in Figure 1.
+
+                     +--------------------------------+
+                     |          Link Header           |
+                     +--------------------------------+
+                     |       TRILL Data Header        |
+                     +--------------------------------+
+                     |   Inner Ethernet Addresses     |
+                     +--------------------------------+
+                     |           Data Label           |
+                     +--------------------------------+
+                     |       L2-IS-IS Ethertype       |
+                     +--------------------------------+
+                     |         ESADI Payload          |
+                     +--------------------------------+
+                     |          Link Trailer          |
+                     +--------------------------------+
+
+                   Figure 1: TRILL ESADI Packet Overview
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                    [Page 7]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   TRILL ESADI packets sent on an Ethernet link are structured as shown
+   in Figure 2.  The outer VLAN tag will not be present if it was not
+   included by the Ethernet port that sent the packet.
+
+   Outer Ethernet Header:
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Next Hop Destination Address                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Next Hop Destination Addr.    | Sending RBridge Port MAC Addr.|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Sending RBridge Port MAC Address              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       ...Ethernet frame tagging including optional Outer.VLAN tag...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Ethertype = TRILL      0x22F3 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   TRILL Header:                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                      | V | R |M|Op-Length| Hop Count |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Egress Nickname               | Ingress (Origin) Nickname     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   Inner Ethernet Header:
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      All-Egress-RBridges                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | All-Egress-RBridges (cont.)   | Origin RBridge MAC Address    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               Origin RBridge MAC Address (continued)          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Ethertype = L2-IS-IS   0x22F4 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ESADI Payload (formatted as IS-IS):
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   Frame Check Sequence:
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  FCS (Frame Check Sequence)                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 2: ESADI Ethernet Link Packet Format
+
+   The Next Hop Destination Address or Outer.MacDA is the All-RBridges
+   multicast address if the ESADI PDU is being multicast.  If it is
+   being unicast, the Next Hop Destination Address is the unicast
+   address of the next-hop RBridge.  The VLAN for the Outer.VLAN
+
+
+
+Zhai, et al.                 Standards Track                    [Page 8]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   information, if present, will be the Designated VLAN for the link on
+   which the packet is sent.  The V and R fields will be zero while the
+   M bit will be one, unless the ESADI PDU was unicast, in which case
+   the M bit will be zero.  The Data Label specified will be the VLAN or
+   FGL to which the ESADI packet applies.  The Origin RBridge MAC
+   Address or Inner.MacSA MUST be a MAC address unique across the campus
+   owned by the RBridge originating the ESADI packet -- for example, any
+   of its port MAC addresses if it has any Ethernet ports -- and each
+   ESADI RBridge MUST use the same Inner.MacSA for all of the ESADI
+   packets it originates.
+
+   TRILL ESADI packets sent on a PPP link are structured as shown in
+   Figure 3 [RFC6361].
+
+   PPP Header:
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | PPP = TNP (TRILL Data) 0x005D |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   TRILL Header:                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                      | V | R |M|Op-Length| Hop Count |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Egress Nickname               | Ingress (Origin) Nickname     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   Inner Ethernet Header:
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      All-Egress-RBridges                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | All-Egress-RBridges (cont.)   | Origin RBridge MAC Address    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               Origin RBridge MAC Address (continued)          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Ethertype = L2-IS-IS   0x22F4 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ESADI Payload (formatted as IS-IS):
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   PPP Check Sequence:
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       PPP Check Sequence                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 3: ESADI PPP Link Packet Format
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                    [Page 9]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+2.1.  ESADI Virtual Link
+
+   All RBridges forward ESADI packets as if they were ordinary TRILL
+   Data packets.  Because of this forwarding, it appears to an instance
+   of the ESADI protocol at an RBridge that it is directly connected by
+   a multi-access virtual link to all RBridges in the campus that are
+   "data reachable" from it (see Section 2 of [RFC7180]) and are running
+   ESADI for that Data Label.  No "routing" calculation (least-cost path
+   or distribution tree construction) ever has to be performed by ESADI.
+   An ESADI RBridge merely transmits the ESADI packets it originates on
+   this virtual link as described for TRILL Data packets in [RFC6325]
+   and [RFC7172].  For multicast ESADI packets, it may use any
+   distribution tree that it might use for an ordinary multi-destination
+   TRILL Data packet.  RBridges that do not implement the ESADI
+   protocol, do not have it enabled, or are not participating in the
+   ESADI protocol for the Data Label of an ESADI packet do not
+   decapsulate or locally process the ESADI packet.  Thus, ESADI packets
+   are transparently tunneled through transit RBridges.
+
+2.2.  ESADI Neighbor Determination
+
+   The ESADI instance for Data Label X at an RBridge RB1 determines who
+   its adjacent ESADI neighbors are by examining the TRILL IS-IS link
+   state database for RBridges that are data reachable from RB1 (see
+   Section 2 of [RFC7180]) and are announcing their participation in
+   Data Label X ESADI.  When an RBridge RB2 becomes data unreachable
+   from RB1 or the relevant entries for RB2 are purged from the core
+   IS-IS link state database, it is lost as a neighbor and also dropped
+   from any ESADI instances from the point of view of RB1, and when RB2
+   is no longer announcing participation in Data Label X ESADI, it
+   ceases to be a neighbor for any Data Label X ESADI instance.  All
+   these considerations are Data Label scoped.  Because of these
+   mechanisms whereby an ESADI instance at an ESADI RBridge can
+   determine its ESADI adjacencies by examining the TRILL IS-IS link
+   state database, there are no "Hellos" sent in ESADI and no adjacency
+   information is carried in ESADI-LSPs.
+
+   A participation announcement in a VLAN scoped ESADI instance is
+   generated by setting a flag bit in the Interested VLANs sub-TLV, and
+   an announcement for an FGL scoped ESADI instance is generated by
+   setting a flag bit in the Interested Labels sub-TLV [RFC7176] (see
+   Section 7.1).
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 10]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+2.3.  ESADI Payloads
+
+   TRILL ESADI packet payloads are structured like IS-IS Extended
+   Level 1 Circuit Scope (E-L1CS) LSP, CSNP, and PSNP PDUs [RFC7356],
+   except as indicated below, but are always TRILL encapsulated on the
+   wire as if they were TRILL Data packets.  The information distributed
+   by the ESADI protocol includes a list of local end station MAC
+   addresses connected to the originating RBridge and, for each such
+   address, a 1-octet unsigned "Confidence" rating in the range 0-254
+   (see Section 6.2).  It is entirely up to the originating RBridge
+   which locally connected MAC addresses it wishes to advertise via
+   ESADI and with what Confidence.  It MAY advertise all, some, or none
+   of such addresses.  In addition, some ESADI parameters of the
+   advertising RBridge (see Section 6.1) and, optionally, authentication
+   information (see Section 6.3) are included.  Future uses of ESADI may
+   distribute other similar address and reachability information.
+
+   TRILL ESADI-LSPs MUST NOT contain a Data Label ID in their payload.
+   The Data Label to which the ESADI data applies is the Data Label of
+   the TRILL Data packet enclosing the ESADI payload.  If a Data Label
+   ID could occur within the payload, it might conflict with that TRILL
+   Data packet Data Label and could conflict with any future Data Label
+   mapping scheme that may be adopted [VLANmapping].  If a VLAN or FGL
+   ID field within an ESADI-LSP PDU does include a value, that field's
+   contents MUST be ignored.
+
+3.  ESADI DRB (Designated RBridge) Determination
+
+   Because ESADI does no adjacency announcement or routing, the
+   ESADI-DRB never creates a pseudonode.  However, a DRB [RFC7177] is
+   still needed to issue ESADI-CSNP PDUs and respond to ESADI-PSNP PDUs
+   for ESADI-LSP synchronization.
+
+   Generally speaking, the DRB election on the ESADI virtual link (see
+   Section 2.1) operates similarly to the DRB election on a TRILL IS-IS
+   broadcast link, as described in Section 4.2.1 ("DRB Election
+   Details") of [RFC7177], with the following exceptions: in the Data
+   Label X ESADI-DRB election at RB1 on an ESADI virtual link, the
+   candidates are the local ESADI instance for Data Label X and all
+   remote ESADI instances at RBridges that are (1) data reachable from
+   RB1 [RFC7180] and (2) announcing in their TRILL IS-IS LSP that they
+   are participating in ESADI for Data Label X.  The winner is the
+   instance with the highest ESADI Parameter 7-bit priority field with
+   ties broken by the System ID, comparing fields as unsigned integers
+   with the larger magnitude considered higher priority.  "SNPA/MAC
+   address" (Subnetwork Point of Attachment / MAC address) is not
+   considered in this tiebreaking, and there is no "Port ID".
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 11]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+4.  ESADI PDU Processing
+
+   Data Label X ESADI neighbors are usually not connected directly by a
+   physical link but are always logically connected by a virtual link
+   (see Section 2.1).  There could be hundreds or thousands of ESADI
+   RBridges (TRILL switches) on the virtual link.  The only PDUs used in
+   ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDUs.  In
+   particular, there are no Hello or MTU PDUs, because ESADI does not
+   build a topology, does not do any routing calculations, and does not
+   determine MTU.  Instead, ESADI uses the distribution trees and the Sz
+   campus minimum link MTU determined by the core TRILL IS-IS (see
+   [RFC6325] and [RFC7180]).
+
+4.1.  Unicasting ESADI PDUs
+
+   For [IS-IS], PDU multicasting is normal on a local link and no effort
+   is made to optimize to unicast, because on the typical physical link
+   for which IS-IS was designed (commonly a piece of multi-access
+   Ethernet cable), any frame made the link busy for that frame time.
+   However, to ESADI instances, what appears to be a simple multi-access
+   link is generally a set of multi-hop distribution trees that may or
+   may not be pruned.  Thus, transmitting a multicast frame on such a
+   tree can impose a substantially greater load than transmitting a
+   unicast frame.  This load may be justified if there are likely to be
+   multiple listeners but may not be justified if there is only one
+   recipient of interest.  For this reason, under some circumstances,
+   ESADI PDUs MAY be TRILL unicast if it is confirmed that the
+   destination RBridge supports receiving unicast ESADI PDUs (see
+   Section 6.1).
+
+   The format of a unicast ESADI packet is the format of a multicast
+   TRILL ESADI packet as described in Section 2 above, except as
+   follows:
+
+   o  On an Ethernet link, in the outer Ethernet header the Outer.MacDA
+      is the unicast address of the next-hop RBridge.
+
+   o  In the TRILL Header, the M bit is set to zero and the Egress
+      Nickname is the nickname of the destination RBridge.
+
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 12]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is
+   replaced with the following:
+
+   4.6.2.2.  TRILL ESADI Packets
+
+      If M = 1, the egress nickname designates the distribution tree.
+      The packet is forwarded as described in Section 4.6.2.5.  In
+      addition, if (1) the forwarding RBridge is interested in the
+      specified VLAN or fine-grained label [RFC7172], (2) the forwarding
+      RBridge implements the TRILL ESADI protocol, and (3) ESADI is
+      enabled for the specified VLAN or fine-grained label, then the
+      inner frame is decapsulated and provided to that local ESADI
+      protocol.
+
+      If M = 0 and the egress nickname is not that of the receiving
+      RBridge, the packet is forwarded as for known unicast TRILL Data
+      frames as described in Section 4.6.2.4.  If M = 0 and the egress
+      nickname is that of the receiving RBridge, and the receiving
+      RBridge supports unicast ESADI PDUs, then the ESADI packet is
+      decapsulated and processed if it meets the three numbered
+      conditions in the paragraph above; otherwise, it is discarded.
+
+   The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above refer to
+   those sections in [RFC6325].
+
+4.2.  General Transmission of ESADI PDUs
+
+   Following the usual [IS-IS] rules, an ESADI instance does not
+   transmit any ESADI PDUs if it has no ESADI adjacencies.  Such
+   transmission would just be a waste of bandwidth.
+
+   The MTU available to ESADI payloads is at least 24 bytes less than
+   that available to TRILL IS-IS because of the additional fields
+   required ( 2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) +
+   6(Inner.MacSA) + 4/8(Data Label) bytes ).  Thus, the inner ESADI
+   payload, starting with the Intradomain Routeing Protocol
+   Discriminator byte, MUST NOT exceed Sz minus 24 for a VLAN ESADI
+   instance or Sz minus 28 for an FGL ESADI instance; however, if a
+   larger payload is received, it is processed normally (see [RFC6325]
+   and [RFC7180] for discussions of Sz and MTU).
+
+   In all cases where this document says that an ESADI PDU is multicast,
+   if the transmitting RBridge has only one neighbor and that neighbor
+   advertises support for unicast, the PDU MAY be unicast (see
+   Section 4.1).
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 13]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   A priority bit to indicate that an LSP fragment should be flooded
+   with high priority is provided by [RFC7356].  This bit SHOULD be set
+   on ESADI-LSP fragment zero because it is important that the ESADI
+   Parameter APPsub-TLV get through promptly.  This bit SHOULD NOT be
+   set on other ESADI-LSP fragments to avoid giving undue priority to
+   less urgent PDUs.
+
+4.3.  General Receipt of ESADI PDUs
+
+   In contrast with Layer 3 IS-IS PDU acceptance tests, which check the
+   source inner and outer SNPA/MAC in order to verify that a PDU is from
+   an adjacent TRILL switch, in TRILL ESADI adjacency is based on the
+   system ID, so the system ID inside the PDU is all that is tested for.
+
+   If an ESADI instance believes that it has no ESADI neighbors, it
+   ignores any ESADI PDUs it receives.
+
+4.4.  ESADI Reliable Flooding
+
+   The IS-IS reliable flooding mechanism (the Update Process) is
+   modified for ESADI in the ways listed below.  Except as otherwise
+   stated, the ESADI update process works as described in [IS-IS],
+   [RFC1195], and [RFC7356].
+
+   When an ESADI instance sees that it has a new ESADI neighbor, its
+   self-originated ESADI-LSP fragments are scheduled to be sent and MAY
+   be unicast to that neighbor if the neighbor is announcing in its LSP
+   that it supports unicast ESADI (see Section 6.1).  If all the other
+   ESADI instances for the same Data Label send their self-originated
+   ESADI-LSPs immediately, there may be a surge of traffic to that new
+   neighbor.  Therefore, the ESADI instances SHOULD wait an interval of
+   time before sending their ESADI-LSP(s) to a new neighbor.  The
+   interval time value is up to the device implementation.  One
+   suggestion is that the interval time can be assigned a random value
+   with a range based on the RBridge's nickname (or any one of its
+   nicknames, if it holds more than one), such as ( 2000 * nickname /
+   2**16 ) milliseconds, assuming "nickname" to be an unsigned quantity.
+
+   All the TRILL switches participating in an ESADI instance for some
+   Data Label appear to ESADI to be adjacent.  Thus, the originator of
+   any active ESADI-LSP fragment always appears to be on link and, to
+   spread the burden of such a response, could be the RBridge to respond
+   to any ESADI-CSNP or PSNP request for that fragment.  However, under
+   very rare circumstances, it could be that some version of the LSP
+   fragment with a higher sequence number is actually held by another
+   ESADI RBridge on the link, so non-originators need to be able to
+   respond eventually.  Thus, when the receipt of a CSNP or PSNP causes
+   the SRMflag (Send Routing Message flag [IS-IS]) to be set for an LSP
+
+
+
+Zhai, et al.                 Standards Track                   [Page 14]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   fragment, action is as specified in [IS-IS] for the originating ESADI
+   RBridge of the fragment; however, at a non-originating ESADI RBridge,
+   when changing the SRMflag from 0 to 1, the lastSent timestamp [IS-IS]
+   is also set to the current time minus
+
+          minimumLSPTransmissionInterval * Random (Jitter) / 100
+
+   (where minimumLSPTransmissionInterval, Random, and Jitter are as in
+   [IS-IS]).  This will delay and jitter the transmission of the LSP
+   fragment by non-originators.  This gives the originator more time to
+   send the fragment and provides more time for such an originator-
+   transmitted copy to traverse the likely multi-hop path to
+   non-originators and clear the SRMflag for the fragment at
+   non-originators.
+
+   The multi-hop distribution tree method with Reverse Path Forwarding
+   Check used for multicast distribution by TRILL will typically be less
+   reliable than transmission over a single local broadcast link hop.
+   For LSP synchronization robustness, in addition to sending
+   ESADI-CSNPs as usual when it is the DRB, an ESADI RBridge SHOULD also
+   transmit an ESADI-CSNP for an ESADI instance if all of the following
+   conditions are met:
+
+   o  it sees one or more ESADI neighbors for that instance, and
+
+   o  it does not believe it is the DRB for the ESADI instance, and
+
+   o  it has not received or sent an ESADI-CSNP PDU for the instance for
+      the average of the CSNP Time (see Section 6.1) of the DRB and its
+      CSNP Time.
+
+5.  End Station Addresses
+
+   The subsections below discuss end station address considerations in
+   the context of ESADI.
+
+5.1.  Learning Confidence Level
+
+   The Confidence level mechanism [RFC6325] allows an RBridge campus
+   manager to cause certain address learning sources to prevail over
+   others.  MAC address information learned through a registration
+   protocol, such as [802.1X] with a cryptographically based EAP
+   [RFC3748] method, might be considered more reliable than information
+   learned through the mere observation of data traffic.  When such
+   authenticated learned address information is transmitted via the
+   ESADI protocol, the use of authentication in the TRILL ESADI-LSP
+   packets could make tampering with it in transit very difficult.  As a
+   result, it might be reasonable to announce such authenticated
+
+
+
+Zhai, et al.                 Standards Track                   [Page 15]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   information via the ESADI protocol with a high Confidence, so it
+   would be used in preference to any alternative learning from data
+   observation.
+
+5.2.  Forgetting End Station Addresses
+
+   The end station addresses learned through the TRILL ESADI protocol
+   should be forgotten through changes in ESADI-LSPs.  The timeout of
+   the learned end station address is up to the originating RBridge that
+   decides when to remove such information from its ESADI-LSPs (or up to
+   ESADI protocol timeouts if the originating RBridge becomes
+   unreachable).
+
+   If RBridge RBn participating in the TRILL ESADI protocol for Data
+   Label X no longer wishes to participate in ESADI, it ceases to
+   participate by (1) clearing the ESADI Participation bit in the
+   appropriate Interested VLANs or Interested Labels sub-TLV and (2)
+   sending a final ESADI-LSP nulling out its ESADI-LSP information.
+
+5.3.  Duplicate MAC Address
+
+   With ESADI, it is possible to persistently see occurrences of the
+   same MAC address in the same Data Label being advertised as reachable
+   by two or more RBridges.  The specification of how to handle this
+   situation in [RFC6325] is updated by this document, by replacing the
+   last sentence of the last paragraph of Section 4.2.6 of [RFC6325] as
+   shown below to provide better traffic-spreading while avoiding
+   possible address flip-flopping.
+
+   As background, assume some end station or set of end stations ESn
+   have two or more ports with the same MAC address in the same Data
+   Label with the ports connected to different RBridges (RB1, RB2, ...)
+   by separate links.  With ESADI, some other RBridge, RB0, can
+   persistently see that MAC address in that Data Label connected to
+   multiple RBridges.  When RB0 ingresses a frame, say from ES0,
+   destined for that MAC and label, the current [RFC6325] text permits a
+   wide range of behavior.  In particular, [RFC6325] would permit RB0 to
+   use some rule, such as "always encapsulate to the egress with the
+   lowest System ID", which would put all of this traffic through only
+   one of the egress RBridges and one of the end station ports.  With
+   that behavior, there would be no load-spreading, even if there were
+   multiple different ingress RBridges and/or different MAC addresses
+   with the same reachability.  [RFC6325] would also permit RB0 to send
+   different traffic to different egresses by doing ECMP (Equal Cost
+   Multipath) at a flow level, which would likely result in return
+   traffic for RB0 to egress to ES0 from various of RB1, RB2, ... for
+   the same MAC and label.  The resulting address reachability
+   flip-flopping perceived at RB0 could cause problems.
+
+
+
+Zhai, et al.                 Standards Track                   [Page 16]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   This update to [RFC6325] avoids these potential difficulties by
+   requiring that RB0 use one of the following two policies: (1) only
+   encapsulate to one egress RBridge for any particular MAC and label,
+   but select that egress pseudorandomly, based on the topology
+   (including MAC reachability) or (2) if RB0 will not be disturbed by
+   the returning TRILL Data packets showing the same MAC or by label
+   flip-flopping between different ingresses, RB0 may use ECMP.
+   Assuming multiple ingress RBridges and/or multiple MAC and label
+   addresses, strategy 1 should result in load-spreading without address
+   flip-flopping, while strategy 2 will produce better load-spreading
+   than strategy 1 but with address flip-flopping from the point of view
+   of RB0.
+
+   OLD [RFC6325] Section 4.2.6 text:
+
+      "... If confidences are also tied between the duplicates, for
+      consistency it is suggested that RB2 direct all such frames (or
+      all such frames in the same ECMP flow) toward the same egress
+      RBridge; however, the use of other policies will not cause a
+      network problem since transit RBridges do not examine the
+      Inner.MacDA for known unicast frames."
+
+   NEW [RFC6325] Section 4.2.6 text:
+
+      "... If confidences are also tied between the duplicates, then RB2
+      MUST adopt one of the following two strategies:
+
+      1. In a pseudorandom way [RFC4086], select one of the egress
+         RBridges that is least cost from RB2 and to which the
+         destination MAC appears to be attached, and send all traffic
+         for the destination MAC and VLAN (or FGL [RFC7172]) to that
+         egress.  This pseudorandom choice need only be changed when
+         there is a change in campus topology or MAC attachment
+         information.  Such pseudorandom selection will, over a
+         population of ingress RBridges, probabilistically spread
+         traffic over the possible egress RBridges.  Reasonable inputs
+         to the pseudorandom selection are the ingress RBridge System ID
+         and/or nickname, the VLAN or FGL, the destination MAC address,
+         and a vector of the RBridges with connectivity to that MAC and
+         VLAN or FGL.  There is no need for different RBridges to use
+         the same pseudorandom function.
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 17]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+         As an example of such a pseudorandom function, if there are k
+         egress RBridges (RB0, RB1, ..., RB(k-1)) all reporting
+         attachment to address MACx in Data Label DLy, then an ingress
+         RBridge RBin could select the one to which it will send all
+         unicast TRILL Data packets addressed to MACx in DLy based on
+         the following:
+
+            FNV-32(RBin | MACx | DLy | RB0 | RB1 | ... | RB(k-1)) mod k
+
+            where the FNV (Fowler/Noll/Vo) algorithm is specified in
+            [FNV], RBx means the nickname for RBridge RBx, "|" means
+            concatenation, MACx is the destination MAC address, DLy is
+            the Data Label, and "mod k" means the integer division
+            remainder of the output of the FNV-32 function considered as
+            a positive integer divided by k.
+
+      2. If RB2 supports ECMP and will not be disturbed by return
+         traffic from the same MAC and VLAN (or FGL [RFC7172]) coming
+         from a variety of different RBridges, then it MAY send traffic
+         using ECMP at the flow level to the egress RBridges that are
+         least cost from RB2 and to which the destination MAC appears to
+         be attached."
+
+6.  ESADI-LSP Contents
+
+   The only PDUs used in ESADI are the ESADI-LSP, ESADI-CSNP, and
+   ESADI-PSNP PDUs.  Currently, the contents of an ESADI-LSP consist of
+   zero or more MAC-Reachability TLVs, optionally an Authentication TLV,
+   and exactly one ESADI parameter APPsub-TLV.  Other similar data may
+   be included in the future and, as in [IS-IS], an ESADI instance
+   ignores any TLVs or sub-TLVs it does not understand.  Because these
+   PDUs are formatted as Extended Level 1 Circuit Scope (E-L1CS) PDUs
+   [RFC7356], the Type and Length fields in the TLVs are 16-bit.
+
+   This section specifies the format for the ESADI Parameter APPsub-TLV,
+   gives the reference for the ESADI MAC-Reachability TLV, and discusses
+   default authentication configuration.
+
+   For robustness, the payload for an ESADI-LSP number zero and any
+   ESADI-CSNP or ESADI-PSNP covering fragment zero MUST NOT exceed 1470
+   minus 24 bytes in length (1446 bytes) if it has an Inner.VLAN, or
+   1470 minus 28 bytes (1442 bytes) if it has an Inner.FGL.  However, if
+   an ESADI-LSP number zero or such an ESADI-CSNP or ESADI-PSNP is
+   received that is longer, it is still processed normally.  (As stated
+   in Section 4.3.1 of [RFC6325], 1470 bytes was chosen to make it
+   extremely unlikely that a TRILL control packet, even with reasonable
+   additional headers, tags, and/or encapsulation, would encounter MTU
+   problems on an inter-RBridge link.)
+
+
+
+Zhai, et al.                 Standards Track                   [Page 18]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+6.1.  ESADI Parameter Data
+
+   Figure 4 presents the format of the ESADI parameter data.  This
+   APPsub-TLV MUST be included in a TRILL GENINFO TLV in ESADI-LSP
+   number zero.  If it is missing from ESADI-LSP number zero or if
+   ESADI-LSP number zero is not known, priority for the sending RBridge
+   defaults to 0x40 and CSNP Time defaults to 30.  If there is more than
+   one occurrence in ESADI-LSP number zero, the first occurrence will be
+   used.  Occurrences of the ESADI Parameter APPsub-TLV in non-zero
+   ESADI-LSP fragments are ignored.
+
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+               | Type                          |   (2 bytes)
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+               | Length                        |   (2 bytes)
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+               |R| Priority    |                   (1 byte)
+               +-+-+-+-+-+-+-+-+
+               | CSNP Time     |                   (1 byte)
+               +-+-+-+-+-+-+-+-+
+               | Flags         |                   (1 byte)
+               +---------------+
+               | Reserved for expansion            (variable)
+               +-+-+-+-...
+
+                   Figure 4: ESADI Parameter APPsub-TLV
+
+   Type: Set to ESADI-PARAM sub-TLV (TRILL APPsub-TLV type 0x0001).
+      Two bytes, because this APPsub-TLV appears in an extended TLV
+      [RFC7356].
+
+   Length: Variable, with a minimum of 3, but must fit within the ESADI
+      packet.  This field is encoded as an unsigned integer in network
+      byte order [RFC7356].
+
+   R: A reserved bit that MUST be sent as zero and ignored on receipt.
+
+   Priority: Gives the originating RBridge's priority for being the DRB
+      on the ESADI instance virtual link (see Section 3) for the Data
+      Label in which the PDU containing the parameter data was sent.  It
+      is an unsigned 7-bit integer with the larger magnitude indicating
+      higher priority.  It defaults to 0x40 for an RBridge participating
+      in ESADI for which it has not been configured.
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 19]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   CSNP Time: An unsigned byte that gives the amount of time in seconds
+      during which the originating RBridge, if it is the DRB on the
+      ESADI virtual link, will send at least three ESADI-CSNP PDUs.  It
+      defaults to 30 seconds for an RBridge participating in ESADI for
+      which it has not been configured.
+
+   Flags: A byte of flags associated with the originating ESADI
+      instance, as follows:
+
+                     0   1   2   3   4   5   6   7
+                  +---+---+---+---+---+---+---+---+
+                  | UN|           RESV            |
+                  +---+---+---+---+---+---+---+---+
+
+      The UN flag indicates that the RBridge originating the ESADI-LSP,
+      including this ESADI parameter data, will accept and properly
+      process ESADI PDUs sent by TRILL unicast (see Section 4.1).  The
+      remaining RESV bits are reserved for future use and MUST be sent
+      as zero and ignored on receipt.
+
+   Reserved for future expansion: Future versions of the ESADI Parameter
+      APPsub-TLV may have additional information.  A receiving ESADI
+      RBridge ignores any additional data here, unless it implements
+      such future expansion(s).
+
+6.2.  MAC-Reachability TLV
+
+   The primary information in TRILL ESADI-LSP PDUs consists of
+   MAC-Reachability (MAC-RI) TLVs specified in [RFC6165].  These TLVs
+   contain one or more unicast MAC addresses of end stations that are
+   both on a port and in a VLAN for which the originating RBridge is
+   Appointed Forwarder, along with the 1-octet unsigned Confidence in
+   this information with a value in the range 0-254.  If such a TLV is
+   received containing a Confidence of 255, it is treated as if the
+   Confidence was 254.  (This is to assure that any received address
+   information can be overridden by local address information statically
+   configured with a Confidence of 255.)
+
+   The TLVs in TRILL ESADI PDUs, including the MAC-RI TLV, MUST NOT
+   contain the Data Label ID.  If a Data Label ID is present in the
+   MAC-RI TLV, it is ignored.  In the ESADI PDU, only the Inner.VLAN or
+   Inner.FGL tag indicates the Data Label to which the ESADI-LSP
+   applies.
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 20]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+6.3.  Default Authentication
+
+   The Authentication TLV may be included in ESADI PDUs [RFC5310]
+   [IS-IS].  The default for ESADI PDU authentication is based on the
+   state of TRILL IS-IS shared secret authentication for TRILL IS-IS LSP
+   PDUs.  If TRILL IS-IS authentication and ESADI are implemented at a
+   TRILL switch, then ESADI MUST be able to use the authentication
+   algorithms implemented for TRILL IS-IS and implement the keying
+   material derivation function given below.  If ESADI authentication
+   has been manually configured, that configuration is not restricted by
+   the configuration of TRILL IS-IS security.
+
+   If TRILL IS-IS authentication is not in effect for LSP PDUs
+   originated by a TRILL switch, then ESADI PDUs originated by that
+   TRILL switch are by default also unsecured.
+
+   If such IS-IS LSP PDU authentication is in effect at a TRILL switch,
+   then, unless configured otherwise, ESADI PDUs sent by that switch
+   MUST use the same algorithm in their Authentication TLVs.  The ESADI
+   authentication keying material used is derived from the IS-IS LSP
+   shared secret keying material as detailed below.  However, such
+   authentication MAY be configured to use some other keying material.
+
+           HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key )
+
+   In the algorithm above, HMAC-SHA256 is as described in [FIPS180] and
+   [RFC6234], and "TRILL ESADI" is the 11-byte US ASCII [ASCII] string
+   indicated.  IS-IS-LSP-shared-key is secret keying material being used
+   by the originating TRILL switch for IS-IS LSP authentication.
+
+7.  IANA Considerations
+
+   IANA allocation and registry considerations are given below.  Three
+   new sub-registries have been created in the "Transparent
+   Interconnection of Lots of Links (TRILL) Parameters" registry located
+   at <http://www.iana.org/assignments/trill-parameters> -- two in
+   Section 7.1 and one in Section 7.2 -- and various code points have
+   been assigned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 21]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+7.1.  ESADI Participation and Capability Flags
+
+   IANA Action 1:
+
+      IANA has created the following new sub-registry called "Interested
+      VLANs Flag Bits" in the "Transparent Interconnection of Lots of
+      Links (TRILL) Parameters" registry.
+
+         Sub-registry: Interested VLANs Flag Bits
+
+         Registration Procedures: IETF Review
+
+         Note: These bits appear in the Interested VLANs record within
+         the Interested VLANs and Spanning Tree Roots Sub-TLV (INT-VLAN)
+         specified in [RFC7176].
+
+         References: [RFC7176], [RFC7357]
+
+       Bit  Mnemonic  Description                      Reference
+       ---  --------  -----------                      ---------
+         0     M4     IPv4 Multicast Router Attached   [RFC7176]
+         1     M6     IPv6 Multicast Router Attached   [RFC7176]
+         2      -     Unassigned
+         3     ES     ESADI Participation              [RFC7357]
+        4-15    -     (used for a VLAN ID)             [RFC7176]
+       16-19    -     Unassigned
+       20-31    -     (used for a VLAN ID)             [RFC7176]
+
+      The creation of this sub-registry (as immediately above) assigned
+      bit 3 as the ESADI Participation bit in the Interested VLANs and
+      Spanning Tree Roots sub-TLV.  If The ESADI Participation bit is a
+      one, it indicates that the originating RBridge is participating in
+      ESADI for the indicated Data Label(s).
+
+   IANA Action 2:
+
+      IANA has created the following new sub-registry called "Interested
+      Labels Flag Bits" in the "Transparent Interconnection of Lots of
+      Links (TRILL) Parameters" registry.
+
+         Sub-registry: Interested Labels Flag Bits
+
+         Registration Procedures: IETF Review
+
+         Note: These bits appear in the Interested Labels record within
+         the Interested Labels and Spanning Tree Roots Sub-TLV
+         (INT-LABEL) specified in [RFC7176].
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 22]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+         References: [RFC7176], [RFC7357]
+
+      Bit  Mnemonic  Description                      Reference
+      ---  --------  -----------                      ---------
+        0     M4     IPv4 Multicast Router Attached   [RFC7176]
+        1     M6     IPv6 Multicast Router Attached   [RFC7176]
+        2     BM     Bit Map                          [RFC7176]
+        3     ES     ESADI Participation              [RFC7357]
+       4-7     -     Unassigned
+
+      The creation of this sub-registry (as immediately above) assigned
+      bit 3 as the ESADI Participation bit in the Interested Labels and
+      Spanning Tree Roots sub-TLV.  If The ESADI Participation bit is a
+      one, it indicates that the originating RBridge is participating in
+      ESADI for the indicated Data Label(s).
+
+7.2.  TRILL GENINFO TLV
+
+   IANA Action 3:
+
+      IANA has allocated the IS-IS Application Identifier 1 under the
+      Generic Information TLV (#251) [RFC6823] for TRILL.
+
+   IANA Action 4:
+
+      IANA has created a sub-registry in the "Transparent
+      Interconnection of Lots of Links (TRILL) Parameters" registry as
+      follows:
+
+         Sub-registry:  TRILL APPsub-TLV Types under IS-IS TLV 251
+                        Application Identifier 1
+
+         Registration Procedures: IETF Review with additional
+            requirements on the documentation of the use being
+            registered as specified in Section 7.2 of [RFC7357].
+
+         Note: Types greater than 255 are only usable in contexts
+         permitting a type larger than one byte, such as extended TLVs
+         [RFC7356].
+
+         Reference: [RFC7357]
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 23]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+                Type      Name              Reference
+             ----------  --------          -----------
+                     0   Reserved          [RFC7357]
+                     1   ESADI-PARAM       [RFC7357]
+                 2-254   Unassigned        [RFC7357]
+                   255   Reserved          [RFC7357]
+             256-65534   Unassigned        [RFC7357]
+                 65535   Reserved          [RFC7357]
+
+      TRILL APPsub-TLV Types 2 through 254 and 256 through 65534 are
+      available for assignment by IETF Review.  The RFC causing such an
+      assignment will also include a discussion of security issues and
+      of the rate of change of the information being advertised.  TRILL
+      APPsub-TLVs MUST NOT alter basic IS-IS protocol operation
+      including the establishment of adjacencies, the update process,
+      and the decision process for TRILL IS-IS [IS-IS] [RFC1195]
+      [RFC7177].  The TRILL Generic Information TLV MUST NOT be used in
+      an IS-IS instance zero [RFC6822] LSP but may be used in Flooding
+      Scoped LSPs (FS-LSPs) [RFC7356].
+
+   The V, I, D, and S flags in the initial flags byte of a TRILL Generic
+   Information TLV have the meanings specified in [RFC6823] but are not
+   currently used, as TRILL operates as a Level 1 IS-IS area and no
+   semantics are hereby assigned to the inclusion of an IPv4 and/or IPv6
+   address via the I and V flags.  Thus, these I and V flags MUST be
+   zero; however, if either or both are one, the space that should be
+   taken by an IPv4 and/or IPv6 address, respectively, is skipped over
+   and ignored.  Furthermore, the use of multilevel IS-IS is an obvious
+   extension for TRILL [MultiLevel], and future IETF Standards Actions
+   may update or obsolete this specification to provide for the use of
+   any or all of these flags in the TRILL GENINFO TLV.
+
+   The ESADI Parameters information, for which TRILL APPsub-TLV 1 is
+   hereby assigned, is compact and slow changing (see Section 6.1).
+
+   For security considerations related to ESADI and the ESADI Parameter
+   APPsub-TLV, see Section 8.
+
+8.  Security Considerations
+
+   ESADI PDUs can be authenticated through the inclusion of the
+   Authentication TLV [RFC5310].  Defaults for such authentication are
+   described in Section 6.3.
+
+   The ESADI-LSP data primarily announces MAC address reachability
+   within a Data Label.  Such reachability can, in some cases, be an
+   authenticated registration (for example, a Layer 2 authenticated
+   registration using cryptographically based EAP (Extensible
+
+
+
+Zhai, et al.                 Standards Track                   [Page 24]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   Authentication Protocol [RFC3748]) methods via [802.1X]).  The
+   combination of these techniques can cause ESADI MAC reachability
+   information to be substantially more trustworthy than MAC
+   reachability learned from observation of the data plane.
+   Nevertheless, ESADI still involves trusting all other RBridges in the
+   TRILL campus, at least those that have the keying material necessary
+   to construct a valid Authentication TLV.
+
+   However, there may be cases where authenticated registration is used
+   for end stations, because of a significant threat of forged packets
+   on end station links, but it is not necessary to authenticate ESADI
+   PDUs because that threat is not present for inter-RBridge trunks.
+   For example, a TRILL campus with secure RBridges and inter-RBridge
+   links configured as trunks but with some end stations connected via
+   IEEE 802.11 wireless access links might use 802.11 authentication for
+   the connection of such end stations but might not necessarily
+   authenticate ESADI PDUs.  Note that if the IS-IS LSPs in a TRILL
+   campus are authenticated, perhaps due to a concern about forged
+   packets, the ESADI PDUs will be authenticated by default as provided
+   in Section 6.3.
+
+   MAC reachability learned from the data plane (the TRILL default) is
+   overwritten by any future learning of the same type.  ESADI
+   advertisements are represented in the Data Label scoped link state
+   database.  Thus, ESADI makes visible any multiple attachments of the
+   same MAC address within a Data Label to different RBridges (see
+   Section 5.3).  This may or may not be an error or misconfiguration,
+   but ESADI at least makes it explicitly and persistently visible,
+   which would not be the case with data plane learning.
+
+   For general TRILL security considerations, see [RFC6325].
+
+8.1.  Privacy Considerations
+
+   The address reachability information distributed by ESADI has
+   substantial privacy considerations under many, but not all,
+   circumstances.
+
+   For example, if ESADI were used in a TRILL campus with independent
+   user end stations at the edge, the MAC addresses of such end stations
+   could uniquely identify the users of those end stations.  Their
+   reachability would be sensitive information and, particularly if
+   logged, could reveal such user information.  On the other hand, if
+   TRILL is being used to implement an Internet Exchange Point (IXP) to
+   connect Internet Service Providers (ISPs), the MAC addresses being
+   advertised in ESADI would typically be those of the ISP's directly
+   connected IP router ports, since Layer 3 routers bound the TRILL
+   campus, for which there would be few privacy concerns.
+
+
+
+Zhai, et al.                 Standards Track                   [Page 25]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   However, records of MAC attachment that include a modest amount of
+   history, perhaps a few days' worth, can be useful in managing a
+   network and troubleshooting network problems.  It might, in some
+   cases, also be legally required, or required for billing purposes or
+   the like.
+
+   Network operators should seek a reasonable balance between these
+   competing considerations, customized for the circumstances of their
+   particular networks where ESADI is in use.  They should not maintain
+   logs of MAC reachability information for any longer than is clearly
+   required.
+
+9.  Acknowledgements
+
+   The authors thank the following, listed in alphabetic order, for
+   their suggestions and contributions:
+
+      David Black, Somnath Chatterjee, Adrian Farrel, Stephen Farrell,
+      Sujay Gupta, Russ Housley, Pearl Liang, Kathleen Moriarty, Thomas
+      Narten, Erik Nordmark, and Mingui Zhang.
+
+10.  References
+
+10.1.  Normative References
+
+   [ASCII]    American National Standards Institute (formerly United
+              States of America Standards Institute), "USA Code for
+              Information Interchange", ANSI X3.4-1968, 1968.
+
+              ANSI X3.4-1968 has been replaced by newer versions with
+              slight modifications, but the 1968 version remains
+              definitive for the Internet.
+
+   [FIPS180]  "Secure Hash Standard (SHS)", National Institute of
+              Standards and Technology, Federal Information Processing
+              Standard (FIPS) 180-4, March 2012, <http://csrc.nist.gov/
+              publications/fips/fips180-4/fips-180-4.pdf>.
+
+   [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.
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 26]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              June 2005.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
+              and M. Fanto, "IS-IS Generic Cryptographic
+              Authentication", RFC 5310, February 2009.
+
+   [RFC6165]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
+              Systems", RFC 6165, 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.
+
+   [RFC6361]  Carlson, J. and D. Eastlake 3rd, "PPP Transparent
+              Interconnection of Lots of Links (TRILL) Protocol Control
+              Protocol", RFC 6361, August 2011.
+
+   [RFC6823]  Ginsberg, L., Previdi, S., and M. Shand, "Advertising
+              Generic Information in IS-IS", RFC 6823, December 2012.
+
+   [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.
+
+   [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.
+
+   [RFC7177]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
+              V. Manral, "Transparent Interconnection of Lots of Links
+              (TRILL): Adjacency", RFC 7177, May 2014.
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 27]
+
+RFC 7357                      TRILL: ESADI                September 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.
+
+   [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
+              Scope Link State PDUs (LSPs)", RFC 7356, September 2014.
+
+10.2.  Informative References
+
+   [802.1X]   IEEE 802.1, "IEEE Standard for Local and metropolitan area
+              networks--Port-Based Network Access Control", IEEE
+              Standard 802.1X-2010, February 2010.
+
+   [FNV]      Fowler, G., Noll, L., Vo, K., and D. Eastlake 3rd, "The
+              FNV Non-Cryptographic Hash Algorithm", Work in Progress,
+              April 2014.
+
+   [MultiLevel]
+              Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai,
+              "Flexible Multilevel TRILL (Transparent Interconnection of
+              Lots of Links)", Work in Progress, June 2014.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, June 2004.
+
+   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
+
+   [RFC6822]  Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D.
+              Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
+
+   [VLANmapping]
+              Perlman, R., Rijhsinghani, A., Eastlake 3rd, D., Banerjee,
+              A., and D. Dutt, "TRILL: Campus Label and Priority
+              Regions", Work in Progress, January 2014.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 28]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+Appendix A.  Interoperability and Changes to RFC 6325
+
+   This appendix summarizes the significant changes this document makes
+   to the TRILL base protocol specification [RFC6325].  Although
+   simultaneous use of [RFC6325] ESADI and ESADI as specified in this
+   document in a TRILL campus is very unlikely due to non-deployment of
+   [RFC6325] ESADI, this appendix also discusses, for each change, the
+   interoperability considerations should such simultaneous use occur.
+
+A.1.  ESADI PDU Changes
+
+   The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads is
+   changed from the IS-IS Level 1 format [IS-IS] to the Extended Level 1
+   Circuit Scope format (E-L1CS) specified in [RFC7356].  This change is
+   not backwards compatible with [RFC6325].  It is made in light of the
+   information-carrying capacity of the E-L1CS format, which is
+   256 times greater than that of the base IS-IS format.  It is
+   anticipated that this greater information-carrying capacity will be
+   needed, under some circumstances, to carry end station addressing
+   information or other similar address and reachability information
+   when it is added to ESADI in the future.
+
+   The PDU numbers used for the ESADI LSP, CSNP, and PSNP PDUs in
+   [RFC6325] are 18, 24, and 26 [IS-IS].  With this document, the format
+   changes, and the PDU numbers change to 10, 11, and 12 [RFC7356].  The
+   use of different PDU numbers assures that a PDU will not be
+   mis-parsed.  Because of this, implementations of this document and
+   implementations of [RFC6325] ESADI will discard each other's PDUs.
+   Thus, address reachability or other information distributed through
+   either type of ESADI implementation will only be communicated to
+   other implementations of the same type, and the two communities will
+   not communicate any information with each other.
+
+   Note that RBridges can use the TRILL mandatory-to-implement,
+   enabled-by-default data plane address learning in addition to ESADI.
+   (Section 5 of this document and the material it references explain
+   how to handle conflicts between different sources of address
+   reachability information.)  Simply leaving data plane address
+   learning enabled would enable smooth incremental migration from
+   [RFC6325] ESADI to the ESADI specification in this document, should
+   that be necessary.  The data plane address learning would fill in any
+   gaps due to non-communication between the two types of ESADI
+   implementations, although without the speed or security advantages
+   of ESADI.
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 29]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+A.2.  Unicasting Changes
+
+   Unicasting of ESADI PDUs is optionally supported, including replacing
+   Section 4.6.2.2 of [RFC6325] with the new text given in Section 4.1
+   of this document.  This unicast support is backwards compatible
+   because it is only used when the recipient RBridge signals its
+   support.
+
+A.3.  Message Timing Changes and Suggestions
+
+   The following timing-related ESADI message changes and suggestions
+   are included in this document:
+
+   1. Provide for staggered delay for non-originators of ESADI-LSP
+      fragments in response to requests for such fragments by CSNP and
+      PSNP messages.
+
+   2. Suggest staggered timing of unicast ESADI-LSPs when a new ESADI
+      RBridge appears on the ESADI virtual link.
+
+   These relate only to the timing of messages for congestion
+   minimization.  Should a message be lost, due to congestion or
+   otherwise, it will be later retransmitted as a normal part of the
+   robust flooding mechanism used by ESADI.
+
+A.4.  Duplicate Address Reachability
+
+   The handling of persistent reachability of the same MAC within the
+   same Data Label from two or more RBridges is substantially modified,
+   including the explicit replacement of some text in Section 4.2.6 of
+   [RFC6325] (see Section 5.3 of this document).  There is no problem
+   with a mixture of ESADI implementations in a TRILL campus, some
+   conforming to [RFC6325] and some conforming to this document, for
+   handling this condition.  The more implementations conform to the
+   improved behavior specified in this document for this condition, the
+   better the traffic-spreading will be, and the less likely address
+   flip-flopping problems will be.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 30]
+
+RFC 7357                      TRILL: ESADI                September 2014
+
+
+Authors' Addresses
+
+   Hongjun Zhai
+   ZTE Corporation
+   68 Zijinghua Road
+   Nanjing 200012
+   China
+   Phone: +86-25-52877345
+   EMail: zhai.hongjun@zte.com.cn
+
+   Fangwei Hu
+   ZTE Corporation
+   889 Bibo Road
+   Shanghai 201203
+   China
+   Phone: +86-21-68896273
+   EMail: hu.fangwei@zte.com.cn
+
+   Radia Perlman
+   EMC
+   2010 256th Ave. NE, #200
+   Bellevue, WA  98007
+   USA
+   EMail: Radia@alum.mit.edu
+
+   Donald Eastlake 3rd
+   Huawei Technologies
+   155 Beaver Street
+   Milford, MA  01757
+   USA
+   Phone: +1-508-333-2270
+   EMail: d3e3e3@gmail.com
+
+   Olen Stokes
+   Extreme Networks
+   2121 RDU Center Drive, Suite 300
+   Morrisville, NC  27560
+   USA
+   EMail: ostokes@extremenetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+Zhai, et al.                 Standards Track                   [Page 31]
+