tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8171

 
 
 

Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms

Part 3 of 3, p. 42 to 55
Prev Section

 


prevText      Top      ToC       Page 42 
4.  Directory Use Strategies and Push-Pull Hybrids

   For some edge nodes that have a great number of Data Labels enabled,
   managing the MAC and Data Label <-> Edge RBridge mapping for hosts
   under all those Data Labels can be a challenge.  This is especially
   true for data-center gateway nodes, which need to communicate with
   many, if not all, Data Labels.

Top      Up      ToC       Page 43 
   For those edge TRILL switch nodes, a hybrid model should be
   considered.  That is, the Push Model is used for some Data Labels or
   addresses within a Data Label, while the Pull Model is used for other
   Data Labels or addresses within a Data Label.  The network operator
   decides, via configuration, which Data Labels' mapping entries are
   pushed down from directories and which Data Labels' mapping entries
   are pulled.

   For example, assume a data center where hosts in specific Data
   Labels, say VLANs 1 through 100, communicate regularly with external
   peers.  The mapping entries for those 100 VLANs should probably be
   pushed down to the data-center gateway routers.  For hosts in other
   Data Labels that only communicate with external peers occasionally
   for management interfacing, the mapping entries for those VLANs
   should be pulled down from the directory when needed.

   Similarly, within a Data Label, it could be that some addresses, such
   as the addresses of gateways, files, DNS, or database server hosts
   are commonly referenced by most other hosts but those other hosts,
   perhaps compute engines, are typically only referenced by a few hosts
   in that Data Label.  In that case, the address information for the
   commonly referenced hosts could be pushed as an incomplete directory,
   while the addresses of the others are pulled when needed.

   The mechanisms described in this document for Push and Pull Directory
   services make it easy to use Push for some Data Labels or addresses
   and Pull for others.  In fact, different TRILL switches can even be
   configured so that some use Push Directory services and some use Pull
   Directory services for the same Data Label if both Push and Pull
   Directory services are available for that Data Label.  Also, there
   can be Data Labels for which directory services are not used at all.

   There are a wide variety of strategies that a TRILL switch can adopt
   for making use of directory assistance.  A few suggestions are given
   below.

   -  Even if a TRILL switch will normally be operating with information
      from a complete Push Directory server, there will be a period of
      time when it first comes up before the information it holds is
      complete.  Or, it could be that the only Push Directories that can
      push information to it are incomplete or that they are just
      starting and may not yet have pushed the entire directory.  Thus,
      it is RECOMMENDED that all TRILL switches have a strategy for
      dealing with the situation where they do not have complete
      directory information.  Examples are to send a Pull Directory
      query or to revert to the behavior described in [RFC6325].

Top      Up      ToC       Page 44 
   -  If a TRILL switch receives a native frame X resulting in seeking
      directory information, a choice needs to be made as to what to do
      if it does not already have the directory information it needs.
      In particular, it could (1) immediately flood the TRILL Data
      packet resulting from ingressing X in parallel with seeking the
      directory information, (2) flood that TRILL Data packet after a
      delay, if it fails to obtain the directory information, or
      (3) discard X if it fails to obtain the information.  The choice
      might depend on the priority of frame X, since the higher that
      priority the more urgent the frame typically is, and the greater
      the probability of harm in delaying it.  If a Pull Directory
      request is sent, it is RECOMMENDED that its priority be derived
      from the priority of frame X according to the table below;
      however, it SHOULD be possible, on a per-TRILL-switch basis, to
      configure the second two columns of this table.

          Ingressed     If Flooded    If Flooded
          Priority      Immediately   After Delay
          --------      -----------   -----------
            7             5             6
            6             5             6
            5             4             5
            4             3             4
            3             2             3
            2             0             2
            0             1             0
            1             1             1

      Note: The odd-looking ordering of numbers towards the bottom of
      the columns above is because priority 1 is lower than priority
      zero.  That is to say, the values in the first column are in
      priority order.  They will look more logical if you think of "0"
      as being "1.5".

   Priority 7 is normally only used for urgent messages critical to
   adjacency and so SHOULD NOT be the default for directory traffic.
   Unsolicited updates are sent with a priority that is configured per
   Data Label and that defaults to priority 5.

