Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation
RFC 8380
Document | Type | RFC - Proposed Standard (May 2018; No errata) | |
---|---|---|---|
Authors | Linda Dunbar , Donald Eastlake , Radia Perlman | ||
Last updated | 2018-05-21 | ||
Replaces | draft-dunbar-trill-directory-assisted-encap | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Susan Hares | ||
Shepherd write-up | Show (last changed 2018-02-19) | ||
IESG | IESG state | RFC 8380 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Alia Atlas | ||
Send notices to | (None) | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) L. Dunbar Request for Comments: 8380 D. Eastlake 3rd Category: Standards Track Huawei ISSN: 2070-1721 R. Perlman Dell/EMC May 2018 Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation Abstract This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection of Lots of Links) encapsulation with assistance from a directory service. 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 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8380. Copyright Notice Copyright (c) 2018 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 (https://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. Dunbar, et al. Standards Track [Page 1] RFC 8380 Directory-Assisted TRILL Encap May 2018 Table of Contents 1. Introduction ....................................................2 2. Conventions Used in This Document ...............................2 3. Directory Assistance to Non-RBridge .............................3 4. Source Nickname in Encapsulation by Non-RBridge Nodes ...........6 5. Benefits of a Non-RBridge Performing TRILL Encapsulation ........6 5.1. Avoid Nickname Exhaustion Issue ............................6 5.2. Reduce MAC Tables for Switches on Bridged LANs .............6 6. Manageability Considerations ....................................7 7. Security Considerations .........................................7 8. IANA Considerations .............................................9 9. References .....................................................9 9.1. Normative References .....................................10 9.2. Informative References ...................................10 Acknowledgments ...................................................10 Authors' Addresses.................................................10 1. Introduction This document describes how data center networks can benefit from non-RBridge nodes performing TRILL encapsulation with assistance from a directory service and specifies a method for them to do so. [RFC7067] and [RFC8171] describe the framework and methods for edge RBridges to get (MAC and VLAN) <-> Edge RBridge mapping from a directory service instead of flooding unknown destination MAC addresses across a TRILL domain. If it has the needed directory information, any node, even a non-RBridge node, can perform the TRILL data packet encapsulation. This document describes the benefits of and a scheme for non-RBridge nodes performing TRILL encapsulation. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. AF: Appointed Forwarder RBridge port [RFC8139]. Bridge: A device compliant with IEEE 802.1Q. In this document, Bridge is used interchangeably with Layer 2 switch. DA: Destination Address. ES-IS: End System to Intermediate System [RFC8171]. Dunbar, et al. Standards Track [Page 2] RFC 8380 Directory-Assisted TRILL Encap May 2018 Host: A physical server or a virtual machine running applications. A host usually has at least one IP address and at least one MAC address.Show full document text