TRILL Working Group                                         Hongjun
Internet Engineering Task Force (IETF)                           H. Zhai
INTERNET-DRAFT                                                Fangwei
Request for Comments: 7357                                         F. Hu
Intended status: Proposed Standard                                   ZTE
Updates: 6325                                              Radia                                                        ZTE
Category: Standards Track                                     R. Perlman
ISSN: 2070-1721                                               Intel Labs
                                                         Donald
                                                         D. Eastlake 3rd
                                                                  Huawei
                                                             Olen
                                                               O. Stokes
                                                        Extreme Networks
Expires: Decemeber 6, 2014                                  June 7,
                                                             August 2014

                                 TRILL:
     ESADI (End

         Transparent Interconnection of Lots of Links (TRILL):
     End Station Address Distribution Information) Information (ESADI) Protocol
                    <draft-ietf-trill-esadi-09.txt>

Abstract

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol provides least cost least-cost pair-wise data forwarding without
   configuration in multi-hop networks with arbitrary topologies and
   link technologies.  TRILL supports multi-pathing of both unicast and
   multicast traffic.  Devices that implement the TRILL protocol are
   called TRILL Switches 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) 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 Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this an Internet Standards Track document.

   This document is unlimited. Comments should be sent
   to the TRILL working group mailing list: <trill@ietf.org>.

   Internet-Drafts are working documents a product of the Internet Engineering Task Force (IETF), its areas,
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

INTERNET-DRAFT                                              TRILL: ESADI

   Internet-Drafts are draft documents valid has been approved for a maximum 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 six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It
   http://www.rfc-editor.org/info/rfc7357.

Copyright Notice

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

   This document is inappropriate subject to use Internet-Drafts 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 reference
   material or they describe your rights and restrictions with respect
   to cite them other than this document.  Code Components extracted from this document must
   include Simplified BSD License text as "work described in progress."

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

INTERNET-DRAFT                                              TRILL: ESADI
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction............................................4
      1.1 Introduction ....................................................4
      1.1. Content and Precedence.................................5
      1.2 Terminology............................................5 Precedence .....................................5
      1.2. Terminology ................................................5
   2. ESADI Protocol Overview.................................7
      2.1 Overview .........................................6
      2.1. ESADI Virtual Link....................................10
      2.2 Link ........................................10
      2.2. ESADI Neighbor Determination..........................11
      2.3 Determination ..............................10
      2.3. ESADI Payloads........................................11 Payloads ............................................11
   3. ESADI DRB (Designated RBridge) Determination...........13 Determination ...................11
   4. ESADI PDU processing...................................14
      4.1 Processing ...........................................12
      4.1. Unicasting ESADI PDUs.................................14
      4.2 PDUs .....................................12
      4.2. General Transmission of ESADI PDUs....................15
      4.3 PDUs ........................13
      4.3. General Receipt of ESADI PDUs.........................16
      4.4 PDUs .............................14
      4.4. ESADI Reliable Flooding...............................16 Flooding ...................................14
   5. End Station Addresses..................................18
      5.1 Addresses ..........................................15
      5.1. Learning Confidence Level.............................18
      5.2 Level .................................15
      5.2. Forgetting End Station Addresses......................18
      5.3 Addresses ..........................16
      5.3. Duplicate MAC Address.................................18 Address .....................................16
   6. ESADI-LSP Contents.....................................21
      6.1 Contents .............................................18
      6.1. ESADI Parameter Data..................................21
      6.2 MAC Reachability TLV..................................23
      6.3 Data ......................................19
      6.2. MAC-Reachability TLV ......................................20
      6.3. Default Authentication................................23 Authentication ....................................21
   7. IANA Considerations....................................25
      7.1 Considerations ............................................21
      7.1. ESADI Participation and Capability Flags..............25
      7.2 Flags ..................22
      7.2. TRILL GENINFO TLV.....................................26 TLV .........................................23
   8. Security Considerations................................28
      8.1 Considerations ........................................24
      8.1. Privacy Considerations................................28 Considerations ....................................25
   9. Acknowledgements.......................................30 Acknowledgements ...............................................26
   10. References ....................................................26
      10.1. Normative references......................................31 References .....................................26
      10.2. Informative References....................................32 References ...................................28
   Appendix A: A. Interoperability and Changes to [RFC6325].....34
      A.1 RFC 6325 ..............29
      A.1. ESADI PDU Changes.....................................34
      A.2 Changes .........................................29
      A.2. Unicasting Changes....................................35
      A.3 Changes ........................................30
      A.3. Message Timing Changes and Suggestions................35
      A.4 Suggestions ....................30
      A.4. Duplicate Address Reachability........................35

      Appendix Z: Change History................................36

      Authors' Addresses........................................40

