Inter-AS Option B between NVO3 and BGP/MPLS IP VPN network
draft-hao-l3vpn-inter-nvo3-vpn-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Hao Weiguo , Lucy Yong , Susan Hares | ||
| Last updated | 2014-06-30 | ||
| Replaced by | draft-hao-bess-inter-nvo3-vpn | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hao-l3vpn-inter-nvo3-vpn-00
L3VPN Weiguo Hao
Lucy Yong
Internet Draft Huawei
S. Hares
Hickory Hill Consulting
Intended status: Informational July 1, 2014
Expires: January 2015
Inter-AS Option B between NVO3 and BGP/MPLS IP VPN network
draft-hao-l3vpn-inter-nvo3-vpn-00.txt
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 January 1, 2015.
Copyright Notice
Copyright (c) 2013 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
Hao & et,al Expires January 1, 2015 [Page 1]
Internet-Draft Inter-As Option-B June 2014
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
This draft describes option-B inter-as connection between NVO3
network and MPLS/IP VPN network. Comparing to traditional Option-B
inter-as connection defined in [RFC 4364], this draft provides
enhancement for heterogeneous network multi-as connection, the
control plane and data plane procedures in NVO3 network are newly
designed.
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document............................ 3
3. Reference model ............................................. 4
4. Option-A inter-as solution overview.......................... 5
5. Option-B inter-as solution overview.......................... 6
6. Inter-As Option-B procedures................................. 6
6.1. Routing distribution procedures......................... 7
6.1.1. Using RFC 4364..................................... 7
6.1.1.1. Internal DC to external DC direction...........8
6.1.1.2. External DC to internal DC direction..........10
6.1.2. NVE-NVA architecture.............................. 12
6.1.2.1. Internal DC to external DC direction..........12
6.1.2.2. External DC to internal DC direction..........13
6.2. Data plane procedures.................................. 13
6.2.1. Internal DC to external DC direction.............. 13
6.2.2. External DC to internal DC direction.............. 14
7. Security Considerations..................................... 14
8. IANA Considerations ........................................ 14
9. References ................................................. 14
9.1. Normative References................................... 14
9.2. Informative References................................. 14
10. Acknowledgments ........................................... 15
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)
Hao & et,al Expires January 1, 2015 [Page 2]
Internet-Draft Inter-As Option-B June 2014
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 VN ID 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,
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-
Hao & et,al Expires January 1, 2015 [Page 3]
Internet-Draft Inter-As Option-B June 2014
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.
3. Reference model
|---------------------------------------------------|
| ------ AS1 |
| | TS1| - |
| ------ - |
| - ------ ------ |
| - |NVE1| -- |TOR1|---------------- |
| ------ - ------ ------ | |
| | TS2|- | |
| ------ | |
| -------- |
| |------------ | ASBR1| |
| ------ | -------- |
| | TS3| - | | |
| ------ - | | |
| - ------ ------ | |
| - |NVE2| -- |TOR2| | |
| ------ - ------ ------ | |
| | TS4|- | |
| ------ | |
|----------------------------------------------------
| | |
| ------ | |
| | CE1| - | |
| ------ - | |
| - ------ -------- |
| - | PE1| --------------------| ASBR2| |
| ------ - ------ -------- |
| | CE2|- |
| ------ AS2 |
|---------------------------------------------------|
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
ASBR1 forms NVO3 overlay network in internal DC. TS1 and TS2 connect
to NVE1, TS3 and TS4 connect to NVE2. PE1 and ASBR2 forms MPLS
Hao & et,al Expires January 1, 2015 [Page 4]
Internet-Draft Inter-As Option-B June 2014
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.
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.
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 (ASBR1 and ASBR2) 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. In normal
case ASBR1 also acts as NVO3 layer 3 gateway, it can terminate NVO3
encapsulation for inter-subnet traffic between TS in internal DC and
CE in external DC.
For the traffic from internal DC to external DC, the forwarding
process of ASBR1 at internal DC is as follows:
1. Terminates NVO3 encapsulation and gets VN ID.
2. Finds corresponding VRF relying on the VN ID.
3. Looks up IP forwarding table in the VRF, and then forwards the
traffic to a sub-interface connecting to peer ASBR.
The forwarding process of ASBR2 at MPLS/VPN network is as follows:
1. Finds corresponding VRF based on sub-interface.
2. Looks up IP forwarding table in the VRF, encapsulates the traffic
with MPLS VPN label, and then sends the traffic to MPLS VPN
network.
For the traffic from external DC to internal DC, the traffic
forwarding process is similar to the above process.
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.
Hao & et,al Expires January 1, 2015 [Page 5]
Internet-Draft Inter-As Option-B June 2014
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. Due to it 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 by one or more sub-interfaces that are enabled to receive
MPLS traffic. 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 upon MPLS tunnels, traffic
separation among different VPNs between the ASBRs relies on MPLS VPN
Label.
In this solution, the procedures in MPLS/IP VPN network are same as
defined in [RFC4364], but the procedures in NVO3 network need to be
newly designed to support inter-as Option-B.
The advantage of this option is that it's more scalable, as there is
no need to have one sub-interface and BGP session per VPN/Tenant.
6. Inter-As Option-B procedures
The TS and CE information in above figure 1 are as follows:
Hao & et,al Expires January 1, 2015 [Page 6]
Internet-Draft Inter-As Option-B June 2014
+-------+----------+-------------+---------+
| TS | Tenant | IP Address | VN ID |
+-------+----------+-------------+---------+
| TS1 | 1 | 10.1.1.2 | 10 |
+-------+----------+-------------+---------+
| TS2 | 2 | 20.1.1.2 | 20 |
+-------+----------+-------------+---------+
| TS3 | 1 | 10.1.1.3 | 10 |
+-------+----------+-------------+---------+
| TS4 | 2 | 20.1.1.3 | 20 |
+-------+----------+-------------+---------+
Table 1 TS information in NVO3 network
+-------+--------------------+-------------+-------------+---------+
| CE | Route Distinguisher| Route Target| IP Address | Mask |
+-------+--------------------+-------------+-------------+---------+
| CE1 | VPN-Red1 | 1:1 | 30.1.1.1 | 24 |
+-------+--------------------+-------------+-------------+---------+
| CE2 | VPN-Green1 | 2:2 | 40.1.1.1 | 24 |
+-------+--------------------+-------------+-------------+---------+
Table 2 CE information in MPLS/IP VPN network
Section 6.1 below describes the route distribution process for this
option, and section 6.2 describes the data forwarding process.
NVO3 network can pass routing data for the NVEs (IP Address, VN ID)
through either: a) RFC 4364 running between the NVEs and the ASBR1,
or b) NVE-NVA architecture. Therefore, the routing distribution
process is different for these two options. Section 6.1.1 describes
the routing distribution procedures using RFC 4364 on NVO3 network,
and section 6.1.2 describes the procedures using NVE-NVA
architecture.
The Data plane process is same in these two cases.
6.1. Routing distribution procedures
6.1.1. Using RFC 4364
The route distribution in NVO3 network makes use of the BGP multiple
tunnel identifiers [BGP Remote-Next-Hop] to create an RFC4364
Option-B solution. This section provides a step by step explanation
of the process.
In internal DC network, VRF1 and VRF2 are created on NVE1 and NVE2
to isolate IP forwarding process between tenant 1 and tenant 2.
Route distinguishers (RD) and RT are specified for each VRF on these
Hao & et,al Expires January 1, 2015 [Page 7]
Internet-Draft Inter-As Option-B June 2014
NVEs. BGP MPLS/IP VPN protocol extension is running between NVEs and
ASBR1 utilizing the [BGP Remote-Next-Hop] which describes the BGP
MPLS/IP VPN protocol extension detail to specify a set of remote
tunnels (1 to N) that occur between two BGP speakers. The VRF
configuration information on each NVE are as follows:
+----------+----------+--------------------+-------------+
| NVE | Tenant | Route Distinguisher| Route Target|
+----------+----------+--------------------+-------------+
| NVE1 | 1 | VPN-Red2 | 1:1 |
+----------+----------+--------------------+-------------+
| NVE1 | 2 | VPN-Green2 | 2:2 |
+----------+----------+--------------------+-------------+
| NVE2 | 1 | VPN-Red3 | 1:1 |
+----------+----------+--------------------+-------------+
| NVE2 | 2 | VPN-Green3 | 2:2 |
+----------+----------+--------------------+-------------+
6.1.1.1. Internal DC to external DC direction
1. NVE1 and NVE2 operate as a layer 3 gateway for local connecting
TS. NVE1 and NVE2 learn the local TS's IP Address via ARP, and
advertise this information to the ASBR1. The routing information
from NVE1 and NVE2 are as follows:
+---------+------------------------+-------------+---------+
| NVE | RD:IP Prefix | Route Target| VN ID |
+---------+------------------------+-------------+---------+
| NVE1 |VPN-Red2:10.1.1.2/32 | 1:1 | 10 |
+---------+------------------------+-------------+---------+
| NVE1 |VPN-Green2:20.1.1.2/32 | 2:2 | 20 |
+---------+------------------------+-------------+---------+
| NVE2 |VPN-Red3:10.1.1.3/32 | 1:1 | 10 |
+---------+------------------------+-------------+---------+
| NVE2 |VPN-Green3:20.1.1.3/32 | 2:2 | 20 |
+---------+------------------------+-------------+---------+
Routing information sent form NVE1 and NVE2
2. ASBR1 allocates MPLS VPN Label per tenant (VN ID) per NVE and the
RD and RT remain the same. Then the ASBR1 advertises the VPN
route with new allocated MPLS VPN Label to ASBR2. The allocated
MPLS VPN label and its corresponding NVE+VN ID forms incoming
forwarding table which is used to forward MPLS traffic from
external DC to internal DC. The incoming forwarding table on
ASBR1 is as follows:
Hao & et,al Expires January 1, 2015 [Page 8]
Internet-Draft Inter-As Option-B June 2014
+--------------------+------------------+
| MPLS VPN Label | NVE + VN ID |
+--------------------+------------------+
| 1000 | NVE1 + 10 |
+--------------------+------------------+
| 2000 | NVE1 + 20 |
+--------------------+------------------+
| 1001 | NVE2 + 10 |
+--------------------+------------------+
| 2001 | NVE2 + 20 |
+--------------------+------------------+
Incoming forwarding table
3. ASBR2 allocates new local VPN label for each receiving VPN label
from ASBR1 firstly, then ASBR2 advertises the VPN route with new
allocated MPLS VPN Label to PE1. As for data plane forwarding
process, the new local VPN label are in VPN label, the receiving
VPN label from ASBR1 are out VPN label. The VPN label switch
table on ASBR2 is as follows:
+------------------+--------------------+
| In VPN Labels | Out VPN Labels |
+------------------+--------------------+
| 1000 | 1000 |
+------------------+--------------------+
| 2000 | 2000 |
+------------------+--------------------+
| 1001 | 1001 |
+------------------+--------------------+
| 2001 | 2001 |
+------------------+--------------------+
VPN label switch table
4. PE1 matches the Route Target Attribute in BGP MPLS/IP VPN
protocol with local VRF's import RT configuration. Then it
populates local VRF with these matched VPN routes. The routing
tables of VPN-Red and VPN-Green are as follows:
Hao & et,al Expires January 1, 2015 [Page 9]
Internet-Draft Inter-As Option-B June 2014
+------------------+--------------------+--------------------+
| IP Prefix | VPN Label | BGP Peer |
+------------------+--------------------+--------------------+
| 10.1.1.2/32 | 1000 | ASBR2 |
+------------------+--------------------+--------------------+
| 10.1.1.3/32 | 1001 | ASBR2 |
+------------------+--------------------+--------------------+
Routing table in VPN-Red
+------------------+--------------------+--------------------+
| IP Prefix | VPN Label | BGP Peer |
+------------------+--------------------+--------------------+
| 20.1.1.2/32 | 2000 | ASBR2 |
+------------------+--------------------+--------------------+
| 20.1.1.3/32 | 2001 | ASBR2 |
+------------------+--------------------+--------------------+
Routing table in VPN-Green
6.1.1.2. External DC to internal DC direction
1. PE1 learns IP prefix from CE1 and CE2 and populates these IP
prefix to local VRF. Then the PE allocates VPN Label for these IP
prefix and announces VPN routing information with allocated VPN
Label to ASBR1. The VPN routing information are as follows:
+--------------------+------------------------------------+--------------------+
| Route Target | IP Prefix | VPN Label |
+--------------------+------------------------------------+--------------------+
| 1:1 |VPN-Red1:30.1.1.1/24 | 3000 |
+--------------------+------------------------------------+--------------------+
| 2:2 |VPN-Green1:40.1.1.1/24 | 4000 |
+--------------------+------------------------------------+--------------------+
2. ASBR2 allocates new local VPN label for each receiving VPN label
from PE1, then ASBR2 advertises the VPN route with new allocated
MPLS VPN Label to ASBR1. As for data plane forwarding process,
the new local VPN label are in VPN label, the receiving VPN label
from ASBR1 are out VPN label. The VPN label switch table on ASBR2
is as follows:
Hao & et,al Expires January 1, 2015 [Page 10]
Internet-Draft Inter-As Option-B June 2014
+------------------+--------------------+
| In VPN Label | Out VPN Label |
+------------------+--------------------+
| 3000 | 3000 |
+------------------+--------------------+
| 4000 | 4000 |
+------------------+--------------------+
3. ASBR1 allocates VN ID for each VPN Label receiving from ASBR2,
and then ASBR2 advertises the VPN route with new allocated VN ID
to each NVE (NVE1 and NVE2). The role of the VN ID is similar to
the role of In VPN Label in ASBR1, it has local significance on
ASBR1, each VN ID corresponds to per MPLS VPN Label on peer ASBR2;
The VN ID space should be assigned in beforehand and should be
orthogonal to the VN ID space for tenant identification(for
example, assuming ASBR1 has local connecting TSs of tenant 1 to
tenant 100, VN ID 1 to 100 are allocated for these tenants, other
VN ID other than 1 to 100 can be allocated for outgoing
forwarding table purpose). The allocated VN ID and its
corresponding out VPN Label forms an outgoing forwarding table
which is used to forward NVO3 traffic from internal DC to
external DC. The outgoing forwarding table on ASBR1 is as follows:
+------------------+--------------------+
| VN ID | Out VPN Label |
+------------------+--------------------+
| 10000 | 3000 |
+------------------+--------------------+
| 10001 | 4000 |
+------------------+--------------------+
Outgoing forwarding table
4. NVE1 matches the Route Target Attribute in BGP MPLS/IP VPN
protocol with local VRF's import RT configuration. Then it
populates local VRF with these matched VPN routes. The routing
tables of tenant 1 and tenant 2 are as follows:
Hao & et,al Expires January 1, 2015 [Page 11]
Internet-Draft Inter-As Option-B June 2014
+------------------+--------------------+--------------------+
| IP Prefix | VN ID | Dest Outer IP |
+------------------+--------------------+--------------------+
| 30.1.1.1/24 | 10000 | ASBR1 |
+------------------+--------------------+--------------------+
Tenant 1 routing table on NVE1 and NVE2
+------------------+--------------------+--------------------+
| IP Prefix | VN ID | Dest Outer IP |
+------------------+--------------------+--------------------+
| 40.1.1.1/24 | 10001 | ASBR1 |
+------------------+--------------------+--------------------+
Tenant 2 routing table on NVE1 and NVE2
6.1.2. NVE-NVA architecture
No distributed BGP VPN protocol (RFC4364) is running on all NVEs and
ASBR1 in NVO3 network, NVEs and ASBR1 are controlled by centralized
NVA. The NVA runs EBGP VPN protocol with peer ASBR2 and exchanges
VPN routing information between NVO3 network and MPLS/IP VPN network.
NVA maintains tenant information collected from all tenants. This
information includes VN ID 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.
NVA also maintains all TS's MAC/IP address and its attached NVE
information for each tenant.
------ EBGP --------
|NVA | ------------- |ASBR2 |
------ --------
.
. Southbound interface(Openflow,OVSDB,etc)
........................
. . .
. . .
. . .
------ ------ -------
|NVE1| |NVE2| |ASBR1|
------ ------ -------
Figure 2 NVE-NVA Archetecture
6.1.2.1. Internal DC to external DC direction
1. NVA allocates MPLS VPN Label per tenant per NVE.
Hao & et,al Expires January 1, 2015 [Page 12]
Internet-Draft Inter-As Option-B June 2014
2. NVA advertises all internal data center VPN routing information
to peer ASBR2, which includes RD, IP prefix, RT, and MPLS VPN
Label.
3. NVA downloads incoming forwarding table to ASBR1.
6.1.2.2. External DC to internal DC direction
1. NVA receives VPN routing information from peer ASBR2.
2. NVA allocates VN ID for each MPLS VPN Label receiving from ASBR2.
3. NVA downloads outgoing forwarding table to ASBR1.
4. NVA matches local Route Target configuration, imports VPN route
to each tenant, and downloads routing table to corresponding NVE.
6.2. Data plane procedures
This section describes the step by step procedures of data forward
for either: a) internal DC to external DC IP data flows, or b) the
external DC to internal DC IP data flows.
6.2.1. Internal DC to external DC direction
1. TS1 sends traffic to NVE1, the destination IP is CE1's IP address
of 30.1.1.1.
2. NVE1 looks up VRF1's IP forwarding table, then it gets NVO3
tunnel encapsulation information. The destination outer address
is ASBR1's IP address, VN ID is 10000. NVE1 performs NVO3
encapsulation and sends the traffic to ASBR1.
3. ASBR1 decapsulates NVO3 encapsulation and gets VN ID 10000. Then
it looks up outgoing forwarding table based on the VN ID and gets
MPLS VPN label 3000. Finally it pushes MPLS VPN label for the IP
traffic and sends it to ASBR2.
4. ASBR2 swaps VPN Label, then sends the traffic to PE1 through IGP
tunnel.
5. PE1 terminates IGP tunnel, pops MPLS VPN label 3000, looks up
local IP forwarding table in VRF1, and then forwards the traffic
to CE1.
Hao & et,al Expires January 1, 2015 [Page 13]
Internet-Draft Inter-As Option-B June 2014
6.2.2. External DC to internal DC direction
1. CE1 sends traffic to PE1, destination IP is TS1's IP address of
10.1.1.2.
2. PE1 looks up local IP forwarding table in VPN-RED, pushes MPLS
VPN label 1000, then searches IGP tunnel, then the PE sends the
traffic to ASBR2 through IGP tunnel.
3. ASBR2 terminates IGP tunnel, swaps MPLS VPN label, then sends the
traffic to ASBR1.
4. ASBR1 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, VN ID is
10.
5. NVE1 decapsulates NVO3 encapsulation, gets local VRF1 relying on
VN ID 10, looks up local IP forwarding table in VRF1, then sends
the traffic to TS1.
7. 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].
8. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove
this section before publication.
9. References
9.1. Normative References
[1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[1] [RFC4364] E. Rosen, Y. Rekhter, " BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
Hao & et,al Expires January 1, 2015 [Page 14]
Internet-Draft Inter-As Option-B June 2014
[2] [NVA] D.Black, etc, "An Architecture for Overlay Networks (NVO3)",
draft-ietf-nvo3-arch-01, February 14, 2014
[3] [BGP Remote-Next-Hop] G. Van de Velde,etc, "BGP Remote-Next-Hop",
draft-vandevelde-idr-remote-next-hop-05, January, 2014
[4] [RFC7047] B. Pfaff, B. Davie,"The Open vSwitch Database
Management Protocol", RFC 7047, December 2013
[5] [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)
10. Acknowledgments
Authors like to thank Xiaohu Xu, Liang Xia, Shunwan Zhang for his
valuable inputs.
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.
Hao & et,al Expires January 1, 2015 [Page 15]