[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-hu-trill-rbridge-esadi) 00 01 02 03 04 05 06 07 08 09 RFC 7357

TRILL Working Group                                         Hongjun Zhai
INTERNET-DRAFT                                                Fangwei Hu
Intended status: Proposed Standard                                   ZTE
Updates: 6325                                              Radia Perlman
                                                              Intel Labs
                                                         Donald Eastlake
                                                                  Huawei
                                                             Olen Stokes
                                                        Extreme Networks
Expires: August 21, 2013                               February 22, 2013


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



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 multi-pathing of both unicast and
   multicast traffic.  Devices that implement the TRILL protocol are
   called RBridges (Routing Bridges) or TRILL Switches.

   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 addresses and
   other information to TRILL switches pariticipating in ESADI for the
   relevant Data Label.  This document updates RFC 6325, specifically
   the documentation of the ESADI protocol.




Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the TRILL working group mailing list: <rbridge@postel.org>.

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






H. Zhai, et al                                                  [Page 1]


INTERNET-DRAFT                                              TRILL: ESADI


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

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











































H. Zhai, et al                                                  [Page 2]


INTERNET-DRAFT                                              TRILL: ESADI


Table of Contents

      1. Introduction............................................4
      1.1 Content and Precedence.................................5
      1.2 Terminology............................................5
      1.3 Acknowledgements.......................................5

      2. ESADI Protocol Overview.................................7
      2.1 ESADI Virtual Link....................................10
      2.2 ESADI Neighbor Determination..........................11
      2.3 ESADI Payloads........................................11

      3. ESADI DRB Determination................................13

      4. ESADI PDU processing...................................14
      4.1 Sending of ESADI PDUs.................................15
      4.2 Receipt of ESADI PDUs.................................16

      5. End Station Addresses..................................17
      5.1 Learning Confidence Level.............................17
      5.2 Forgetting End Station Addresses......................17
      5.3 Duplicate MAC Address.................................17

      6. ESADI-LSP Contents.....................................20
      6.1 ESADI Parameter Data..................................20
      6.2 MAC Reachability TLV..................................21
      6.3 Default Authentication................................22

      7. IANA Considerations....................................23
      7.1 ESADI Participation and Capability Flags..............23
      7.2 TRILL GENINFO TLV.....................................24

      8. Security Considerations................................26

      Normative references......................................27
      Informative References....................................28

      Appendix Z: Change History................................29
      Z.1 From -00 to -01.......................................29
      Z.2 From -01 to -02.......................................29

      Authors' Addresses........................................30










H. Zhai, et al                                                  [Page 3]


INTERNET-DRAFT                                              TRILL: ESADI


1. Introduction

   The IETF 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 multi-pathing of both unicast and
   multicast traffic.  TRILL accomplishes this with the IS-IS
   (Intermediate System to Intermediate System) [IS-IS] [RFC1195]
   [rfc6326bis] 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) and FGLs (Fine Grained Labels,
   [RFCfgl]).  Devices that implement TRILL are called TRILL switches or
   RBridges (Routing Bridges).

   There are five ways an RBridge can learn end station addresses, as
   described in Section 4.8 of [RFC6325].  The ESADI (End Station
   Address Distribution Information) protocol is an optional Data Label
   scoped way RBridges can communicate, with each other, information
   such as end station addresses and their RBridge of attachment. An
   RBridge 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 RBridges that are
   running ESADI for that Data Label. (In the future, ESADI may also be
   used for additional types of information.)

   By default, TRILL switches with connected end stations learn
   addresses from the data plane when ingressing and egressing native
   frames. The ESADI protocol's potential advantages over data plane
   learning include the following:

   1. Security advantages: (1a) 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]). (1b) 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 stations MAC (Media Access Control) addresses.  If an end
      station is unplugged from one RBridge and plugged into another,
      frames ingressed for that MAC address can be black holed.  They
      can be sent just to the older egress RBridge that the end station
      was connected to until cached address information at some remote
      ingress RBridge times out, possibly for tens of seconds or more
      [RFC6325].




H. Zhai, et al                                                  [Page 4]


INTERNET-DRAFT                                              TRILL: ESADI


   MAC address reachability information, some ESADI parameters, and
   optionally authentication information are carried in ESADI packets
   rather than in the TRILL IS-IS protocol.  As described 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
   RBridges through TRILL IS-IS but only to RBridges advertising ESADI
   participation for the Data Label in which those end stations occur.




