TRILL working group L. Dunbar Internet Draft D. Eastlake Intended status: Standard Track Huawei Expires: October 2014 Radia Perlman Intel I. Gashinsky Yahoo April 8, 2014 Directory Assisted TRILL Encapsulation draft-dunbar-trill-directory-assisted-encap-07.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 8, 2014. Dunbar, et al. Expires October 8, 2014 [Page 1] Internet-Draft Directory Assisted TRILL Encap April 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This draft describes how data center network can benefit from non-RBridge nodes performing TRILL encapsulation with assistance from directory service. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Directory Assistance to Non-RBridge............................4 4. Source Nickname in Frames Encapsulated by Non-RBridge Nodes.............................................................6 5. Benefits of Non-RBridge encapsulating TRILL header.............7 5.1. Avoid Nickname Exhaustion Issue...........................7 5.2. Reduce MAC Tables for switches on Bridged LANs............7 6. Conclusion and Recommendation..................................8 7. Manageability Considerations...................................8 8. Security Considerations........................................9 9. IANA Considerations............................................9 10. References....................................................9 10.1. Normative References.....................................9 10.2. Informative References...................................9 11. Acknowledgments..............................................10 Dunbar, et al. Expires October 8, 2014 [Page 2] Internet-Draft Directory Assisted TRILL Encap April 2014 1. Introduction This draft describes how data center network can benefit from non-RBridge nodes performing TRILL encapsulation with assistance from directory service. [RFC7067] describes the framework for RBridge edge to get MAC&VLAN<->RBridgeEdge mapping from a directory service in data center environment instead of flooding unknown DAs across TRILL domain. When directory is used, any node, even a non- RBridge node, can perform the TRILL encapsulation. This draft is to describe the benefits and the scheme of 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC- 2119 significance. AF Appointed Forwarder RBridge port [RFC6439] Bridge: IEEE 802.1Q compliant device. In this draft, Bridge is used interchangeably with Layer 2 switch. DA: Destination Address DC: Data Center EoR: End of Row switches in data center. Also known as Aggregation switches in some data centers Host: Application running on a physical server or a virtual machine. A host usually has at least one IP address and at least one MAC address. SA: Source Address ToR: Top of Rack Switch in data center. It is also known as access switches in some data centers. Dunbar, et al. Expires October 8, 2014 [Page 3] Internet-Draft Directory Assisted TRILL Encap April 2014 TRILL-EN: TRILL Encapsulating node. It is a node that only performs the TRILL encapsulation but doesn’t participate in RBridge’s IS-IS routing. VM: Virtual Machines 3. Directory Assistance to Non-RBridge With directory assistance [RFC7067], a non-RBridge can be informed if a packet needs to be forwarded across the RBridge domain and the corresponding egress RBridge. Suppose the RBridge domain boundary starts at network switches (not virtual switches embedded on servers), a directory can assist Virtual Switches embedded on servers to encapsulate with a proper TRILL header by providing the nickname of the egress RBridge edge to which the target is attached. The other information needed to encapsulate can be either learned by listening to TRILL Hellos, which will indicate the MAC address and nickname of appropriate edge RBridges, or by configuration. If a target is not attached to other RBridge edge nodes based on the directory [RFC7067], the non-RBridge node can forward the data frames natively, i.e. not encapsulating any TRILL header. \ +-------+ +------+ TRILL Domain/ \ +/------+ | +/-----+ | / \ | Aggr11| + ----- |AggrN1| + / \ +---+---+/ +------+/ / \ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ / \- |T11|... |T1x| |T21| ... |T2y|--- +---+ +---+ +---+ +---+ | | | | +-|-+ +-|-+ +-|-+ +-|-+ | |... | V | | V | ... | V |<- vSwitch +---+ +---+ +---+ +---+ | |... | V | | V | ... | V | +---+ +---+ +---+ +---+ | |... | V | | V | ... | V | +---+ +---+ +---+ +---+ Figure 1 TRILL domain in typical Data Center Network Dunbar, et al. Expires October 8, 2014 [Page 4] Internet-Draft Directory Assisted TRILL Encap April 2014 When a TRILL encapsulated data packet reaches the ingress RBridge, the ingress RBridge can simply forward the pre- encapsulated packet to the RBridge that is specified by the egress nickname field of the TRILL header of the data frame. When the ingress RBridge receives a native Ethernet frame, it handles it as usual and may drop it if it has complete directory information indicating that the target is not attached to the TRILL campus. In this environment with complete directory information, the ingress RBridge doesn’t flood or send the received Ethernet data frames to TRILL domain when the DA in the Ethernet data frames is unknown. When all attached nodes to ingress RBridge can pre-encapsulate TRILL header for traffic across the TRILL domain, the ingress RBridge don’t need to encapsulate any native Ethernet frames to the TRILL domain. All native Ethernet frames are switched by the attached bridged LAN per IEEE802.1Q. Under this environment, there is no need to designate AF ports and all RBridge edge ports connected to one bridged LAN can receive and forward pre-encapsulated traffic, which can greatly improve the overall network utilization. Note: [RFC6325] Section 4.6.2 Bullet 8 specifies that an RBridge port can be configured to accept TRILL encapsulated frames from a neighbor that is not an RBridge. When a TRILL frame arrives at an RBridge whose nickname matches with the destination nickname in the TRILL header of the frame, the processing is exactly same as normal, i.e. the RBridge decapsulates the received TRILL frame and forwards the decapsulated Ethernet frame to the target attached to its edge ports. When the DA of the decapsulated Ethernet frame is not in the egress RBridge’s local MAC attachment tables, the egress RBridge can flood the decapsulated Ethernet frame to all hosts attached or drop the frame (if the egress RBridge is configured with the policy). We call a node that only performs the TRILL encapsulation but doesn’t participate in RBridge’s IS-IS routing a TRILL Encapsulating node (TRILL-EN). The TRILL Encapsulating Node can get the MAC&VLAN<->RBridgeEdge mapping table pulled from directory servers [RFC7067]. Dunbar, et al. Expires October 8, 2014 [Page 5]