RFC 8171
Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
Pages: 55
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 42 to 55
4. Directory Use Strategies and Push-Pull Hybrids
For some edge nodes that have a great number of Data Labels enabled, managing the MAC and Data Label <-> Edge RBridge mapping for hosts under all those Data Labels can be a challenge. This is especially true for data-center gateway nodes, which need to communicate with many, if not all, Data Labels.
For those edge TRILL switch nodes, a hybrid model should be
considered. That is, the Push Model is used for some Data Labels or
addresses within a Data Label, while the Pull Model is used for other
Data Labels or addresses within a Data Label. The network operator
decides, via configuration, which Data Labels' mapping entries are
pushed down from directories and which Data Labels' mapping entries
are pulled.
For example, assume a data center where hosts in specific Data
Labels, say VLANs 1 through 100, communicate regularly with external
peers. The mapping entries for those 100 VLANs should probably be
pushed down to the data-center gateway routers. For hosts in other
Data Labels that only communicate with external peers occasionally
for management interfacing, the mapping entries for those VLANs
should be pulled down from the directory when needed.
Similarly, within a Data Label, it could be that some addresses, such
as the addresses of gateways, files, DNS, or database server hosts
are commonly referenced by most other hosts but those other hosts,
perhaps compute engines, are typically only referenced by a few hosts
in that Data Label. In that case, the address information for the
commonly referenced hosts could be pushed as an incomplete directory,
while the addresses of the others are pulled when needed.
The mechanisms described in this document for Push and Pull Directory
services make it easy to use Push for some Data Labels or addresses
and Pull for others. In fact, different TRILL switches can even be
configured so that some use Push Directory services and some use Pull
Directory services for the same Data Label if both Push and Pull
Directory services are available for that Data Label. Also, there
can be Data Labels for which directory services are not used at all.
There are a wide variety of strategies that a TRILL switch can adopt
for making use of directory assistance. A few suggestions are given
below.
- Even if a TRILL switch will normally be operating with information
from a complete Push Directory server, there will be a period of
time when it first comes up before the information it holds is
complete. Or, it could be that the only Push Directories that can
push information to it are incomplete or that they are just
starting and may not yet have pushed the entire directory. Thus,
it is RECOMMENDED that all TRILL switches have a strategy for
dealing with the situation where they do not have complete
directory information. Examples are to send a Pull Directory
query or to revert to the behavior described in [RFC6325].
- If a TRILL switch receives a native frame X resulting in seeking
directory information, a choice needs to be made as to what to do
if it does not already have the directory information it needs.
In particular, it could (1) immediately flood the TRILL Data
packet resulting from ingressing X in parallel with seeking the
directory information, (2) flood that TRILL Data packet after a
delay, if it fails to obtain the directory information, or
(3) discard X if it fails to obtain the information. The choice
might depend on the priority of frame X, since the higher that
priority the more urgent the frame typically is, and the greater
the probability of harm in delaying it. If a Pull Directory
request is sent, it is RECOMMENDED that its priority be derived
from the priority of frame X according to the table below;
however, it SHOULD be possible, on a per-TRILL-switch basis, to
configure the second two columns of this table.
Ingressed If Flooded If Flooded
Priority Immediately After Delay
-------- ----------- -----------
7 5 6
6 5 6
5 4 5
4 3 4
3 2 3
2 0 2
0 1 0
1 1 1
Note: The odd-looking ordering of numbers towards the bottom of
the columns above is because priority 1 is lower than priority
zero. That is to say, the values in the first column are in
priority order. They will look more logical if you think of "0"
as being "1.5".
Priority 7 is normally only used for urgent messages critical to
adjacency and so SHOULD NOT be the default for directory traffic.
Unsolicited updates are sent with a priority that is configured per
Data Label and that defaults to priority 5.
5. TRILL ES-IS
TRILL ES-IS (End System to Intermediate System) is a variation of
TRILL IS-IS [RFC7176] [RFC7177] [RFC7780] designed to operate on a
TRILL link among and between one or more TRILL switches and end
stations on that link. TRILL ES-IS is analogous to the ISO/IEC ES-IS
standard [ISO9542] but is implemented in a significantly different
way as a variation of TRILL IS-IS, as specified in this section.
Support of TRILL ES-IS is generally optional for both the TRILL
switches and the end stations on a link but may be required to
support certain features. At the time of this writing, the only
features requiring TRILL ES-IS are those listed in this section.
TRILL ES-IS
o is useful for supporting Pull Directory hosting on, or use from,
end stations (see Section 3.5),
o is useful for supporting specialized end stations [DirAsstEncap]
[SmartEN], and
o may have additional future uses.
The advantages of TRILL ES-IS over simply making an "end station" be
a TRILL switch include relieving the end station of having to
maintain a copy of the core link-state database (LSPs) and of having
to perform routing calculations or having the ability to forward
traffic.
Except as provided below in this section, TRILL ES-IS PDUs and TLVs
are the same as TRILL IS-IS PDUs and TLVs.
5.1. PDUs and System IDs
All TRILL ES-IS PDUs (except some MTU-probe and MTU-ack PDUs, which
may be unicast) are multicast using the TRILL-ES-IS multicast MAC
address (see Section 7.6). This use of a different multicast address
assures that TRILL ES-IS and TRILL IS-IS PDUs will not be confused
for one another.
Because end stations do not have IS-IS System IDs, TRILL ES-IS uses
port MAC addresses in their place. This is convenient, since MAC
addresses are 48-bit and almost all IS-IS implementations use 48-bit
System IDs. Logically, TRILL IS-IS operates between the TRILL
switches in a TRILL campus as identified by the System ID, while
TRILL ES-IS operates between Ethernet ports on an Ethernet link
(which may be a bridged LAN) as identified by the MAC address
[RFC6325].
As System IDs of TRILL switches in a campus are required to be
unique, so the MAC addresses of TRILL ES-IS ports on a link MUST be
unique.
5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs
TRILL ES-IS adjacency formation and Designated RBridge (DRB) election operate between the ports on the link as specified in [RFC7177] for a broadcast link. The DRB specifies an ES-IS Designated VLAN for the link. Adjacency determination, DRB election, and Designated VLANs as described in this section are distinct from TRILL IS-IS adjacency, DRB election, and Designated VLANs. Although the "Report state" [RFC7177] exists for TRILL ES-IS adjacencies, such adjacencies are only reported in TRILL ES-IS LSPs, not in any TRILL IS-IS LSPs. End stations supporting TRILL ES-IS MUST assign a unique Port ID to each of their TRILL ES-IS ports; the Port ID appears in the TRILL ES-IS Hellos they send. TRILL ES-IS has nothing to do with Appointed Forwarders. The Appointed Forwarders sub-TLV and the VLANs Appointed sub-TLV [RFC7176] are not used and SHOULD NOT be sent in TRILL ES-IS; if such a sub-TLV is received in TRILL ES-IS, it is ignored. (The Appointed Forwarders on a link are determined as specified in [RFC8139], using TRILL IS-IS.) Although some of the ports sending TRILL ES-IS PDUs are on end stations and thus not on routers (TRILL switches), they nevertheless may make use of the Router CAPABILITY (#242) [RFC7981] and MT-Capability (#144) [RFC6329] IS-IS TLVs to indicate capabilities as specified in [RFC7176]. TRILL ES-IS Hellos are like TRILL IS-IS Hellos, but note the following: in the Special VLANs and Flags sub-TLV [RFC7176], any TRILL switches advertise a nickname they own, but for end stations, that field MUST be sent as zero and ignored on receipt. In addition, in the Special VLANs and Flags sub-TLV (Section 2.2.1 of [RFC7176]) in a TRILL ES-IS Hello, the AF and TR flag bits MUST be sent as zero, the AC flag bit MUST be sent as one (1), and all three are ignored on receipt.
5.3. Link State
The only link-state transmission and synchronization that occur in TRILL ES-IS are for E-L1CS (Extended Level 1 Circuit Scope) PDUs [RFC7356]. In particular, the end-station Ethernet ports supporting TRILL ES-IS do not support the core TRILL IS-IS LSPs and do not support E-L1FS (Extended Level 1 Flooding Scope) LSPs [RFC7780] (or the CSNPs or PSNPs (Partial Sequence Number PDUs) [RFC7356] corresponding to either of them). TLVs and sub-TLVs that would otherwise be sent in TRILL IS-IS LSPs or E-L1FS LSPs are instead sent in E-L1CS LSPs.6. Security Considerations
For general TRILL security considerations, see [RFC6325].6.1. Directory Information Security
Incorrect directory information can result in a variety of security threats, including those listed below. Directory servers therefore need to take care to implement and enforce access control policies that are not overly permissive. o Incorrect directory mappings can result in data being delivered to the wrong end stations, or set of end stations in the case of multi-destination packets, violating security policy. o Missing, incorrect, or inaccessible directory data can result in denial of service due to sending data packets to black holes or discarding data on ingress due to incorrect information that their destinations are not reachable or that their source addresses are forged. For these reasons, whatever server or end station the directory information resides on, it needs to be protected from unauthorized modification. Parties authorized to modify directory data can violate availability and integrity policies.6.2. Directory Confidentiality and Privacy
In implementations of the base TRILL protocol [RFC6325] [RFC7780], RBridges deal almost exclusively with MAC addresses. The use of directories to map to/from IP addresses means that RBridges deal more actively with IP addresses as well. But RBridges in any case would be exposed to plain-text ARP/ND/SEND/IP traffic and so can see all this addressing metadata. So, this more-explicit dealing with IP addresses has little effect on the privacy of end-station traffic.
Parties authorized to read directory data can violate privacy policies for such data.6.3. Directory Message Security Considerations
Push Directory data is distributed through ESADI-LSPs [RFC7357]. ESADI is built on IS-IS, and such data can thus be authenticated with the widely implemented and deployed IS-IS PDU security. This mechanism provides authentication and integrity protection. See [RFC5304], [RFC5310], and the Security Considerations section of [RFC7357]. Pull Directory queries and responses are transmitted as RBridge-to-RBridge or native RBridge Channel messages [RFC7178]. Such messages can be secured by the mechanisms specified in [RFC7978]. These mechanisms can provide authentication and confidentiality protection. At the time of this writing, these security mechanisms are believed to be less widely implemented than IS-IS security.7. IANA Considerations
7.1. ESADI-Parameter Data Extensions
IANA has created a subregistry in the "TRILL Parameters" registry as follows: Subregistry: ESADI-Parameter APPsub-TLV Flag Bits Registration Procedure(s): Standards Action References: [RFC7357] [RFC8171] Bit Mnemonic Description Reference --- -------- ---------------------------- --------------- 0 UN Supports Unicast ESADI ESADI [RFC7357] 1-2 PDSS Push Directory Server Status [RFC8171] 3-7 - Unassigned In addition, the ESADI-Parameter APPsub-TLV is optionally extended, as provided in its original specification in ESADI [RFC7357], by 1 byte as shown below. Therefore, [RFC8171] has also been added as a second reference to the ESADI-Parameter APPsub-TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry.
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|R| Priority | (1 byte)
+-+-+-+-+-+-+-+-+
| CSNP Time | (1 byte)
+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+---------------+
|PushDirPriority| (optional, 1 byte)
+---------------+
| Reserved for (variable)
| expansion
+-+-+-+-...
The meanings of all the fields are as specified in ESADI [RFC7357],
except that the added PushDirPriority is the priority of the
advertising ESADI instance to be a Push Directory as described in
Section 2.3. If the PushDirPriority field is not present
(Length = 3), it is treated as if it were 0x3F. 0x3F is also the
value used and placed here by a TRILL switch whose priority to be a
Push Directory has not been configured.
7.2. RBridge Channel Protocol Numbers
IANA has assigned a new RBridge Channel Protocol number (0x005) from
the range assignable by Standards Action [RFC5226] and updated the
subregistry accordingly in the "TRILL Parameters" registry. The
description is "Pull Directory Services". The reference is
[RFC8171].
7.3. The Pull Directory (PUL) and No Data (NOD) Bits
IANA has assigned a previously reserved bit in the Interested VLANs
field of the Interested VLANs sub-TLV and the Interested Labels field
of the Interested Labels sub-TLV [RFC7176] to indicate a Pull
Directory server (PUL). This bit has been added, with this document
as a reference, to the "Interested VLANs Flag Bits" and "Interested
Labels Flag Bits" subregistries created by [RFC7357], as shown below.
IANA has assigned a previously reserved bit in the Interested VLANs field of the Interested VLANs sub-TLV and the Interested Labels field of the Interested Labels sub-TLV [RFC7176] to indicate No Data (NOD) (see Section 3.8). This bit has been added, with this document as a reference, to the "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" subregistries created by [RFC7357], as shown below. The bits are as follows: Registry: Interested VLANs Flag Bits Bit Mnemonic Description Reference --- -------- -------------- --------------- 18 PUL Pull Directory [RFC8171] 19 NOD No Data [RFC8171] Registry: Interested Labels Flag Bits Bit Mnemonic Description Reference --- -------- -------------- --------------- 6 PUL Pull Directory [RFC8171] 7 NOD No Data [RFC8171]7.4. TRILL Pull Directory QTYPEs
IANA has created a new registry as follows: Name: TRILL Pull Directory Query Types (QTYPEs) Registration Procedure(s): IETF Review Reference: [RFC8171] Initial contents as in Section 3.2.1.7.5. Pull Directory Error Code Registries
IANA has created a new registry and two new indented subregistries as follows: Registry Name: TRILL Pull Directory Errors Registration Procedure(s): IETF Review Reference: [RFC8171] Initial contents as in Section 3.6.1.
Subregistry
Name: Sub-codes for TRILL Pull Directory Errors 1 and 3
Registration Procedure(s): Expert Review
Reference: [RFC8171]
Initial contents as in Section 3.6.2.
Subregistry
Name: Sub-codes for TRILL Pull Directory Errors 128 and 131
Registration Procedure(s): Expert Review
Reference: [RFC8171]
Initial contents as in Section 3.6.3.
7.6. TRILL-ES-IS MAC Address
IANA has assigned a TRILL multicast MAC address (01-80-C2-00-00-47)
from the "TRILL Multicast Addresses" registry. The description is
"TRILL-ES-IS". The reference is [RFC8171].
8. References
8.1. Normative References
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>.
[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
Reverse Address Resolution Protocol", STD 38, RFC 903,
DOI 10.17487/RFC0903, June 1984,
<http://www.rfc-editor.org/info/rfc903>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>. [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>. [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>. [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>. [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>. [RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>. [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>. [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>. [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>. [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>. [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>. [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>. [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>. [RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, August 2016, <http://www.rfc-editor.org/info/rfc7961>. [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <http://www.rfc-editor.org/info/rfc7981>. [RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC7961, June 2017, <http://www.rfc-editor.org/info/rfc8139>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>. [RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <http://www.rfc-editor.org/info/rfc7978>. [ARPND] Li, Y., Eastlake 3rd, D., Dunbar, L., Perlman, R., and M. Umair, "TRILL: ARP/ND Optimization", Work in Progress, draft-ietf-trill-arp-optimization-08, April 2017. [DirAsstEncap] Dunbar, L., Eastlake 3rd, D., and R. Perlman, "Directory Assisted TRILL Encapsulation", Work in Progress, draft-ietf-trill-directory-assisted-encap-05, May 2017. [ISO9542] ISO 9542:1988, "Information processing systems -- Telecommunications and information exchange between systems -- End system to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473)", August 1988. [SmartEN] Perlman, R., Hu, F., Eastlake 3rd, D., Krupakaran, K., and T. Liao, "TRILL Smart Endnodes", Work in Progress, draft-ietf-trill-smart-endnodes-05, February 2017. [X.233] International Telecommunication Union, ITU-T Recommendation X.233: "Information technology - Protocol for providing the connectionless-mode network service: Protocol specification", August 1997, <https://www.itu.int/rec/T-REC-X.233/en>.
Acknowledgments
The contributions of the following persons are gratefully acknowledged: Amanda Baber, Matthew Bocci, Alissa Cooper, Stephen Farrell, Daniel Franke, Igor Gashinsky, Joel Halpern, Susan Hares, Alexey Melnikov, Gayle Noble, and Tianran Zhou.Authors' Addresses
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Linda Dunbar Huawei Technologies 5430 Legacy Drive, Suite #175 Plano, TX 75024 United States of America Phone: +1-469-277-5840 Email: ldunbar@huawei.com Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States of America Email: Radia@alum.mit.edu Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China Phone: +86-25-56622310 Email: liyizhou@huawei.com