RFC 7357

RFC 7357 (Part 1 of 6) 💖

Okay bestie, meet RFC 7357! 🦋 It's titled Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol, and it's a Standards Track document from the IETF. The date on it is September 2014, and the ISSN is 2070-1721. 📅

The authors are H. Zhai and F. Hu from ZTE, R. Perlman from Intel Labs, D. Eastlake 3rd from Huawei, and O. Stokes from Extreme Networks. Their whole squad is giving 👑

This doc updates RFC 6325, the TRILL base protocol spec. The title block doesn't list anything it obsoletes. 🧚

Abstract ✨

Okay so, TRILL (Transparent Interconnection of Lots of Links) is the protocol that does least-cost pair-wise data forwarding with zero configuration in multi-hop networks, no matter how weirdly the topology or link technologies are built. It's giving "safe even during temporary loops" too, and it supports multipathing for both unicast and multicast traffic. 🌈 The devices that run TRILL are called TRILL switches or RBridges (Routing Bridges). 💅

ESADI (End Station Address Distribution Information) is an optional protocol 💜 (fine, not capitalized, it's optional for real). It lets a TRILL switch share end station address and reachability info with other TRILL switches that are also running ESADI, and it does this in a Data Label scoped way (a VLAN or a fine-grained label). This document updates RFC 6325, specifically the ESADI protocol part, and it is not backwards compatible. 🙈

Status of This Memo 📜

This is an Internet Standards Track document. ⭐

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741. 🎀

If you want the current status, any errata, or a way to send feedback, check out http://www.rfc-editor.org/info/rfc7357. 🔗

Copyright Notice 🎀

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 💀

Table of Contents 🧚

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

---

1. Introduction 🦋

Okay so the TRILL protocol [RFC6325] gives you least-cost pair-wise data forwarding with no configuration, in multi-hop networks with arbitrary topologies and link technologies. It's safe even during temporary loops and supports multipathing for unicast and multicast traffic. ✨ TRILL does this with the IS-IS (Intermediate System to Intermediate System) [IS-IS] [RFC1195] [RFC7176] link-state routing protocol, using a header with a hop count. 🌸 The design also optimizes how multi-destination frames get distributed, and it supports two types of data labeling: VLANs (Virtual Local Area Networks) [RFC6325] and FGLs (fine-grained labels) [RFC7172]. Devices that implement TRILL are called TRILL switches or RBridges (Routing Bridges). 💖

There are five ways a TRILL switch can learn end station addresses, as described in Section 4.8 of [RFC6325]. One of them is ESADI (End Station Address Distribution Information), an optional, Data Label scoped way for TRILL switches to share stuff like end station addresses and the TRILL switch they're attached to. A TRILL switch that's announcing interest in a Data Label MAY use ESADI to announce the end station address of some or all of its attached end stations in that Data Label to other TRILL switches running ESADI for that Data Label. (Later on, ESADI might also be used for other address and reachability info. Stay tuned! 👀)

By default, TRILL switches with connected end stations learn addresses from the data plane when they ingress and egress native frames, although that learning can be turned off. 🫧 ESADI's potential advantages over data plane learning include the following:

1. Security advantages 🔐:
   • a) ESADI can announce end stations with an authenticated enrollment. For example, the enrollment can be authenticated by cryptographically based EAP (Extensible Authentication Protocol) [RFC3748] methods via [802.1X].
   • b) ESADI supports cryptographic authentication of its message payloads for more secure transmission.
2. Fast update advantages ⚡: ESADI gives a fast update of end station MAC (Media Access Control) addresses and their TRILL switch of attachment. Picture this: an end station gets unplugged from one TRILL switch and plugged into another. Ingressed frames with that end station's MAC address as their destination can get black-holed. They can be sent just to the older egress TRILL switch the end station used to be connected to, until the cached address info at some remote ingress TRILL switch times out, which can take possibly tens of seconds [RFC6325]. Not it. 🙈

MAC address reachability information, some ESADI parameters, and optional authentication information are carried in ESADI packets, not in the TRILL IS-IS protocol. As specified below, ESADI is, for each Data Label, a virtual logical topology overlay in the TRILL topology. 🧩 The big perk of using ESADI instead of TRILL IS-IS is that end station attachment info doesn't get flooded to every TRILL switch. It only goes to the TRILL switches advertising ESADI participation for the Data Label where those end stations live. Iconic, honestly. 👑

1.1. Content and Precedence

This document updates [RFC6325], the TRILL base protocol specification. It replaces the description of the TRILL ESADI protocol (Section 4.2.5 of [RFC6325], including all subsections), gives more detail on ESADI, updates other ESADI-related sections of [RFC6325], and takes priority over [RFC6325] in any case where they conflict. So yes, familiarity with [RFC6325] is really assumed here. 📚

These changes include a change to the format of ESADI-LSPs (ESADI Link State Protocol Data Units) that is not backwards compatible. 🙃 The reason is the substantially increased amount of information that can be carried, plus the very limited, if any, deployment of RFC 6325 ESADI. Appendix A goes into more detail on these changes. 🎀

Section 2 of this document is the ESADI protocol overview. Section 3 specifies ESADI DRB (Designated RBridge) determination. Section 4 discusses how ESADI PDUs get processed. Section 5 talks about interaction with other modes of end station address learning. Section 6 describes the ESADI-LSP and its contents. 🗺️

1.2. Terminology

This document uses the acronyms defined in [RFC6325], plus the following:

• Data Label: VLAN or FGL. 🏷️
• ESADI RBridge: An RBridge that is participating in ESADI for one or more Data Labels. 🦋
• FGL: Fine-Grained Label [RFC7172]. ✨
• LSP: Link State PDU [IS-IS]. 🌈
• LSP number zero: A Link State PDU with fragment number equal to zero. 🔢
• PDU: Protocol Data Unit. 📦
• TRILL switch: An alternative name for an RBridge. 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 📖

