TRILL Working Group                                         Hongjun Zhai
INTERNET-DRAFT                                                Fangwei Hu
Intended status: Proposed Standard                                   ZTE
Updates: 6325                                              Radia Perlman
                                                              Intel Labs
                                                         Donald Eastlake
                                                                  Huawei
Expires: October 10, 2012                                 April 11, 2012


                       TRILL: The ESADI Protocol
                 <draft-hu-trill-rbridge-esadi-04.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 the multi-pathing of both unicast
   and multicast traffic. Devices that implement the TRILL protocol are
   called RBridges (Routing Bridges) or TRILL Switches.

   The ESADI (End System Address Distribution Information) protocol is a
   VLAN (Virtual Local Area Network) scoped way that TRILL switches can
   communicate end station addresses to each other.  An RBridge
   announcing VLAN-x connectivity (normally a VLAN-x appointed
   forwarder) and running the TRILL ESADI protocol can receive remote
   address information and/or transmit local address information for
   VLAN-x to other such RBridges.  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.

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


H. Zhai, et al                                                  [Page 1]


INTERNET-DRAFT                                              TRILL: ESADI


   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

      2. ESADI Protocol Overview.................................6
      3. ESADI DRB State.........................................8

      4. ESADI PDU processing....................................9
      4.1 Sending of ESASI PDUs..................................9
      4.2 Receipt of ESADI PDUs.................................10

      5. ESADI-LSP Contents.....................................11
      5.1 ESADI Parameter Data..................................11
      5.2 MAC Reachability TLV..................................12

      6. IANA Considerations....................................13
      6.1 ESADI Participation Flag..............................13
      6.2 TRILL GENAPP TLV......................................13

      7. Security Considerations................................15

      8. References.............................................16
      8.1 Normative references..................................16
      8.2 Informative References................................17


























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 by using the IS-IS
   (Intermediate System to Intermediate System) [IS-IS] [RFC1195]
   [RFC6326] link state routing protocol and encapsulating traffic using
   a header that includes a hop count.  The design supports VLANs
   (Virtual Local Area Networks) and optimization of the distribution of
   multi-destination frames based on VLANs and IP multicast groups.
   Devices that implement TRILL are called RBridges (Routing Bridges) or
   TRILL switches.

   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 VLAN scoped
   way RBridges can communicate end station addresses with each other.
   An RBridge that is announcing connectivity to VLAN-x (normally a
   VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce
   the end station address of some or all of its attached VLAN-x end
   nodes to other RBridges that are running ESADI for VLAN-x.

   By default, RBridges 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: 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]).  In addition, the ESADI protocol supports cryptographic
      authentication of its message payloads for more secure
      transmission.

   2. Fast update advantages: ESADI protocol provides a fast update of
      end nodes MAC (Media Access Control) addresses.  If an end station
      is unplugged from one RBridge and plugged into another, frames
      addressed to that older RBridge can be black holed.  They can be
      sent just to the older RBridge that the end station was connected
      to until cached address information at some remote RBridge times
      out, possibly for tens of seconds [RFC6325].

   MAC address reachability information and some ESADI parameters are
   carried in ESADI frames rather than in the TRILL IS-IS protocol.  As
   described below, ESADI is, for each VLAN, a virtual logical topology
   overlay in the TRILL topology. An advantage of using ESADI is that


H. Zhai, et al                                                  [Page 4]


INTERNET-DRAFT                                              TRILL: ESADI


   the end station attachment information is not flooded to all RBridges
   through TRILL IS-IS but only to participating RBridges advertising
   ESADI support for the VLAN in which those end stations occur.




1.1 Content and Precedence

   This document updates [RFC6325], the TRILL basic specification,
   particularly the description of the ESADI protocol, and prevails over
   [RFC6325] in the case of conflicts.

   Section 2 is the ESADI protocol overview. Section 3 specifies ESADI
   DRB state.  Section 4 discusses the processing of ESADI PDUs. Section
   5 describes the ESADI-LSP contents.




1.2 Terminology

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

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





















H. Zhai, et al                                                  [Page 5]


INTERNET-DRAFT                                              TRILL: ESADI