1.1 Content and Precedence

   This document updates [RFC6325], the TRILL basic specification,
   essentially replacing the description of the ESADI protocol, and
   prevails over [RFC6325] where they conflict.

   Section 2 is the ESADI protocol overview. Section 3 specifies ESADI
   DRB state.  Section 4 discusses the processing of ESADI PDUs. Section
   5 discusses interaction with other modes of end station address
   learning. And Section 6 describes the ESADI-LSP contents.




1.2 Terminology

   This document uses the acronyms defined in [RFC6325] and the
   following phrase:

      Data Label - VLAN or FGL.

      FGL - Fine Grained Lable [RFCfgl]

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

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




1.3 Acknowledgements

   The authors thank the following, listed in alphabetic order, for
   their suggestions and contributions:



H. Zhai, et al                                                  [Page 5]


INTERNET-DRAFT                                              TRILL: ESADI


      Somnath Chatterjee and Thomas Narten

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
















































H. Zhai, et al                                                  [Page 6]


INTERNET-DRAFT                                              TRILL: ESADI


2. ESADI Protocol Overview

   ESADI is a Data Label scoped way for 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 protocol from the TRILL IS-IS implemented by all
   RBridges in a campus.  There is a separate ESADI instance for each
   Data Label (VLAN or FGL). In essence, for each 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 being specified in [RFC6822].) It is an implementation
   decision how independent the multiple ESADI instances at an RBridge
   are. 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 or could be a separate database per Data Label. But
   the ESADI update process operates separately for each ESADI instance
   and independently from the TRILL IS-IS update process.

   ESADI does no routing so there is no reason for pseudo-nodes in ESADI
   and none are created. This allows re-purposing one byte of the LSP ID
   field to expand the number of possible fragments from 2**8 to 2**16.
   In [IS-IS], the "LSP ID" field is 8 bytes. (Actually it is the length
   of System ID plus 2, but we will assume a 6-byte System ID.)  The top
   6 bytes of the LSP ID are the router's System ID, the next byte is
   non-zero for pseudo-nodes, and the bottom byte is the fragment
   number. In ESADI-LSPs, there is just the System ID followed by two
   bytes of fragment number.  The same change is made to the LSP ID
   field of the Remaining Lifetime TLV which is used in EASDI-CSNP and
   ESADI-PSNP. The bottom byte of the ESADI CSNP/PSNP Header Source ID
   is always zero.

   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.














H. Zhai, et al                                                  [Page 7]


INTERNET-DRAFT                                              TRILL: ESADI


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

                   Figure 1. TRILL ESADI Packet Overview

   TRILL ESADI packets sent on an Ethernet link are structured as shown
   below.  The outer VLAN tag will not be present if it was stripped by
   an Ethernet port out of which the packet was sent.

































H. Zhai, et al                                                  [Page 8]


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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = C-Tag      0x8100 | Outer.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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 while, 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
   information will always 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
   will be one unless the ESADI PDU was unicast as discussed below, in
   which case the M field 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


H. Zhai, et al                                                  [Page 9]


INTERNET-DRAFT                                              TRILL: ESADI


   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 RBridge MUST use the same Inner.MacSA for all of the ESADI
   packets that RBridge originates.

   TRILL ESADI packets sent on a PPP link are structured as shown below
   [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) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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 ESADI Virtual Link
   All transit 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 other RBridges in the
   campus running ESADI for that Data Label. No "routing" computation or
   routing decisions ever have to be performed by ESADI. An ESADI


H. Zhai, et al                                                 [Page 10]


INTERNET-DRAFT                                              TRILL: ESADI


   RBridge merely transmits the ESADI packets it originates on this
   virtual link as described for TRILL Data packets in [RFC6325] and
   [RFCfgl]. 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 for the Data Label of an
   ESADI packet do not decapsulate or locally process any TRILL ESADI
   packets they receive.  Thus the 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 ESADI neighbors are by logically examining the TRILL IS-IS link
   state database for RBridges that are data and IS-IS reachable from
   RB1 (see Section 2 of [ClearCorrect]) and are announcing their
   participation in Data Label X ESADI. When an RBridge RB2 becomes IS-
   IS or 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
   potential neighbor and also dropped from any ESADI instances. And
   when RB2 is no longer announcing participation in Data Label X ESADI,
   it ceases to be a neighbor for the Data Label X ESADI instance, these
   considerations being Data Label scoped. Because of these mechanisms,
   there are no "Hellos" sent in ESADI.

   Participation announcement in a VLAN scoped ESADI instance is through
   setting a flag bit in the Interested VLANs sub-TLV and announcement
   for an FGL scoped ESADI instance is through setting a flag bit in the
   Interested Labels sub-TLV [rfc6326bis]. (See Section 7.1)




