TRILL Working Group HJ. Zhai Internet-Draft XH. Dai Intended status: Standards Track ZTE Corporation Expires: March 25, 2013 September 21, 2012 RBridge: ESADI-Extension draft-zhai-esadi-extension-for-rbv-00 Abstract In a virtual RBridge(RBv), traffic from end station ES1 to ES2 will enter a TRILL campus through one member RBridge RB1 of RBv, but reverse traffic might choose another member RBridge RB2 to leave TRILL campus. If RB1 can't obtain the location of ES2 via other means, it has to treat the traffic to ES2 as unknown destination traffic and multicasts it in TRILL campus. However, if RB2 can share its learned MAC addresses with RB1, the above problem can be resolved. Based on appropriate extensions of ESADI, this document proposes, in control plane, an approach for informations synchronization within a group of RBridges. Current informations mainly include end station addresses, but may include other informations in the future. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 25, 2013. Copyright Notice Copyright (c) 2012 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 Zhai & Dai Expires March 25, 2013 [Page 1] Internet-Draft ESADI-Extension for RBv September 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 3. Contributing authors . . . . . . . . . . . . . . . . . . . . . 4 4. Problems Statement . . . . . . . . . . . . . . . . . . . . . . 4 5. ESADI Extensions . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General Extension . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Transmitting an Extended ESADI Frame . . . . . . . . . 7 5.1.2. Receiving an Extended ESADI Frame . . . . . . . . . . 8 5.2. Extension for MAC Address Sharing . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zhai & Dai Expires March 25, 2013 [Page 2] Internet-Draft ESADI-Extension for RBv September 2012 1. Introduction In TRILL, MAC flip-flopping problem will occur in case of service edge RBridge failure or other network unrest, this problem will be worsened under LAG or multi-homing scenario, please see section 1 in [DraftPN] for detailed descriptions. so virtual RBridge(RBv), along with its pseudo-nickname(s), is introduced to TRILL to address these problems. An RBv represents a group of different RBridge ports through which member RBridges provide end-station services to a set of their attached end stations, Member RBridges announce their attachment to RBv in their LSP packets, then, based on these LSPs, other RBridges can compute the optimal path(s) to RBv. However, the RBv mechanism may cause new problems in frame forwarding. For example, Native traffic from ES1 to ES2 will enter a TRILL campus through RB1 in an RBv, but the reverse traffic (i.e., traffic from ES2 to ES1) leaves the TRILL campus through RB2 in this RBv. Then RB1 loses the chance to learn where ES2 is in data plane. If RB1 has no other ways to get the location of ES2, it will have to always treat the traffic from ES1 to ES2 as unknown unicast traffic and multicast it in TRILL campus. Furthermore, if RB2 does not know the location of ES1 and its link to ES1 fails, ES1 can't receive expected traffic even if RB1 has an active link to ES1. So, we propose to share MAC address informations among member RBridges in a group ,such as an RBv, to address the forwarding problems above. Information shared may not limit to MAC addresses, it may include other informations as the progressing of TRILL in the future. On the other hand, this information sharing is not bound to RBv , it may be used in other RBridge group cases, such as Border RBridges of an area in multi-level [MultiTRILL] [DraftDefault]. Since ESADI protocol[RFC6325][ESADI] provides a way that an RBridge can announce and learn end station addresses, we can reuse it for information sharing. However, at current, it is VLAN scoped, if an ESADI RBridge wants to share its end station addresses in several VLANs, it must enable several ESADI instances, each per VLAN. Furthermore, the current ESADI protocol can only be used to distribute MAC addresses of local end stations connected to the originating RBridge. In order to share informations within a group of RBridges as well as information of remote end stations, ESADI should be extended to some extent. 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 Zhai & Dai Expires March 25, 2013 [Page 3] Internet-Draft ESADI-Extension for RBv September 2012 document are to be interpreted as described in [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in [RFC2119]. 2.1. Abbreviations ES: End Station ESADI: End Station Address Distribution Information LAG: Link Aggregation Group 3. Contributing authors Thanks Ting Liao and Bo Wu for their discussions and inputting. 4. Problems Statement With the introduction of virtual RBridge, MAC flip-flopping problem in LAN or LAG can be resolved, for more informations on virtual RBridge, please refer to [DraftPN]. However, some new problems may occur with the introduction of RBv. For example, see Figure 1 shown below. Zhai & Dai Expires March 25, 2013 [Page 4] Internet-Draft ESADI-Extension for RBv September 2012 ES2 O | ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | ^ ^ +-------+ ^ ^ | RBn | TRILL ^ ^ +-------+ CAMPUS ^ ^ | ^ ^ * * * * * * * * * * * ^ ^ * * ^ ^ * other RBridges * ^ ^ * * ^ ^ * * ^ ^ * * * * * * * * * * * ^ ^ | | ^ ^ +------+ +-----+ ^ ^ | RB1 | | RB2 | ^ ^ +------+ + ----+ ^ ^ \............/ ^ ^ ^ ^ ^ ^ ^:\ RBv /:^ ^ ^ ^ ^ ^ ^ ^ :\......../: \ / O ES1 Figure 1 RBv in LAG scenario Native frames from ES1 to ES2 will enter the TRILL campus through one member RBridge of the RBv, such as RB1 in Figure 1, so RB1 has ES1's MAC address; but with regard to traffic returns from ES2 to ES1, RBx excutes SPF and finds that the shortest path to this RBv is through RB2. If the link between RB2 and ES1 fails, and RB2 does not know how to reach ES1 for lack of MAC address of ES1, the received traffic will not be transmitted to ES1 properly by RB2. Thus, the MAC addresses of locally attached end stations on a member RBridge SHOULD be shared among all other member RBridges in an RBv. With these shared informations, if RB2 receives native frames destinationed to ES1, it can determine how to forward these frames to ES1. Furthermore, if the link between RB2 and ES1 is good, the reverse traffic will be egressed out of TRILL by RB2. Then RB2 learns the location of ES2 by decapsulating such traffic into its native form. If RB1 has no other ways to get the location of ES2 and RB2 does not share this information with RB1, RB1 will not know where ES2 is. Then it has to always treat the traffic from ES1 to ES2 as unknown Zhai & Dai Expires March 25, 2013 [Page 5] Internet-Draft ESADI-Extension for RBv September 2012 unicast traffic and multicast it in TRILL if it is responsible to ingress such traffic. Always multicasting such traffic adds additional forwarding burden on TRILL network. Therefore, in addition to local attached end station MAC addresses, the learned remote MAC addresses should also be shared among all member RBridges in an RBv. With the shared information, RB1 can unicast traffic from ES1 to ES2 through the TRILL campus. 5. ESADI Extensions As described before, current ESADI is based on VLAN, and only destributes MAC addresses of locally attached end stations. In order to be used to solve the above problems, ESADI defined in [RFC6325] and [ESADI] should be extended to a certain extent. In the following sections, we call ESADI defined in [RFC6325] and [ESADI] as base ESADI. Extended ESADI definded in this document is used on a group base, such as an RBv, and can be used to distribute MAC address &VLAN informations of locally attached end stations as well as learned MAC addresses & VLAN of remote end stations. The following sections will give detailed extensions on base ESADI. 5.1. General Extension If member RBridges want to share informations (such as the learned MAC addresses) within the scope of their RBridge group (such as an RBv), each of them should create and enable a separate ESADI instance for that group, we call this kind of ESADI instance as non-VLAN- scoped ESADI instance. Then the shared informations can be carried in the ESADI frames originated by that instance and be flooded to other member RBridges. In the payload of those frames, the nickname of the group is also carried to indicate the scope in which the informations are expected to share. When receiving such frames, if the RBridge is (1) interested in the specified group, (2) implements this ESADI protocol extension, and (3) has an enabled ESADI instance for that group, the inner frame is decapsulated and provided to that local ESADI instance. Then the shared informations carried in the frames are learned by the RBridge. Otherwise, the shared informations carried in those frames SHOULD not be learned. Similar to ESADI instances for a VLAN, it appears to the instance for a group at one RBridge that it is directly connected by a multi- access virtual link to all other member RBridges in the group running Zhai & Dai Expires March 25, 2013 [Page 6] Internet-Draft ESADI-Extension for RBv September 2012 ESADI for that group. From all the instances on the virtual link, one is selected as ESADI-DRB to send ESADI-CSNPs periodically to keep Link State Database synchronized among its neighbors on that virtual link. After receiving an ESADI-PSNP PDU, the DRB will send the ESADI-LSPs requested by the ESADI-PSNP on the virtual link. The winner is the instance with the highest ESADI priority with System ID as tie-breaking. 5.1.1. Transmitting an Extended ESADI Frame Transmitting an extended ESADI frame is similar to base ESADI protocol, except differences described below. First, there are two methods to send such extended ESADI frames, with these methods, a receiving RBridge can distinguish such frames from the base ESADI frames: 1. Unicast method: In an ESADI frame originated by a VLAN-scoped ESADI instance, the VLAN specified in the Inner.VLAN information is the VLAN to which this ESADI frame applies, and neither 0x0 nor 0xFFF is a valid value for Inner.VLAN. When a VLAN-scoped ESADI instance receives an ESADI frame with an invalid Inner.VLAN, it discards the frame. Maybe the two values might be used as value of Inner.VLAN in the frame originated by a non-VLAN- scoped ESADI instance. Since VLAN ID 0xFFF is reserved, we proposed 0x0 is used as one method for this purpose in this document. For a non-VLAN-scoped ESADI instance, if 0x0 is used as Inner.VLAN, ESADI frames can be only unicast to its neighbors; since 0x0 is not a valid Inner.VLAN in multi-destination TRILL frames (which include ESADI frames), ESADI frames with 0x0 as Inner.VLAN may be discarded by a transit RBridge. Except for Inner.VLAN, other fields in Inner Ethernet header of such a frame are as same as those of VLAN-scoped ESADI frame. 2. Multicast method: In basic ESADI protocol, a VLAN-scoped ESADI instance MUST use a globally unique unicast MAC address as the Inner.MacSA in its originated multi-destination ESADI frames. Therefore, a non-unicast MAC address can be employed by a non VLAN-scope ESADI instance to indicate its multi-destination frames are not VLAN-scoped. In this document, we propose the multicast Zhai & Dai Expires March 25, 2013 [Page 7] Internet-Draft ESADI-Extension for RBv September 2012 MAC address of ALL-Egress-Address for this purpose. For such a frame, while any valid VLAN ID can be used as Inner.VLAN in such a frame, we RECOMMEND that VLAN ID 1 is used as Inner.VLAN since it is a default VLAN supported by all RBridges. Then a non-VLAN-scoped ESADI instance can multicast such ESADI frames to its neighbors for the necessary informations sharing. Except for proposed Inner.MacSA and the recommended VLAN ID, other fields in Inner Ethernet header of such a frame are the same as those of VLAN-scoped ESADI frame. Notes: an RBridge may use unicast method to send extended ESADI frames to each member in a same group if there are few members in this group; otherwise, if there are larger numbers of RBridgs in this group, we suggest using multicast method. Second, an extended ESADI frame MUST carry a group TLV in its payload to indicate the group to which the ESADI frame applies, and this TLV contains the nickname of the group. This TLV MUST be the first TLV in payload of each of such ESADI frames (such as ESADI-LSPs, ESADI- PSNP and ESADI-CSNP if the originator believes it is ESADI-DRB), then it is convenient for an RBridge to decide which the extended ESADI instance is proper to process the frame when receiving it. 5.1.2. Receiving an Extended ESADI Frame For an RBridge RBn, when receiving a TRILL frame, it does the general examinations (specified in Section 4.6.2 of RFC6325) on the frame. If it confirms the frame is an ESADI frame, that is, Inner.MacDA is the ALL-Egress-Address multicast MAC address, and then the following additional tests are done: o If M=0 and the egress nickname is not that of RBn, the frame is forwarded as known unicast TRILL data frame. If M=0 and the egress nickname is that of the receiving RBridge, then the frame is de-capsulated and processed locally. The Inner.VLAN is examined, if being not 0x0, the frame is a VLAN-scoped ESADI frame and provided to its associated local ESADI instance. If being 0x0, the frame is a non-VLAN-scoped ESADI frame, then the first TLV in payload is checked. If it is a group TLV, the frame is a group-scoped ESADI frame and the frame is provided to the interested group-scoped ESADI instance. o If M=1, the frame is a multicast ESADI frame and is forwarded down the tree specified by the egress RBridge nickname. In addition, the Inner.MacSA is examined. If it is a unicast MAC address, the frame is a VLAN-scoped ESADI frame and provided to its associated Zhai & Dai Expires March 25, 2013 [Page 8] Internet-Draft ESADI-Extension for RBv September 2012 local ESADI instance. If Inner.MacSA is ALL-Egress-Address, the frame is not a VLAN-scoped ESADI frame, then the first TLV in payload is checked. If it is a group TLV, the frame is a group- scoped ESADI frame and the frame is provided to the interested group-scoped ESADI instance. 5.2. Extension for MAC Address Sharing In order to realize MAC address sharing within a group of RBridges, we reuse the MAC reachability TLV defined in [RFC6165] and [ESADI] to carry MAC addresses of attached end stations. And the main differences covers the nickname and the VLAN ID fields in the MAC Reachability TLV, please see the following paragraph. There are two cases on the MAC addresses in MAC Reachability TLV, one is that the MAC addresses are addresses of local attached end stations; the other is MAC addresses of end stations attached to a remote RBridge. When transmitting an extended ESADI frame, for the former case, a MAC Reachability TLV might not contain a nickname, if must have one, this should be the device nickname of the originating RBridge; For the latter case, the nickname in a MAC Reachability TLV is the egress nickname of the end station identified by the MAC address. So when an RBridge receives a group-scoped ESADI frame, it can learn the location of the end station, i.e, if a MAC Reachability TLV contains a nickname, then the end station is attached to the RBridge identified by this nickname, otherwise, to the RBridge identified by the ingress nickname in TRILL header. In this document, it is RECOMMENDED that the preference of MAC addresses learned through group-scoped ESADI instance frames is lower than those learned from local native frames. 6. IANA Considerations TBD. 7. Security Considerations TBD. 8. Acknowledgements TBD Zhai & Dai Expires March 25, 2013 [Page 9] Internet-Draft ESADI-Extension for RBv September 2012 9. References 9.1. Normative References [CMT] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT)for TRILL", draft-ietf-trill-cmt-00.txt Work in Progress, April 2012. [ESADI] Zhai, H., Hu, F., Eastlake 3rd, D., and R. Perlman, "TRILL (Transparent Interconnection of Lots of Links): The ESADI (End Station Address Distribution Information) Protocol", draft-ietf-trill-esadi-00.txt Work in Progress, June 2012. [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. [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011. [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. 9.2. Informative References [DraftDefault] Senevirathne, T., Pathangi, J., Hudson, J., Aldrin, S., Banerjee, A., and S. Merchant, "Default Nickname Based Approach for Multilevel TRILL", draft-tissa-trill-multilevel-00.txt Work in Progress, February 2012. [DraftPN] Zhai, H., Hu, F., Eastlake 3rd, D., and R. Perlman, "RBridge: Pseudo-Nickname", draft-hu-trill-pseudonode-nickname-03.txt Work in Progress, Aug 2012. [MultiTRILL] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Multilevel TRILL (Transparent Interconnection of Lots of Links)", draft-perlman-trill-rbridge-multilevel-04.txt Work in Progress, May 2012. Zhai & Dai Expires March 25, 2013 [Page 10] Internet-Draft ESADI-Extension for RBv September 2012 Authors' Addresses Hongjun Zhai ZTE Corporation 68 Zijinghua Road, Yuhuatai District Nanjing, Jiangsu 210012 China Email: zhai.hongjun@zte.com.cn Xuehui Dai ZTE Corporation Email: dai.xuehui@zte.com.cn Zhai & Dai Expires March 25, 2013 [Page 11]