Internet DRAFT - draft-ietf-trill-esadi
draft-ietf-trill-esadi
TRILL Working Group Hongjun Zhai
INTERNET-DRAFT Fangwei Hu
Intended status: Proposed Standard ZTE
Updates: 6325 Radia Perlman
Intel Labs
Donald Eastlake
Huawei
Olen Stokes
Extreme Networks
Expires: Decemeber 6, 2014 June 7, 2014
TRILL:
ESADI (End Station Address Distribution Information) Protocol
<draft-ietf-trill-esadi-09.txt>
Abstract
The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol provides least cost pair-wise data forwarding without
configuration in multi-hop networks with arbitrary topologies and
link technologies. TRILL supports multi-pathing of both unicast and
multicast traffic. Devices that implement the TRILL protocol are
called 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 Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list: <trill@ietf.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
H. Zhai, et al [Page 1]
INTERNET-DRAFT TRILL: ESADI
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
H. Zhai, et al [Page 2]
INTERNET-DRAFT TRILL: ESADI
Table of Contents
1. Introduction............................................4
1.1 Content and Precedence.................................5
1.2 Terminology............................................5
2. ESADI Protocol Overview.................................7
2.1 ESADI Virtual Link....................................10
2.2 ESADI Neighbor Determination..........................11
2.3 ESADI Payloads........................................11
3. ESADI DRB (Designated RBridge) Determination...........13
4. ESADI PDU processing...................................14
4.1 Unicasting ESADI PDUs.................................14
4.2 General Transmission of ESADI PDUs....................15
4.3 General Receipt of ESADI PDUs.........................16
4.4 ESADI Reliable Flooding...............................16
5. End Station Addresses..................................18
5.1 Learning Confidence Level.............................18
5.2 Forgetting End Station Addresses......................18
5.3 Duplicate MAC Address.................................18
6. ESADI-LSP Contents.....................................21
6.1 ESADI Parameter Data..................................21
6.2 MAC Reachability TLV..................................23
6.3 Default Authentication................................23
7. IANA Considerations....................................25
7.1 ESADI Participation and Capability Flags..............25
7.2 TRILL GENINFO TLV.....................................26
8. Security Considerations................................28
8.1 Privacy Considerations................................28
9. Acknowledgements.......................................30
Normative references......................................31
Informative References....................................32
Appendix A: Interoperability and Changes to [RFC6325].....34
A.1 ESADI PDU Changes.....................................34
A.2 Unicasting Changes....................................35
A.3 Message Timing Changes and Suggestions................35
A.4 Duplicate Address Reachability........................35
Appendix Z: Change History................................36
Authors' Addresses........................................40
H. Zhai, et al [Page 3]
INTERNET-DRAFT TRILL: ESADI
1. Introduction
The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol [RFC6325] provides least cost pair-wise data forwarding
without configuration in multi-hop networks with arbitrary topologies
and link technologies, safe forwarding even during periods of
temporary loops, and support for multi-pathing of both unicast and
multicast traffic. TRILL accomplishes this with the IS-IS
(Intermediate System to Intermediate System) [IS-IS] [RFC1195]
[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 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: (1a) The ESADI protocol can be used to
announce end stations with an authenticated enrollment (for
example enrollment authenticated by cryptographically based EAP
(Extensible Authentication Protocol [RFC3748]) methods via
[802.1X]). (1b) The ESADI protocol supports cryptographic
authentication of its message payloads for more secure
transmission.
2. Fast update advantages: The ESADI protocol provides a fast update
of end 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 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].
H. Zhai, et al [Page 4]
INTERNET-DRAFT TRILL: ESADI
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, obsoleting and 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 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 (Protocol Data Units). Section
5 discusses interaction with other modes of end station address
learning. And Section 6 describes the ESADI-LSP (Link State PDU) and
its contents.
1.2 Terminology
This document uses the acronyms defined in [RFC6325] and 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].
H. Zhai, et al [Page 5]
INTERNET-DRAFT TRILL: ESADI
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 Considerations terms such as "IETF Review" as to be
interpreted as described in [RFC5226].
H. Zhai, et al [Page 6]
INTERNET-DRAFT TRILL: ESADI
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 a separate optional protocol 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 in a
single database with a field in each record indicating the Data Label
to which it applies or could be a separate database per Data Label.
But the ESADI update process operates separately for each ESADI
instance and independently from the TRILL IS-IS update process.
ESADI does no routing calculations so there is no reason for pseudo-
nodes in ESADI and none are created (Pseudo-nodes [IS-IS] are a
construct for optimizing routing calculations.) Furthermore, there
may be a requirement for a relatively large amount of data to be
distributed through ESADI which might take 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 [FS-LSP] (see also Section 6). This allows up to
2**16 fragments but does not support link state data associated with
pseudo-nodes.
After the TRILL header, ESADI packets have an inner Ethernet header
with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All-
ESADI-RBridges"), an inner Data Label specifying the VLAN or FGL of
interest, and the "L2-IS-IS" Ethertype followed by the ESADI payload
as shown in Figure 1.
H. Zhai, et al [Page 7]
INTERNET-DRAFT TRILL: ESADI
+--------------------------------+
| Link Header |
+--------------------------------+
| TRILL Data Header |
+--------------------------------+
| Inner Ethernet Addresses |
+--------------------------------+
| Data Label |
+--------------------------------+
| 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
below. The outer VLAN tag will not be present if it was not included
by the Ethernet port that sent the packet.
H. Zhai, et al [Page 8]
INTERNET-DRAFT TRILL: ESADI
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Addr. | Sending RBridge Port MAC Addr.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending RBridge Port MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...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 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 field will be
one unless the ESADI PDU was unicast, in which case the M field will
be zero. The Data Label specified will be the VLAN or FGL to which
the ESADI packet applies. The Origin RBridge MAC Address or
Inner.MacSA MUST be a MAC address unique across the campus owned by
H. Zhai, et al [Page 9]
INTERNET-DRAFT TRILL: ESADI
the RBridge originating the ESADI packet, for example, any of its
port MAC addresses if it has any Ethernet ports, and each RBridge
MUST use the same Inner.MacSA for all of the ESADI packets that
RBridge originates.
TRILL ESADI packets sent on a PPP link are structured as shown below
[RFC6361].
PPP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP = TNP (TRILL data) 0x005D |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress (Origin) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-Egress-RBridges cont. | Origin RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN or FGL Data Label (4 or 8 bytes) [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
H. Zhai, et al [Page 10]
INTERNET-DRAFT TRILL: ESADI
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 for the Data Label
of an ESADI packet do not decapsulate or locally process the TRILL
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.
Participation announcement in a VLAN scoped ESADI instance is through
setting a flag bit in the Interested VLANs sub-TLV and announcement
for an FGL scoped ESADI instance is through setting a flag bit in the
Interested Labels sub-TLV [RFC7176]. (See Section 7.1)
2.3 ESADI Payloads
TRILL ESADI packet payloads are structured like IS-IS Extended Level
1 Circuit Scoped (E-L1CS) LSP, CSNP, and PSNP PDUs [FS-LSP], except
as indicated below, but are always TRILL encapsulated on the wire as
if they were TRILL Data packets. The information distributed by the
ESADI protocol includes a list of local end station MAC addresses
connected to the originating RBridge and, for each such address, a
one octet unsigned "confidence" rating in the range 0-254 (see
H. Zhai, et al [Page 11]
INTERNET-DRAFT TRILL: ESADI
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.
H. Zhai, et al [Page 12]
INTERNET-DRAFT TRILL: ESADI
3. ESADI DRB (Designated RBridge) Determination
Because ESADI does no adjacency announcement or routing, the ESADI-
DRB never creates a pseudonode. But a DRB (Designated RBridge
[RFC7177]) is still needed for ESADI-LSP synchronization by issuing
ESADI-CSNP PDUs and responding to ESADI-PSNP PDUs.
Generally speaking, the DRB election on the ESADI virtual link (see
Section 2.1) operates similarly to 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 (1) are data reachable from
RB1 [RFC7180], and (2) are announcing in their TRILL IS-IS LSP that
they are participating in ESADI for Data Label X. The winner is the
instance with the highest ESADI Parameter 7-bit priority field with
ties broken by System ID, comparing fields as unsigned integers with
the larger magnitude considered higher priority. "SNPA/MAC address"
is not considered in this tie breaking and there is no "Port ID".
H. Zhai, et al [Page 13]
INTERNET-DRAFT TRILL: ESADI
4. ESADI PDU processing
Data Label X ESADI neighbors are usually not connected directly by a
physical link, but are always logically connected by a virtual link
(see Section 2.1). There could be hundreds or thousands of ESADI
RBridges (TRILL switches) on the virtual link. There are only ESADI-
LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI. In particular,
there are no Hello or MTU PDUs because ESADI does not build a
topology, does not do any routing calculations, and does not
determine MTU, using the campus Sz. (Sz is the TRILL campus wide
minimum link MTU (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. But
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, 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.
To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is
replaced with the following:
"4.6.2.2. TRILL ESADI Packets
If M=1, the egress nickname designates the distribution tree. The
packet is forwarded as described in Section 4.6.2.5. In addition,
if the forwarding RBridge is (1) interested in the specified VLAN
or Fine Grained Label [RFC7172], (2) implements the TRILL ESADI
protocol, and (3) ESADI is enabled for that VLAN or Fine Grained
H. Zhai, et al [Page 14]
INTERNET-DRAFT TRILL: ESADI
Label, the inner frame is decapsulated and provided to that local
ESADI protocol.
If M=0 and the egress nickname is not that of the receiving
RBridge, the packet is forwarded as for known unicast TRILL Data
in Section 4.6.2.4. If M=0 and the egress nickname is that of the
receiving RBridge and the receiving RBridge supports unicast ESADI
PDUs, then the ESADI packet is decapsulated and processed if it
meets the three numbered conditions in the paragraph above,
otherwise it is discarded."
The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above refer to
those sections in [RFC6325].
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).
A priority bit to indicate that an LSP fragment should be flooded
with high priority is provided by [FS-LSP]. This bit SHOULD be set on
ESADI-LSP fragment zero because it is important that the ESADI
Parameters 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.
H. Zhai, et al [Page 15]
INTERNET-DRAFT TRILL: ESADI
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
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 [FS-LSP].
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. So 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 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
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
minimumLSPTimeInterval * Random (Jitter) / 100
H. Zhai, et al [Page 16]
INTERNET-DRAFT TRILL: ESADI
(where minimumLSPTimeInterval, 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 DRB, an ESADI RBridge SHOULD also transmit
an ESADI-CSNP for an ESADI instance if all of the following
conditions are met:
o it sees one or more ESADI neighbors for that instance, and
o it does not believe it is DRB for the ESADI instance, and
o it has not received or sent an ESADI-CSNP PDU for the instance for
the average of the CSNP Time (see Section 6.1) of the DRB and its
CSNP Time.
H. Zhai, et al [Page 17]
INTERNET-DRAFT TRILL: ESADI
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
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 time out of
the learned end station address is up to the originating RBridge that
decides when to remove such information from its ESADI-LSPs (or up to
ESADI protocol timeouts if the originating RBridge becomes
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
H. Zhai, et al [Page 18]
INTERNET-DRAFT TRILL: ESADI
situation in [RFC6325] is updated 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] also would also permit RB0 to
send different traffic to different egresses by doing ECMP at a flow
level, which would likely result in return traffic 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.
This update to [RFC6325] avoids these potential difficulties by
requiring RB0 to use one of the following two policies: (1) only
encapsulate to one egress RBridge for any particular MAC and label
but to select that egress pseudo-randomly based on the topology
including MAC reachability or (2) if it will not be disturbed by the
returning TRILL Data packets showing the same MAC and label flip-
flopping between different ingresses, it 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
H. Zhai, et al [Page 19]
INTERNET-DRAFT TRILL: ESADI
adopt one of the following two strategies:
1. In a pseudo-random way [RFC4086], select one of the egress
RBridges that is least cost from RB2 and to which the
destination MAC appears to be attached and send all traffic for
the destination MAC and VLAN (or FGL [RFC7172]) to that egress.
This pseudo-random choice need only be changed when there is a
change in campus topology or MAC attachment information. Such
pseudo-random selection will, over a population of ingress
RBridges, probabilistically spread traffic over the possible
egress RBridges. Reasonable inputs to the pseudo-random
selection are the ingress RBridge System ID and/or nickname,
the VLAN or FGL, the destination MAC address, and a vector of
the RBridges with connectivity to that MAC and VLAN or FGL.
There is no need for different RBridges to use the same pseudo-
random function.
As an example of such a pseudo-random 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 FNV 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."
H. Zhai, et al [Page 20]
INTERNET-DRAFT TRILL: ESADI
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 consists 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 [FS-LSP],
the Type and Length fields in the TLVs are 16-bit.
This section specifies the format for the ESADI parameter data
APPsub-TLV, gives the reference for the ESADI MAC Reachability TLV,
and discusses default authentication configuration.
For robustness, the payload for an ESADI-LSP number zero 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. But 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.)
6.1 ESADI Parameter Data
The figure below presents the format of the ESADI parameter data.
This APPsub-TLV MUST be included in a TRILL GENINFO TLV in ESADI-LSP
number zero. If it is missing from ESADI-LSP number zero or if ESADI-
LSP number zero is not known, priority for the sending RBridge
defaults to 0x40 and CSNP Time defaults to 30. If there is more than
one occurrence in ESADI-LSP number zero, the first occurrence will be
used. Occurrences of the ESADI parameter data APPsub-TLV in non-zero
ESADI-LSP fragments are ignored.
H. Zhai, et al [Page 21]
INTERNET-DRAFT TRILL: ESADI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 subTLV (TRILL APPsub-TLV type 0x0001). Two
bytes because this APPsub-TLV appears in an Extended TLV [FS-LSP].
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 [FS-LSP].
R: A reserved bit that MUST be sent as zero and ignored on receipt.
Priority: The Priority field gives the originating RBridge's priority
for being DRB on the ESADI instance virtual link (see Section 3)
for the Data Label in which the PDU containing the parameter data
was sent. It is an unsigned seven-bit integer with larger
magnitude indication higher priority. It defaults to 0x40 for an
RBridge participating in ESADI for which it has not been
configured.
CSNP Time: An unsigned byte that gives the amount of time in seconds
during which the originating RBridge, if it is DRB on the ESADI
virtual link, will send at least three EASDI-CSNP PDUs. It
defaults to 30 seconds for an RBridge participating in ESADI for
which it has not been configured.
Flags: A byte of flags associated with the originating ESADI instance
as follows:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| UN| 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
H. Zhai, et al [Page 22]
INTERNET-DRAFT TRILL: ESADI
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
Parameters APPsub-TLV may have additional information. A receiving
ESADI RBridge ignores any additional data here unless it
implements such future expansion(s).
6.2 MAC Reachability TLV
The primary information in TRILL ESADI-LSP PDUs consists of MAC
Reachability (MAC-RI) TLVs specified in [RFC6165]. These TLVs
contain one or more unicast MAC addresses of end stations that are
both on a port and in a VLAN for which the originating RBridge is
appointed forwarder, along with the one octet unsigned Confidence in
this information with a value in the range 0-254. If such a TLV is
received 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.
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, by default, ESADI PDUs originated
by that TRILL switch are also unsecured.
If such IS-IS LSP PDU authentication is in effect at a TRILL switch
H. Zhai, et al [Page 23]
INTERNET-DRAFT TRILL: ESADI
then, unless configured otherwise, ESADI PDUs sent by that switch
MUST use the same algorithm in their Authentication TLVs. The ESADI
authentication keying material used is derived from the IS-IS LSP
shared secret keying material as detailed below. However, such
authentication MAY be configured to use some other keying material.
HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key )
In the above HMAC-SHA256 is as described in [FIPS180] [RFC6234] and
"TRILL ESADI" is the eleven byte US ASCII [ASCII] string indicated.
IS-IS-LSP-shared-key is secret keying material being used by the
originating TRILL switch for IS-IS LSP authentication.
H. Zhai, et al [Page 24]
INTERNET-DRAFT TRILL: ESADI
7. IANA Considerations
IANA allocation and registry considerations are given below. Three
new sub-registries are created in the 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 assigned.
7.1 ESADI Participation and Capability Flags
IANA Action 1:
IANA is requested to create the following new sub-registry called
"Interested VLANs Flag Bits" in the 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], [This document]
Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 M4 IPv4 Multicast Router Attached [RFC7176]
1 M6 IPv6 Multicast Router Attached [RFC7176]
2 - Unassigned
3 ES ESADI Participation This document
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 assigns 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 is requested to create the following new sub-registry called
"Interested Labels Flag Bits" in the TRILL Parameters registry.
H. Zhai, et al [Page 25]
INTERNET-DRAFT TRILL: ESADI
Sub-Registry: Interested Labels Flag Bits
Registration Procedures: IETF Review
Note: These bits appear in the Interested Labels record within the
Interested Labels and Spanning Tree Roots Sub-TLV (INT-LABEL)
specified in [RFC7176].
References: [RFC7176], [this document]
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 This document
4-7 - Unassigned
The creation of this sub-registry as immediately above assigns 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 is requested to allocate the IS-IS Application Identifier TBD
[1 suggested] under the Generic Information TLV (#251) [RFC6823]
for TRILL.
IANA Action 4:
IANA is requested to create a subregistry in the TRILL Parameters
Registry as follows:
H. Zhai, et al [Page 26]
INTERNET-DRAFT TRILL: ESADI
Sub-Registry: TRILL APPsub-TLV Types under IS-IS TLV #251
Application Identifier #TBD
Registration Procedures: IETF Review with additional
requirements on the documentation of the use being
registered as specified in Section 7.2 of <this
document>.
Note: Types greater than 255 are only usable in contexts
permitting a type larger than one byte, such as Extended
TLVs [FS-LSP].
Reference: <this RFC>
Type Name Reference
---------- -------- -----------
0 Reserved <this RFC>
1 ESADI-PARAM <this RFC>
2-254 Unassigned <this RFC>
255 Reserved <this RFC>
256-65534 Unassigned <this RFC>
65535 Reserved <this RFC>
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 FS-LSPs [FS-LSP].
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 is one, the space that should be taken by
and IPv4 and/or IPv6 address respectively is skipped over and
ignored. Furthermore, use of multi-level 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 parameters
APPsub-TLV, see Section 8.
H. Zhai, et al [Page 27]
INTERNET-DRAFT TRILL: ESADI
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
Authentication Protocol [RFC3748]) methods via [802.1X]). The
combination of these techniques can cause EASDI 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 it is not necessary to authenticate
ESADI PDUs despite using authenticated registration for end stations
because of a significant threat of forged packets on end station
links when 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 some end stations connected via IEEE 802.11
wireless access links might use 802.11 authentication for the
connection of such end stations but 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 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.
H. Zhai, et al [Page 28]
INTERNET-DRAFT TRILL: ESADI
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, be revealing of their users. 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.
However, records of MAC attachment, including 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 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.
H. Zhai, et al [Page 29]
INTERNET-DRAFT TRILL: ESADI
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.
This document was produced with raw nroff. All macros used were
defined in the source file.
H. Zhai, et al [Page 30]
INTERNET-DRAFT TRILL: ESADI
Normative references
[ASCII] - American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968
has been replaced by newer versions with slight modifications,
but the 1968 version remains definitive for the Internet.
[FIPS180] - "Secure Hash Standard (SHS)", United States of American,
National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 180-4, March 2012,
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
[FS-LSP] - Ginsberg, L., S. Previdi, Y. Yang, "IS-IS Flooding Scope
LSPs", draft-ietf-isis-fs-lsp, in RFC Editor's queue.
[IS-IS] - International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in conjunction
with the protocol for providing the connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov
2002.
[RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June
2005.
[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
H. Zhai, et al [Page 31]
INTERNET-DRAFT TRILL: ESADI
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.
Informative References
[802.1X] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
networks / Port-Based Network Access Control", IEEE Std
802.1X-2010, 5 February 2010.
[FNV] - G. Fowler, L. Noll, K. Vo & D. Eastlake, "The FNV Non-
Cryptographic Hash Algorithm", draft-eastlake-fnv, Work in
progress.
[RFC3748] - Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May
2011.
[RFC6822] - Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and
D. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
[MultiLevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai,
"Multilevel TRILL (Transparent Interconnection of Lots of
Links)", draft-perlman-trill-rbridge-multilevel, work in
progress.
H. Zhai, et al [Page 32]
INTERNET-DRAFT TRILL: ESADI
[VLANmapping] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani,
and D. Eastlake, "RBridges: Campus VLAN and Priority Regions",
draft-ietf-trill-rbridge-vlan-mapping, work in progress.
H. Zhai, et al [Page 33]
INTERNET-DRAFT TRILL: ESADI
Appendix A: Interoperability and Changes to [RFC6325]
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 Scoped format (E-L1CS) specified in [FS-LSP]. This change is
not backwards compatible with [RFC6325]. It is made in light of the
256 times greater information carrying capacity of the E- L1CS format
compared with the base IS-IS format. It is anticipated that this
greater carrying capacity will be needed, under some circumstances,
to carry end station addressing information or other similar address
and reachability information that 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 [FS-LSP]. 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] EASDI 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 implementation although
without the speed or security advantages of ESADI.
H. Zhai, et al [Page 34]
INTERNET-DRAFT TRILL: ESADI
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 relevant 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 EASDI 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 with 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 are.
H. Zhai, et al [Page 35]
INTERNET-DRAFT TRILL: ESADI
Appendix Z: Change History
RFC Editor: Please delete this section before publication.
Z.1 From -00 to -01
1. Add Section 6.3 "Default Authentication".
2. Add "Acknowledgements" Section.
3. Change requirement from "MAY" to "SHOULD" for an ESADI RBridge
that is not DRB to send an ESADI-CSNP if it does not receive an
ESADI-CSNP in long enough.
4. Default CSNP Time was listed as 30 in one place and 40 in another.
Change to uniformly specify 30.
5. Update references to RFC 6326 to reference the 6326bis draft.
6. Relax allocation criteria for TRILL APPsub-TLV type code points
from Standard Action to IETF Review.
7. Numerous Editorial changes.
Z.2 From -01 to -02
1. Extend to cover FGL and well as VLAN and introduce the term "Data
Label" to cover both.
2. Expand number of LSP fragments to 2**16.
3. Simplify neighbor detection to no longer require possession of
ESADI-LSP zero.
4. Add update to last sentence of Section 4.2.6 of [RFC6325].
5. Update references for publication of RFCs 6822 and 6823.
6. Additional minor changes.
H. Zhai, et al [Page 36]
INTERNET-DRAFT TRILL: ESADI
Z.3 From -02 to -03
1. Replace instances of "IS-IS and data unreachable" with just "data
unreachable" as data unreachability implies IS-IS unreachability
[RFC7180].
2. With ESADI, there is just one virtual link on which all
participating TRILL switches are adjacent. Thus, all of the useful
ESADI-LSPs in an ESADI link state database are originated by a
station on this virtual link. To avoid overworking the ESADI DRB
on the link, ESADI-LSPs sent by a reachable TRILL switch in
response to an ESADI-PSNP should be sent by the TRILL switch
originating those EASDI-LSPs.
3. Re-organize material on sending and receiving ESADI PDUs into more
smaller subsections that cover all the different circumstances.
4. Substantially expand Security Considerations section.
5. Numerous editorial changes.
Z.4 From -03 to -04
1. Change to using Extended Level 1 Circuit Scope [FS-LSP] for EASDI-
LSP, ESADI-CSNP, and ESADI-PSNP PDUs.
2. Update references to RFC 6327 to the rfc6327bis draft.
3. Sort Informational References RFCs in numeric order.
4. Add Appendix A: summary of changes to [RFC6325].
5. Minor editing changes.
Z.5 From -04 to -05
1. Expand Appendix A to be more complete and precise.
2. Add L2-IS-IS Ethertype to Figure 1 so figure and text match.
3. For clarification, add an example pseudo-random function to the
new text in Section 5.3.
4. Eliminate possible unicasting of PSNPs.
H. Zhai, et al [Page 37]
INTERNET-DRAFT TRILL: ESADI
5. Provide for staggered delay for non-originators of ESADI-LSP
fragments in response to requests for such fragments by CSNP and
PSNP messages.
6. In Section 7.2, cover inclusion in FS-LSPs as permitted by [FS-
LSP].
7. Some editing changes including expanding "MAC&label".
Z.6 From -05 to -06
1. In Section 4.3: "a an adjacent" -> "an adjacent".
2. In Section 4.4: "( 100 - Random (Jitter) )" -> Random(Jitter)".
3. Add one Acknowledgement.
Z.7 From -06 to -07
Update based on GENART and IANA reviews:
1. Update and extend the first paragraph of Section 1.1 and items 2
and 3 in Appendix A with particular attention to how this
document updates RFC 6325 and backwards compatibility.
2. Minor edits to the first part of Section 2 to clarify "pseudo-
nodes" and the use of common components inside an RBridge
implementation of the independent ESADI instances.
3. Add references to [RFC7172] inside Figures 2 and 3.
4. Section 2.1, minor edits for clarity.
5. Section 2.2, "is ignored" -> "MUST be ignored".
6. Section 3, minor edit to clarify DRB election references.
7. Explain source of "1470 bytes" in Section 6.
8. Add new second paragraph to Section 8 to clarify cases where you
might want authenticated end-station registration but would not
need ESADI-PDU authentication.
9. Substantial editorial changes to the IANA Considerations (Section
H. Zhai, et al [Page 38]
INTERNET-DRAFT TRILL: ESADI
7), based on IANA review, to clarify the requested IANA actions.
10. Update Acknowledgements.
11. Other minor editorial changes.
Z.8 From -07 to -08
Update primarily based on IESG review
1. Re-write of Appendix A to add substantial interoperability
considerations material.
2. Addition of Privacy Considerations subsection to Security
Considerations.
3. Addition of references to [RFC5310] in connection with
authentication of ESADI PDUs.
4. Update draft references due to RFC publications and add some
Acknowledgements.
5. Minor editorial changes.
Z.9 From -08 to -09
1. Fix a few typos.
2. Clarify encoding of Length field in Section 6.1.
3. Clarify some wording in Section 1, list item 2.
H. Zhai, et al [Page 39]
INTERNET-DRAFT TRILL: ESADI
Authors' Addresses
Hongjun Zhai
ZTE Corporation
68 Zijinghua Road
Nanjing 200012 China
Phone: +86-25-52877345
Email: zhai.hongjun@zte.com.cn
Fangwei Hu
ZTE Corporation
889 Bibo Road
Shanghai 201203 China
Phone: +86-21-68896273
Email: hu.fangwei@zte.com.cn
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054-1549 USA
Phone: +1-408-765-8080
Email: Radia@alum.mit.edu
Donald Eastlake
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Olen Stokes
Extreme Networks
Pamlico Building One, Suite 100
3306 East NC Hwy 54
RTP, NC 27709 USA
Email: ostokes@extremenetworks.com
H. Zhai, et al [Page 40]
INTERNET-DRAFT TRILL: ESADI
Copyright and IPR Provisions
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.
H. Zhai, et al [Page 41]