2.3 ESADI Payloads

   TRILL ESADI packet payloads are structured like IS-IS PDUs, 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 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 possibly authenticaiton information
   (see Section 6.3) are included. Future uses of ESADI may distribute


H. Zhai, et al                                                 [Page 11]


INTERNET-DRAFT                                              TRILL: ESADI


   other types of 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 is ignored.










































H. Zhai, et al                                                 [Page 12]


INTERNET-DRAFT                                              TRILL: ESADI


3. ESADI DRB Determination

   Because ESADI does no adjacency announcement or routing, the ESADI-
   DRB never creates a pseudonode. But a DRB is still needed for LSP
   synchronization by issuing ESADI-CSNP PDUs and responding to ESADI-
   PSNP PDUs.

   Generally speaking, the DRB election on the ESADI virtual link (see
   Section 2.1) operates similarly to a TRILL IS-IS broadcast link
   [RFC6327] 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 (1) are data and IS-IS reachable from RB1
   [ClearCorrect], 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 System ID, comparing fields as unsigned integers with
   the larger magnitude considered higher priority. "SNPA/MAC address"
   is not considered and there is no "Port ID".

































H. Zhai, et al                                                 [Page 13]


INTERNET-DRAFT                                              TRILL: ESADI


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 on the virtual link.  There are only ESADI-LSP, ESADI-CSNP
   and ESADI-PSNP PDUs used in ESADI. In particular, there are no Hello
   or MTU PDUs because ESADI does not build a topology and does not do
   any routing.

   In IS-IS, PDU multicasting is normal on a local link and no effort is
   made to optimize to unicast because under the original conditions
   when IS-IS was designed (commonly a piece of multi-access Ethernet
   cable) any frame made the link busy for that frame time. But in ESADI
   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).

   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 the forwarding RBridge is (1) interested in the specified VLAN
      or Fine Grained Label, (2) implements the TRILL ESADI protocol,
      and (3) ESADI is enabled for that VLAN or Fine Grained Label, 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
      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].

   Section 4.1 describes the sending of ESADI PDUs. Section 4.2 covers
   the receipt of ESADI PDUs.


H. Zhai, et al                                                 [Page 14]


INTERNET-DRAFT                                              TRILL: ESADI


4.1 Sending of ESADI PDUs

   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(Inner.VLAN/Inner.FGL) 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 ESDAI instance; however, if a
   larger payload is received, it is processed normally. (See [RFC6325]
   and [ClearCorrect] for discussions of Sz and MTU.)

   An ESADI instance does not transmit any ESADI PDUs if it has zero
   EASDI neighbors. When an ESADI instance sees that it has a new
   neighbor, its self-originated EASDI-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 the other ESADI instances should
   wait an interval of time before sending the ESADI-LSP to a new
   neighbor.  The interval time value is up to the device implementation
   and is subject to the usual IS-IS timing jitter. One suggestion is
   that the interval time can be assigned a random value with a range
   based on the ESADI instace DRB priority such ( 2 * (127 - priority) /
   128) seconds.

   If the ESADI instance believes it is DRB, it multicasts an ESADI-CSNP
   periodically (thrice per CSNP Time, see Section 6.1) to keep the link
   state database synchronized among its neighbors on the virtual link.
   After receiving an ESADI-PSNP PDU, the DRB will multicast the ESADI-
   LSPs requested by the ESADI-PSNP on the virtual link.

   The multi-hop TRILL multi-destination packet distribution with
   Reverse Path Forwarding Check will typically be less reliable than
   the single hop link-local LSP synchronization of TRILL IS-IS.
   Therefore, for LSP synchronization robustness, in addition to sending
   ESADI-CSNPs when it is 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 DRB for the ESADI instance, and
   o  it has not received or sent an ESADI-CSNP PDUs for the instance
      for the CSNP Time (see Section 6.1) of the DRB.

   In the case of receiving an ESADI-LSP with a smaller sequence number
   than the copy stored in the local EASDI Link State Database the local
   ESADI instance will also schedule to multicast the stored copy.



