BESS Weiguo Hao Lucy Yong S. Hares Internet Draft Huawei R. Raszuk Mirantis Inc. L. Fang Osama Zia Microsoft Shahram Davari Broadcom Andrew Qu MediaTec Intended status: Standard Track March 4, 2015 Expires: September 2015 Inter-AS Option B between NVO3 and BGP/MPLS IP VPN network draft-hao-bess-inter-nvo3-vpn-01.txt Abstract This draft describes the solution of inter-as option-B connection between NVO3 network and MPLS/IP VPN network. The ASBR located in NVO3 network is called ASBR-d, the control plane and data plane procedures at ASBR-d are specified in this document, they are different from traditional option-B ASBR defined in [RFC 4364]. 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." Hao & et,al Expires September 4, 2015 [Page 1] Internet-Draft Inter-As Option-B March 2015 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 4, 2015. Copyright Notice Copyright (c) 2015 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. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 3 3. Reference model ............................................. 5 4. Option-A inter-as solution overview.......................... 6 5. Option-B inter-as solution overview.......................... 6 6. Vanilla Inter-As Option-B procedures......................... 7 6.1. Using RFC 4364 ......................................... 7 6.1.1. DC to WAN direction................................ 7 6.1.2. WAN to DC direction................................ 8 6.1.3. NVE Operations..................................... 9 6.2. NVE-NVA architecture................................... 10 6.2.1. DC to WAN direction............................... 10 6.2.2. WAN to DC direction............................... 11 6.2.3. NVE Operations.................................... 11 6.3. Data plane procedures.................................. 11 6.3.1. DC to WAN direction............................... 11 6.3.2. WAN to DC direction............................... 12 7. Partial Option-B solution................................... 12 8. Inter-as option comparisons................................. 13 9. Security Considerations..................................... 13 10. IANA Considerations........................................ 14 11. References ................................................ 14 11.1. Normative References.................................. 14 11.2. Informative References................................ 14 12. Acknowledgments ........................................... 14 Hao & et,al Expires September 4, 2015 [Page 2] Internet-Draft Inter-As Option-B March 2015 1. Introduction In cloud computing era, multi-tenancy has become a core requirement for data centers. Since NVO3 can satisfy multi-tenancy key requirements, this technology is being deployed in an increasing number of cloud data center network. NVO3 focuses on the construction of overlay networks that operate over an IP (L3) underlay transport network. It can provide layer 2 bridging and layer 3 IP service for each tenant. VXLAN and NVGRE are two typical NVO3 technologies. NVO3 overlay network can be controlled through centralized NVE-NVA architecture or through distributed BGP VPN protocol. NVO3 has good scaling properties from relatively small networks to networks with several million tenant systems (TSs) and hundreds of thousands of virtual networks within a single administrative domain. In NVO3 network, 24-bit VNID is used to identify different virtual networks, theoretically 16M virtual networks can be supported in a data center. In a data center network, each tenant may include one or more layer 2 virtual network and in normal cases each tenant corresponds to one routing domain (RD). Normally each layer 2 virtual network corresponds to one or more subnets. To provide cloud service to external data center client, data center networks should be connected with WAN networks. BGP MPLS/IP VPN has already been widely deployed at WAN networks. Normally internal data center and external MPLS/IP VPN network belongs to different autonomous system(AS). This requires the setting up of inter-as connections at Autonomous System Border Routers(ASBRs) between NVO3 network and external MPLS/IP network. Currently, a typical connection mechanism between a data center network and an MPLS/IP VPN network is similar to Inter-AS Option-A of RFC4364, but it has scalability issue if there is huge number of tenants in data center networks. To overcome the issue, inter-as Option-B between NVO3 network and BGP MPLS/IP VPN network is proposed in this draft. 2. Conventions used in this document Network Virtualization Edge (NVE) - An NVE is the network entity that sits at the edge of an underlay network and implements network virtualization functions. Tenant System - A physical or virtual system that can play the role of a host, or a forwarding element such as a router, switch, Hao & et,al Expires September 4, 2015 [Page 3] Internet-Draft Inter-As Option-B March 2015 firewall, etc. It belongs to a single tenant and connects to one or more VNs of that tenant. VN - A VN is a logical abstraction of a physical network that provides L2 network services to a set of Tenant Systems. RD - Route Distinguisher. RDs are used to maintain uniqueness among identical routes in different VRFs, The route distinguisher is an 8- octet field prefixed to the customer's IP address. The resulting 12- octet field is a unique "VPN-IPv4" address. RT - Route targets. It is used to control the import and export of routes between different VRFs. Hao & et,al Expires September 4, 2015 [Page 4] Internet-Draft Inter-As Option-B March 2015 3. Reference model +---------------------------------------------------+ | +----+ AS1 | | | TS1| - | | +----+ - | | - +----+ +----+ | | - |NVE1| -- |TOR1|---------------+ | | +----+ - +----+ +----+ | | | | TS2|- | | | +----+ | | | +-------+ | | +------------ | ASBR-d|-|--| | +----+ | +-------+ | | | | TS3| - | | | | +----+ - | | | | - +----+ +----+ | | | - |NVE2| -- |TOR2| | | | +----+ - +----+ +----+ | | | | TS4|- | | | +----+ | | ----------------------------------------------------| | | |---------------------------------------------------| | | AS2 | | | +----+ | | | | CE1| - | | | +----+ - | | | - +----+ +-------+ | | | - | PE1| --------------------| ASBR-w|-|--| | +----+ - +----+ +-------+ | | | CE2|- | | +----+ | |---------------------------------------------------| Figure 1 Reference model Figure 1 shows an arbitrary Multi-AS VPN interconnectivity scenario between NVO3 network and BGP MPLS/IP VPN network. NVE1, NVE2, and ASBR-d forms NVO3 overlay network in internal DC. TS1 and TS2 connect to NVE1, TS3 and TS4 connect to NVE2. PE1 and ASBR-w forms MPLS IP/VPN network in external DC. CE1 and CE2 connect to PE1. The NVO3 network belongs to AS 1, the MPLS/IP VPN network belongs to AS 2. Hao & et,al Expires September 4, 2015 [Page 5] Internet-Draft Inter-As Option-B March 2015 There are two tenants in NVO3 network, TSs in tenant 1 can freely communicate with CEs in VPN-Red, TSs in tenant 2 can freely communicate with CEs in VPN-Green. TS1 and TS3 belong to tenant 1, TS2 and TS4 belong to tenant 2. CE1 belongs to VPN-Red, CE2 belongs to VPN-Green. VNID 10 and VNID 20 are used to identify tenant 1 and tenant 2 respectively. 4. Option-A inter-as solution overview In Option-A inter-as solution, peering ASBRs are connected by multiple sub-interfaces, each ASBR acts as a PE, and thinks that the other ASBR is a CE. Virtual routing and forwarding (VRF)data bases (RIB/FIB) are configured at AS border routers (ASBR-d and ASBR-w) so that each ASBRs associate each such sub-interface with a VRF and use EBGP to distribute unlabeled IPv4 addresses to each other. In the data-plane, VLANs are used for tenant traffic separation. ASBR-d terminates NVO3 encapsulation for inter-subnet traffic from TS in internal DC to CE in external DC. Option-A inter-as solution has following issues: 1. Up to 16 million (16M) gateway interfaces (virtual/physical) and 16M EBGP session need to exist between the ASBRs. 2. UP to 16M VRFs need to be supported on border routers. 3. Several million routing entries need to be supported on border routers. Inter-as option-B between NVO3 network and MPLS IP/VPN network can be used to address these issues. As option-B proposed in this draft is for multi-as interconnection between heterogeneous networks, so there are some differences from traditional Inter-AS Option-B of RFC4364. 5. Option-B inter-as solution overview Similar to the solution described in section 10, part (b) of [RFC4364] (commonly referred to as Option-B) peering ASBRs are connected as private peers that are enabled to receive Labeled packets from trusted peers. An MP-BGP session is used to distribute the labeled VPN prefixes between the ASBRs. In data plane, the traffic that flows between the ASBRs is placed in MPLS tunnels. Traffic separation among different VPNs between the ASBRs relies on MPLS VPN Label. The advantage of this option is that it's more scalable, as there is no need to have separate interface and BGP session per VPN/Tenant. Hao & et,al Expires September 4, 2015 [Page 6] Internet-Draft Inter-As Option-B March 2015 As for the routing distribution process from DC to WAN side, MPLS VPN Label is allocated on ASBR-d per VN per NVE. As for the routing distribution process from WAN to DC side, VNID is allocated per MPLS VPN Label receiving from ASBR-w on ASBR-d. As for the data plane process, NVO3 tunnel and MPLS VPN tunnel are stitched at ASBR-d. From DC to WAN side, NVO3 tunnel is terminated, VNID and MPLS VPN Label switching is performed by looking up outgoing forwarding table in section 6.1.2. From WAN to DC side, MPLS VPN tunnel is terminated, MPLS VPN Label and NVO3 tunnel switching is performed by looking up incoming forwarding table in section 6.1.1. ASBR-w has no difference with traditional RFC4364 based Option-B behavior, no VRF is created on the ASBR-d. 6. Vanilla Inter-As Option-B procedures Each NVE can operate as a gateway for local connecting TS(s). There must be a separate VNID to identify each tenant. VRFs can be created on each NVE to isolate IP forwarding process between different tenants. The BGP routes are originated on NVE with either implied nexthop address of the BGP router or self-nexthop set. Routing information for each tenant should be synchronized between NVO3 and MPLS VPN network. In internal DC NVO3 network, routing information synchronization between NVE and ASBR-d can be through either: a) RFC 4364 running between the NVEs and the ASBR-d or b) NVE-NVA architecture. The Data plane process is same in these two cases. 6.1. Using RFC 4364 Route distinguishers (RD) and RT are specified for each VRF on each NVE. BGP MPLS/IP VPN protocol extension is running between NVEs and ASBR-d utilizing the [BGP Remote-Next-Hop] attribute which describes the BGP MPLS/IP VPN protocol extension details to specify a set of remote tunnels (1 to N) that occur between two BGP speakers. [Note: the [BGP Remote-Next-Hop] is a work-in-progress that is an individual draft. The IDR WG may modify this draft or adopt another that provides a similar mechanism to support remote next-hops. This draft will follow the IDR adoption of a remote next-hop solution.] 6.1.1. DC to WAN direction 1. NVE1 and NVE2 advertise local TS's IP Address to ASBR-d. NVE1 and NVE2 learn the local TS's IP Address via ARP or other mode. Hao & et,al Expires September 4, 2015 [Page 7] Internet-Draft Inter-As Option-B March 2015 2. When ASBR-d receives routing information from each NVE, it allocates MPLS VPN Label per tenant (VNID) per NVE and the RD and RT remain the same (see table 2 below for examples) . Then the ASBR-d advertises the VPN route with new allocated MPLS VPN Label to ASBR-w. The allocated MPLS VPN label and its corresponding pair forms incoming forwarding table which is used to forward MPLS traffic from WAN to DC side. As an example the incoming forwarding table on ASBR-d could be as follows: +--------------------+------------------+ | MPLS VPN Label | NVE + VNID | +--------------------+------------------+ | 1000 | NVE1 + 10 | +--------------------+------------------+ | 2000 | NVE1 + 20 | +--------------------+------------------+ | 1001 | NVE2 + 10 | +--------------------+------------------+ | 2001 | NVE2 + 20 | +--------------------+------------------+ Table 1 Incoming forwarding table +---------+-------+-------+---------+---------+---------+---------+---------+ | Node | RD | RT | ASBR-d | ASBR-w | PE | CE1 | CE2 | |NVE1 TS1 | RD-A | RT-A |RD-A,RT-A|RD-A,RT-A|RD-A,RT-A|RD-A,RT-A| blocked | |NVE2 TS2 | RD-B | RT-B |RD-B,RT-B|RD-B,RT-B|RD-B,RT-B| blocked |RD-B,RT-B| |NVE2 TS3 | RD-C | RT-A |RD-C,RT-A|RD-C,RT-A|RD-C,RT-A|RD-C,RT-A| blocked | |NVE2 TS4 | RD-D | RT-B |RD-D,RT-B|RD-D,RT-B|RD-D,RT-B| blocked |RD-D,RT-B| +---------+-------+-------+---------+---------+---------+---------+---------+ Table 2 RD, RT from NVE 6.1.2. WAN to DC direction 1. When ASBR-d receives routing information from ASBR-w, ASBR-d allocates VNID for each VPN Label, and then ASBR-w advertises the VPN route with new allocated VNID to each NVE (NVE1 and NVE2). The role of the VNID is similar to the role of Incoming VPN Label in traditional MPLS VPN Option-B based ASBR defined in [RFC 4364], it has local significance on ASBR-d, each VNID corresponds to a MPLS VPN Label received from peer ASBR-w. The allocated VNID and its corresponding out VPN Label forms an outgoing forwarding table which is used to forward NVO3 traffic from DC to WAN side. Assuming ASBR-d receives VPN Label 3000 and 4000 from ASBR-w allocated for VPN-Red and VPN-Green at PE1 respectively, the outgoing forwarding table on ASBR-d is as follows: Hao & et,al Expires September 4, 2015 [Page 8] Internet-Draft Inter-As Option-B March 2015 +------------------+--------------------+ | VNID | Out VPN Label | +------------------+--------------------+ | 10000 | 3000 | +------------------+--------------------+ | 10001 | 4000 | +------------------+--------------------+ Table 3 Outgoing forwarding table +---------+-------+-------+---------+---------+---------+-------+--------+ | Node | RD | RT | PE | ASBR-w | ASBR-d | NVE1 | NVE2 | |CE1 | RD-A | RT-A |RD-A,RT-A|RD-A,RT-A|RD-A,RT-A| filter| Filter | |CE2 | RD-B | RT-B |RD-B,RT-B|RD-B,RT-B|RD-B,RT-B| filter| filter | +---------+-------+-------+---------+---------+---------+-------+--------+ Table 4 RD, RT from CE 2. When each local NVE receives routing information from ASBR-d, it matches the Route Target Attribute in BGP MPLS/IP VPN protocol with local VRF's import RT configuration and populates local VRF with these matched VPN routes (see table 4 above). 6.1.3. NVE Operations Each NVE is a BGP speaker. Operator may configure single and unique VNID for each tenant network on all NVEs or configure NVEs to locally allocate VNID for each VRF on the NVEs, the VNID is called VNID-t. Operators configure RD/RT for each tenant network. When an NVE advertises a prefix with RD/RT, tunnel encapsulation [RFC5512] and VNID-t are carried in BGP update message. The NVE BGP receiver imports the prefix according RD/RT and maintains the mapping of prefix and VNID plus outer IP address in VRF. If single and unique VNID, (denoted as a VNID-t)is used for per tenant network, the VRF can have the mappings of the prefix and the outer IP address only for those prefix mapped to the VNID-t. When receiving a packet from a tenant system locally, NVE performs a lookup in the corresponding tenant table for the destination address on the packet. If the prefix results to single IP address, NVE will encapsulate the packet with VNID-t and IP address as outer IP address. If the prefix results to a VNID and IP address, NVE will encapsulate the packet with the VNID and IP address as outer IP address. When receiving a packet from NVO3, NVE decapsulates the packet to find the attached tenant system based on the VNID and destination address on the packet, forward the decapsulated packet to the tenant system. Hao & et,al Expires September 4, 2015 [Page 9] Internet-Draft Inter-As Option-B March 2015 6.2. NVE-NVA architecture All NVEs in NVO3 network don't need support distributed BGP VPN protocol (RFC4364), these NVEs are controlled by centralized NVA. The NVA runs IBGP VPN protocol for all the NVEs with ASBR-d utilizing the [BGP Remote-Next-Hop] attribute to pass along the tunnel endpoints and encapsulations associated with NVE1. The ASBR-d runs EBGP VPN protocol with peer ASBR-w. ASBR-d allocates MPLS VPN Label per tenant per NVE. NVA maintains all tenant information, and originates BGP routes with the appropriate RD and AD. The NVA tenant information includes VNID to identify each tenant and the corresponding RD and RT. This information can be statically configured by operators or dynamically notified by cloud management systems. This information also includes all TS's MAC/IP address and its attached NVE information. ------ IBGP ------- EBGP -------- |NVA | ------- |ASBR-d| ----------|ASBR-w | ------ ------- -------- . . Southbound interface (Openflow,OVSDB, I2RS) ............ . . . . . . ------ ------ |NVE1| |NVE2| ------ ------ Figure 2 NVE-NVA Architecture 6.2.1. DC to WAN direction 1. NVA advertises all internal data center VPN routing information to ASBR-d, which includes RD, RT, VNID, IP prefix and the attached NVE IP address. The VNID and NVE IP address are used for traffic NVO3 encapsulation from ASBR-d to NVE. Note that this VNID (aka VNID-t) is tenant identifier on NVEs. 2. ASBR-d allocates MPLS VPN Label per VNID per NVE and generates incoming forwarding table same as Table 1. Hao & et,al Expires September 4, 2015 [Page 10] Internet-Draft Inter-As Option-B March 2015 6.2.2. WAN to DC direction 1. ASBR-d receives VPN routing information from peer ASBR-w. ASBR-d allocates VNID (for example VNID-l), for each MPLS VPN Label receiving from ASBR-w and generates outgoing forwarding table same as Table 2. Then it advertises the VPN route to NVA, which includes RD, RT, VNID-l, IP prefix, and set itself as next hop. The VNID and ASBR-d IP address are used for traffic NVO3 encapsulation from NVE to ASBR-d. 2. NVA matches local Route Target configuration, imports VPN route to each tenant, and downloads routing table to corresponding NVE. 6.2.3. NVE Operations Each NVE maintains a lookup table per tenant, i.e. VNID-t and received the mappings from NVA for each tenant presenting on the NVE. For the prefix that is from inside DC, the inner/outer mapping entry is the prefix <-> remote NVE IP address. For the prefix that is from outside DC, the inner/outer mapping entry is the prefix <-> VNID-d + ASBR1-d IP address. When receiving a packet from a tenant system locally, NVE performs a lookup in the corresponding tenant table for the destination address on the packet. If the prefix results to single IP address, NVE will encapsulate the packet with VNID-t and IP address as outer IP address. If the prefix results to a VNID and IP address, NVE will encapsulate the packet with the VNID and IP address as outer IP address. When receiving a packet from NVO3, NVE decapsulates the packet and find the attached tenant system based on the VNID and destination address on the packet, forward the decapsulated packet to the tenant system. 6.3. Data plane procedures This section describes the step by step procedures of data forward between TS1 and CE1 for either: a) DC to WAN direction IP data flows, or b) WAN to DC direction IP data flows. 6.3.1. DC to WAN direction 1. TS1 sends traffic to NVE1, the destination IP is CE1's IP address. Hao & et,al Expires September 4, 2015 [Page 11] Internet-Draft Inter-As Option-B March 2015 2. NVE1 looks up tenant 1's IP forwarding table, then it gets NVO3 tunnel encapsulation information. The destination outer address is ASBR-d's IP address, VNID is 10000 allocated by ASBR-d for VPN route of CE1 received from ASBR-w. NVE1 performs NVO3 encapsulation and sends the traffic to ASBR-d. 3. ASBR-d decapsulates NVO3 encapsulation and gets VNID 10000. Then it looks up outgoing forwarding table based on the VNID and gets MPLS VPN label 3000. Finally it pushes MPLS VPN label for the IP traffic and sends it to ASBR-w. 4. Then the traffic is forwarded to CE1 through regular MPLS VPN forwarding process. 6.3.2. WAN to DC direction 1. CE1 sends traffic to PE1, destination IP is TS1's IP address. The traffic is forwarded to ASBR-d through regular MPLS VPN forwarding process. The incoming MPLS VPN label at ASBR-d is 1000 allocated by ASBR-d for tenant 1 at NVE1. 2. ASBR-d looks up incoming forwarding table and gets NVO3 encapsulation, then performs NVO3 encapsulation and sends the traffic to NVE1. The destination outer IP is NVE1's IP, VNID is 10 corresponding to tenant 1. 3. NVE1 decapsulates NVO3 encapsulation, gets local IP forwarding table relying on VNID 10, and then sends the traffic to TS1. 7. Partial Option-B solution At WAN network side, if there is a VPN with multiple IP prefixes, VPN route synchronization to local NVE located in data center network will cause a lot pressure on BGP processing with route table and route calculations. In this case, the procedures above at ASBR-d can be transformed as follows. EBGP VPN connection for this VPN is terminated at ASBR-d, which means the ASBR doesn't allocate new VNID for each MPLS VPN Label and advertise it to peer NVE in local AS, VRF is created on the ASBR-d, the VPN route from WAN side populates to local VRF. For the traffic from DC to WAN side, IP forwarding process is performed, VRF is selected based on VNID, and then the traffic will be MPLS encapsulated and send to peer ASBR-w. Hao & et,al Expires September 4, 2015 [Page 12] Internet-Draft Inter-As Option-B March 2015 8. Inter-as option comparisons The document describes several inter-as implementation options between ASBR-d and ASBR-w. The following table illustrates the comparison among the implementation options. +----------------+-----------+------------------+----------------+ | | Option-A |Partial Option-B |Vanilla Option-B| +----------------+-----------+------------------+----------------+ | Sub-interface | Yes | No | No | +----------------+-----------+------------------+----------------+ | VRF | Yes | Yes | No | +----------------+-----------+------------------+----------------+ | Scalability | Worst | Middle | Best | +----------------+-----------+------------------+----------------+ | Hardware | | | | | Implementation | | | | | at ASBR-d |No Upgrade | No Upgrade | Need Upgrade | +----------------+-----------+------------------+----------------+ Table 5 Inter-as option comparisons Option-A design uses a regular VPN handoff between ASBR-d and ASBR-w. A sub-interface is required per a NVO instance in between. Both border routers perform the VRF lookup. Thus, the solution has a scalability concern. Existing hardware supports this solution. Partial Option-B does not require sub-interfaces between ASBR-d and ASBR-w, only ASBR-d performs the VRF lookup, so it has better scalability than option A. Existing hardware can support this solution. In the vanilla Option-B solution, there is no sub-interface between border routers and no VRF table on ASBR-d and ASBR-w. Tunnel stitching is performed on the ASBR-d. Thus this solution has the best scalability. From hardware perspective, the vanilla option-B needs ASBR-d hardware upgrade to support the tunnel stitching. 9. Security Considerations Similar to the security considerations for inter-as Option-B in [RFC4364] the appropriate trust relationship must exist between NVO3 network and MPLS/IP VPN network. VPN-IPv4 routes in NVO3 network should neither be distributed to nor accepted from the public Internet, or from any BGP peers that are not trusted. For other general VPN Security Considerations, see [RFC4364]. Hao & et,al Expires September 4, 2015 [Page 13] Internet-Draft Inter-As Option-B March 2015 10. IANA Considerations This document requires no IANA actions. RFC Editor: Please remove this section before publication. 11. References 11.1. Normative References [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] [RFC4364] E. Rosen, Y. Rekhter, " BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [3] [RFC5512] P. Mohapatra, E. Rosen, " The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC5512, April 2009 11.2. Informative References [1] [NVA] D.Black, etc, "An Architecture for Overlay Networks (NVO3)", draft-ietf-nvo3-arch-01, February 14, 2014 [2] [BGP Remote-Next-Hop] G. Van de Velde,etc, ''BGP Remote-Next-Hop'', draft-vandevelde-idr-remote-next-hop-05, January, 2014 [3] [RFC7047] B. Pfaff, B. Davie,''The Open vSwitch Database Management Protocol'', RFC 7047, December 2013 [4] [OpenFlow1.3]OpenFlow Switch Specification Version 1.3.0 (Wire Protocol 0x04). June 25, 2012. (https://www.opennetworking.org/images/stories/downloads/sdn- resources/onf-specifications/openflow/openflow-spec-v1.3.0.pdf) 12. Acknowledgments Authors like to thank Xiaohu Xu, Liang Xia, Shunwan Zhang, Yizhou Li, Lili Wang for his valuable inputs. Hao & et,al Expires September 4, 2015 [Page 14] Internet-Draft Inter-As Option-B March 2015 Authors' Addresses Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56623144 Email: haoweiguo@huawei.com Lucy Yong Huawei Technologies Phone: +1-918-808-1918 Email: lucy.yong@huawei.com Susan Hares Huawei Technologies Phone: +1-734-604-0323 Email: shares@ndzh.com. Robert Raszuk Mirantis Inc. 615 National Ave. #100 Mt View, CA 94043 USA Email: robert@raszuk.net Luyuan Fang Microsoft Email: lufang@microsoft.com Osama Zia Microsoft osamaz@microsoft.com Shahram Davari Broadcom Davari@Broadcom.com Andrew Qu MediaTec andrew.qu@mediatek.com Hao & et,al Expires September 4, 2015 [Page 15]