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