INTERNET-DRAFT                                              TRILL: ESADI Reachability ............................30

1.  Introduction

   The IETF TRILL (Transparent Interconnection of Lots of Links) protocol
   [RFC6325] provides least cost 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 multi-pathing 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]) Networks)
   [RFC6325] and FGLs (Fine Grained
   Labels, [RFC7172]). (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,
   communicate with each other, 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
   frames, although such learning can be disabled.  The ESADI protocol's
   potential advantages over data plane learning include the following:

   1. Security advantages: (1a)

      a) The ESADI protocol can be used to announce end stations with an
         authenticated enrollment (for
      example example, enrollment authenticated
         by cryptographically based EAP (Extensible Authentication Protocol [RFC3748])
         Protocol) [RFC3748] methods via [802.1X]). (1b)

      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 black
      holed.
      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].

INTERNET-DRAFT                                              TRILL: ESADI

   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

1.1.  Content and Precedence

   This document updates [RFC6325], the TRILL base protocol
   specification, obsoleting and replacing the description of the TRILL ESADI protocol
   (Section 4.2.5 of [RFC6325] [RFC6325], including all subsections), providing
   more detail on ESADI, updating other ESADI
   related 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 (Protocol Data Units). PDUs.  Section 5 discusses
   interaction with other modes of end station address learning. And
   Section 6 describes the ESADI-LSP (Link State PDU) and its contents.

1.2

1.2.  Terminology

   This document uses the acronyms defined in [RFC6325] and [RFC6325], in addition to
   the following:

      Data Label - Label:      VLAN or FGL.

      ESADI RBridge - RBridge:   An RBridge that is participating in ESADI for one
                       or more Data Labels.

      FGL - Fine Grained

      FGL:             Fine-Grained Label [RFC7172].

      LSP -

      LSP:             Link State PDU [IS-IS].

INTERNET-DRAFT                                              TRILL: ESADI

      LSP number zero - zero: A Link State PDU with fragment number equal to
                       zero.

      PDU -

      PDU:             Protocol Data Unit.

      TRILL switch - an 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 Considerations IANA-related terms such as "IETF Review" as are to be
   interpreted as described in [RFC5226].

