Internet DRAFT - draft-jin-l3vpn-vpn4dc-interconnect
draft-jin-l3vpn-vpn4dc-interconnect
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
(<Local System identifier, Local Port ID>, <Peer System identifier,
Peer Port ID>). 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 (<Local System identifier,
Local Port ID, VLAN value>, <Peer System identifier, Peer Port ID,
VLAN value>), 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 <Local System identifier, Local Port ID, VLAN value>. 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 <Local System identifier,
Local Port ID, VLAN value>, 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 <Peer System identifier, Peer Port ID, VLAN
value>. If found, then corresponding <Local System identifier, Local
Jin, et al. Expires April 27, 2012 [Page 5]
Internet-Draft draft-jin-l3vpn-vpn4dc-interconnect-00 Oct 2011
Port ID, VLAN value> 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 <Local
System identifier, Local Port ID>, and assigning the same VLAN number
as carried in the attribute, then VRF link connection pair is
generated. Then new <Local System identifier, Local Port ID, VLAN
value> 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]