H. Zhai, et al                                                 [Page 15]


INTERNET-DRAFT                                              TRILL: ESADI


   The format of a unicast ESADI packet is the format of TRILL ESADI
   packet, 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.




4.2 Receipt of ESADI PDUs

   Because ESADI adjacency is in terms of System ID, all IS-IS PDU
   acceptance tests that check that the PDU is from an adjacent system
   instead check that the System ID is that of an ESADI neighbor and do
   not check either the source Inner or Outer SNPA/MAC.

   Because all data reachable ESADI RBridges participating for Data
   Label X are adjacent, when RB1 receives an ESADI-CSNP from RB2 and
   detects that it has ESADI-LSPs that RB2 is missing, it sets the
   transmission flag only for its own ESADI-LSPs that RB2 is missing.
   Missing ESADI-LSPs originated by other ESADI RBridges will be
   detected by those other ESADI RBridges.

   When receiving an ESADI-PSNP PDU, if the local ESADI instance is DRB,
   the ESADI-LSP PDUs requested by the ESADI-PSNP will be multicast on
   the virtual link.























H. Zhai, et al                                                 [Page 16]


INTERNET-DRAFT                                              TRILL: ESADI


5. End Station Addresses




5.1 Learning Confidence Level

   The confidence level mechanism 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 frames.  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, 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 TRILL ESADI protocol should
   be forgotten through changes in ESADI-LSPs. The time out 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
   inaccessible).

   If RBridge RBn participating in the TRILL ESADI protocol for Data
   Label X no longer wishes to participate in ESADI, it ceases to
   participate in ESADI by (1) clearing the ESADI participation bit in
   the appropriate Interested VLANs or Interested Lables 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 two occurances of the
   same MAC address with the same Data Label being advertised by two or
   more RBridges. The specification of how to handle this situation in
   [RFC6325] is updated by replacing the last sentence of the last
   paragraph of Section 4.2 of [RFC6325] as shown below to provide
   better traffic spreading while avoiding possible address flip-
   flopping.


H. Zhai, et al                                                 [Page 17]


INTERNET-DRAFT                                              TRILL: ESADI


   As background, assume some end station or set of end stations have
   two or more ports with the same MAC&VLAN with each port connected to
   different RBridges (RB1, RB2, ...) by separate links.  With ESADI,
   some other RBridge, RB0, can persistently see that MAC&VLAN connected
   to multiple RBridges. When RB0 ingresses a frame destined that
   MAC&VLAN, the current [RFC6325] text permits a wide range of
   behavior. In particular, it would permit RB0 to use some rule such as
   always send to the egress with the lowest System ID, which would put
   all of this traffic through one of the egress RBridges and one of the
   end station ports.  There would be no load spreading even if there
   were multiple different ingress RBridges and/or different MAC
   addresses. It also would also permit RB0 to send different traffic to
   different egresses by doing ECMP at a flow level, which would likely
   result in return traffic to RB0 from RB1, RB2, ... for the same
   MAC&VLAN. The resulting address flip-flopping could cause problems.
   This update to [RFC6325] avoids these potential difficulties by
   requiring RB0 to either (1) use only one egress for a particular
   MAC&VLAN but to select that egress pseudo-randomly based on the
   topology including MAC reachabilty or (2) if it will not be disturbed
   by the returning TRILL Data packets showing the same MAC&VLAN flip-
   flopping between different ingresses, it may use ECMP.  Assuming
   multiple ingress RBridges and/or multiple MAC addresses, stragegy 1
   should result in load spreading without address flip-floping while
   stragegy 2 will produce more uniform load spreading.

   OLD [RFC6325] 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] text:
      "...

      If confidences are also tied between the duplicates then RB2 MUST
      adopt one of the following two strategies:

      1. In a pseudo-random 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) to that egress. This
         pseudo-random choice need only be changed when there is a
         change in campus topology or MAC attachment information. Such
         pseudo-random selection will, over a population of ingress
         RBridges, probabilisticly spread traffic over the possible
         egress RBridges. Reasonable inputs to the pseudo-random
         selection are the ingress RBridge System ID and/or nickname,
         the VLAN or FGL, the destination MAC address, and a vector of