5.  TRILL ES-IS

   TRILL ES-IS (End System to Intermediate System) is a variation of
   TRILL IS-IS [RFC7176] [RFC7177] [RFC7780] designed to operate on a
   TRILL link among and between one or more TRILL switches and end
   stations on that link.  TRILL ES-IS is analogous to the ISO/IEC ES-IS
   standard [ISO9542] but is implemented in a significantly different
   way as a variation of TRILL IS-IS, as specified in this section.
   Support of TRILL ES-IS is generally optional for both the TRILL

Top      Up      ToC       Page 45 
   switches and the end stations on a link but may be required to
   support certain features.  At the time of this writing, the only
   features requiring TRILL ES-IS are those listed in this section.

   TRILL ES-IS

   o  is useful for supporting Pull Directory hosting on, or use from,
      end stations (see Section 3.5),

   o  is useful for supporting specialized end stations [DirAsstEncap]
      [SmartEN], and

   o  may have additional future uses.

   The advantages of TRILL ES-IS over simply making an "end station" be
   a TRILL switch include relieving the end station of having to
   maintain a copy of the core link-state database (LSPs) and of having
   to perform routing calculations or having the ability to forward
   traffic.

   Except as provided below in this section, TRILL ES-IS PDUs and TLVs
   are the same as TRILL IS-IS PDUs and TLVs.

5.1.  PDUs and System IDs

   All TRILL ES-IS PDUs (except some MTU-probe and MTU-ack PDUs, which
   may be unicast) are multicast using the TRILL-ES-IS multicast MAC
   address (see Section 7.6).  This use of a different multicast address
   assures that TRILL ES-IS and TRILL IS-IS PDUs will not be confused
   for one another.

   Because end stations do not have IS-IS System IDs, TRILL ES-IS uses
   port MAC addresses in their place.  This is convenient, since MAC
   addresses are 48-bit and almost all IS-IS implementations use 48-bit
   System IDs.  Logically, TRILL IS-IS operates between the TRILL
   switches in a TRILL campus as identified by the System ID, while
   TRILL ES-IS operates between Ethernet ports on an Ethernet link
   (which may be a bridged LAN) as identified by the MAC address
   [RFC6325].

   As System IDs of TRILL switches in a campus are required to be
   unique, so the MAC addresses of TRILL ES-IS ports on a link MUST be
   unique.

