Network Working Group L. Jin Internet-Draft ZTE Intended status: Standards Track N. So Expires: April 27, 2012 Verizon B. Khasnabish Wu. Bo ZTE Oct 25, 2011 L3VPN automatical interconnection for VPN4DC draft-jin-l3vpn-vpn4dc-interconnect-00.txt Abstract VPN4DC provides VPN oriented datacenter service to customer through L3VPN which is consisted of (private) L3VPN in datacenter and network provider's L3VPN over wide geographical area. If we considering the two L3VPN in two different AS, [RFC4364] providers three options to achieve L3VPN inter-AS connection. Both option A and B could be used to connect L3VPN in VPN4DC. This draft discusses a novel method for implementing option A, to automatically configure the VRF interface in order to interconnect the two segments of the end-to-end L3VPN. This L3VPN interconnection automation mechanism is expected to significantly reduce the VPN oriented inter-connection/service provisioning time. 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 April 27, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Jin, et al. Expires April 27, 2012 [Page 1] Internet-Draft draft-jin-l3vpn-vpn4dc-interconnect-00 Oct 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Interconnect VRF interface attribute encoding . . . . . . . . . 3 3. Link connection discovery . . . . . . . . . . . . . . . . . . . 5 4. PE procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative references . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Jin, et al. Expires April 27, 2012 [Page 2] Internet-Draft draft-jin-l3vpn-vpn4dc-interconnect-00 Oct 2011 1. Introduction VPN4DC provides VPN oriented datacenter service to customer through L3VPN which is consisted of (private) L3VPN in datacenter and network provider's L3VPN over wide geographical area. If we considering the two L3VPN in two different AS, [RFC4364] providers three options to achieve L3VPN inter-AS connection. Both option A and B could be used to connect L3VPN in VPN4DC. For option A, operator should configure the local VRF interface on both border PEs of two L3VPNs to construct a VRF-to-VRF interconnection network, while deploying option B, the border PE router in datacenter should support MPLS or other kinds of tunnel to connect peer border PE in L3VPN. VRF-to-VRF interconnection on two border PEs is achieved by the sub- interface, and each border PE will consider the other border PE in peer L3VPN as CE. VRF-to-VRF interconnection could provide better connection access control for network provider when providing datacenter!_s L3VPN access. The pain point for VRF-to-VRF interconnection is that operator has to manually configure the sub- interface on both border PEs of the two L3VPN, which greatly increases service provisioning time and wrong configuration probability. This draft discusses a novel method for implementing option A, to automatically configure the VRF interface in order to interconnect the two segments of the end-to-end L3VPN. This L3VPN interconnection automation mechanism is expected to significantly reduce the VPN oriented inter-connection/service provisioning time. 2. Interconnect VRF interface attribute encoding In order to automatically configure the VRF interface to achieve VRF- to-VRF interconnection, the VRF interface should be advertised by MP- BGP IPv4/v6 VPN-route. This document defines a new BGP attribute, called interconnect VRF interface attribute. This is an optional transitive BGP attribute. +----------------------------------------+ | System Identifier (variable) | +----------------------------------------+ | Port ID (variable) | +----------------------------------------+ | VLAN Value (variable) | +----------------------------------------+ System identifier: This system identifier indicates the system ID of Jin, et al. Expires April 27, 2012 [Page 3] Internet-Draft draft-jin-l3vpn-vpn4dc-interconnect-00 Oct 2011 the sender. This should be the IPv4/v6 IP address that assigned to the sender system. 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Add. Length | Add value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address value (cont) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Address Family: Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC3232] that encodes the address family for the system identifier. - Address Length: Length of the system identifier in octets. - Address value: An address encoded according to the Address Family field. Port ID: This port ID indicates the interface ID or name that interconnects peer PE of the other L3VPN. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Port. Length | Port ID Value (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... - Port Length: Length of the Port ID value in octets. - Port ID value: A value encoded to indicate a unique value on PE. VLAN value: This VLAN value indicates the VLAN number that interconnects peer PE of the other L3VPN. If the value of this field is zero, no VLAN is presented. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | VLAN. Length | VLAN Value (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Jin, et al. Expires April 27, 2012 [Page 4] Internet-Draft draft-jin-l3vpn-vpn4dc-interconnect-00 Oct 2011 - VLAN value could contain one or two VLAN tags, and each VLAN tag should contain 32bits as specified in [IEEE802.1Q]. 3. Link connection discovery Prior L3VPN auto-connection, the two border PEs in corresponding L3VPN MUST discover the physical link connection between them. A physical link connection pair should be established after this discovery. The physical link connection pair could be presented as (, ). There are various ways to achieve the link connection discovery, e.g, LLDP (Link Layer Discovery Protocol) [IEEE802.1AB] or manual configuration, and out of the scope of this draft. VRF link connection pair presented as (, ), which indicates the sub-link connecting two border PEs, see more detail in section 4. The VLAN value in the above link connection pair should have same VLAN ID, and would refer to one or two VLAN tags. 4. PE procedures The E-BGP session should be established between the two border PEs. The procedure of PE is the same as defined in [RFC4364] except the following. If the border PE already has VRF link connection pair for the corresponding VRF, interconnect VRF interface attribute is derived from . Then border PE advertises VPN-Route of the VRF with the interconnect VRF interface attribute. If the border PE does not have VRF link connection pair, and if border PE acts as active role, it should assign a VLAN number which has not been used yet, and then generate , and then border PE advertises VPN-Route of the VRF with the interconnect VRF interface attribute. If border PE is a passive role without VRF link connection pair, it should not advertise VPN-Route to peer border PE. When PE receiving VPN-route with interconnect VRF interface attribute, it should use this attribute to search the VRF link connection pairs to match . If found, then corresponding should be the output interface of this VRF to peer border PE. If does not find, it should search the physical link connection pair without VLAN number and find its corresponding , and assigning the same VLAN number as carried in the attribute, then VRF link connection pair is generated. Then new should be the output interface of this VRF to peer border PE. If the PE could not assign the VLAN number as carried in the attribute, a BGP notification message should be generated to peer border PE with UPDATE Message Error sub-code named "invalid VRF interface attribute with VLAN number". Border PE receiving such kind of error code in BGP notification message could assign another VLAN number locally, and send BGP UPDATE message again to peer border PE. 5. Security considerations The VRF-Route with interconnect VRF interface attribute described in this draft would trigger the PE to configure VLAN number automatically, which possibly leads to potential threat by some unauthorized VRF-Route with this new attribute. The physical link connection pair restricts the VLAN number assignment to only those interfaces with peer border PE. BGP MD5 authentication should also be enabled to ensure security. 6. IANA Considerations This document defines a new BGP optional transitive attribute, called interconnect VRF interface attribute. This document defines a new UPDATE Message Error sub-code, called "invalid VRF interface attribute with VLAN number". 7. References 7.1. Normative references [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 7.2. Informative References [IEEE802.1AB] ""IEEE standard 802.1AB: Station and Media Access Control Connectivity Discovery.", IEEE802.1AB , Oct 2009. Jin, et al. Expires April 27, 2012 [Page 6] Internet-Draft draft-jin-l3vpn-vpn4dc-interconnect-00 Oct 2011 [IEEE802.1Q] "IEEE standard 802.1Q: Virtual Bridged Local Area Networks.", IEEE802.1Q , 2005. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. Authors' Addresses Lizhong Jin ZTE Corporation Email: lizhong.jin@zte.com.cn Ning So Verizon Email: ning.so@verizon.com Bhumip Khasnabish ZTE USA Email: bhumip.khasnabish@zteusa.com Bo Wu ZTE Corporation Email: wu.bo@zte.com.cn Jin, et al. Expires April 27, 2012 [Page 7]