Network working group X. Xu Internet Draft Huawei Category: Standard Track H. Shah Ciena Corp L. Yong P. Ashwood-Smith Huawei Y. Fan China Telecom Expires: April 2013 October 15, 2012 NVo3 Control Plane Protocol Using IS-IS draft-xu-nvo3-isis-cp-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 April 15, 2013. Copyright Notice Copyright (c) 2009 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 Xu, et al. Expires April 15, 2013 [Page 1] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 (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. Abstract This document describes the use of IS-IS as a common control plane protocol of Network Virtualization over L3 (NVo3) overlay networks which can be suitable for any specific NVo3 overlay encapsulation formats. 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]. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 3 3. Control Plane ............................................... 4 3.1. VN Membership Auto-discovery ........................... 4 3.1.1. VN Info TLV ....................................... 4 3.2. Encapsulation Capability Advertisement ................. 5 3.2.1. Encapsulation Capability TLV ...................... 5 3.2.2. Encapsulation Type Sub-TLV ........................ 6 3.3. Tunnel Address Prefix Advertisement .................... 7 3.3.1. Tunnel Address Prefix TLV ......................... 7 3.4. Layer2 NV Multi-homing ................................. 8 3.4.1. Layer2 NV Multi-homing TLV ........................ 9 3.4.2. DF Election Procedure ............................ 10 3.4.3. MAC Withdrawn in the Active/standby Failover ..... 10 3.5. MAC Reachability Info Advertisement ................... 10 3.6. IP Reachability Info Advertisement .................... 11 4. Security Considerations .................................... 11 5. IANA Considerations ........................................ 11 6. Acknowledgements ........................................... 12 7. References ................................................. 12 7.1. Normative References .................................. 12 7.2. Informative References ................................ 12 8. Authors' Addresses ......................................... 13 Xu, et al. Expires April 15, 2013 [Page 2] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 1. Introduction [NVo3-PS] discusses the need of an overlay-based network virtualization approach, referred to as Network Virtualization over Layer3 (NVo3), for providing multi-tenancy capabilities in large data centers networks and outlines the needs for a control plane protocol to facilitate running these NVo3 overlay networks. [NVo3-FW] provides a framework for NVo3 overlay networks and meanwhile describes the needs for a control plane protocol to provide the following capabilities such as auto-provisioning/service discovery, address mapping advertisement and tunnel management. [NVo3-CP] outlines the high-level requirements of the control plane protocol(s) for NVo3 overlay networks. IS-IS protocol [IS-IS] is a much proven and well-known routing protocol which has been widely deployed in many large carrier networks and data center networks for decades of years. Due to its extendibility, IS-IS protocol now is not only used for propagating IP reachability information in Layer3 networks (see [RFC1195]), but also used for propagating MAC reachability information in Layer2 networks or Layer2 overlay networks(see [RFC6165]). This document accordingly proposes using IS-IS as a common control plane protocol of NVo3 overlay networks which can be workable with any specific NVo3 overlay encapsulation formats including Layer2 overlay encapsulation formats as well as Layer3 overlay encapsulation formats. It's no doubt that Border Gateway Protocol (BGP) is more scalable than IS-IS and hence the former is more suitable to be used as a common NVo3 control plane in large data center network environments. However, for some small and even medium sized data center networks, the complexity of BGP is perhaps too much and even unaffordable. IS- IS -based common NVo3 control plane could be an alternative choice for these small and even medium data center networks where automating and simplifying the network provisioning is particularly important. 2. Terminology This memo makes use of the terms defined in [NVo3-FW], [RFC4664], and [RFC4364]. Xu, et al. Expires April 15, 2013 [Page 3] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 3. Control Plane 3.1. VN Membership Auto-discovery One of the requirements of the NVo3 overlay control plane protocol outlined in [NVo3-CP] is: "Do not rely on IP Multicast in the Underlying Network". As such, the control plane protocol SHOULD at least have the capability of VN membership auto-discovery. By propagating the following VN Info TLVs among Network Virtualization Edges (NVEs) (i.e., PE routers in the context of L2VPN [RFC4761, RFC4762] or L3VPN [RFC4364] technologies), NVEs belonging to the same VN instance could discover one another automatically. Note that this TLV is applicable to both Layer2 and Layer3 overlay cases. 3.1.1. VN Info TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Type=VN Info | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originating NVE's IP Address | | (128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (8 bits) | VN ID (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (12 bits) | Local MPLS Label (20 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (8 bits) | VN ID (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (12 bits) | Local MPLS Label (20 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type code for VN Info TLV: TBD. Length Xu, et al. Expires April 15, 2013 [Page 4] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 Total number of bytes contained in the value field. Originating NVE's IP Address This 128-bit field is filled with one of the originating NVE's IPv4 or IPv6 addresses which are reachable across the IP backbone. The address filled in this field SHOULD be used as a tunnel destination address by remote NVEs when these NVEs acting as NVEs want to tunnel a customer Ethernet frame or IP packet to such NVE. If the IP address is IPv4, the last four octets of this field are filled with the IPv4 address while the remaining part is set to zero. In other words, it is filled with an IPv4-mapped IPv6 address. VN ID This field is filled with a 24-bit globally significant VN ID for a particular attached VN instance. Local MPLS Label This field is filled with a locally significant MPLS label associated with the VN ID. This field is only meaningful in the case where MPLS labels are contained in the NVo3 encapsulated packets and are used for identifying specific VN instances that the encapsulated packets belong to. Otherwise, this field MUST be set to zero. 3.2. Encapsulation Capability Advertisement To reach a consensus on what specific encapsulation format to be used between ingress and egress NVE pairs, egress NVEs SHOULD advertise their own encapsulation capabilities automatically by using the following Encapsulation Type TLV. In other words, egress NVEs SHOULD notice ingress NVEs of what specific encapsulation format(s) they can support. Note that this TLV is applicable to both Layer2 and Layer3 overlay cases. 3.2.1. Encapsulation Capability TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |Type=Encap Cap | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xu, et al. Expires April 15, 2013 [Page 5] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 | Encap Type Sub-TLV (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type code for Encapsulation Capability TLV: TBD. Length Total number of bytes contained in the value field. Value This field is filled with one or more Encap Type Sub-TLVs with each indicating one specific encapsulation type. 3.2.2. Encapsulation Type Sub-TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |Type=Encap Type| +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Specific Encap Format (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type code for the Encapsulation Type Sub-TLV, and this document defines the following types: - VXLAN [VXLAN]: Sub-TLV Type = 1 - NVGRE [NVGRE]: Sub-TLV Type = 2 - STT [STT]: Sub-TLV Type = 3 - MPLS-in-GRE [RFC4023]: Sub-TLV Type = 4 - MPLS-in-IP [RFC4023]: Sub-TLV Type = 5 - MPLS-in-UDP [MPLS-in-UDP]: Sub-TLV Type = 6 Xu, et al. Expires April 15, 2013 [Page 6] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 Length Total number of bytes contained in the value field. Value This field is filled with the detailed encapsulation requirements specific to a given encapsulation format. If there is no further encapsulation requirement, this field could be zero in length. More details are to be defined in the future version of this document. 3.3. Tunnel Address Prefix Advertisement To facilitate the load-balancing of encapsulated NVo3 overlay traffic in the IP core of the underlying networks in some cases, it'd better for distinct traffic flows between a given tunnel endpoint pair (i.e., an ingress and egress NVE pair) to be encapsulated with tunnel headers of as many different tunnel destination addresses as possible. To achieve this goal, egress NVEs could notice ingress NVEs of multiple tunnel endpoint addresses for encapsulation in the form of an IP address prefix. If more than one IP address prefix needs to be advertised, multiple such TLVs can be carried in a LSP. Note that this TLV is applicable to both Layer2 and Layer3 overlay cases. 3.3.1. Tunnel Address Prefix TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |Type=Tunnel AP | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Subnet Address (32 or 128 bits) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Subnet Mask (32 or 128 bits) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type code for Tunnel Address Prefix TLV: TBD. Length Xu, et al. Expires April 15, 2013 [Page 7] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 Total number of bytes contained in the value field. If the tunnel address prefix is an IPv4 one, the Length value is set to 8, and if the tunnel address prefix is an IPv6 one, the Length value is set to 32. Value This field is filled with a two tuple . 3.4. Layer2 NV Multi-homing Taking the scenario shown in Figure 1 as an example, a physical Ethernet switch or a virtual switch embedded on a physical server is dual-homed to two NVEs, NVE-1 and NVE-2. The dual-homed device is referred to as a DHD. These two NVEs form one or more redundancy groups (RG) with each providing a given VLAN on the DHD a reliable connectivity to the corresponding NV overlay(s) on the NVEs. For example, the DHD is configured with two VLANs which are attached to two NV instances respectively. These two NVEs would therefore form two separate RGs with each for a given VLAN or VN instance. These NVEs uses the following Layer2 VN Multi-homing TLV to automatically elect the one among them as the designated forwarder (DF) on the per RG basis. The DF SHOULD keep its attachment circuit to the multi- homed DHD in forwarding status while all the other NVEs of that RG that are not elected as the DF MUST keep their attachment circuits to the multi-homed DHD in non-forwarding status. To achieve a better load-balance among these two NVEs, NVE-1 could be elected as a DF for some RGs associated with the DHD, while NVE-2 could be elected as a DF for the remaining RGs associated with the same DHD. .............. : : ___ NVE-1 : / : NVE-3 __/ : IP Core : DHD __ : Network : \ : : \___ NVE-2 : : : .............. Figure 1: Layer2 VN Multi-homing Scenario Once a given NVE within a RG loses its connectivity to the corresponding multi-homed DHD, such NVE SHOULD be deemed as not being a member NVE of the RGs associated with the DHD anymore and Xu, et al. Expires April 15, 2013 [Page 8] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 therefore SHOULD withdraw the corresponding Layer2 VN multi-homing TLV advertisements that it had propagated before. 3.4.1. Layer2 NV Multi-homing TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |Type=L2 VN MH | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (8 bits) | VN ID (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | DHD ID (7 bytes) | +-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv (8 bits) | VN ID (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | DHD ID (7 bytes) | +-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type code for Layer2 Multi-homing TLV: TBD. Length Total number of bytes contained in the value field. VN ID This field is filled with a 24-bit globally significant VN ID for a particular attached Layer2 VN instance. Priority This field is filled with an 8-bit unsigned integer value which represents the priority of the originating NVE used for DF election within a given RG. The higher value means the higher priority for DF election. Xu, et al. Expires April 15, 2013 [Page 9] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 DHD ID This field is filled with a 7-byte unsigned integer value which represents the DHD. 3.4.2. DF Election Procedure Among a set of NVEs which are connected to a given DHD, the one with the highest priority would be elected to be the DF. The originating NVE's IP address would be resorted for tie breaking in case more than one NVE is configured with the same highest priority. 3.4.3. MAC Withdrawn in the Active/standby Failover In the case where the DF ceases the DF role due to some reason, e.g., the DF loses the connectivity to the multi-homed CE device or operators proactively triggers the DF switchover by decreasing the priority of the current DF, remote PE routers SHOULD flush all MAC addresses learnt against it. In the control-plane based MAC-learning mode, the former DF would withdraw the affected MAC reachability info which has been advertised before. In the data-plane based MAC- learning mode, the former DF would withdraw the affected VPLS info that has been advertised before and thus remote PE routers could flush all MAC addresses which are within the affected VPLS instance and learnt against the former DF upon receiving the VPLS info withdrawal announcement. The side-effect of such operation is that those MAC addresses which are leant against the former DF but not actually learnt from the affected CE device would also be flushed unnecessarily since remote PE routers have no way to distinguish which MAC addresses are learnt from the affected CE device and which not. 3.5. MAC Reachability Info Advertisement For those Layer2 overlay approaches which adopts the control-plane based MAC address learning mechanism, MAC reachability information of a given VN instance would be exchanged across NVEs of that VN instance. Upon learning MAC addresses of their local TES's somehow, NVEs SHOULD immediately advertise these MAC addresses to remote NVEs of the same VN instance by using the MAC-Reachability TLV defined in [RFC6165]. One or more MAC-Reachability TLVs are carried in a LSP which in turn is encapsulated with an Ethernet header. The source MAC address is the originating NVE's MAC address whereas the destination MAC address is a to-be-defined multicast MAC address specifically identifying all NVEs. Such Ethernet frames containing Xu, et al. Expires April 15, 2013 [Page 10] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 IS-IS LSPs are forwarded towards remote NVEs as if they were customer multicast Ethernet frames. Egress NVEs receiving the above frames SHOULD intercept them and accordingly process them. IP address of the NVE originating these MAC routes could be derived either from the "IP Interface Address" field contained in the corresponding LSPs (Note that the IP address here SHOULD be identical with that contained in the VN Info TLV) or from the tunnel source IP address of the NVo3 encapsulated packet containing such MAC routes. Since these LSPs are fully transparent to core routers of the underlying networks (i.e., non-NVE routers), there is no impact on the control plane of core routers at all. More details about the control-plane based MAC learning procedure are for further study. 3.6. IP Reachability Info Advertisement For those Layer3 overlay approaches, IP reachability information of a given VN instance, including both host routes and subnet routes, SHOULD be exchanged across NVEs of that VN instance. The IP- Reachability TLV defined in [RFC1195] could be used directly here. One or more IP-Reachability TLVs are carried in a LSP which in turn is encapsulated with an Ethernet header. The source MAC address is the originating NVE's MAC address whereas the destination MAC address is a to-be-defined multicast MAC address specifically identifying all NVEs. Such Ethernet frames containing IS-IS LSPs are forwarded towards remote NVEs as if they were customer multicast Ethernet frames. Egress NVEs receiving the above frames SHOULD intercept them and accordingly process them. Similarly, since these LSPs are fully transparent to core routers of the underlying networks (i.e., non-NVE routers), there is no impact on the control plane of core routers at all. 4. Security Considerations This document doesn't introduce additional security risk to IS-IS, nor does it provide any additional security feature for IS-IS. 5. IANA Considerations Several IS-IS TLV type codes as mentioned above are required to be allocated by IANA. Xu, et al. Expires April 15, 2013 [Page 11] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 6. Acknowledgements TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2005. [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195 1990. [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, 2009. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. [MPLS-in-UDP] X. Xu, et al., "Encapsulating MPLS in UDP", draft-xu- mpls-in-udp-01.txt (work in progress), May 2012. [RFC6165] A. Banerjee., D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, February 2011. [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006. Xu, et al. Expires April 15, 2013 [Page 12] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC4364] Rosen, E and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [NVo3-PS] Narten, et al, "Problem Statement: Overlays for Network Virtualization", draft-ietf-nvo3-overlay-problem- statement-00.txt (work in progress), September 2012. [NVo3-FW] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for DC Network Virtualization", draft-ietf-nvo3-framework-03.txt (work in progress), September 2012. [NVo3-CP] Kreeger, L. et al, "Network Virtualization Overlay Control Protocol Requirements", draft-kreeger-nvo3-overlay-cp (work in progress), July 2012. [VXLAN] Sridhar, T., Bursell, M., Kreeger, L., Dutt, D., Wright, C., Mahalingam, M., Duda, K., and P. Agarwal, "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan- 01.txt (work in progress), February 2012. [NVGRE] Sridhavan, M., Duda, K., Ganga, I., Greenberg, A., Lin, G., Pearson, M., Thaler, P., Tumuluri, C., and Y. Wang, "NVGRE: Network Virtualization using Generic Routing Encapsulation", draft-sridharan-virtualization-nvgre- 00.txt (work in progress), September 2011. [STT] Davie, B and J. Gross, "A Stateless Transport Tunneling Protocol for Network Virtualization (STT)", draft-davie-stt-02.txt (work in progress), September 2012. 8. Authors' Addresses Xiaohu Xu Huawei Technologies, Beijing, China Email: xuxiaohu@huawei.com Xu, et al. Expires April 15, 2013 [Page 13] Internet-Draft NVo3 Control Plane Protocol Using IS-IS October 2012 Himanshu Shah Ciena Corp Email: hshah@ciena.com Lucy Yong Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075, US Email: lucyyong@huawei.com Peter Ashwood-Smith Huawei 303 Terry Fox Drive, Suite 400, Kanata, Ontario K2K 3J1 Email: Peter.AshwoodSmith@huawei.com Yongbing Fan Guangzhou Institute,China Telecom Guangzhou, China. Phone: +86 20 38639121 Email: fanyb@gsta.com Xu, et al. Expires April 15, 2013 [Page 14]