Top      Up      ToC       Page 46 
5.2.  Adjacency, DRB Election, Port IDs, Hellos, and TLVs

   TRILL ES-IS adjacency formation and Designated RBridge (DRB) election
   operate between the ports on the link as specified in [RFC7177] for a
   broadcast link.  The DRB specifies an ES-IS Designated VLAN for the
   link.  Adjacency determination, DRB election, and Designated VLANs as
   described in this section are distinct from TRILL IS-IS adjacency,
   DRB election, and Designated VLANs.

   Although the "Report state" [RFC7177] exists for TRILL ES-IS
   adjacencies, such adjacencies are only reported in TRILL ES-IS LSPs,
   not in any TRILL IS-IS LSPs.

   End stations supporting TRILL ES-IS MUST assign a unique Port ID to
   each of their TRILL ES-IS ports; the Port ID appears in the TRILL
   ES-IS Hellos they send.

   TRILL ES-IS has nothing to do with Appointed Forwarders.  The
   Appointed Forwarders sub-TLV and the VLANs Appointed sub-TLV
   [RFC7176] are not used and SHOULD NOT be sent in TRILL ES-IS; if such
   a sub-TLV is received in TRILL ES-IS, it is ignored.  (The Appointed
   Forwarders on a link are determined as specified in [RFC8139], using
   TRILL IS-IS.)

   Although some of the ports sending TRILL ES-IS PDUs are on end
   stations and thus not on routers (TRILL switches), they nevertheless
   may make use of the Router CAPABILITY (#242) [RFC7981] and
   MT-Capability (#144) [RFC6329] IS-IS TLVs to indicate capabilities as
   specified in [RFC7176].

   TRILL ES-IS Hellos are like TRILL IS-IS Hellos, but note the
   following: in the Special VLANs and Flags sub-TLV [RFC7176], any
   TRILL switches advertise a nickname they own, but for end stations,
   that field MUST be sent as zero and ignored on receipt.  In addition,
   in the Special VLANs and Flags sub-TLV (Section 2.2.1 of [RFC7176])
   in a TRILL ES-IS Hello, the AF and TR flag bits MUST be sent as zero,
   the AC flag bit MUST be sent as one (1), and all three are ignored
   on receipt.

Top      Up      ToC       Page 47 
5.3.  Link State

   The only link-state transmission and synchronization that occur in
   TRILL ES-IS are for E-L1CS (Extended Level 1 Circuit Scope) PDUs
   [RFC7356].  In particular, the end-station Ethernet ports supporting
   TRILL ES-IS do not support the core TRILL IS-IS LSPs and do not
   support E-L1FS (Extended Level 1 Flooding Scope) LSPs [RFC7780] (or
   the CSNPs or PSNPs (Partial Sequence Number PDUs) [RFC7356]
   corresponding to either of them).  TLVs and sub-TLVs that would
   otherwise be sent in TRILL IS-IS LSPs or E-L1FS LSPs are instead sent
   in E-L1CS LSPs.

6.  Security Considerations

   For general TRILL security considerations, see [RFC6325].

6.1.  Directory Information Security

   Incorrect directory information can result in a variety of security
   threats, including those listed below.  Directory servers therefore
   need to take care to implement and enforce access control policies
   that are not overly permissive.

   o  Incorrect directory mappings can result in data being delivered to
      the wrong end stations, or set of end stations in the case of
      multi-destination packets, violating security policy.

   o  Missing, incorrect, or inaccessible directory data can result in
      denial of service due to sending data packets to black holes or
      discarding data on ingress due to incorrect information that their
      destinations are not reachable or that their source addresses are
      forged.

   For these reasons, whatever server or end station the directory
   information resides on, it needs to be protected from unauthorized
   modification.  Parties authorized to modify directory data can
   violate availability and integrity policies.

6.2.  Directory Confidentiality and Privacy

   In implementations of the base TRILL protocol [RFC6325] [RFC7780],
   RBridges deal almost exclusively with MAC addresses.  The use of
   directories to map to/from IP addresses means that RBridges deal more
   actively with IP addresses as well.  But RBridges in any case would
   be exposed to plain-text ARP/ND/SEND/IP traffic and so can see all
   this addressing metadata.  So, this more-explicit dealing with IP
   addresses has little effect on the privacy of end-station traffic.

Top      Up      ToC       Page 48 
   Parties authorized to read directory data can violate privacy
   policies for such data.

6.3.  Directory Message Security Considerations

   Push Directory data is distributed through ESADI-LSPs [RFC7357].
   ESADI is built on IS-IS, and such data can thus be authenticated with
   the widely implemented and deployed IS-IS PDU security.  This
   mechanism provides authentication and integrity protection.  See
   [RFC5304], [RFC5310], and the Security Considerations section of
   [RFC7357].

   Pull Directory queries and responses are transmitted as
   RBridge-to-RBridge or native RBridge Channel messages [RFC7178].
   Such messages can be secured by the mechanisms specified in
   [RFC7978].  These mechanisms can provide authentication and
   confidentiality protection.  At the time of this writing, these
   security mechanisms are believed to be less widely implemented than
   IS-IS security.

7.  IANA Considerations

7.1.  ESADI-Parameter Data Extensions

   IANA has created a subregistry in the "TRILL Parameters" registry
   as follows:

      Subregistry: ESADI-Parameter APPsub-TLV Flag Bits
      Registration Procedure(s): Standards Action
      References: [RFC7357] [RFC8171]

         Bit  Mnemonic  Description                    Reference
         ---  --------  ----------------------------   ---------------
           0    UN      Supports Unicast ESADI         ESADI [RFC7357]
         1-2    PDSS    Push Directory Server Status   [RFC8171]
         3-7    -       Unassigned

   In addition, the ESADI-Parameter APPsub-TLV is optionally extended,
   as provided in its original specification in ESADI [RFC7357], by
   1 byte as shown below.  Therefore, [RFC8171] has also been added as a
   second reference to the ESADI-Parameter APPsub-TLV in the "TRILL
   APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"
   registry.

Top      Up      ToC       Page 49 
             +-+-+-+-+-+-+-+-+
             | Type          |           (1 byte)
             +-+-+-+-+-+-+-+-+
             | Length        |           (1 byte)
             +-+-+-+-+-+-+-+-+
             |R| Priority    |           (1 byte)
             +-+-+-+-+-+-+-+-+
             | CSNP Time     |           (1 byte)
             +-+-+-+-+-+-+-+-+
             | Flags         |           (1 byte)
             +---------------+
             |PushDirPriority|           (optional, 1 byte)
             +---------------+
             | Reserved for              (variable)
             |  expansion
             +-+-+-+-...

   The meanings of all the fields are as specified in ESADI [RFC7357],
   except that the added PushDirPriority is the priority of the
   advertising ESADI instance to be a Push Directory as described in
   Section 2.3.  If the PushDirPriority field is not present
   (Length = 3), it is treated as if it were 0x3F.  0x3F is also the
   value used and placed here by a TRILL switch whose priority to be a
   Push Directory has not been configured.

7.2.  RBridge Channel Protocol Numbers

   IANA has assigned a new RBridge Channel Protocol number (0x005) from
   the range assignable by Standards Action [RFC5226] and updated the
   subregistry accordingly in the "TRILL Parameters" registry.  The
   description is "Pull Directory Services".  The reference is
   [RFC8171].

7.3.  The Pull Directory (PUL) and No Data (NOD) Bits

   IANA has assigned a previously reserved bit in the Interested VLANs
   field of the Interested VLANs sub-TLV and the Interested Labels field
   of the Interested Labels sub-TLV [RFC7176] to indicate a Pull
   Directory server (PUL).  This bit has been added, with this document
   as a reference, to the "Interested VLANs Flag Bits" and "Interested
   Labels Flag Bits" subregistries created by [RFC7357], as shown below.

Top      Up      ToC       Page 50 
   IANA has assigned a previously reserved bit in the Interested VLANs
   field of the Interested VLANs sub-TLV and the Interested Labels field
   of the Interested Labels sub-TLV [RFC7176] to indicate No Data (NOD)
   (see Section 3.8).  This bit has been added, with this document as a
   reference, to the "Interested VLANs Flag Bits" and "Interested Labels
   Flag Bits" subregistries created by [RFC7357], as shown below.

   The bits are as follows:

      Registry: Interested VLANs Flag Bits

      Bit Mnemonic  Description     Reference
      --- -------- --------------  ---------------
       18    PUL   Pull Directory  [RFC8171]
       19    NOD   No Data         [RFC8171]

      Registry: Interested Labels Flag Bits

      Bit Mnemonic  Description     Reference
      --- -------- --------------  ---------------
        6    PUL   Pull Directory  [RFC8171]
        7    NOD   No Data         [RFC8171]

7.4.  TRILL Pull Directory QTYPEs

   IANA has created a new registry as follows:

      Name: TRILL Pull Directory Query Types (QTYPEs)
      Registration Procedure(s): IETF Review
      Reference: [RFC8171]
      Initial contents as in Section 3.2.1.

7.5.  Pull Directory Error Code Registries

   IANA has created a new registry and two new indented subregistries
   as follows:

      Registry
         Name: TRILL Pull Directory Errors
         Registration Procedure(s): IETF Review
         Reference: [RFC8171]

         Initial contents as in Section 3.6.1.

Top      Up      ToC       Page 51 
         Subregistry
            Name: Sub-codes for TRILL Pull Directory Errors 1 and 3
            Registration Procedure(s): Expert Review
            Reference: [RFC8171]

            Initial contents as in Section 3.6.2.

         Subregistry
            Name: Sub-codes for TRILL Pull Directory Errors 128 and 131
            Registration Procedure(s): Expert Review
            Reference: [RFC8171]

            Initial contents as in Section 3.6.3.

7.6.  TRILL-ES-IS MAC Address

   IANA has assigned a TRILL multicast MAC address (01-80-C2-00-00-47)
   from the "TRILL Multicast Addresses" registry.  The description is
   "TRILL-ES-IS".  The reference is [RFC8171].

8.  References

8.1.  Normative References

   [RFC826]   Plummer, D., "Ethernet Address Resolution Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, DOI 10.17487/RFC0826, November 1982,
              <http://www.rfc-editor.org/info/rfc826>.

   [RFC903]   Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
              Reverse Address Resolution Protocol", STD 38, RFC 903,
              DOI 10.17487/RFC0903, June 1984,
              <http://www.rfc-editor.org/info/rfc903>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971,
              DOI 10.17487/RFC3971, March 2005,
              <http://www.rfc-editor.org/info/rfc3971>.

Top      Up      ToC       Page 52 
   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304,
              October 2008, <http://www.rfc-editor.org/info/rfc5304>.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, DOI 10.17487/RFC5310,
              February 2009, <http://www.rfc-editor.org/info/rfc5310>.

   [RFC6165]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
              Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011,
              <http://www.rfc-editor.org/info/rfc6165>.

   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
              <http://www.rfc-editor.org/info/rfc6325>.

   [RFC6329]  Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
              A., and P. Unbehagen, "IS-IS Extensions Supporting
              IEEE 802.1aq Shortest Path Bridging", RFC 6329,
              DOI 10.17487/RFC6329, April 2012,
              <http://www.rfc-editor.org/info/rfc6329>.

   [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
              IETF Protocol and Documentation Usage for IEEE 802
              Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
              October 2013, <http://www.rfc-editor.org/info/rfc7042>.

   [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,
              DOI 10.17487/RFC7172, May 2014,
              <http://www.rfc-editor.org/info/rfc7172>.

   [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,
              DOI 10.17487/RFC7176, May 2014,
              <http://www.rfc-editor.org/info/rfc7176>.

Top      Up      ToC       Page 53 
   [RFC7177]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
              V. Manral, "Transparent Interconnection of Lots of Links
              (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177,
              May 2014, <http://www.rfc-editor.org/info/rfc7177>.

   [RFC7178]  Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
              Ward, "Transparent Interconnection of Lots of Links
              (TRILL): RBridge Channel Support", RFC 7178,
              DOI 10.17487/RFC7178, May 2014,
              <http://www.rfc-editor.org/info/rfc7178>.

   [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
              Scope Link State PDUs (LSPs)", RFC 7356,
              DOI 10.17487/RFC7356, September 2014,
              <http://www.rfc-editor.org/info/rfc7356>.

   [RFC7357]  Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
              Stokes, "Transparent Interconnection of Lots of Links
              (TRILL): End Station Address Distribution Information
              (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
              September 2014, <http://www.rfc-editor.org/info/rfc7357>.

   [RFC7780]  Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
              Ghanwani, A., and S. Gupta, "Transparent Interconnection
              of Lots of Links (TRILL): Clarifications, Corrections, and
              Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
              <http://www.rfc-editor.org/info/rfc7780>.

   [RFC7961]  Eastlake 3rd, D. and L. Yizhou, "Transparent
              Interconnection of Lots of Links (TRILL): Interface
              Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961,
              August 2016, <http://www.rfc-editor.org/info/rfc7961>.

   [RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Information", RFC 7981,
              DOI 10.17487/RFC7981, October 2016,
              <http://www.rfc-editor.org/info/rfc7981>.

   [RFC8139]  Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F.
              Hu, "Transparent Interconnection of Lots of Links (TRILL):
              Appointed Forwarders", RFC 8139, DOI 10.17487/RFC7961,
              June 2017, <http://www.rfc-editor.org/info/rfc8139>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <http://www.rfc-editor.org/info/rfc8174>.

Top      Up      ToC       Page 54 
8.2.  Informative References

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC7067]  Dunbar, L., Eastlake 3rd, D., Perlman, R., and I.
              Gashinsky, "Directory Assistance Problem and High-Level
              Design Proposal", RFC 7067, DOI 10.17487/RFC7067,
              November 2013, <http://www.rfc-editor.org/info/rfc7067>.

   [RFC7978]  Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent
              Interconnection of Lots of Links (TRILL): RBridge Channel
              Header Extension", RFC 7978, DOI 10.17487/RFC7978,
              September 2016, <http://www.rfc-editor.org/info/rfc7978>.

   [ARPND]    Li, Y., Eastlake 3rd, D., Dunbar, L., Perlman, R., and M.
              Umair, "TRILL: ARP/ND Optimization", Work in Progress,
              draft-ietf-trill-arp-optimization-08, April 2017.

   [DirAsstEncap]
              Dunbar, L., Eastlake 3rd, D., and R. Perlman, "Directory
              Assisted TRILL Encapsulation", Work in Progress,
              draft-ietf-trill-directory-assisted-encap-05, May 2017.

   [ISO9542]  ISO 9542:1988, "Information processing systems --
              Telecommunications and information exchange between
              systems -- End system to Intermediate system routeing
              exchange protocol for use in conjunction with the Protocol
              for providing the connectionless-mode network service
              (ISO 8473)", August 1988.

   [SmartEN]  Perlman, R., Hu, F., Eastlake 3rd, D., Krupakaran, K., and
              T. Liao, "TRILL Smart Endnodes", Work in Progress,
              draft-ietf-trill-smart-endnodes-05, February 2017.

   [X.233]    International Telecommunication Union, ITU-T
              Recommendation X.233: "Information technology - Protocol
              for providing the connectionless-mode network service:
              Protocol specification", August 1997,
              <https://www.itu.int/rec/T-REC-X.233/en>.

Top      Up      ToC       Page 55 
Acknowledgments

   The contributions of the following persons are gratefully
   acknowledged:

      Amanda Baber, Matthew Bocci, Alissa Cooper, Stephen Farrell,
      Daniel Franke, Igor Gashinsky, Joel Halpern, Susan Hares, Alexey
      Melnikov, Gayle Noble, and Tianran Zhou.

Authors' Addresses

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


   Linda Dunbar
   Huawei Technologies
   5430 Legacy Drive, Suite #175
   Plano, TX  75024
   United States of America
   Phone: +1-469-277-5840
   Email: ldunbar@huawei.com


   Radia Perlman
   EMC
   2010 256th Avenue NE, #200
   Bellevue, WA  98007
   United States of America
   Email: Radia@alum.mit.edu


   Yizhou Li
   Huawei Technologies
   101 Software Avenue
   Nanjing  210012
   China
   Phone: +86-25-56622310
   Email: liyizhou@huawei.com