INTERNET-DRAFT                                              TRILL: ESADI

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 a separate 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 in a single database with a field in each record
   indicating the Data Label to which it applies applies, or it could be a
   separate database per Data Label.
   But  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 calculations, so there is no reason for pseudo-
   nodes
   pseudonodes in ESADI and none are created (Pseudo-nodes created.  (Pseudonodes [IS-IS] are
   a construct for optimizing routing calculations.)  Furthermore, there
   may be a requirement for a
   relatively large amount of ESADI data will have to be
   distributed through distributed,
   under some circumstances, using ESADI which might take mechanisms; this would require
   a large number of ESADI-
   LSP 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 [FS-LSP] [RFC7356] (see also
   Section 6).  This allows up to 2**16 fragments but does not support
   link state data associated with
   pseudo-nodes. pseudonodes.

   After the TRILL header, Header, ESADI packets have an inner Ethernet header
   with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All-
   ESADI-RBridges"),
   "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
   payload, as shown in Figure 1.

INTERNET-DRAFT                                              TRILL: ESADI

                     +--------------------------------+
                     |          Link Header           |
                     +--------------------------------+
                     |       TRILL Data Header        |
                     +--------------------------------+
                     |   Inner Ethernet Addresses     |
                     +--------------------------------+
                     |           Data Label           |
                     +--------------------------------+
                     |       L2-IS-IS Ethertype       |
                     +--------------------------------+
                     |         ESADI Payload          |
                     +--------------------------------+
                     |          Link Trailer          |
                     +--------------------------------+

                   Figure 1. 1: TRILL ESADI Packet Overview
   TRILL ESADI packets sent on an Ethernet link are structured as shown
   below.
   in Figure 2.  The outer VLAN tag will not be present if it was not
   included by the Ethernet port that sent the packet.

INTERNET-DRAFT                                              TRILL: ESADI

   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. (cont.)   | Origin RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Origin RBridge MAC Address continued (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 next-hop RBridge.  The VLAN for the Outer.VLAN
   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 field bit will be
   one one, unless the ESADI PDU was unicast, in which case
   the M field 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

INTERNET-DRAFT                                              TRILL: ESADI the RBridge originating the ESADI packet, packet -- for example, any
   of its port MAC addresses if it has any Ethernet ports, ports -- and each
   ESADI RBridge MUST use the same Inner.MacSA for all of the ESADI
   packets that
   RBridge it originates.

   TRILL ESADI packets sent on a PPP link are structured as shown below in
   Figure 3 [RFC6361].

   PPP Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PPP = TNP (TRILL data) 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. (cont.)   | Origin RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Origin RBridge MAC Address continued (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

2.1

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
   "data reachable" from it (see Section 2 of [RFC7180]) and are running

INTERNET-DRAFT                                              TRILL: ESADI
   ESADI for that Data Label.  No "routing" calculation (least cost (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 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 TRILL ESADI packet.  Thus, ESADI packets
   are transparently tunneled through transit RBridges.

2.2

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.

   Participation

   A participation announcement in a VLAN scoped ESADI instance is through
   generated by setting a flag bit in the Interested VLANs sub-TLV sub-TLV, and
   an announcement for an FGL scoped ESADI instance is through generated by
   setting a flag bit in the Interested Labels sub-TLV [RFC7176]. (See [RFC7176] (see
   Section 7.1)

2.3 7.1).

2.3.  ESADI Payloads

   TRILL ESADI packet payloads are structured like IS-IS Extended
   Level 1 Circuit Scoped Scope (E-L1CS) LSP, CSNP, and PSNP PDUs [FS-LSP], [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
   one octet 1-octet unsigned "confidence" "Confidence" rating in the range 0-254
   (see

INTERNET-DRAFT                                              TRILL: ESADI 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. 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 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.

INTERNET-DRAFT                                              TRILL: ESADI

3.  ESADI DRB (Designated RBridge) Determination

   Because ESADI does no adjacency announcement or routing, the ESADI-
   DRB
   ESADI-DRB never creates a pseudonode. But  However, a DRB (Designated RBridge
   [RFC7177]) [RFC7177] is
   still needed for ESADI-LSP synchronization by issuing to issue ESADI-CSNP PDUs and responding respond to ESADI-PSNP PDUs. 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 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 (1) are (1) data reachable from
   RB1 [RFC7180], [RFC7180] and (2) are 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 tie breaking tiebreaking, and there is no "Port ID".

INTERNET-DRAFT                                              TRILL: ESADI

4.  ESADI PDU processing Processing

   Data Label X ESADI neighbors are usually not connected directly by a
   physical link, 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.  There are  The only ESADI-
   LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI.
   ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDUs.  In
   particular, there are no Hello or MTU PDUs PDUs, because ESADI does not
   build a topology, does not do any routing calculations, and does not
   determine MTU, using MTU.  Instead, ESADI uses the campus Sz. (Sz is distribution trees and the TRILL Sz
   campus wide minimum link MTU determined by the core TRILL IS-IS (see
   [RFC6325] and [RFC7180]).)

4.1 [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 unicast, because on the typical physical link
   for which IS-IS was designed (commonly a piece of multi-access
   Ethernet cable) cable), any frame made the link busy for that frame time. But
   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, packet as described in Section 2 above, except as
   follows:

   o  On an Ethernet link, in the Outer outer Ethernet Header header the Outer.MacDA
      is the unicast address of the next hop next-hop RBridge.

   o  In the TRILL header, Header, the M bit is set to zero and the Egress
      Nickname is the nickname of the destination RBridge.

   To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is
   replaced with the following:

   "4.6.2.2.

   4.6.2.2.  TRILL ESADI Packets

      If M=1, 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 (1) interested in the
      specified VLAN or Fine Grained Label fine-grained label [RFC7172], (2) the forwarding
      RBridge implements the TRILL ESADI protocol, and (3) ESADI is
      enabled for that the specified VLAN or Fine Grained

INTERNET-DRAFT                                              TRILL: ESADI

      Label, fine-grained label, then the
      inner frame is decapsulated and provided to that local ESADI
      protocol.

      If M=0 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 M = 0 and the egress
      nickname is that of the receiving RBridge 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 above; otherwise, it is discarded." 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

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 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 normally (see [RFC6325]
   and [RFC7180] for discussions of Sz and MTU.) 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).

   A priority bit to indicate that an LSP fragment should be flooded
   with high priority is provided by [FS-LSP]. [RFC7356].  This bit SHOULD be set
   on ESADI-LSP fragment zero because it is important that the ESADI
   Parameters
   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.

INTERNET-DRAFT                                              TRILL: ESADI

4.3

4.3.  General Receipt of ESADI PDUs

   In contrast with layer 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, 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

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 [FS-LSP]. [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. So  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
   nicknames, if it holds more than one) one), such as ( 2000 * nickname /
   2**16 ) milliseconds 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  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
   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

              minimumLSPTimeInterval

          minimumLSPTransmissionInterval * Random (Jitter) / 100

INTERNET-DRAFT                                              TRILL: ESADI

   (where minimumLSPTimeInterval, 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 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
   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.

INTERNET-DRAFT                                              TRILL: ESADI

5.  End Station Addresses

   The subsections below discuss end station address considerations in
   the context of ESADI.

5.1

5.1.  Learning Confidence Level

   The confidence 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
   information via the ESADI protocol with a high confidence, Confidence, so it
   would be used in preference to any alternative learning from data
   observation.

5.2

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 time out 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 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

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

INTERNET-DRAFT                                              TRILL: ESADI
   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 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 rule, such as always "always encapsulate to the egress with the
   lowest System ID, 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, load-spreading, even if there were
   multiple different ingress RBridges and/or different MAC addresses
   with the same reachability.  [RFC6325] also 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.

   This update to [RFC6325] avoids these potential difficulties by
   requiring that RB0 to use one of the following two policies: (1) only
   encapsulate to one egress RBridge for any particular MAC and label label,
   but to select that egress pseudo-randomly pseudorandomly, based on the topology
   including
   (including MAC reachability reachability) or (2) if it RB0 will not be disturbed by
   the returning TRILL Data packets showing the same MAC and or by label flip-
   flopping
   flip-flopping between different ingresses, it RB0 may use ECMP.
   Assuming multiple ingress RBridges and/or multiple MAC and label
   addresses, strategy 1 should result in load spreading load-spreading without address flip-
   flopping
   flip-flopping, while strategy 2 will produce better load spreading 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 duplicates, then RB2
      MUST

INTERNET-DRAFT                                              TRILL: ESADI adopt one of the following two strategies:

      1. In a pseudo-random 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 attached, and send all traffic
         for the destination MAC and VLAN (or FGL [RFC7172]) to that
         egress.  This pseudo-random pseudorandom choice need only be changed when
         there is a change in campus topology or MAC attachment
         information.  Such
         pseudo-random pseudorandom selection will, over a
         population of ingress RBridges, probabilistically spread
         traffic over the possible egress RBridges.  Reasonable inputs
         to the pseudo-random 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 pseudo-
         random pseudorandom function.

         As an example of such a pseudo-random 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."

INTERNET-DRAFT                                              TRILL: ESADI

6.  ESADI-LSP Contents

   The only PDUs used in ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI-
   PSNP
   ESADI-PSNP PDUs.  Currently, the contents of an ESADI-LSP consists consist of
   zero or more MAC Reachability 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 [FS-LSP],
   [RFC7356], the Type and Length fields in the TLVs are 16-bit.

   This section specifies the format for the ESADI parameter data Parameter APPsub-TLV,
   gives the reference for the ESADI MAC Reachability 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 Inner.VLAN, or
   1470 minus 28 bytes (1442 bytes) if it has an Inner.FGL.  But  However, if
   an ESADI-
   LSP 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.)

6.1

6.1.  ESADI Parameter Data

   The figure below

   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
   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 data Parameter APPsub-TLV in non-zero
   ESADI-LSP fragments are ignored.

INTERNET-DRAFT                                              TRILL: ESADI

               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               | Type                          |   (2 bytes)
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               | Length                        |   (2 bytes)
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |R| Priority    |                   (1 byte)
               +-+-+-+-+-+-+-+-+
               | CSNP Time     |                   (1 byte)
               +-+-+-+-+-+-+-+-+
               | Flags         |                   (1 byte)
               +---------------+
               | Reserved for expansion            (variable)
               +-+-+-+-...

                   Figure 4. 4: ESADI Parameter APPsub-TLV

   Type: set Set to ESADI-PARAM subTLV sub-TLV (TRILL APPsub-TLV type 0x0001).
      Two
      bytes bytes, because this APPsub-TLV appears in an Extended extended TLV [FS-LSP].
      [RFC7356].

   Length: Variable Variable, with a minimum of 3 3, but must fit within the ESADI
      packet.  This field is encoded as an unsigned integer in network
      byte order [FS-LSP]. [RFC7356].

   R: A reserved bit that MUST be sent as zero and ignored on receipt.

   Priority: The Priority field gives 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 seven-bit 7-bit integer with the larger magnitude indication indicating
      higher priority.  It defaults to 0x40 for an RBridge participating
      in ESADI for which it has not been configured.

   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 EASDI-CSNP 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
      instance, as follows:

                     0   1   2   3   4   5   6   7
                  +---+---+---+---+---+---+---+---+
                  | UN|           RESV            |
                  +---+---+---+---+---+---+---+---+

      The UN flag indicates that the RBridge originating the ESADI-
         LSP, ESADI-LSP,
      including this ESADI Parameter Data, parameter data, will accept and properly
      process ESADI PDUs sent by TRILL unicast (see Section

INTERNET-DRAFT                                              TRILL: ESADI 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
      Parameters Parameter
      APPsub-TLV may have additional information.  A receiving ESADI
      RBridge ignores any additional data here here, unless it implements
      such future expansion(s).

6.2 MAC Reachability

6.2.  MAC-Reachability TLV

   The primary information in TRILL ESADI-LSP PDUs consists of MAC
   Reachability
   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,
   Appointed Forwarder, along with the one octet 1-octet unsigned Confidence in
   this information with a value in the range 0-254.  If such a TLV is
   received containing a confidence Confidence of 255, it is treated as if the
   confidence
   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
   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.

6.3

6.3.  Default Authentication

   The Authentication TLV may be included in ESADI PDUs [RFC5310] [IS-
   IS].
   [IS-IS].  The default for ESADI PDU Authentication 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, by default, 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

INTERNET-DRAFT                                              TRILL: ESADI 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 above algorithm above, HMAC-SHA256 is as described in [FIPS180] [RFC6234] and
   [RFC6234], and "TRILL ESADI" is the eleven byte 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.

INTERNET-DRAFT                                              TRILL: ESADI

7.  IANA Considerations

   IANA allocation and registry considerations are given below.  Three
   new sub-registries are have been created in the TRILL Parameters "Transparent
   Interconnection of Lots of Links (TRILL) Parameters" registry located
   at http://www.iana.org/assignments/trill-parameters, <http://www.iana.org/assignments/trill-parameters> -- two in
   Section 7.1 and one in Section 7.2, 7.2 -- and various code points have
   been assigned.

7.1

7.1.  ESADI Participation and Capability Flags

   IANA Action 1:

      IANA is requested to create has created the following new sub-registry called "Interested
      VLANs Flag Bits" in the TRILL Parameters "Transparent Interconnection of Lots of
      Links (TRILL) Parameters" registry.

      Sub-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], [This document] [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              This document              [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 (as immediately above assigns above) assigned
      bit 3 as the ESADI Participation bit in the Interested VLANs and
      Spanning Tree Roots Sub-TLV. 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 is requested to create has created the following new sub-registry called "Interested
      Labels Flag Bits" in the TRILL Parameters "Transparent Interconnection of Lots of
      Links (TRILL) Parameters" registry.

INTERNET-DRAFT                                              TRILL: ESADI

      Sub-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].

         References: [RFC7176], [this document] [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              This document              [RFC7357]
       4-7     -     Unassigned

      The creation of this sub-registry as (as immediately above assigns above) assigned
      bit 3 as the ESADI Participation bit in the Interested Labels and
      Spanning Tree Roots Sub-TLV. 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

7.2.  TRILL GENINFO TLV

   IANA Action 3:

      IANA is requested to allocate has allocated the IS-IS Application Identifier TBD
      [1 suggested] 1 under the
      Generic Information TLV (#251) [RFC6823] for TRILL.

   IANA Action 4:

      IANA is requested to create has created a subregistry sub-registry in the TRILL Parameters
   Registry "Transparent
      Interconnection of Lots of Links (TRILL) Parameters" registry as
      follows:

INTERNET-DRAFT                                              TRILL: ESADI

      Sub-Registry:

         Sub-registry:  TRILL APPsub-TLV Types under IS-IS TLV #251 251
                        Application Identifier #TBD 1

         Registration Procedures: IETF Review with additional
            requirements on the documentation of the use being
            registered as specified in Section 7.2 of <this
            document>. [RFC7357].

         Note: Types greater than 255 are only usable in contexts
         permitting a type larger than one byte, such as Extended extended TLVs [FS-LSP].
         [RFC7356].

         Reference: <this RFC> [RFC7357]
                Type      Name              Reference
             ----------  --------          -----------
                     0   Reserved          <this RFC>          [RFC7357]
                     1   ESADI-PARAM       <this RFC>       [RFC7357]
                 2-254   Unassigned        <this RFC>        [RFC7357]
                   255   Reserved          <this RFC>          [RFC7357]
             256-65534   Unassigned        <this RFC>        [RFC7357]
                 65535   Reserved          <this RFC>          [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], [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 FS-LSPs [FS-LSP]. 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 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  Thus, these I and V flags MUST be
   zero; however, if either or both is are one, the space that should be
   taken by
   and an IPv4 and/or IPv6 address respectively address, respectively, is skipped over
   and ignored.  Furthermore, the use of multi-level multilevel IS-IS is an obvious
   extension for TRILL [MultiLevel] [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 security considerations related to ESADI and the ESADI parameters Parameter
   APPsub-TLV, see Section 8.

INTERNET-DRAFT                                              TRILL: ESADI

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 Layer 2 authenticated
   registration using cryptographically based EAP (Extensible
   Authentication Protocol [RFC3748]) methods via [802.1X]).  The
   combination of these techniques can cause EASDI 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 it is not necessary to authenticate
   ESADI PDUs despite using authenticated registration is used
   for end stations stations, because of a significant threat of forged packets
   on end station
   links when links, but it is not necessary to authenticate ESADI
   PDUs because that threat is not present for inter-RBridge trunks.
   For
   example 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  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 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, security considerations, see [RFC6325].

8.1

8.1.  Privacy Considerations

   The address reachability information distributed by ESADI has
   substantial privacy considerations under many, but not all,
   circumstances.

INTERNET-DRAFT                                              TRILL: ESADI

   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, be revealing of their users. 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.

   However, records of MAC attachment, including attachment that include a modest amount of
   history, perhaps a few days days' worth, can be useful in managing a
   network and troubleshooting network problems.  It might, in some
   cases, also be legally required required, or required for billing purposes or
   the like.

   Network operators should seek a reasonable balance between these
   competing considerations 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.

INTERNET-DRAFT                                              TRILL: ESADI

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.

   This document was produced with raw nroff. All macros used were
   defined in the source file.

INTERNET-DRAFT                                              TRILL: ESADI

10.  References

10.1.  Normative references 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)", United States of American, National Institute of Science
              Standards and Technology, Federal Information Processing
              Standard (FIPS) 180-4, March 2012,
         http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf

   [FS-LSP] - Ginsberg, L., S. Previdi, Y. Yang, "IS-IS Flooding Scope
         LSPs", draft-ietf-isis-fs-lsp, in RFC Editor's queue. <http://csrc.nist.gov/
              publications/fips/fips180-4/fips-180-4.pdf>.

   [IS-IS] - International Organization for Standardization,
         "Intermediate system    ISO/IEC 10589:2002, Second Edition, "Information
              technology -- Telecommunications and information exchange
              between systems -- Intermediate System to Intermediate system
              System intra-domain routeing information exchange protocol
              for use in conjunction with the protocol for providing the
              connectionless-mode Network
         Service network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 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.

   [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

INTERNET-DRAFT                                              TRILL: ESADI
              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.

   [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, August 2014.

10.2.  Informative References

   [802.1X] -   IEEE 802.1, "IEEE Standard for Local and metropolitan area
         networks / Port-Based
              networks--Port-Based Network Access Control", IEEE Std
              Standard 802.1X-2010, 5 February 2010.

   [FNV] - G.      Fowler, L. G., Noll, K. Vo & L., Vo, K., and D. Eastlake, Eastlake 3rd, "The
              FNV Non-
         Cryptographic Non-Cryptographic Hash Algorithm", draft-eastlake-fnv, Work in
         progress. 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.

   [MultiLevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai,
         "Multilevel TRILL (Transparent Interconnection of Lots of
         Links)", draft-perlman-trill-rbridge-multilevel, work in
         progress.

INTERNET-DRAFT                                              TRILL: ESADI

   [VLANmapping] -
              Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani, A., Eastlake 3rd, D., Banerjee,
              A., and D. Eastlake, "RBridges: Dutt, "TRILL: Campus VLAN Label and Priority
              Regions",
         draft-ietf-trill-rbridge-vlan-mapping, work Work in progress.

INTERNET-DRAFT                                              TRILL: ESADI Progress, January 2014.

Appendix A: A.  Interoperability and Changes to [RFC6325] 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 appendix also discusses, for each change, the
   interoperability considerations should such simultaneous use occur.

A.1

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 Scoped Scope format (E-L1CS) specified in [FS-LSP]. [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 information carrying capacity than that of the E- L1CS format
   compared with the base IS-IS format.  It is
   anticipated that this greater carrying information-carrying capacity will be
   needed, under some circumstances, to carry end station addressing
   information or other similar address and reachability information that is
   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
   changes, and the PDU numbers change to 10, 11, and 12 [FS-LSP]. [RFC7356].  The
   use of different PDU numbers assures that a PDU will not be mis-
   parsed.
   mis-parsed.  Because of this, implementations of this document and
   implementations of [RFC6325] ESADI will discard each other's PDUs.
   Thus
   Thus, address reachability or other information distributed through
   either type of ESADI implementation will only be communicated to
   other implementations of the same type 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
   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] EASDI 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 non-communication between the two types of ESADI implementation
   implementations, although without the speed or security advantages
   of ESADI.

INTERNET-DRAFT                                              TRILL: ESADI

A.2

A.2.  Unicasting Changes

   Unicasting of ESADI PDUs is optionally supported 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

A.3.  Message Timing Changes and Suggestions

   The following timing relevant 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 EASDI 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

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 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 with 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 traffic-spreading will be be, and the less likely address
   flip-flopping problems are.

INTERNET-DRAFT                                              TRILL: ESADI

Appendix Z: Change History

   RFC Editor: Please delete this section before publication.

Z.1 From -00 to -01

   1. Add Section 6.3 "Default Authentication".

   2. Add "Acknowledgements" Section.

   3. Change requirement from "MAY" to "SHOULD" for an ESADI RBridge
      that is not DRB to send an ESADI-CSNP if it does not receive an
      ESADI-CSNP in long enough.

   4. Default CSNP Time was listed as 30 in one place and 40 in another.
      Change to uniformly specify 30.

   5. Update references to RFC 6326 to reference the 6326bis draft.

   6. Relax allocation criteria for TRILL APPsub-TLV type code points
      from Standard Action to IETF Review.

   7. Numerous Editorial changes.

Z.2 From -01 to -02

   1. Extend to cover FGL and well as VLAN and introduce the term "Data
      Label" to cover both.

   2. Expand number of LSP fragments to 2**16.

   3. Simplify neighbor detection to no longer require possession of
      ESADI-LSP zero.

   4. Add update to last sentence of Section 4.2.6 of [RFC6325].

   5. Update references for publication of RFCs 6822 and 6823.

   6. Additional minor changes.

INTERNET-DRAFT                                              TRILL: ESADI

Z.3 From -02 to -03

   1. Replace instances of "IS-IS and data unreachable" with just "data
      unreachable" as data unreachability implies IS-IS unreachability
      [RFC7180].

   2. With ESADI, there is just one virtual link on which all
      participating TRILL switches are adjacent. Thus, all of the useful
      ESADI-LSPs in an ESADI link state database are originated by a
      station on this virtual link. To avoid overworking the ESADI DRB
      on the link, ESADI-LSPs sent by a reachable TRILL switch in
      response to an ESADI-PSNP should be sent by the TRILL switch
      originating those EASDI-LSPs.

   3. Re-organize material on sending and receiving ESADI PDUs into more
      smaller subsections that cover all the different circumstances.

   4. Substantially expand Security Considerations section.

   5. Numerous editorial changes.

Z.4 From -03 to -04

   1. Change to using Extended Level 1 Circuit Scope [FS-LSP] for EASDI-
      LSP, ESADI-CSNP, and ESADI-PSNP PDUs.

   2. Update references to RFC 6327 to the rfc6327bis draft.

   3. Sort Informational References RFCs in numeric order.

   4. Add Appendix A: summary of changes to [RFC6325].

   5. Minor editing changes.

Z.5 From -04 to -05

   1. Expand Appendix A to be more complete and precise.

   2. Add L2-IS-IS Ethertype to Figure 1 so figure and text match.

   3. For clarification, add an example pseudo-random function to the
      new text in Section 5.3.

   4. Eliminate possible unicasting of PSNPs.

INTERNET-DRAFT                                              TRILL: ESADI

   5. Provide for staggered delay for non-originators of ESADI-LSP
      fragments in response to requests for such fragments by CSNP and
      PSNP messages.

   6. In Section 7.2, cover inclusion in FS-LSPs as permitted by [FS-
      LSP].

   7. Some editing changes including expanding "MAC&label".

Z.6 From -05 to -06

   1. In Section 4.3: "a an adjacent" -> "an adjacent".

   2. In Section 4.4: "( 100 - Random (Jitter) )" -> Random(Jitter)".

   3. Add one Acknowledgement.

Z.7 From -06 to -07

   Update based on GENART and IANA reviews:

    1. Update and extend the first paragraph of Section 1.1 and items 2
       and 3 in Appendix A with particular attention to how this
       document updates RFC 6325 and backwards compatibility.

    2. Minor edits to the first part of Section 2 to clarify "pseudo-
       nodes" and the use of common components inside an RBridge
       implementation of the independent ESADI instances.

    3. Add references to [RFC7172] inside Figures 2 and 3.

    4. Section 2.1, minor edits for clarity.

    5. Section 2.2, "is ignored" -> "MUST be ignored".

    6. Section 3, minor edit to clarify DRB election references.

    7. Explain source of "1470 bytes" in Section 6.

    8. Add new second paragraph to Section 8 to clarify cases where you
       might want authenticated end-station registration but would not
       need ESADI-PDU authentication.

    9. Substantial editorial changes to the IANA Considerations (Section

INTERNET-DRAFT                                              TRILL: ESADI

       7), based on IANA review, to clarify the requested IANA actions.

   10. Update Acknowledgements.

   11. Other minor editorial changes.

Z.8 From -07 to -08

   Update primarily based on IESG review

   1. Re-write of Appendix A to add substantial interoperability
      considerations material.

   2. Addition of Privacy Considerations subsection to Security
      Considerations.

   3. Addition of references to [RFC5310] in connection with
      authentication of ESADI PDUs.

   4. Update draft references due to RFC publications and add some
      Acknowledgements.

   5. Minor editorial changes.

Z.9 From -08 to -09

   1. Fix a few typos.

   2. Clarify encoding of Length field in Section 6.1.

   3. Clarify some wording in Section 1, list item 2.

INTERNET-DRAFT                                              TRILL: ESADI will be.

Authors' Addresses

   Hongjun Zhai
   ZTE Corporation
   68 Zijinghua Road
   Nanjing 200012
   China
   Phone: +86-25-52877345
   Email:
   EMail: zhai.hongjun@zte.com.cn

   Fangwei Hu
   ZTE Corporation
   889 Bibo Road
   Shanghai 201203
   China
   Phone: +86-21-68896273
   Email:
   EMail: hu.fangwei@zte.com.cn

   Radia Perlman
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA 95054-1549
   EMC
   2010 256th Ave. NE, #200
   Bellevue, WA  98007
   USA

   Phone: +1-408-765-8080
   Email:
   EMail: Radia@alum.mit.edu

   Donald Eastlake 3rd
   Huawei Technologies
   155 Beaver Street
   Milford, MA  01757
   USA
   Phone: +1-508-333-2270
   Email:
   EMail: d3e3e3@gmail.com

   Olen Stokes
   Extreme Networks
   Pamlico Building One,
   2121 RDU Center Drive, Suite 100
   3306 East 300
   Morrisville, NC Hwy 54
   RTP, NC 27709  27560
   USA

   Email:
   EMail: ostokes@extremenetworks.com

INTERNET-DRAFT                                              TRILL: ESADI

Copyright and IPR Provisions

   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.