2. ESADI Protocol Overview

   ESADI is a VLAN scoped way that RBridges can announce and learn end
   station addresses rapidly and securely.  An RBridge that is
   announcing itself as connected to one or more VLANs (usually because
   it is an Appointed Forwarder for those VLANs) and participates in the
   ESADI protocol 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
   VLAN. In essence, for each VLAN, 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
   [MultiInstance].) It is an implementation decision how independent
   the implementations of multiple ESADI instances at an RBridge are.
   For example, the ESADI link state could be in a single database with
   a field in each record indicating the VLAN to which it applies or
   could be a separate database per VLAN. But the update processes
   operate separately for each ESADI instance.

   After the TRILL header, ESADI frames have an inner Ethernet header
   with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All-
   ESADI-RBridges"), an Inner.VLAN tag specifying the VLAN of interest,
   and the "L2-IS-IS" Ethertype followed by the ESADI payload as shown
   in Figure 1.  For more detail see Section 4.2.5 in the TRILL base
   protocol specification [RFC6325].

   TRILL ESADI frame Structure

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

                                 Figure 1

   All transit RBridges forward ESADI frames as if they were ordinary
   multicast TRILL Data frames.  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 VLAN. No "routing"
   computation or routing decisions ever have to be performed by ESADI.
   An ESADI RBridge merely transmits the ESADI frames it originates on


H. Zhai, et al                                                  [Page 6]


INTERNET-DRAFT                                              TRILL: ESADI


   this virtual link as described for any multicast frame in [RFC6325]
   using any distribution tree that it might use for a normal TRILL Data
   frame. RBridges that do not implement the ESADI protocol, do not have
   it enabled, or are not participating for the Inner.VLAN of an ESADI
   frame do not decapsulate or locally process any TRILL ESADI frames
   they receive.  Thus the ESADI frames are transparently tunneled
   through transit RBridges.

   TRILL ESADI frame 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 frames.

   The ESADI instance for VLAN-x at an RBridge RB1 determines who its
   ESADI potential 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 VLAN-x ESADI. When an RBridge RB2 becomes IS-IS or
   data unreachable from RB1 or any of 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 VLAN-x ESADI, it
   ceases to be a potential neighbor for the VLAN-x ESADI instance. RB2
   becomes an actual ESADI adjacency for RB1 when it is a potential
   neighbor and RB1 holds an ESADI-LSP zero for RB2, all these
   considerations being VLAN scoped. Because of these mechanisms, there
   are no "Hellos" sent in ESADI.

   The information distributed by the ESADI protocol is 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 5.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. Future uses of ESADI may
   distribute additional types of information.

   TRILL ESADI-LSPs MUST NOT contain a VLAN ID in their payload. The
   VLAN ID to which the ESADI data applies is the Inner.VLAN of the
   TRILL Data frame enclosing the ESADI payload. If a VLAN ID could
   occur within the payload, it might conflict with the Inner.VLAN and
   could conflict with any future VLAN mapping scheme that may be
   adopted [VLANmapping]. If a VLAN ID field within an ESADI-LSP PDU
   does include a VLAN ID, its contents is ignored.

   (In the future, TRILL may be extended to provide more fine-grained
   labeling of data and ports. If so, it is expected that ESADI will be
   extended by allowing such labeling of ESADI frames, in addition to
   the current Inner.VLAN labeling. As with this specification, it would
   generally be prohibited for such fine-grained labeling information to
   appear inside such extended ESADI frame payloads.)


H. Zhai, et al                                                  [Page 7]


INTERNET-DRAFT                                              TRILL: ESADI


3. ESADI DRB State

   Generally speaking, the DRB state on an ESADI link operate similarly
   to a TRILL IS-IS broadcast link with the following exception:

   In the ESADI-DRB election at RB1 on an ESADI link, comparing with
   [RFC6327], the candidates are the local ESADI instance for VLAN-x and
   all remote ESADI instances at RBridges that (1) are data and IS-IS
   reachable from RB1 [ClearCorrect], (2) are announcing in their TRILL
   IS-IS LSP that they are participating in ESADI for VLAN-x, and (3)
   for which RB1 is holding an ESADI-LSP zero with an ESADI Pararmeters
   APPsub-TLV. 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. In particular "SNPA/MAC address" is not
   considered and there is no "Port ID".

   Because ESADI does no routing, the ESADI-DRB does not create a
   pseudo-node.

