H. Zhai, et al                                                 [Page 18]


INTERNET-DRAFT                                              TRILL: ESADI


         the RBridges with connectivity to that MAC and VLAN. There is
         no need for different RBridges to use the same pseudo-random
         function.

      2. If RB2 supports ECMP and will not be disturbed by return
         traffic from the same MAC and VLAN (or FGL) coming from
         different ingress RBridges, then it MAY send traffic over 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."










































H. Zhai, et al                                                 [Page 19]


INTERNET-DRAFT                                              TRILL: ESADI


6. ESADI-LSP Contents

   The only PDUs used in ESADI are the Level 1 ESADI-LSP, ESADI-CSNP,
   and ESADI-PSNP PDUs. Currently, the contents of an ESADI-LSP consists
   of zero or more MAC Reachability TLVs, optionally an Authentication
   TLV, and exactly one ESADI parameter APPsub-TLV. Other data may be
   included in the future and, as in IS-IS, an ESADI instances ignores
   any TLVs or sub-TLVs it does not understand.

   This section specifies the format for the ESADI parameter data
   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 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. But if an ESADI-LSP number zero is received longer, it is
   still processed normally.




6.1 ESADI Parameter Data

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

                +-+-+-+-+-+-+-+-+
                | Type          |           (1 byte)
                +-+-+-+-+-+-+-+-+
                | Length        |           (1 byte)
                +-+-+-+-+-+-+-+-+
                |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 subTLV (TRILL APPsub-TLV type 1).


H. Zhai, et al                                                 [Page 20]