Capitalized IANA-related terms such as "IETF Review" are to be interpreted as described in [RFC5226]. 🫶

2. ESADI Protocol Overview ✨

okay so ESADI is a Data Label scoped way for TRILL switches (also known as RBridges) to announce and learn end station addresses rapidly and securely 💅 an RBridge that is announcing participation in ESADI for one or more Data Labels is called an ESADI RBridge 🦋

ESADI is an optional protocol that is separate from the mandatory TRILL IS-IS that every RBridge in a campus implements 🎀 there is a separate ESADI instance for each Data Label (VLAN or FGL) if ESADI is being used for that Data Label 🌸 basically, for each one, you get a modified instance of the IS-IS reliable flooding mechanism that ESADI RBridges may choose to join 💖 (these are not the instances specified in [RFC6822], so don't mix them up bestie 🙈) multiple ESADI instances can share implementation components inside an RBridge as long as that sharing keeps each instance running independently 🫶 for example, the ESADI link state database could be one single database with a field in each record saying which Data Label it applies to, or it could be a separate database per Data Label ✨ but the ESADI update process runs separately for each ESADI instance and independently from the TRILL IS-IS update process, no mixing 🔥

ESADI does no routing calculations, so there is no reason for pseudonodes in ESADI and none are created 💅 (pseudonodes [IS-IS] are a construct for optimizing routing calculations, so ESADI doesn't need them 🧚) also, a relatively large amount of ESADI data may have to be distributed under some circumstances using ESADI mechanisms, which would need a large number of ESADI-LSP fragments 😭 so ESADI-LSP, ESADI-CSNP, and ESADI-PSNP payloads (ESADI Link State PDU, Complete Sequence Number PDU, and Partial Sequence Number PDU) are formatted as Extended Level 1 Circuit Scope (E-L1CS) PDUs [RFC7356] (see also Section 6) 🌈 this allows up to 2**16 fragments, but it does not support link state data associated with pseudonodes 💜

After the TRILL Header, ESADI packets have an inner Ethernet header with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All-ESADI-RBridges"), an inner Data Label specifying the VLAN or FGL of interest, and the "L2-IS-IS" Ethertype, followed by the ESADI payload, as shown in Figure 1 🦋

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

                   Figure 1: TRILL ESADI Packet Overview

TRILL ESADI packets sent on an Ethernet link are structured as shown in Figure 2 🌸 the outer VLAN tag won't be there if the Ethernet port that sent the packet didn't include one 🫶

   Outer Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Next Hop Destination Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Hop Destination Addr.    | Sending RBridge Port MAC Addr.|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Sending RBridge Port MAC Address              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ...Ethernet frame tagging including optional Outer.VLAN tag...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = TRILL      0x22F3 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   TRILL Header:                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      | V | R |M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Egress Nickname               | Ingress (Origin) Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Inner Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      All-Egress-RBridges                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | All-Egress-RBridges (cont.)   | Origin RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Origin RBridge MAC Address (continued)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = L2-IS-IS   0x22F4 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ESADI Payload (formatted as IS-IS):
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Frame Check Sequence:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  FCS (Frame Check Sequence)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: ESADI Ethernet Link Packet Format

The Next Hop Destination Address or Outer.MacDA is the All-RBridges multicast address if the ESADI PDU is being multicast 🦋 if it's being unicast, the Next Hop Destination Address is the unicast address of the next-hop RBridge 💅 the VLAN for the Outer.VLAN information, if present, will be the Designated VLAN for the link the packet is sent on ✨ the V and R fields will be zero, and the M bit will be one, unless the ESADI PDU was unicast, in which case the M bit will be zero 🌈 the Data Label specified will be the VLAN or FGL the ESADI packet applies to 🫶 the Origin RBridge MAC Address or Inner.MacSA MUST be a MAC address unique across the campus, owned by the RBridge originating the ESADI packet (for example, any of its port MAC addresses if it has any Ethernet ports) 🔥 and each ESADI RBridge MUST use the same Inner.MacSA for all of the ESADI packets it originates 💖

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

   PPP Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PPP = TNP (TRILL Data) 0x005D |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   TRILL Header:                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      | V | R |M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Egress Nickname               | Ingress (Origin) Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Inner Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      All-Egress-RBridges                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | All-Egress-RBridges (cont.)   | Origin RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Origin RBridge MAC Address (continued)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = L2-IS-IS   0x22F4 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ESADI Payload (formatted as IS-IS):
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   PPP Check Sequence:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       PPP Check Sequence                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: ESADI PPP Link Packet Format

2.1. ESADI Virtual Link

all RBridges forward ESADI packets as if they were ordinary TRILL Data packets 🌸 because of this forwarding, it appears to an instance of the ESADI protocol at an RBridge that it is directly connected by a multi-access virtual link to all RBridges in the campus that are "data reachable" from it (see Section 2 of [RFC7180]) and are running ESADI for that Data Label 🦋 no "routing" calculation (least-cost path or distribution tree construction) ever has to be performed by ESADI 💅 an ESADI RBridge merely transmits the ESADI packets it originates on this virtual link, as described for TRILL Data packets in [RFC6325] and [RFC7172] 🫶 for multicast ESADI packets, it may use any distribution tree that it might use for an ordinary multi-destination TRILL Data packet ✨ RBridges that do not implement the ESADI protocol, do not have it enabled, or are not participating in the ESADI protocol for the Data Label of an ESADI packet do not decapsulate or locally process the ESADI packet 🌈 thus, ESADI packets are transparently tunneled through transit RBridges 💜

2.2. ESADI Neighbor Determination

the ESADI instance for Data Label X at an RBridge RB1 determines who its adjacent ESADI neighbors are by examining the TRILL IS-IS link state database for RBridges that are data reachable from RB1 (see Section 2 of [RFC7180]) and are announcing their participation in Data Label X ESADI 🔥 when an RBridge RB2 becomes data unreachable from RB1, or the relevant entries for RB2 are purged from the core IS-IS link state database, it is lost as a neighbor and also dropped from any ESADI instances from the point of view of RB1 🙈 and when RB2 is no longer announcing participation in Data Label X ESADI, it ceases to be a neighbor for any Data Label X ESADI instance 💀 all these considerations are Data Label scoped 🧚 because of these mechanisms, whereby an ESADI instance at an ESADI RBridge can determine its ESADI adjacencies by examining the TRILL IS-IS link state database, there are no "Hellos" sent in ESADI and no adjacency information is carried in ESADI-LSPs 🎀

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

2.3. ESADI Payloads

okay bestie, ESADI payloads are basically dressed up like IS-IS Extended Level 1 Circuit Scope (E-L1CS) LSP, CSNP, and PSNP PDUs [RFC7356] 💅, with a few exceptions we'll get to. The twist is that they're always TRILL encapsulated on the wire, like they're regular TRILL Data packets 🎀. What's inside is the info ESADI shares: a list of the local end station MAC addresses hanging off the originating RBridge, and for each one a 1-octet unsigned "Confidence" rating from 0-254 (see Section 6.2) ✨. The originating RBridge gets to decide which of its local MACs it wants to advertise and with what Confidence, totally its call 👑. It MAY advertise all, some, or none of them 🦋. The payload also carries some ESADI parameters of the advertising RBridge (see Section 6.1), and optionally authentication info (see Section 6.3) 🫶. Future versions of ESADI might share other similar address and reachability info too, so stay tuned 🌈.

TRILL ESADI-LSPs MUST NOT contain a Data Label ID in their payload 🙈. The Data Label that the ESADI data applies to is just the Data Label of the TRILL Data packet wrapping the ESADI payload. If a Data Label ID could show up inside the payload, it could clash with that TRILL Data packet's Data Label, and it could also clash with any future Data Label mapping scheme that might get adopted [VLANmapping] 💀. Also, if a VLAN or FGL ID field inside an ESADI-LSP PDU does have a value in it, those contents MUST be ignored 🧚.

3. ESADI DRB (Designated RBridge) Determination

ngl this part is so cute 🥹. ESADI doesn't do any adjacency announcing or routing, so the ESADI-DRB never makes a pseudonode 🍓. BUT a DRB [RFC7177] is still needed to send out ESADI-CSNP PDUs and reply to ESADI-PSNP PDUs for ESADI-LSP synchronization, so it's still a big deal 💖.

Generally speaking, the DRB election on the ESADI virtual link (see Section 2.1) works kinda like the DRB election on a TRILL IS-IS broadcast link, as described in Section 4.2.1 ("DRB Election Details") of [RFC7177] 🦋. There are a few differences though, so pay attention 👀. In a Data Label X ESADI-DRB election at RB1 on an ESADI virtual link, the candidates are the local ESADI instance for Data Label X plus all the remote ESADI instances at RBridges that are (1) data reachable from RB1 [RFC7180] and (2) announcing in their TRILL IS-IS LSP that they're participating in ESADI for Data Label X ✨. The winner is the instance with the highest ESADI Parameter 7-bit priority field, and ties get broken by the System ID. The fields are compared as unsigned integers, and the larger magnitude counts as higher priority 👑. "SNPA/MAC address" (Subnetwork Point of Attachment / MAC address) does NOT factor into this tiebreak, and there's no "Port ID" either 🙅‍♀️.

4. ESADI PDU Processing

Data Label X ESADI neighbors usually aren't hooked up directly by a physical link, but they're always logically connected by a virtual link (see Section 2.1) 🌸. There could be hundreds or even thousands of ESADI RBridges (TRILL switches) on that virtual link, which is a lot of friends 😭. The only PDUs ESADI uses are ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDUs. There are no Hello or MTU PDUs, because ESADI doesn't build a topology, doesn't do routing calculations, and doesn't determine MTU 🙈. Instead, it borrows the distribution trees and the Sz campus minimum link MTU that the core TRILL IS-IS figured out (see [RFC6325] and [RFC7180]) 🧚.

4.1. Unicasting ESADI PDUs

Okay so with [IS-IS], PDU multicasting is totally normal on a local link, and nobody bothers optimizing to unicast 🤷‍♀️. That made sense back when IS-IS was designed for the usual physical link (commonly a piece of multi-access Ethernet cable), since any frame just kept the link busy for that frame time. But to ESADI instances, what looks like a simple multi-access link is actually a set of multi-hop distribution trees that may or may not be pruned 🌳. So sending a multicast frame on one of those trees can put a way bigger load on the network than sending a unicast frame 😱. That load can be worth it if there are likely to be lots of listeners, but it might not be worth it if there's only one recipient who actually cares 💅. So under some circumstances, ESADI PDUs MAY be TRILL unicast, if it's confirmed that the destination RBridge supports receiving unicast ESADI PDUs (see Section 6.1) 💖.

The format of a unicast ESADI packet is the same as a multicast TRILL ESADI packet (described in Section 2 above), except for these changes:

• On an Ethernet link, in the outer Ethernet header, the Outer.MacDA is the unicast address of the next-hop RBridge 🎀.
• In the TRILL Header, the M bit is set to zero, and the Egress Nickname is the nickname of the destination RBridge 🦋.

To make unicasting of ESADI PDUs work, Section 4.6.2.2 of [RFC6325] gets 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. On top of that, if (1) the forwarding RBridge is interested in the specified VLAN or fine-grained label [RFC7172], (2) the forwarding RBridge implements the TRILL ESADI protocol, and (3) ESADI is enabled for the specified VLAN or fine-grained label, then the inner frame gets decapsulated and handed off to that local ESADI protocol ✨.

If M = 0 and the egress nickname is not that of the receiving RBridge, the packet is forwarded like a known unicast TRILL Data frame, as described in Section 4.6.2.4 🌈. If M = 0 and the egress nickname IS that of the receiving RBridge, and the receiving RBridge supports unicast ESADI PDUs, then the ESADI packet gets decapsulated and processed if it meets the three numbered conditions in the paragraph above. Otherwise, it gets discarded 💀.

The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above point to those sections in [RFC6325] 📚.

4.2. General Transmission of ESADI PDUs

Following the usual [IS-IS] rules, an ESADI instance does NOT transmit any ESADI PDUs if it has no ESADI adjacencies 🙅‍♀️. Sending them would just be a waste of bandwidth, and nobody wants that 😤.

The MTU available to ESADI payloads is at least 24 bytes less than what's available to TRILL IS-IS, because of the extra fields that are required: 2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) + 6(Inner.MacSA) + 4/8(Data Label) bytes 🧮. So the inner ESADI payload, starting with the Intradomain Routeing Protocol Discriminator byte, MUST NOT exceed Sz minus 24 for a VLAN ESADI instance, or Sz minus 28 for an FGL ESADI instance. That said, if a bigger payload does get received, it's still processed normally (see [RFC6325] and [RFC7180] for the deets on Sz and MTU) 🌸.

In all cases where this document says an ESADI PDU is multicast, if the transmitting RBridge has only one neighbor and that neighbor advertises support for unicast, the PDU MAY be unicast (see Section 4.1) 🦋.

A priority bit to say that an LSP fragment should be flooded with high priority is provided by [RFC7356] ⚡. This bit SHOULD be set on ESADI-LSP fragment zero, because it's important that the ESADI Parameter APPsub-TLV gets through promptly 🏃‍♀️. This bit SHOULD NOT be set on other ESADI-LSP fragments, though, so we don't give undue priority to less urgent PDUs 🙄.

4.3. General Receipt of ESADI PDUs

Here's the glow-up 🪞. Layer 3 IS-IS PDU acceptance tests check the source inner and outer SNPA/MAC to verify that a PDU is from an adjacent TRILL switch. But in TRILL ESADI, adjacency is based on the system ID instead, so the system ID inside the PDU is all that gets tested 🆔.

If an ESADI instance believes it has no ESADI neighbors, it ignores any ESADI PDUs it receives 🙈.

4.4. ESADI Reliable Flooding

The IS-IS reliable flooding mechanism (the Update Process) gets modified for ESADI in the ways listed below 🔧. Except where it says otherwise, the ESADI update process works as described in [IS-IS], [RFC1195], and [RFC7356] 📖.

When an ESADI instance sees that it has a new ESADI neighbor, its self-originated ESADI-LSP fragments get scheduled to be sent, and they 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 could be a surge of traffic to that new neighbor 😵. So the ESADI instances SHOULD wait an interval of time before sending their ESADI-LSP(s) to a new neighbor ⏳. The interval value is up to the device implementation. One suggestion is that the interval can be assigned a random value, with a range based on the RBridge's nickname (or any one of its nicknames, if it holds more than one), such as ( 2000 * nickname / 2**16 ) milliseconds, assuming "nickname" is an unsigned quantity 🎲.

All the TRILL switches participating in an ESADI instance for some Data Label appear to ESADI to be adjacent 👯‍♀️. So the originator of any active ESADI-LSP fragment always appears to be on link, and to spread the burden of responding, it could be the RBridge that answers any ESADI-CSNP or PSNP request for that fragment 🤝. BUT under very rare circumstances, a version of the LSP fragment with a higher sequence number could actually be held by another ESADI RBridge on the link, so non-originators need to be able to respond eventually 😬. So when receiving a CSNP or PSNP causes the SRMflag (Send Routing Message flag [IS-IS]) to be set for an LSP fragment, the action is as specified in [IS-IS] for the originating ESADI RBridge of the fragment. However, at a non-originating ESADI RBridge, when changing the SRMflag from 0 to 1, the lastSent timestamp [IS-IS] is also set to the current time minus:

minimumLSPTransmissionInterval * Random (Jitter) / 100

(where minimumLSPTransmissionInterval, Random, and Jitter are as in [IS-IS]). This delays and jitters the transmission of the LSP fragment by non-originators 🕰️. It gives the originator more time to send the fragment, and gives that originator-transmitted copy more time to travel the likely multi-hop path to non-originators and clear the SRMflag for the fragment at non-originators 🛣️.

The multi-hop distribution tree method with Reverse Path Forwarding Check used for multicast distribution by TRILL will typically be less reliable than transmission over a single local broadcast link hop 📉. For LSP synchronization robustness, in addition to sending ESADI-CSNPs as usual when it's the DRB, an ESADI RBridge SHOULD ALSO transmit an ESADI-CSNP for an ESADI instance if ALL of the following conditions are met 🛡️:

• it sees one or more ESADI neighbors for that instance, and
• it does not believe it is the DRB for the ESADI instance, and
• it has not received or sent an ESADI-CSNP PDU for the instance for the average of the CSNP Time (see Section 6.1) of the DRB and its CSNP Time.

5. End Station Addresses

Next up, we're getting into the end station address stuff 🏠. The subsections below talk about end station address considerations in the context of ESADI 💜.

5.1. Learning Confidence Level 🎀

okay so the Confidence level mechanism [RFC6325] lets an RBridge campus manager make certain address learning sources win over others 💅. MAC addresses learned through a registration protocol like [802.1X] with a cryptographically based EAP [RFC3748] method might be seen as more reliable than stuff learned by just watching data traffic go by 👀. when that authenticated info gets sent over the ESADI protocol, the authentication in the TRILL ESADI-LSP packets could make tampering with it in transit very difficult 🔒. so it could make sense to announce that kind of info via ESADI with a high Confidence, so it gets used over anything learned from data observation. periodt 💖

5.2. Forgetting End Station Addresses 🧹

end station addresses learned through the TRILL ESADI protocol should be forgotten through changes in ESADI-LSPs ✨. the originating RBridge gets to decide when to remove that info from its ESADI-LSPs, so the timeout is up to it (or up to ESADI protocol timeouts if the originating RBridge becomes unreachable 🫥).

now, if RBridge RBn is in the TRILL ESADI protocol for Data Label X but no longer wants to participate in ESADI, it bounces out like this 👋: (1) it clears the ESADI Participation bit in the appropriate Interested VLANs or Interested Labels sub-TLV, and (2) it sends a final ESADI-LSP that nulls out its ESADI-LSP information. bye bestie 🦋

5.3. Duplicate MAC Address 👯

okay this one is lowkey the drama 🍿. with ESADI, it's possible to persistently see the same MAC address in the same Data Label being advertised as reachable by two or more RBridges. the way [RFC6325] handles this is updated by this document 🛠️. we're replacing the last sentence of the last paragraph of Section 4.2.6 of [RFC6325] with the new text below, to get better traffic-spreading while avoiding possible address flip-flopping.

here's the background 🧠. say some end station (or set of end stations) ESn has two or more ports with the same MAC address in the same Data Label, and those ports are connected to different RBridges (RB1, RB2, ...) by separate links. with ESADI, some other RBridge, RB0, can persistently see that MAC address in that Data Label connected to multiple RBridges. when RB0 ingresses a frame from ES0 that's destined for that MAC and label, the current [RFC6325] text allows a wide range of behavior. [RFC6325] would let RB0 use a rule like "always encapsulate to the egress with the lowest System ID," which sends all that traffic through only one egress RBridge and one end station port 🙃. with that, there's no load-spreading, even with multiple different ingress RBridges and/or different MAC addresses with the same reachability. [RFC6325] would also let RB0 send different traffic to different egresses by doing ECMP (Equal Cost Multipath) at a flow level, which would likely mean return traffic for RB0 to egress to ES0 comes from various of RB1, RB2, ... for the same MAC and label. that address reachability flip-flopping, as seen at RB0, could cause problems 😵‍💫.

this update fixes that by requiring RB0 to use one of two policies 🙌: (1) only encapsulate to one egress RBridge for any particular MAC and label, but pick that egress pseudorandomly, based on the topology (including MAC reachability), or (2) if RB0 won't be disturbed by the returning TRILL Data packets showing the same MAC, or by label flip-flopping between different ingresses, RB0 may use ECMP. assuming multiple ingress RBridges and/or multiple MAC and label addresses, strategy 1 should result in load-spreading without address flip-flopping, while strategy 2 will produce better load-spreading than strategy 1, but with address flip-flopping from the point of view of RB0 🎢.

OLD [RFC6325] Section 4.2.6 text, the bit we're replacing 🗑️:

"... If confidences are also tied between the duplicates, for
consistency it is suggested that RB2 direct all such frames (or
all such frames in the same ECMP flow) toward the same egress
RBridge; however, the use of other policies will not cause a
network problem since transit RBridges do not examine the
Inner.MacDA for known unicast frames."

NEW [RFC6325] Section 4.2.6 text, the glow-up ✨:

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

1. In a pseudorandom way [RFC4086], select one of the egress
   RBridges that is least cost from RB2 and to which the
   destination MAC appears to be attached, and send all traffic
   for the destination MAC and VLAN (or FGL [RFC7172]) to that
   egress.  This pseudorandom choice need only be changed when
   there is a change in campus topology or MAC attachment
   information.  Such pseudorandom selection will, over a
   population of ingress RBridges, probabilistically spread
   traffic over the possible egress RBridges.  Reasonable inputs
   to the pseudorandom selection are the ingress RBridge System ID
   and/or nickname, the VLAN or FGL, the destination MAC address,
   and a vector of the RBridges with connectivity to that MAC and
   VLAN or FGL.  There is no need for different RBridges to use
   the same pseudorandom function.

   As an example of such a pseudorandom function, if there are k
   egress RBridges (RB0, RB1, ..., RB(k-1)) all reporting
   attachment to address MACx in Data Label DLy, then an ingress
   RBridge RBin could select the one to which it will send all
   unicast TRILL Data packets addressed to MACx in DLy based on
   the following:

      FNV-32(RBin | MACx | DLy | RB0 | RB1 | ... | RB(k-1)) mod k

      where the FNV (Fowler/Noll/Vo) algorithm is specified in
      [FNV], RBx means the nickname for RBridge RBx, "|" means
      concatenation, MACx is the destination MAC address, DLy is
      the Data Label, and "mod k" means the integer division
      remainder of the output of the FNV-32 function considered as
      a positive integer divided by k.

2. If RB2 supports ECMP and will not be disturbed by return
   traffic from the same MAC and VLAN (or FGL [RFC7172]) coming
   from a variety of different RBridges, then it MAY send traffic
   using ECMP at the flow level to the egress RBridges that are
   least cost from RB2 and to which the destination MAC appears to
   be attached."

---

6. ESADI-LSP Contents 📦

the only PDUs used in ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDUs 💌. right now, an ESADI-LSP holds zero or more MAC-Reachability TLVs, optionally an Authentication TLV, and exactly one ESADI parameter APPsub-TLV. other similar data might show up later, and just like in [IS-IS], an ESADI instance ignores any TLVs or sub-TLVs it doesn't understand 🤷‍♀️. because these PDUs are formatted as Extended Level 1 Circuit Scope (E-L1CS) PDUs [RFC7356], the Type and Length fields in the TLVs are 16-bit 🔢.

this section gives the format for the ESADI Parameter APPsub-TLV, points to the reference for the ESADI MAC-Reachability TLV, and talks about default authentication configuration 🎀.

for robustness 🛡️, the payload for an ESADI-LSP number zero, and for any ESADI-CSNP or ESADI-PSNP covering fragment zero, MUST NOT exceed 1470 minus 24 bytes in length (1446 bytes) if it has an Inner.VLAN, or 1470 minus 28 bytes (1442 bytes) if it has an Inner.FGL. but if an ESADI-LSP number zero, or such an ESADI-CSNP or ESADI-PSNP, comes in longer, it still gets processed normally 🙏. (as Section 4.3.1 of [RFC6325] says, 1470 bytes was picked to make it super unlikely that a TRILL control packet, even with reasonable extra headers, tags, and/or encapsulation, would run into MTU problems on an inter-RBridge link 🚦.)

6.1. ESADI Parameter Data 🧁

Figure 4 shows 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's missing from ESADI-LSP number zero, or if ESADI-LSP number zero isn't known, the priority for the sending RBridge defaults to 0x40 and CSNP Time defaults to 30. if there's more than one occurrence in ESADI-LSP number zero, the first occurrence is used. occurrences of the ESADI Parameter APPsub-TLV in non-zero ESADI-LSP fragments get ignored 🙅‍♀️.

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

                Figure 4: ESADI Parameter APPsub-TLV

here's what each field does 📝:

• Type: set to the ESADI-PARAM sub-TLV (TRILL APPsub-TLV type 0x0001). it's two bytes, because this APPsub-TLV shows up in an extended TLV [RFC7356] 💅.
• Length: variable, with a minimum of 3, but it must fit within the ESADI packet. this field is encoded as an unsigned integer in network byte order [RFC7356] 🔢.
• R: a reserved bit that MUST be sent as zero and ignored on receipt 🚫.
• Priority: gives the originating RBridge's priority for being the DRB on the ESADI instance virtual link (see Section 3) for the Data Label in which the PDU containing the parameter data was sent 👑. it's an unsigned 7-bit integer, and the larger the magnitude, the higher the priority. it defaults to 0x40 for an RBridge participating in ESADI that hasn't been configured 🙌.
• CSNP Time: an unsigned byte giving the number of seconds during which the originating RBridge, if it's the DRB on the ESADI virtual link, will send at least three ESADI-CSNP PDUs ⏱️. it defaults to 30 seconds for an RBridge participating in ESADI that hasn't been configured ✨.
• Flags: a byte of flags for the originating ESADI instance, laid out like this 🚩:

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

the UN flag says the RBridge originating the ESADI-LSP, including this ESADI parameter data, will accept and properly process ESADI PDUs sent by TRILL unicast (see Section 4.1) 🦄. the remaining RESV bits are reserved for future use and MUST be sent as zero and ignored on receipt 🫶.

• Reserved for future expansion: future versions of the ESADI Parameter APPsub-TLV might carry extra info 🔮. a receiving ESADI RBridge ignores any additional data here, unless it implements that future expansion 🤍.

6.2. MAC-Reachability TLV ✨

okay so the main stuff in ESADI-LSP PDUs is the MAC-Reachability (MAC-RI) TLVs from [RFC6165] 🫶 each one carries one or more unicast MAC addresses of end stations that are on a port and in a VLAN where the originating RBridge is the Appointed Forwarder. it also includes a 1-octet unsigned Confidence value in the range 0-254 💅 if a TLV shows up with a Confidence of 255, the receiver treats it as 254. this is so any address info it received can still be overridden by local info that's 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 does show up in the MAC-RI TLV, it gets ignored. in the ESADI PDU, only the Inner.VLAN or Inner.FGL tag tells you which Data Label the ESADI-LSP applies to. so many tags, bestie 😭

---

6.3. Default Authentication 🔐

the Authentication TLV may be included in ESADI PDUs [RFC5310] [IS-IS]. the default for ESADI PDU authentication is based on the state of TRILL IS-IS shared secret authentication for TRILL IS-IS LSP PDUs 🧚 if TRILL IS-IS authentication and ESADI are both implemented at a TRILL switch, then ESADI MUST be able to use the authentication algorithms implemented for TRILL IS-IS and implement the keying material derivation function given below. if ESADI authentication has been manually configured, that configuration isn't restricted by the TRILL IS-IS security config. main character energy 👑

if TRILL IS-IS authentication isn't in effect for LSP PDUs originated by a TRILL switch, then ESADI PDUs originated by that switch are unsecured by default too 🌸

if 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 is derived from the IS-IS LSP shared secret keying material, as detailed below. however, such authentication MAY be configured to use some other keying material 🦋

HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key )

in the algorithm above, HMAC-SHA256 is as described in [FIPS180] and [RFC6234], and "TRILL ESADI" is the 11-byte US ASCII [ASCII] string indicated. IS-IS-LSP-shared-key is the secret keying material the originating TRILL switch uses for IS-IS LSP authentication 🎀

---

7. IANA Considerations 🌈

okay, IANA stuff! 🎀 the allocation and registry details are below. three new sub-registries got created in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry, located at <http://www.iana.org/assignments/trill-parameters>. two of them are in Section 7.1 and one is in Section 7.2. a bunch of code points got assigned too 🍓

7.1. ESADI Participation and Capability Flags 💜

IANA Action 1:

IANA created a new sub-registry called "Interested VLANs Flag Bits" in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry.

• Sub-registry: Interested VLANs Flag Bits
• Registration Procedures: IETF Review
• Note: These bits appear in the Interested VLANs record within the Interested VLANs and Spanning Tree Roots Sub-TLV (INT-VLAN) specified in [RFC7176].
• References: [RFC7176], [RFC7357]

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

creating this sub-registry assigned bit 3 as the ESADI Participation bit in the Interested VLANs and Spanning Tree Roots sub-TLV. If The ESADI Participation bit is a one, it means the originating RBridge is participating in ESADI for the indicated Data Label(s) ✨

IANA Action 2:

IANA created another new sub-registry, called "Interested Labels Flag Bits", in the same "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry.

• Sub-registry: Interested Labels Flag Bits
• Registration Procedures: IETF Review
• Note: These bits appear in the Interested Labels record within the Interested Labels and Spanning Tree Roots Sub-TLV (INT-LABEL) specified in [RFC7176].
• References: [RFC7176], [RFC7357]

 Bit  Mnemonic  Description                      Reference
 ---  --------  -----------                      ---------
   0     M4     IPv4 Multicast Router Attached   [RFC7176]
   1     M6     IPv6 Multicast Router Attached   [RFC7176]
   2     BM     Bit Map                          [RFC7176]
   3     ES     ESADI Participation              [RFC7357]
  4-7     -     Unassigned

creating this one assigned bit 3 as the ESADI Participation bit in the Interested Labels and Spanning Tree Roots sub-TLV. If The ESADI Participation bit is a one, it means the originating RBridge is participating in ESADI for the indicated Data Label(s) 💅

7.2. TRILL GENINFO TLV 🧚

IANA Action 3:

IANA allocated the IS-IS Application Identifier 1 under the Generic Information TLV (#251) [RFC6823] for TRILL 🌟

IANA Action 4:

IANA created a sub-registry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry, like this:

• Sub-registry: TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1
• Registration Procedures: IETF Review with additional requirements on the documentation of the use being registered as specified in Section 7.2 of [RFC7357].
• Note: Types greater than 255 are only usable in contexts permitting a type larger than one byte, such as extended TLVs [RFC7356].
• Reference: [RFC7357]

       Type      Name              Reference
    ----------  --------          -----------
            0   Reserved          [RFC7357]
            1   ESADI-PARAM       [RFC7357]
        2-254   Unassigned        [RFC7357]
          255   Reserved          [RFC7357]
    256-65534   Unassigned        [RFC7357]
        65535   Reserved          [RFC7357]

TRILL APPsub-TLV Types 2 through 254 and 256 through 65534 are available for assignment by IETF Review. the RFC that causes such an assignment will also include a discussion of security issues and of the rate of change of the information being advertised 🔥 TRILL APPsub-TLVs MUST NOT alter basic IS-IS protocol operation, including the establishment of adjacencies, the update process, and the decision process for TRILL IS-IS [IS-IS] [RFC1195] [RFC7177]. the TRILL Generic Information TLV MUST NOT be used in an IS-IS instance zero [RFC6822] LSP, but it may be used in Flooding Scoped LSPs (FS-LSPs) [RFC7356] 🫶

the V, I, D, and S flags in the initial flags byte of a TRILL Generic Information TLV have the meanings specified in [RFC6823], but they aren't currently used. TRILL operates as a Level 1 IS-IS area, and no semantics are assigned to including an IPv4 and/or IPv6 address via the I and V flags. so these I and V flags MUST be zero. however, if either or both are one, the space that would be taken by an IPv4 and/or IPv6 address, respectively, gets skipped over and ignored 🙈 also, multilevel IS-IS is an obvious extension for TRILL [MultiLevel], and future IETF Standards Actions may update or obsolete this specification to allow any or all of these flags in the TRILL GENINFO TLV ✨

the ESADI Parameters information, which TRILL APPsub-TLV 1 is hereby assigned for, is compact and slow changing (see Section 6.1) 🌸

for security considerations related to ESADI and the ESADI Parameter APPsub-TLV, see Section 8 🔐

---

8. Security Considerations 🚨

ESADI PDUs can be authenticated by including the Authentication TLV [RFC5310]. the defaults for that authentication are described in Section 6.3 💖

the ESADI-LSP data mainly announces MAC address reachability within a Data Label. in some cases, that reachability can be an authenticated registration. for example, a Layer 2 authenticated registration using cryptographically based EAP (Extensible Authentication Protocol [RFC3748]) methods via [802.1X]. when you combine these techniques, ESADI MAC reachability info can be substantially more trustworthy than MAC reachability learned from watching the data plane 🥹 still, ESADI means trusting all the other RBridges in the TRILL campus, at least the ones that have the keying material needed to build a valid Authentication TLV 😬

that said, there may be cases where authenticated registration is used for end stations, because of a significant threat of forged packets on end station links, but it isn't necessary to authenticate ESADI PDUs, since that threat isn't present for inter-RBridge trunks. for example, a TRILL campus with secure RBridges and inter-RBridge links configured as trunks, but with some end stations connected via IEEE 802.11 wireless access links, might use 802.11 authentication for connecting those end stations and might not necessarily authenticate ESADI PDUs. note that if the IS-IS LSPs in a TRILL campus are authenticated, perhaps because of a concern about forged packets, the ESADI PDUs will be authenticated by default, as provided in Section 6.3 🔒

MAC reachability learned from the data plane (the TRILL default) gets overwritten by any future learning of the same type. ESADI advertisements are represented in the Data Label scoped link state database. so ESADI makes visible any multiple attachments of the same MAC address within a Data Label to different RBridges (see Section 5.3). that may or may not be an error or misconfiguration, but ESADI at least makes it explicitly and persistently visible, which wouldn't be the case with data plane learning 👀

for general TRILL security considerations, see [RFC6325] 🦋

8.1. Privacy Considerations 🕵️‍♀️🔐

okay so ESADI's address reachability info has real privacy stakes in lots of situations, but not all of them, so let's break it down bestie 💖

picture a TRILL campus with independent user end stations at the edge. those MAC addresses could literally identify the users behind them 😭 their reachability is sensitive info, and if it gets logged, it could reveal user details. yikes.

now flip it. if TRILL is running an Internet Exchange Point (IXP) to connect Internet Service Providers (ISPs), the MAC addresses advertised in ESADI would usually be the ISP's directly connected IP router ports, because Layer 3 routers bound the TRILL campus. so there are few privacy concerns there ✨

BUT (and this is the plot twist 🙈) a modest amount of MAC attachment history, like maybe a few days' worth, can be super useful for managing a network and troubleshooting problems. it might also be legally required, or needed for billing purposes or stuff like that 🧾

so network operators need to find a reasonable balance between these competing considerations 🎀 customized for their own networks where ESADI is in use. and they should not keep logs of MAC reachability information for any longer than is clearly required. main character energy is knowing when to let the logs go 💅

---

9. Acknowledgements 🫶

the authors thank these lovelies, listed in alphabetic order, for their suggestions and contributions 💜

David Black, Somnath Chatterjee, Adrian Farrel, Stephen Farrell, Sujay Gupta, Russ Housley, Pearl Liang, Kathleen Moriarty, Thomas Narten, Erik Nordmark, and Mingui Zhang. 🌸

---

10. References 📚

10.1. Normative References

• [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. 🧠

• [FIPS180] "Secure Hash Standard (SHS)", National Institute of Standards and Technology, Federal Information Processing Standard (FIPS) 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf>.
• [IS-IS] ISO/IEC 10589:2002, Second Edition, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", 2002.
• [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
• [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
• [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
• [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
• [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
• [RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
• [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", RFC 6823, December 2012.
• [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014.
• [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
• [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
• [RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.
• [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, September 2014.

10.2. Informative References

• [802.1X] IEEE 802.1, "IEEE Standard for Local and metropolitan area networks--Port-Based Network Access Control", IEEE Standard 802.1X-2010, February 2010.
• [FNV] Fowler, G., Noll, L., Vo, K., and D. Eastlake 3rd, "The FNV Non-Cryptographic Hash Algorithm", Work in Progress, April 2014.
• [MultiLevel] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, June 2014.
• [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
• [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
• [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
• [VLANmapping] Perlman, R., Rijhsinghani, A., Eastlake 3rd, D., Banerjee, A., and D. Dutt, "TRILL: Campus Label and Priority Regions", Work in Progress, January 2014.

---

Appendix A. Interoperability and Changes to RFC 6325 🦋

okay this appendix is the tea ☕ it summarizes the significant changes this document makes to the TRILL base protocol specification [RFC6325]. simultaneous use of [RFC6325] ESADI and the ESADI in this document in a TRILL campus is very unlikely, since [RFC6325] ESADI isn't really deployed. but the appendix still talks through the interoperability considerations for each change, just in case 👀

A.1. ESADI PDU Changes 🧩

the ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads change from the IS-IS Level 1 format [IS-IS] to the Extended Level 1 Circuit Scope format (E-L1CS) specified in [RFC7356]. this change is NOT backwards compatible with [RFC6325] 😬 it's made because E-L1CS can carry 256 times more information than the base IS-IS format. that extra room is expected to be needed, in some situations, for end station addressing info or other similar address and reachability info added to ESADI in the future ✨

the PDU numbers used for the ESADI LSP, CSNP, and PSNP PDUs in [RFC6325] are 18, 24, and 26 [IS-IS]. with this document, the format changes and the PDU numbers change to 10, 11, and 12 [RFC7356]. different PDU numbers make sure a PDU won't get mis-parsed 🙌 so implementations of this document and [RFC6325] ESADI will discard each other's PDUs. address reachability and other info sent through one type of ESADI implementation only gets shared with the same type, and the two communities won't share anything with each other 🫤

BUT here's the fun part: RBridges can use the TRILL mandatory-to-implement, enabled-by-default data plane address learning in addition to ESADI. (Section 5 of this document and the material it references explain how to handle conflicts between different sources of address reachability information.) just leaving data plane address learning enabled gives you a smooth, incremental migration from [RFC6325] ESADI to the ESADI spec in this document, if that's ever needed 🦋 data plane learning fills in any gaps caused by the two ESADI types not talking to each other, though you lose the speed and security advantages of ESADI 💔

A.2. Unicasting Changes 📮

unicasting of ESADI PDUs is optionally supported. it replaces Section 4.6.2.2 of [RFC6325] with the new text in Section 4.1 of this document. this unicast support is backwards compatible because it's only used when the recipient RBridge signals its support. ✅

A.3. Message Timing Changes and Suggestions ⏱️

these timing-related ESADI message changes and suggestions are included in this document:

1. provide for staggered delay for non-originators of ESADI-LSP fragments in response to requests for such fragments by CSNP and PSNP messages.
2. suggest staggered timing of unicast ESADI-LSPs when a new ESADI RBridge appears on the ESADI virtual link.

these only affect message timing, to minimize congestion 🚦 if a message gets lost (due to congestion or otherwise), it'll be retransmitted later as a normal part of the robust flooding mechanism ESADI uses. no drama, just resilience 💪

A.4. Duplicate Address Reachability 👯

handling persistent reachability of the same MAC within the same Data Label from two or more RBridges is substantially modified. this includes explicitly replacing some text in Section 4.2.6 of [RFC6325] (see Section 5.3 of this document). there's no problem with a mix of ESADI implementations in a TRILL campus, some conforming to [RFC6325] and some to this document, when handling this condition. the more implementations follow the improved behavior in this document, the better the traffic-spreading gets, and the less likely address flip-flopping problems are 🌈

---

Authors' Addresses 💌

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

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

Radia Perlman
EMC
2010 256th Ave. NE, #200
Bellevue, WA  98007
USA
EMail: Radia@alum.mit.edu

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

Olen Stokes
Extreme Networks
2121 RDU Center Drive, Suite 300
Morrisville, NC  27560
USA
EMail: ostokes@extremenetworks.com