H. Zhai, et al                                                  [Page 8]


INTERNET-DRAFT                                              TRILL: ESADI


4. ESADI PDU processing

   VLAN-x ESADI neighbors are usually not connected directly by a
   physical link, but are always logically connected by a virtual link.
   There could be hundreds of ESADI RBridges on the virtual link.  There
   are only EASDI-LSP, EASDI-CSNP and EASDI-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 Layer 3 IS-IS, PDU multicasting is normally 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 entire 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
   imposes a 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.

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




4.1 Sending of ESASI PDUs

   The MTU available to instances of ESADI 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(Innter.MacSA) + 4(Inner.VLAN)). Thus the inner ESADI payload,
   starting with the Intradomain Routeing Protocol Discriminator, MUST
   NOT exceed Sz minus 24; however, if a larger payload is received, it
   is processed normally.

   Once an ESADI instance is operationally up, it multicasts it self-
   originated LSP number zero on the virtual link to announce its ESADI
   parameters. When the other ESADI instances receive the LSP number
   zero and find a new neighbor, their self-originated LSP fragments are
   scheduled to be sent and MAY be unicast to that neighbor. If all the
   other ESADI instances send their self-originated LSPs immediately,
   there may be a surge of traffic to that new neighbor. So the other
   ESADI instances should wait an interval time before sending the LSP
   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 ESADI priority when
   implementation.



H. Zhai, et al                                                  [Page 9]


INTERNET-DRAFT                                              TRILL: ESADI


   If the ESADI instance is DRB, it multicasts an ESADI-CSNP
   periodically 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 LSPs requested by the PSNP on the virtual
   link.

   For robustness, if an ESADI instance has two or more ESADI neighbors
   and is not DRB and it receives no ESADI-CSNP PDUs for at least the
   CSNP Time (see Section 5.1) of the DRB, it MAY transmit an ESADI-
   CSNP.

   In the case of receiving an ESADI-LSP with a smaller sequence number
   than the copy stored in local EASDI Link State Database, the local
   ESADI instance will also schedule to transmit the stored copy and MAY
   unicast it to the sender.

   The format of a unicast ESADI frame is the format of TRILL ESADI
   frame, in section 4.2 in [RFC6325], except that, 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 PDU acceptance
   tests that check that the PDU is from an adjacent system check that
   the System ID is that of an ESADI neighbor and do not check the
   source SNPA/MAC.

   Because all ESADI instance for VLAN-x are adjacent, when RB1 receives
   an ESADI-CSNP from RB2 and detects that it has ESADI-LSPs that RB1 is
   missing, it sets the transmission flag only for its own EASDI-LSPs
   that RB1 is missing. Missing EASDI-LSPs originated by other ESADI
   instances will be detected by those other instances.

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












H. Zhai, et al                                                 [Page 10]


INTERNET-DRAFT                                              TRILL: ESADI


5. ESADI-LSP Contents

   The only PDUs used in ESADI are the Level 1 ESADI-LSP, ESADI-CSNP,
   and ESADI-PSNP PDUs. The content of an ESADI-LSP consists of zero or
   more MAC Reachability TLVs, optionally an Authentication TLV, and
   exactly one ESADI parameter APPsub-TLV in ESADI-LSP zero. This
   section specifies the format for ESADI parameter data APPsub-TLV and
   gives the reference for the ESADI MAC Reachability TLV. In the
   future, there may be other TLVs or sub-TLVs carried in EASDAI-LSPs.

   ESADI-LSP number zero MUST NOT exceed 1470 minus 24 bytes in length
   (1446 bytes) but if received longer, it is still processed normally.