INTERNET-DRAFT                                              TRILL: ESADI


   Length: Set to 2 to 255.

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

   Priority: The Priority field gives the originating RBridge's priority
      for being DRB on the ESADI instance virtual link (see Section 2.1)
      for the Data Label in which the PDU containing the parameter data
      was sent. It is an unsigned seven-bit integer with larger
      magnitude indication 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 DRB on the ESADI
      virtual link, will send at least three EASDI-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|         Reserved          |
               +---+---+---+---+---+---+---+---+

         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. The
         remaining 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 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 as 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 one octet unsigned Confidence in
   this information with a value in the range 0-254. If such a TLV is
   received with a confidence of 255, it is treated as if the confidence
   was 254. (This is to assure that any received address information can


H. Zhai, et al                                                 [Page 21]


INTERNET-DRAFT                                              TRILL: ESADI


   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 encapsulated TRILL ESADI packet, only
   the Inner.VLAN or Inner.FGL tag indicates the Data Label to which the
   ESADI-LSP applies.




6.3 Default Authentication

   The Authentication TLV may be included in ESADI PDUs. The default for
   ESADI PDU Authentication is based on the state of TRILL IS-IS shared
   secret authentication for 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 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, ESADI PDUs originated
   by that TRILL switch are 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 above HMAC-SHA256 is as described in [FIPS180] [RFC6234] and
   "TRILL ESADI" is the eleven 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.












H. Zhai, et al                                                 [Page 22]


INTERNET-DRAFT                                              TRILL: ESADI


7. IANA Considerations

   IANA allocation and registry considerations are given below.




7.1 ESADI Participation and Capability Flags

   IANA is requested to allocate bit TBD [3 recommended] as the "ESADI
   Participation" bit in the Interested VLANs sub-TLV and the Interested
   Labels sub-TLVs [rfc6326bis]. If The ESADI Participation bit is a
   one, it indicates that the originating RBridge is participating in
   ESADI for the indicated VLAN(s) or FGL(s). In addition, IANA is
   requested to create two sub-registries in the TRILL Parameters
   Registry for such bits1 as follows:

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

      References: [rfc6326bis], This document

         Bit  Mnemonic  Description                      Reference
         ---  --------  -----------                      ---------
           0     M4     IPv4 Multicast Router Attached   [rfc6326bis]
           1     M6     IPv6 Multicast Router Attached   [rfc6326bis]
           2      -     available for allocation
           3     ES     ESADI Participation              This document
          4-15    -     (used for a VLAN ID)             [rfc6326bis]
         16-19    -     available for allocation
         20-31    -     (used for a VLAN ID)             [rfc6326bis]

















H. Zhai, et al                                                 [Page 23]


INTERNET-DRAFT                                              TRILL: ESADI


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

      References: [rfc6326bis], This document

         Bit  Mnemonic  Description                      Reference
         ---  --------  -----------                      ---------
           0     M4     IPv4 Multicast Router Attached   [rfc6326bis]
           1     M6     IPv6 Multicast Router Attached   [rfc6326bis]
           2     BM     Bit Map                          [rfc6326bis]
           3     ES     ESADI Participation              This document
          4-7     -     available for allocation




7.2 TRILL GENINFO TLV

   IANA is requested to allocate an IS-IS Application Identifier under
   the Generic Information TLV (#251) for TRILL [RFC6823] and to create
   a subregistry in the TRILL Parameters Registry for "TRILL APPsub-TLVs
   under IS-IS TLV #251 Application Identifier #TBD".  The initial
   contents of this subregistry are as follows:

             Type   Name                Reference
            ------ --------            -----------
                0  Reserved            <this RFC>
                1  ESADI-PARAM         <this RFC>
            2-254  Available           <this RFC>
              255  Reserved            <this RFC>

   TRILL APPsub-TLV Types 2 through 254 are available for allocation by
   IETF Review. The RFC causing such an allocation 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 TRILL IS-IS
   adjacencies, the IS-IS update process, and the decision process for
   TRILL IS-IS [IS-IS] [RFC1195] [RFC6327]. The TRILL Generic
   Information TLV MUST NOT be used in an IS-IS instance zero [RFC6822].

   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 is hereby assigned to the inclusion of an IPv4 and/or IPv6
   address via the I and V flags. Thus these flags MUST be zero;
   however, use of multi-level IS-IS is an obvious extension for TRILL


H. Zhai, et al                                                 [Page 24]


INTERNET-DRAFT                                              TRILL: ESADI


   [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 parameters
   APPsub-TLV, see Section 8.











































H. Zhai, et al                                                 [Page 25]


INTERNET-DRAFT                                              TRILL: ESADI


8. Security Considerations

   For general TRILL Security Considerations, see [RFC6325].

   More TBD















































H. Zhai, et al                                                 [Page 26]


INTERNET-DRAFT                                              TRILL: ESADI


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)", United States of American,
         National Institute of Science 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] - International Organization for Standardization,
         "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)", 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.

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

   [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
         and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
         6327, July 2011.

   [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent
         Interconnection of Lots of Links (TRILL) Protocol Control
         Protocol", RFC 6361, August 2011.

   [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising
         Generic Information in IS-IS", RFC 6823, December 2012.

   [ClearCorrect] - Eastlake, D., Zhang, M., Ghanwani, A., Manral, V.,
         A. Benerjee, "TRILL: Clarifications, Corrections, and Updates",


H. Zhai, et al                                                 [Page 27]


INTERNET-DRAFT                                              TRILL: ESADI


         draft-ietf-trill-clear-correct, in RFC Editor's queue.

   [rfc6326bis] - Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt,
         D., and A. Banerjee, "Transparent Interconnection of Lots of
         Links (TRILL) Use of IS-IS", draft-ietf-isis-rfc6326bis, work
         in progress.

   [RFCfgl] - Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt,
         "TRILL (Transparent Interconnection of Lots of Links): Fine-
         Grained Labeling", draft-ietf-trill-fine-labeling, work in
         progress.




Informative References

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

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

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

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












H. Zhai, et al                                                 [Page 28]


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 possesion of
      ESADO LSP zero.

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

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

   6. Additional minor changes.







H. Zhai, et al                                                 [Page 29]


INTERNET-DRAFT                                              TRILL: ESADI


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
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA 95054-1549 USA

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


   Donald Eastlake
   Huawei R&D USA
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com


   Olen Stokes
   Extreme Networks
   Pamlico Building One, Suite 100
   3306 East NC Hwy 54
   RTP, NC 27709 USA

   Email: ostokes@extremenetworks.com







H. Zhai, et al                                                 [Page 30]


INTERNET-DRAFT                                              TRILL: ESADI


Copyright and IPR Provisions

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

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





















H. Zhai, et al                                                 [Page 31]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/