diff options
Diffstat (limited to 'doc/rfc/rfc7357.txt')
| -rw-r--r-- | doc/rfc/rfc7357.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc7357.txt b/doc/rfc/rfc7357.txt new file mode 100644 index 0000000..fe91fda --- /dev/null +++ b/doc/rfc/rfc7357.txt @@ -0,0 +1,1739 @@ + + + + + + +Internet Engineering Task Force (IETF) H. Zhai +Request for Comments: 7357 F. Hu +Updates: 6325 ZTE +Category: Standards Track R. Perlman +ISSN: 2070-1721 Intel Labs + D. Eastlake 3rd + Huawei + O. Stokes + Extreme Networks + September 2014 + + + Transparent Interconnection of Lots of Links (TRILL): + End Station Address Distribution Information (ESADI) Protocol + +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 multipathing of both unicast and + multicast traffic. Devices that implement the TRILL protocol are + called TRILL switches or RBridges (Routing Bridges). + + ESADI (End Station Address Distribution Information) is an optional + protocol by which a TRILL switch can communicate, in a Data Label + (VLAN or fine-grained label) scoped way, end station address and + reachability information to TRILL switches participating in ESADI for + the relevant Data Label. This document updates RFC 6325, + specifically the documentation of the ESADI protocol, and is not + backwards compatible. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7357. + + + + + + +Zhai, et al. Standards Track [Page 1] + +RFC 7357 TRILL: ESADI September 2014 + + +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) 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhai, et al. Standards Track [Page 2] + +RFC 7357 TRILL: ESADI September 2014 + + +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 + + + + + + + + + + + + + + +Zhai, et al. Standards Track [Page 3] + +RFC 7357 TRILL: ESADI September 2014 + + +1. Introduction + + The 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 multipathing of both unicast and multicast + traffic. TRILL accomplishes this with the IS-IS (Intermediate System + to Intermediate System) [IS-IS] [RFC1195] [RFC7176] link-state + routing protocol using a header with a hop count. The design + supports optimization of the distribution of multi-destination frames + and two types of data labeling: VLANs (Virtual Local Area Networks) + [RFC6325] 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 these is the ESADI + (End Station Address Distribution Information) protocol, which is an + optional Data Label scoped way by which TRILL switches can + communicate with each other information such as end station addresses + and their TRILL switch of attachment. A TRILL switch that is + announcing interest in a Data Label MAY use the ESADI protocol to + announce the end station address of some or all of its attached end + stations in that Data Label to other TRILL switches that are running + ESADI for that Data Label. (In the future, ESADI may also be used + for other address and reachability information.) + + By default, TRILL switches with connected end stations learn + addresses from the data plane when ingressing and egressing native + frames, although such learning can be disabled. The ESADI protocol's + potential advantages over data plane learning include the following: + + 1. Security advantages: + + a) 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]). + + b) The ESADI protocol supports cryptographic authentication of its + message payloads for more secure transmission. + + 2. Fast update advantages: The ESADI protocol provides a fast update + of end station MAC (Media Access Control) addresses and their + TRILL switch of attachment. If an end station is unplugged from + one TRILL switch and plugged into another, ingressed frames with + that end station's MAC address as their destination can be + + + +Zhai, et al. Standards Track [Page 4] + +RFC 7357 TRILL: ESADI September 2014 + + + black-holed. That is, they can be sent just to the older egress + TRILL switch that the end station was connected to until cached + address information at some remote ingress TRILL switch times out, + possibly for tens of seconds [RFC6325]. + + MAC address reachability information, some ESADI parameters, and + optional authentication information are carried in ESADI packets + rather than in the TRILL IS-IS protocol. As specified below, ESADI + is, for each Data Label, a virtual logical topology overlay in the + TRILL topology. An advantage of using ESADI over using TRILL IS-IS + is that the end station attachment information is not flooded to all + TRILL switches but only to TRILL switches advertising ESADI + participation for the Data Label in which those end stations occur. + +1.1. Content and Precedence + + This document updates [RFC6325], the TRILL base protocol + specification, replacing the description of the TRILL ESADI protocol + (Section 4.2.5 of [RFC6325], including all subsections), providing + more detail on ESADI, updating other ESADI-related sections of + [RFC6325], and prevailing over [RFC6325] in any case where they + conflict. For this reason, familiarity with [RFC6325] is + particularly assumed. These changes include a change to the format + of ESADI-LSPs (ESADI Link State Protocol Data Units) that is not + backwards compatible; this change is justified by the substantially + increased amount of information that can be carried and in light of + the very limited, if any, deployment of RFC 6325 ESADI. These + changes are further discussed in Appendix A. + + Section 2 of this document is the ESADI protocol overview. Section 3 + specifies ESADI DRB (Designated RBridge) determination. Section 4 + discusses the processing of ESADI PDUs. Section 5 discusses + 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], in addition to + 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]. + + + +Zhai, et al. Standards Track [Page 5] + +RFC 7357 TRILL: ESADI September 2014 + + + 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 + + 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 implemented by all RBridges in a campus. There is a + separate ESADI instance for each Data Label (VLAN or FGL) if ESADI is + being used for that Data Label. In essence, for each such Data + Label, there is a modified instance of the IS-IS reliable flooding + mechanism in which ESADI RBridges may choose to participate. (These + are not the instances specified in [RFC6822].) Multiple ESADI + instances may share implementation components within an RBridge as + long as that sharing preserves the independent operation of each + instance of the ESADI protocol. For example, the ESADI link state + database could be a single database with a field in each record + indicating the Data Label to which it applies, or it could be a + separate database per Data Label. However, the ESADI update process + operates separately for each ESADI instance and independently from + the TRILL IS-IS update process. + + ESADI does no routing calculations, so there is no reason for + pseudonodes in ESADI and none are created. (Pseudonodes [IS-IS] are + a construct for optimizing routing calculations.) Furthermore, a + relatively large amount of ESADI data will have to be distributed, + under some circumstances, using ESADI mechanisms; this would require + a large number of ESADI-LSP fragments. ESADI-LSP, ESADI-CSNP, and + ESADI-PSNP (ESADI Link State PDU, Complete Sequence Number PDU, and + Partial Sequence Number PDU) payloads are therefore formatted as + Extended Level 1 Circuit Scope (E-L1CS) PDUs [RFC7356] (see also + Section 6). This allows up to 2**16 fragments but does not support + link state data associated with pseudonodes. + + + +Zhai, et al. Standards Track [Page 6] + +RFC 7357 TRILL: ESADI September 2014 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhai, et al. Standards Track [Page 7] + +RFC 7357 TRILL: ESADI September 2014 + + + TRILL ESADI packets sent on an Ethernet link are structured as shown + in Figure 2. The outer VLAN tag will not be present if it was not + included by the Ethernet port that sent the packet. + + 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 is + being unicast, the Next Hop Destination Address is the unicast + address of the next-hop RBridge. The VLAN for the Outer.VLAN + + + +Zhai, et al. Standards Track [Page 8] + +RFC 7357 TRILL: ESADI September 2014 + + + information, if present, will be the Designated VLAN for the link on + which the packet is sent. The V and R fields will be zero while the + M 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 to which the ESADI packet applies. The Origin RBridge MAC + Address or Inner.MacSA MUST be a MAC address unique across the campus + owned by 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 + + + + + + +Zhai, et al. Standards Track [Page 9] + +RFC 7357 TRILL: ESADI September 2014 + + +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). + + + + + + + + + +Zhai, et al. Standards Track [Page 10] + +RFC 7357 TRILL: ESADI September 2014 + + +2.3. ESADI Payloads + + TRILL ESADI packet payloads are structured like IS-IS Extended + Level 1 Circuit Scope (E-L1CS) LSP, CSNP, and PSNP PDUs [RFC7356], + except as indicated below, but are always TRILL encapsulated on the + wire as if they were TRILL Data packets. The information distributed + by the ESADI protocol includes a list of local end station MAC + addresses connected to the originating RBridge and, for each such + address, a 1-octet unsigned "Confidence" rating in the range 0-254 + (see Section 6.2). It is entirely up to the originating RBridge + which locally connected MAC addresses it wishes to advertise via + ESADI and with what Confidence. It MAY advertise all, some, or none + of such addresses. In addition, some ESADI parameters of the + advertising RBridge (see Section 6.1) and, optionally, authentication + information (see Section 6.3) are included. Future uses of ESADI may + distribute other similar address and reachability information. + + TRILL ESADI-LSPs MUST NOT contain a Data Label ID in their payload. + The Data Label to which the ESADI data applies is the Data Label of + the TRILL Data packet enclosing the ESADI payload. If a Data Label + ID could occur within the payload, it might conflict with that TRILL + Data packet Data Label and could conflict with any future Data Label + mapping scheme that may be adopted [VLANmapping]. If a VLAN or FGL + ID field within an ESADI-LSP PDU does include a value, that field's + contents MUST be ignored. + +3. ESADI DRB (Designated RBridge) Determination + + Because ESADI does no adjacency announcement or routing, the + ESADI-DRB never creates a pseudonode. However, a DRB [RFC7177] is + still needed to issue ESADI-CSNP PDUs and respond to ESADI-PSNP PDUs + for ESADI-LSP synchronization. + + Generally speaking, the DRB election on the ESADI virtual link (see + Section 2.1) operates similarly to the DRB election on a TRILL IS-IS + broadcast link, as described in Section 4.2.1 ("DRB Election + Details") of [RFC7177], with the following exceptions: in the Data + Label X ESADI-DRB election at RB1 on an ESADI virtual link, the + candidates are the local ESADI instance for Data Label X and all + remote ESADI instances at RBridges that are (1) data reachable from + RB1 [RFC7180] and (2) announcing in their TRILL IS-IS LSP that they + are participating in ESADI for Data Label X. The winner is the + instance with the highest ESADI Parameter 7-bit priority field with + ties broken by the System ID, comparing fields as unsigned integers + with the larger magnitude considered higher priority. "SNPA/MAC + address" (Subnetwork Point of Attachment / MAC address) is not + considered in this tiebreaking, and there is no "Port ID". + + + + +Zhai, et al. Standards Track [Page 11] + +RFC 7357 TRILL: ESADI September 2014 + + +4. ESADI PDU Processing + + Data Label X ESADI neighbors are usually not connected directly by a + physical link but are always logically connected by a virtual link + (see Section 2.1). There could be hundreds or thousands of ESADI + RBridges (TRILL switches) on the virtual link. The only PDUs used in + ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDUs. In + particular, there are no Hello or MTU PDUs, because ESADI does not + build a topology, does not do any routing calculations, and does not + determine MTU. Instead, ESADI uses the distribution trees and the Sz + campus minimum link MTU determined by the core TRILL IS-IS (see + [RFC6325] and [RFC7180]). + +4.1. Unicasting ESADI PDUs + + For [IS-IS], PDU multicasting is normal on a local link and no effort + is made to optimize to unicast, because on the typical physical link + for which IS-IS was designed (commonly a piece of multi-access + Ethernet cable), any frame made the link busy for that frame time. + However, to ESADI instances, what appears to be a simple multi-access + link is generally a set of multi-hop distribution trees that may or + may not be pruned. Thus, transmitting a multicast frame on such a + tree can impose a substantially greater load than transmitting a + unicast frame. This load may be justified if there are likely to be + multiple listeners but may not be justified if there is only one + recipient of interest. For this reason, under some circumstances, + ESADI PDUs MAY be TRILL unicast if it is confirmed that the + destination RBridge supports receiving unicast ESADI PDUs (see + Section 6.1). + + The format of a unicast ESADI packet is the format of a multicast + TRILL ESADI packet as described in Section 2 above, except as + follows: + + o On an Ethernet link, in the outer Ethernet header the Outer.MacDA + is the unicast address of the next-hop RBridge. + + o In the TRILL Header, the M bit is set to zero and the Egress + Nickname is the nickname of the destination RBridge. + + + + + + + + + + + + +Zhai, et al. Standards Track [Page 12] + +RFC 7357 TRILL: ESADI September 2014 + + + To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is + replaced with the following: + + 4.6.2.2. TRILL ESADI Packets + + If M = 1, the egress nickname designates the distribution tree. + The packet is forwarded as described in Section 4.6.2.5. In + addition, if (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 is decapsulated and provided to that local ESADI + protocol. + + If M = 0 and the egress nickname is not that of the receiving + RBridge, the packet is forwarded as for known unicast TRILL Data + frames 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 is + decapsulated and processed if it meets the three numbered + conditions in the paragraph above; otherwise, it is discarded. + + The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above refer to + those sections in [RFC6325]. + +4.2. General Transmission of ESADI PDUs + + Following the usual [IS-IS] rules, an ESADI instance does not + transmit any ESADI PDUs if it has no ESADI adjacencies. Such + transmission would just be a waste of bandwidth. + + The MTU available to ESADI payloads is at least 24 bytes less than + that available to TRILL IS-IS because of the additional fields + required ( 2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) + + 6(Inner.MacSA) + 4/8(Data Label) bytes ). Thus, the inner ESADI + payload, starting with the Intradomain Routeing Protocol + Discriminator byte, MUST NOT exceed Sz minus 24 for a VLAN ESADI + instance or Sz minus 28 for an FGL ESADI instance; however, if a + larger payload is received, it is processed normally (see [RFC6325] + and [RFC7180] for discussions of Sz and MTU). + + In all cases where this document says that an ESADI PDU is multicast, + if the transmitting RBridge has only one neighbor and that neighbor + advertises support for unicast, the PDU MAY be unicast (see + Section 4.1). + + + + + + +Zhai, et al. Standards Track [Page 13] + +RFC 7357 TRILL: ESADI September 2014 + + + A priority bit to indicate 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 is important that the ESADI + Parameter APPsub-TLV get through promptly. This bit SHOULD NOT be + set on other ESADI-LSP fragments to avoid giving undue priority to + less urgent PDUs. + +4.3. General Receipt of ESADI PDUs + + In contrast with Layer 3 IS-IS PDU acceptance tests, which check the + source inner and outer SNPA/MAC in order to verify that a PDU is from + an adjacent TRILL switch, in TRILL ESADI adjacency is based on the + system ID, so the system ID inside the PDU is all that is tested for. + + If an ESADI instance believes that it has no ESADI neighbors, it + ignores any ESADI PDUs it receives. + +4.4. ESADI Reliable Flooding + + The IS-IS reliable flooding mechanism (the Update Process) is + modified for ESADI in the ways listed below. Except as otherwise + stated, the ESADI update process works as described in [IS-IS], + [RFC1195], and [RFC7356]. + + When an ESADI instance sees that it has a new ESADI neighbor, its + self-originated ESADI-LSP fragments are scheduled to be sent and MAY + be unicast to that neighbor if the neighbor is announcing in its LSP + that it supports unicast ESADI (see Section 6.1). If all the other + ESADI instances for the same Data Label send their self-originated + ESADI-LSPs immediately, there may be a surge of traffic to that new + neighbor. Therefore, the ESADI instances SHOULD wait an interval of + time before sending their ESADI-LSP(s) to a new neighbor. The + interval time value is up to the device implementation. One + suggestion is that the interval time can be assigned a random value + with a range based on the RBridge's nickname (or any one of its + nicknames, if it holds more than one), such as ( 2000 * nickname / + 2**16 ) milliseconds, assuming "nickname" to be an unsigned quantity. + + All the TRILL switches participating in an ESADI instance for some + Data Label appear to ESADI to be adjacent. Thus, the originator of + any active ESADI-LSP fragment always appears to be on link and, to + spread the burden of such a response, could be the RBridge to respond + to any ESADI-CSNP or PSNP request for that fragment. However, under + very rare circumstances, it could be that some version of the LSP + fragment with a higher sequence number is actually held by another + ESADI RBridge on the link, so non-originators need to be able to + respond eventually. Thus, when the receipt of a CSNP or PSNP causes + the SRMflag (Send Routing Message flag [IS-IS]) to be set for an LSP + + + +Zhai, et al. Standards Track [Page 14] + +RFC 7357 TRILL: ESADI September 2014 + + + fragment, action is as specified in [IS-IS] for the originating ESADI + RBridge of the fragment; however, at a non-originating ESADI RBridge, + when changing the SRMflag from 0 to 1, the lastSent timestamp [IS-IS] + is also set to the current time minus + + minimumLSPTransmissionInterval * Random (Jitter) / 100 + + (where minimumLSPTransmissionInterval, Random, and Jitter are as in + [IS-IS]). This will delay and jitter the transmission of the LSP + fragment by non-originators. This gives the originator more time to + send the fragment and provides more time for such an originator- + transmitted copy to traverse the likely multi-hop path to + non-originators and clear the SRMflag for the fragment at + non-originators. + + The multi-hop distribution tree method with Reverse Path Forwarding + Check used for multicast distribution by TRILL will typically be less + reliable than transmission over a single local broadcast link hop. + For LSP synchronization robustness, in addition to sending + ESADI-CSNPs as usual when it is the DRB, an ESADI RBridge SHOULD also + transmit an ESADI-CSNP for an ESADI instance if all of the following + conditions are met: + + o it sees one or more ESADI neighbors for that instance, and + + o it does not believe it is the DRB for the ESADI instance, and + + o it has not received or sent an ESADI-CSNP PDU for the instance for + the average of the CSNP Time (see Section 6.1) of the DRB and its + CSNP Time. + +5. End Station Addresses + + The subsections below discuss end station address considerations in + the context of ESADI. + +5.1. Learning Confidence Level + + The Confidence level mechanism [RFC6325] allows an RBridge campus + manager to cause certain address learning sources to prevail over + others. MAC address information learned through a registration + protocol, such as [802.1X] with a cryptographically based EAP + [RFC3748] method, might be considered more reliable than information + learned through the mere observation of data traffic. When such + authenticated learned address information is transmitted via the + ESADI protocol, the use of authentication in the TRILL ESADI-LSP + packets could make tampering with it in transit very difficult. As a + result, it might be reasonable to announce such authenticated + + + +Zhai, et al. Standards Track [Page 15] + +RFC 7357 TRILL: ESADI September 2014 + + + information via the ESADI protocol with a high Confidence, so it + would be used in preference to any alternative learning from data + observation. + +5.2. Forgetting End Station Addresses + + The end station addresses learned through the TRILL ESADI protocol + should be forgotten through changes in ESADI-LSPs. The timeout of + the learned end station address is up to the originating RBridge that + decides when to remove such information from its ESADI-LSPs (or up to + ESADI protocol timeouts if the originating RBridge becomes + unreachable). + + If RBridge RBn participating in the TRILL ESADI protocol for Data + Label X no longer wishes to participate in ESADI, it ceases to + participate by (1) clearing the ESADI Participation bit in the + appropriate Interested VLANs or Interested Labels sub-TLV and (2) + sending a final ESADI-LSP nulling out its ESADI-LSP information. + +5.3. Duplicate MAC Address + + With ESADI, it is possible to persistently see occurrences of the + same MAC address in the same Data Label being advertised as reachable + by two or more RBridges. The specification of how to handle this + situation in [RFC6325] is updated by this document, by replacing the + last sentence of the last paragraph of Section 4.2.6 of [RFC6325] as + shown below to provide better traffic-spreading while avoiding + possible address flip-flopping. + + As background, assume some end station or set of end stations ESn + have two or more ports with the same MAC address in the same Data + Label with the ports connected to different RBridges (RB1, RB2, ...) + by separate links. With ESADI, some other RBridge, RB0, can + persistently see that MAC address in that Data Label connected to + multiple RBridges. When RB0 ingresses a frame, say from ES0, + destined for that MAC and label, the current [RFC6325] text permits a + wide range of behavior. In particular, [RFC6325] would permit RB0 to + use some rule, such as "always encapsulate to the egress with the + lowest System ID", which would put all of this traffic through only + one of the egress RBridges and one of the end station ports. With + that behavior, there would be no load-spreading, even if there were + multiple different ingress RBridges and/or different MAC addresses + with the same reachability. [RFC6325] would also permit RB0 to send + different traffic to different egresses by doing ECMP (Equal Cost + Multipath) at a flow level, which would likely result in return + traffic for RB0 to egress to ES0 from various of RB1, RB2, ... for + the same MAC and label. The resulting address reachability + flip-flopping perceived at RB0 could cause problems. + + + +Zhai, et al. Standards Track [Page 16] + +RFC 7357 TRILL: ESADI September 2014 + + + This update to [RFC6325] avoids these potential difficulties by + requiring that RB0 use one of the following two policies: (1) only + encapsulate to one egress RBridge for any particular MAC and label, + but select that egress pseudorandomly, based on the topology + (including MAC reachability) or (2) if RB0 will not 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: + + "... If confidences are also tied between the duplicates, for + consistency it is suggested that RB2 direct all such frames (or + all such frames in the same ECMP flow) toward the same egress + RBridge; however, the use of other policies will not cause a + network problem since transit RBridges do not examine the + Inner.MacDA for known unicast frames." + + NEW [RFC6325] Section 4.2.6 text: + + "... If confidences are also tied between the duplicates, 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. + + + + + + + + + + +Zhai, et al. Standards Track [Page 17] + +RFC 7357 TRILL: ESADI September 2014 + + + 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. Currently, the contents of an ESADI-LSP consist of + zero or more MAC-Reachability TLVs, optionally an Authentication TLV, + and exactly one ESADI parameter APPsub-TLV. Other similar data may + be included in the future and, as in [IS-IS], an ESADI instance + ignores any TLVs or sub-TLVs it does not understand. Because these + PDUs are formatted as Extended Level 1 Circuit Scope (E-L1CS) PDUs + [RFC7356], the Type and Length fields in the TLVs are 16-bit. + + This section specifies the format for the ESADI Parameter APPsub-TLV, + gives the reference for the ESADI MAC-Reachability TLV, and discusses + default authentication configuration. + + For robustness, the payload for an ESADI-LSP number zero and any + ESADI-CSNP or ESADI-PSNP covering fragment zero MUST NOT exceed 1470 + minus 24 bytes in length (1446 bytes) if it has an Inner.VLAN, or + 1470 minus 28 bytes (1442 bytes) if it has an Inner.FGL. However, if + an ESADI-LSP number zero or such an ESADI-CSNP or ESADI-PSNP is + received that is longer, it is still processed normally. (As stated + in Section 4.3.1 of [RFC6325], 1470 bytes was chosen to make it + extremely unlikely that a TRILL control packet, even with reasonable + additional headers, tags, and/or encapsulation, would encounter MTU + problems on an inter-RBridge link.) + + + +Zhai, et al. Standards Track [Page 18] + +RFC 7357 TRILL: ESADI September 2014 + + +6.1. ESADI Parameter Data + + Figure 4 presents the format of the ESADI parameter data. This + APPsub-TLV MUST be included in a TRILL GENINFO TLV in ESADI-LSP + number zero. If it is missing from ESADI-LSP number zero or if + ESADI-LSP number zero is not known, priority for the sending RBridge + defaults to 0x40 and CSNP Time defaults to 30. If there is more than + one occurrence in ESADI-LSP number zero, the first occurrence will be + used. Occurrences of the ESADI Parameter APPsub-TLV in non-zero + ESADI-LSP fragments are 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 + + Type: Set to ESADI-PARAM sub-TLV (TRILL APPsub-TLV type 0x0001). + Two bytes, because this APPsub-TLV appears in an extended TLV + [RFC7356]. + + Length: Variable, with a minimum of 3, but 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 + is an unsigned 7-bit integer with the larger magnitude indicating + higher priority. It defaults to 0x40 for an RBridge participating + in ESADI for which it has not been configured. + + + + + + + + +Zhai, et al. Standards Track [Page 19] + +RFC 7357 TRILL: ESADI September 2014 + + + CSNP Time: An unsigned byte that gives the amount of time in seconds + during which the originating RBridge, if it is the DRB on the + ESADI virtual link, will send at least three ESADI-CSNP PDUs. It + defaults to 30 seconds for an RBridge participating in ESADI for + which it has not been configured. + + Flags: A byte of flags associated with the originating ESADI + instance, as follows: + + 0 1 2 3 4 5 6 7 + +---+---+---+---+---+---+---+---+ + | UN| RESV | + +---+---+---+---+---+---+---+---+ + + The UN flag indicates that the RBridge originating the ESADI-LSP, + including this ESADI parameter data, will accept and properly + process ESADI PDUs sent by TRILL unicast (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 may have additional information. A receiving ESADI + RBridge ignores any additional data here, unless it implements + such future expansion(s). + +6.2. MAC-Reachability TLV + + The primary information in TRILL ESADI-LSP PDUs consists of + MAC-Reachability (MAC-RI) TLVs 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 1-octet unsigned Confidence in + this information with a value in the range 0-254. If such a TLV is + received containing a Confidence of 255, it is treated as if the + Confidence was 254. (This is to assure that any received address + information can be overridden by local address information statically + configured with a Confidence of 255.) + + The TLVs in TRILL ESADI PDUs, including the MAC-RI TLV, MUST NOT + contain the Data Label ID. If a Data Label ID is present in the + MAC-RI TLV, it is ignored. In the ESADI PDU, only the Inner.VLAN or + Inner.FGL tag indicates the Data Label to which the ESADI-LSP + applies. + + + + + + + + +Zhai, et al. Standards Track [Page 20] + +RFC 7357 TRILL: ESADI September 2014 + + +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 implemented at a + TRILL switch, then ESADI MUST be able to use the authentication + algorithms implemented for TRILL IS-IS and implement the keying + material derivation function given below. If ESADI authentication + has been manually configured, that configuration is not restricted by + the configuration of TRILL IS-IS security. + + If TRILL IS-IS authentication is not in effect for LSP PDUs + originated by a TRILL switch, then ESADI PDUs originated by that + TRILL switch are by default also unsecured. + + If such IS-IS LSP PDU authentication is in effect at a TRILL switch, + then, unless configured otherwise, ESADI PDUs sent by that switch + MUST use the same algorithm in their Authentication TLVs. The ESADI + authentication keying material used is derived from the IS-IS LSP + shared secret keying material as detailed below. However, such + authentication MAY be configured to use some other keying material. + + HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key ) + + In the 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 secret keying material being used + by the originating TRILL switch for IS-IS LSP authentication. + +7. IANA Considerations + + IANA allocation and registry considerations are given below. Three + new sub-registries have been created in the "Transparent + Interconnection of Lots of Links (TRILL) Parameters" registry located + at <http://www.iana.org/assignments/trill-parameters> -- two in + Section 7.1 and one in Section 7.2 -- and various code points have + been assigned. + + + + + + + + + + + + + +Zhai, et al. Standards Track [Page 21] + +RFC 7357 TRILL: ESADI September 2014 + + +7.1. ESADI Participation and Capability Flags + + IANA Action 1: + + IANA has created the following 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] + + The creation of this sub-registry (as immediately above) 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 indicates that the originating RBridge is participating in + ESADI for the indicated Data Label(s). + + IANA Action 2: + + IANA has created the following new sub-registry called "Interested + Labels Flag Bits" in the "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]. + + + + +Zhai, et al. Standards Track [Page 22] + +RFC 7357 TRILL: ESADI September 2014 + + + 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 + + The creation of this sub-registry (as immediately above) 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 indicates that the originating RBridge is participating in + ESADI for the indicated Data Label(s). + +7.2. TRILL GENINFO TLV + + IANA Action 3: + + IANA has allocated the IS-IS Application Identifier 1 under the + Generic Information TLV (#251) [RFC6823] for TRILL. + + IANA Action 4: + + IANA has created a sub-registry in the "Transparent + Interconnection of Lots of Links (TRILL) Parameters" registry as + follows: + + 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] + + + + + + + + + + +Zhai, et al. Standards Track [Page 23] + +RFC 7357 TRILL: ESADI September 2014 + + + 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 causing such an + assignment will also include a discussion of security issues and + of the rate of change of the information being advertised. TRILL + APPsub-TLVs MUST NOT alter basic IS-IS protocol operation + including the establishment of adjacencies, the update process, + and the decision process for TRILL IS-IS [IS-IS] [RFC1195] + [RFC7177]. The TRILL Generic Information TLV MUST NOT be used in + an IS-IS instance zero [RFC6822] LSP but 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 are not + currently used, as TRILL operates as a Level 1 IS-IS area and no + semantics are hereby assigned to the inclusion of an IPv4 and/or IPv6 + address via the I and V flags. Thus, these I and V flags MUST be + zero; however, if either or both are one, the space that should be + taken by an IPv4 and/or IPv6 address, respectively, is skipped over + and ignored. Furthermore, the use of multilevel IS-IS is an obvious + extension for TRILL [MultiLevel], and future IETF Standards Actions + may update or obsolete this specification to provide for the use of + any or all of these flags in the TRILL GENINFO TLV. + + The ESADI Parameters information, for which TRILL APPsub-TLV 1 is + hereby assigned, is compact and slow changing (see Section 6.1). + + For security considerations related to ESADI and the ESADI Parameter + APPsub-TLV, see Section 8. + +8. Security Considerations + + ESADI PDUs can be authenticated through the inclusion of the + Authentication TLV [RFC5310]. Defaults for such authentication are + described in Section 6.3. + + The ESADI-LSP data primarily announces MAC address reachability + within a Data Label. Such reachability can, in some cases, be an + authenticated registration (for example, a Layer 2 authenticated + registration using cryptographically based EAP (Extensible + + + +Zhai, et al. Standards Track [Page 24] + +RFC 7357 TRILL: ESADI September 2014 + + + Authentication Protocol [RFC3748]) methods via [802.1X]). The + combination of these techniques can cause ESADI MAC reachability + information to be substantially more trustworthy than MAC + reachability learned from observation of the data plane. + Nevertheless, ESADI still involves trusting all other RBridges in the + TRILL campus, at least those that have the keying material necessary + to construct a valid Authentication TLV. + + However, there may be cases where authenticated registration is used + for end stations, because of a significant threat of forged packets + on end station links, but it is not necessary to authenticate ESADI + PDUs because that threat is not 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 + the connection of such end stations but might not necessarily + authenticate ESADI PDUs. Note that if the IS-IS LSPs in a TRILL + campus are authenticated, perhaps due to a concern about forged + packets, the ESADI PDUs will be authenticated by default as provided + in Section 6.3. + + MAC reachability learned from the data plane (the TRILL default) is + overwritten by any future learning of the same type. ESADI + advertisements are represented in the Data Label scoped link state + database. Thus, ESADI makes visible any multiple attachments of the + same MAC address within a Data Label to different RBridges (see + Section 5.3). This may or may not be an error or misconfiguration, + but ESADI at least makes it explicitly and persistently visible, + which would not be the case with data plane learning. + + For general TRILL security considerations, see [RFC6325]. + +8.1. Privacy Considerations + + The address reachability information distributed by ESADI has + substantial privacy considerations under many, but not all, + circumstances. + + For example, if ESADI were used in a TRILL campus with independent + user end stations at the edge, the MAC addresses of such end stations + could uniquely identify the users of those end stations. Their + reachability would be sensitive information and, particularly if + logged, could reveal such user information. On the other hand, if + TRILL is being used to implement an Internet Exchange Point (IXP) to + connect Internet Service Providers (ISPs), the MAC addresses being + advertised in ESADI would typically be those of the ISP's directly + connected IP router ports, since Layer 3 routers bound the TRILL + campus, for which there would be few privacy concerns. + + + +Zhai, et al. Standards Track [Page 25] + +RFC 7357 TRILL: ESADI September 2014 + + + However, records of MAC attachment that include a modest amount of + history, perhaps a few days' worth, can be useful in managing a + network and troubleshooting network problems. It might, in some + cases, also be legally required, or required for billing purposes or + the like. + + Network operators should seek a reasonable balance between these + competing considerations, customized for the circumstances of their + particular networks where ESADI is in use. They should not maintain + logs of MAC reachability information for any longer than is clearly + required. + +9. Acknowledgements + + The authors thank the following, listed in alphabetic order, for + their suggestions and contributions: + + David Black, Somnath Chatterjee, Adrian Farrel, Stephen Farrell, + Sujay Gupta, Russ Housley, Pearl Liang, Kathleen Moriarty, Thomas + Narten, Erik Nordmark, and Mingui Zhang. + +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. + + + + +Zhai, et al. Standards Track [Page 26] + +RFC 7357 TRILL: ESADI September 2014 + + + [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. + + + + + + + + + + + +Zhai, et al. Standards Track [Page 27] + +RFC 7357 TRILL: ESADI September 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. + + + + + + + + + + + + + + +Zhai, et al. Standards Track [Page 28] + +RFC 7357 TRILL: ESADI September 2014 + + +Appendix A. Interoperability and Changes to RFC 6325 + + This appendix summarizes the significant changes this document makes + to the TRILL base protocol specification [RFC6325]. Although + simultaneous use of [RFC6325] ESADI and ESADI as specified in this + document in a TRILL campus is very unlikely due to non-deployment of + [RFC6325] ESADI, this appendix also discusses, for each change, the + interoperability considerations should such simultaneous use occur. + +A.1. ESADI PDU Changes + + The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads is + changed from the IS-IS Level 1 format [IS-IS] to the Extended Level 1 + Circuit Scope format (E-L1CS) specified in [RFC7356]. This change is + not backwards compatible with [RFC6325]. It is made in light of the + information-carrying capacity of the E-L1CS format, which is + 256 times greater than that of the base IS-IS format. It is + anticipated that this greater information-carrying capacity will be + needed, under some circumstances, to carry end station addressing + information or other similar address and reachability information + when it is added to ESADI in the future. + + The PDU numbers used for the ESADI LSP, CSNP, and PSNP PDUs in + [RFC6325] are 18, 24, and 26 [IS-IS]. With this document, the format + changes, and the PDU numbers change to 10, 11, and 12 [RFC7356]. The + use of different PDU numbers assures that a PDU will not be + mis-parsed. Because of this, implementations of this document and + implementations of [RFC6325] ESADI will discard each other's PDUs. + Thus, address reachability or other information distributed through + either type of ESADI implementation will only be communicated to + other implementations of the same type, and the two communities will + not communicate any information with each other. + + Note that RBridges can use the TRILL mandatory-to-implement, + enabled-by-default data plane address learning in addition to ESADI. + (Section 5 of this document and the material it references explain + how to handle conflicts between different sources of address + reachability information.) Simply leaving data plane address + learning enabled would enable smooth incremental migration from + [RFC6325] ESADI to the ESADI specification in this document, should + that be necessary. The data plane address learning would fill in any + gaps due to non-communication between the two types of ESADI + implementations, although without the speed or security advantages + of ESADI. + + + + + + + +Zhai, et al. Standards Track [Page 29] + +RFC 7357 TRILL: ESADI September 2014 + + +A.2. Unicasting Changes + + Unicasting of ESADI PDUs is optionally supported, including replacing + Section 4.6.2.2 of [RFC6325] with the new text given in Section 4.1 + of this document. This unicast support is backwards compatible + because it is only used when the recipient RBridge signals its + support. + +A.3. Message Timing Changes and Suggestions + + The following 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 relate only to the timing of messages for congestion + minimization. Should a message be lost, due to congestion or + otherwise, it will be later retransmitted as a normal part of the + robust flooding mechanism used by ESADI. + +A.4. Duplicate Address Reachability + + The handling of persistent reachability of the same MAC within the + same Data Label from two or more RBridges is substantially modified, + including the explicit replacement of some text in Section 4.2.6 of + [RFC6325] (see Section 5.3 of this document). There is no problem + with a mixture of ESADI implementations in a TRILL campus, some + conforming to [RFC6325] and some conforming to this document, for + handling this condition. The more implementations conform to the + improved behavior specified in this document for this condition, the + better the traffic-spreading will be, and the less likely address + flip-flopping problems will be. + + + + + + + + + + + + + + +Zhai, et al. Standards Track [Page 30] + +RFC 7357 TRILL: ESADI September 2014 + + +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 + + + + + + + + + + + + +Zhai, et al. Standards Track [Page 31] + |