5.1 ESADI Parameter Data

   The figure below presents the format of the ESADI parameter data.
   This APPsub-TLV MUST be included in a TRILL GENAPP TLV in ESADI-LSP
   number zero. If it is missing, priority is assumed to be zero and
   CSNP time 40. If there is more than one occurrnce, the first
   occurrence will be used.

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

   Type: set to ESADI-PARAM subTLV (TRILL APPsub-TLV type 1).

   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 ESADI instance's priority for
      being DRB on the TRILL ESADI virtual link for the VLAN 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.

   CSNP Time: An unsigned byte that give the amount of time in seconds
      during which the originating RBridge, if it is DRB on the ESADI


H. Zhai, et al                                                 [Page 11]


INTERNET-DRAFT                                              TRILL: ESADI


      link, will send at least 3 EASDI-CSNP PDUs. It defaults to 30
      seconds.

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




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

   To avoid conflict with the Inner.VLAN ID, the TLVs in TRILL ESADI
   PDUs, including the MAC-RI TLV, MUST NOT contain the VLAN ID. If a
   VLAN-ID is present in the MAC-RI TLV, it is ignored. The VLAN to
   which the ESADI-LSP applies is indicated only by the Inner.VLAN tag
   in the encapsulated TRILL ESADI frame.

























H. Zhai, et al                                                 [Page 12]


INTERNET-DRAFT                                              TRILL: ESADI


6. IANA Considerations

   IANA allocation considerations are given below.




6.1 ESADI Participation Flag

   IANA is requested to allocate an "ESADI Participation" bit in the
   Interested VLANs and Spanning Tree Roots sub-TLV [RFC6326]. (bit 2 in
   the Interested VLANs field recommended) If this bit is a one, it
   indicates that the originating RBridge is participating in ESADI for
   the indicated VLAN or VLANs.




6.2 TRILL GENAPP TLV

   IANA is requested to allocate an IS-IS Application Identifier under
   the Generic Information TLV (#251) for TRILL [RFCgenapp] 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
   Standard Action, as modified by [RFC4020]. The standards track 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 TRILL IS-IS protocol operation
   including the establishment of IS-IS adjacencies, the update process,
   and the decision process for TRILL IS-IS [IS-IS] [RFC1195] [RFC6327].
   The TRILL Generic Information TLV MUST NOT be used in TRILL IS-IS
   instance zero.

   The V, I, D, and S flags in the initial flags byte of a TRILL Generic
   Information TLV have the meanings specified in [RFCgenapp] 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
   [MultiLevel] and future IETF Standards Actions may update or obsolete


H. Zhai, et al                                                 [Page 13]


INTERNET-DRAFT                                              TRILL: ESADI


   this specification to provide for the use of any or all of these
   flags in the TRILL GENAPP TLV.

   The ESADI Parameters information, for which APPsub-TLV 1 is hereby
   assigned, is compact and slow changing (see Section 5.1).

   For Security Considerations related to ESADI and the ESADI parameters
   APPsub-TLV, see Section 7.












































H. Zhai, et al                                                 [Page 14]


INTERNET-DRAFT                                              TRILL: ESADI


7. Security Considerations

   For general TRILL Security Considerations, see [RFC6325].

   More TBD















































H. Zhai, et al                                                 [Page 15]


INTERNET-DRAFT                                              TRILL: ESADI


8. References

   Normative and informative references for this document are below.




8.1 Normative references

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

   [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
         Standards Track Code Points", BCP 100, RFC 4020, February 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.

   [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
         Ghanwani, "Transparent Interconnection of Lots of Links (TRILL)
         Use of IS-IS", RFC 6326, July 2011.

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

   [RFCgenapp] - Ginsberg, L., S. Previdi, M. Shand, "Advertising
         Generic Information in IS-IS", draft-ietf-isis-genapp-04.txt,
         in RFC Editor's queue.

   [ClearCorrect] - draft-ietf-trill-clear-correct, work in progress.







H. Zhai, et al                                                 [Page 16]


INTERNET-DRAFT                                              TRILL: ESADI


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

   [MultiInstance] - Previdi, S., L. Ginsberg, M. Shand, A. Roy, D.
         Ward, draft-ietf-isis-mi, work in progress.

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

   [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 17]


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
















H. Zhai, et al                                                 [Page 18]


INTERNET-DRAFT                                              TRILL: ESADI


Copyright and IPR Provisions

   Copyright (c) 2012 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 19]