draft-ietf-bess-evpn-inter-subnet-forwarding-00.txt   draft-ietf-bess-evpn-inter-subnet-forwarding-01.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Wim Henderickx Wim Henderickx
Jorge Rabadan Yakov Rekhter Jorge Rabadan Yakov Rekhter
Alcatel-Lucent John Drake Alcatel-Lucent John Drake
Juniper Juniper
Florin Balus Florin Balus
Nuage Networks Lucy Yong Nuage Networks Lucy Yong
Linda Dunbar Linda Dunbar
Dennis Cai Huawei Dennis Cai Huawei
Cisco Cisco
Expires: May 11, 2015 November 11, 2014 Expires: April 18, 2016 October 18, 2015
Integrated Routing and Bridging in EVPN Integrated Routing and Bridging in EVPN
draft-ietf-bess-evpn-inter-subnet-forwarding-00 draft-ietf-bess-evpn-inter-subnet-forwarding-01
Abstract Abstract
EVPN provides an extensible and flexible multi-homing VPN solution EVPN provides an extensible and flexible multi-homing VPN solution
for intra-subnet connectivity among hosts/VMs over an MPLS/IP for intra-subnet connectivity among hosts/VMs over an MPLS/IP
network. However, there are scenarios in which inter-subnet network. However, there are scenarios in which inter-subnet
forwarding among hosts/VMs across different IP subnets is required, forwarding among hosts/VMs across different IP subnets is required,
while maintaining the multi-homing capabilities of EVPN. This while maintaining the multi-homing capabilities of EVPN. This
document describes an Integrated Routing and Bridging (IRB) solution document describes an Integrated Routing and Bridging (IRB) solution
based on EVPN to address such requirements. based on EVPN to address such requirements.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
for intra-subnet connectivity among Tenant Systems (TS's) over an for intra-subnet connectivity among Tenant Systems (TS's) over an
MPLS/IP network. However, there are scenarios where, in addition to MPLS/IP network. However, there are scenarios where, in addition to
intra-subnet forwarding, inter-subnet forwarding is required among intra-subnet forwarding, inter-subnet forwarding is required among
TS's across different IP subnets at the EVPN PE nodes, also known as TS's across different IP subnets at the EVPN PE nodes, also known as
EVPN NVE nodes throughout this document, while maintaining the multi- EVPN NVE nodes throughout this document, while maintaining the multi-
homing capabilities of EVPN. This document describes an Integrated homing capabilities of EVPN. This document describes an Integrated
Routing and Bridging (IRB) solution based on EVPN to address such Routing and Bridging (IRB) solution based on EVPN to address such
requirements. requirements.
The inter-subnet communication is traditionally achieved at The inter-subnet communication is traditionally achieved at
centralized L3 Gateway nodes where all the inter-subnet communication centralized L3 Gateway (L3GW) nodes where all the inter-subnet
policies are enforced. When two Tenant Systems (TS's) belonging to communication policies are enforced. When two Tenant Systems (TS's)
two different subnets connected to the same PE node wanted to talk to belonging to two different subnets connected to the same PE node
each other, their traffic needed to be back hauled from the PE node wanted to talk to each other, their traffic needed to be back hauled
all the way to the centralized gateway nodes where inter-subnet from the PE node all the way to the centralized gateway nodes where
switching is performed and then back to the PE node. For today's inter-subnet switching is performed and then back to the PE node. For
large multi-tenant data center, this scheme is very inefficient and today's large multi-tenant data center, this scheme is very
sometimes impractical. inefficient and sometimes impractical.
In order to overcome the drawback of centralized approach, IRB In order to overcome the drawback of centralized approach, IRB
functionality is needed on the PE nodes (i.e., NVE devices) as close functionality is needed on the PE nodes (i.e., NVE devices) as close
to TS as possible to avoid hair pinning of user traffic to TS as possible to avoid hair pinning of user traffic
unnecessarily. Under this design, all traffic between hosts attached unnecessarily. Under this design, all traffic between hosts attached
to one NVE can be routed and bridged locally, thus avoiding traffic to one NVE can be routed and bridged locally, thus avoiding traffic
hair-pinning issue at the centralized L3GW. hair-pinning issue of the centralized L3GW.
There can be scenarios where both centralized and decentralized There can be scenarios where both centralized and decentralized
approaches may be preferred simultaneously. For example, to allow approaches may be preferred simultaneously. For example, to allow
NVEs to switch inter-subnet traffic belonging to one tenant or one NVEs to switch inter-subnet traffic belonging to one tenant or one
security zone locally; whereas, to back haul inter-subnet traffic security zone locally; whereas, to back haul inter-subnet traffic
belonging to two different tenants or security zones to the belonging to two different tenants or security zones to the
centralized gateway nodes and perform switching there after the centralized gateway nodes and perform switching there after the
traffic is subjected to Firewall or Deep Packet Inspection (DPI). traffic is subjected to Firewall or Deep Packet Inspection (DPI).
Some TS's run non-IP protocols in conjunction with their IP traffic. Some TS's run non-IP protocols in conjunction with their IP traffic.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
`-+------+' `. ,' `-+------+' `. ,'
__/__ `-+------+' __/__ `-+------+'
:NVE1 : __/__ __\__ :NVE1 : __/__ __\__
'-----' :NVE2 : :NVE3 : '-----' :NVE2 : :NVE3 :
| | '-----' '-----' | | '-----' '-----'
TS1 TS2 | | | TS1 TS2 | | |
TS3 TS4 TS5 TS3 TS4 TS5
Figure 2: Interoperability Use-Cases Figure 2: Interoperability Use-Cases
In what follows, we will describe scenarios 3 through 6 in more In what follows, we will describe scenarios 1 through 4 in more
detail. detail.
2.1 Switching among Subnets within a DC 2.1 Switching among Subnets within a DC
In this scenario, connectivity is required between TS's in the same In this scenario, connectivity is required between TS's in the same
data center, where those hosts belong to different IP subnets. All data center, where those hosts belong to different IP subnets. All
these subnets belong to the same tenant or are part of the same IP these subnets belong to the same tenant or are part of the same IP
VPN. Each subnet is associated with a single EVPN instance (EVI) VPN. Each subnet is associated with a single EVPN instance (EVI)
realized by a collection of MAC-VRFs (one per NVE) residing on the realized by a collection of MAC-VRFs (one per NVE) residing on the
NVEs configured for that EVI. NVEs configured for that EVI.
As an example, consider TS3 and TS5 of Figure 2 above. Assume that As an example, consider TS3 and TS5 of Figure 2 above. Assume that
connectivity is required between these two TS's where TS3 belongs to connectivity is required between these two TS's where TS3 belongs to
the IP-subnet 3 (SN3) whereas TS5 belongs to the IP-subnet 5 (SN5). the IP-subnet 3 (SN3) whereas TS5 belongs to the IP-subnet 5 (SN5).
Both SN3 and SN5 subnets belong to the same tenant (e.g., are part of Both SN3 and SN5 subnets belong to the same tenant (e.g., are part of
the same IP VPN). NVE2 has an EVI3 associated with the SN3 and this the same IP-VRF). NVE2 has an EVI3 associated with the SN3 and this
EVI is represented by a MAC-VRF which is associated with an IP-VRF EVI is represented by a MAC-VRF which is associated with an IP-VRF
(for that IP VPN) via an IRB interface. NVE3 respectively has an EVI5 (for that IP VPN) via an IRB interface. NVE3 respectively has an EVI5
associated with the SN5 and this EVI is represented by an MAC-VRF associated with the SN5 and this EVI is represented by an MAC-VRF
which is associated with an IP-VRF (for the same IP VPN) via an IRB which is associated with the same IP-VRF via a different IRB
interface. interface.
2.2 Switching among EVIs in different DCs without route aggregation 2.2 Switching among EVIs in different DCs without route aggregation
This case is similar to that of section 2.1 above albeit for the fact This case is similar to that of section 2.1 above albeit for the fact
that the TS's belong to different data centers that are that the TS's belong to different data centers that are
interconnected over a WAN (e.g. MPLS/IP PSN). The data centers in interconnected over a WAN (e.g. MPLS/IP PSN). The data centers in
question here are seamlessly interconnected to the WAN, i.e., the WAN question here are seamlessly interconnected to the WAN, i.e., the WAN
edge devices do not maintain any TS-specific addresses in the edge devices do not maintain any TS-specific addresses in the
forwarding path - e.g., there is no WAN edge GW(s) between these DCs. forwarding path - e.g., there is no WAN edge GW(s) between these DCs.
As an example, consider TS3 and TS6 of Figure 2 above. Assume that As an example, consider TS3 and TS6 of Figure 2 above. Assume that
connectivity is required between these two TS's where TS3 belongs to connectivity is required between these two TS's where TS3 belongs to
the SN3 whereas TS6 belongs to the SN6. NVE2 has an EVI3 associated the SN3 whereas TS6 belongs to the SN6. NVE2 has an EVI3 associated
with SN3 and NVE4 has an EVI6 associated with the SN6. Both SN3 and with SN3 and NVE4 has an EVI6 associated with the SN6. Both SN3 and
SN6 are part of the same IP VPN. SN6 are part of the same IP-VRF.
2.3 Switching among EVIs in different DCs with route aggregation 2.3 Switching among EVIs in different DCs with route aggregation
In this scenario, connectivity is required between TS's in different In this scenario, connectivity is required between TS's in different
data centers, and those hosts belong to different IP subnets. What data centers, and those hosts belong to different IP subnets. What
makes this case different from that of Section 2.2 is that (in the makes this case different from that of Section 2.2 is that (in the
context of a given IP-VRF) at least one of the data centers in context of a given IP-VRF) at least one of the data centers in
question has a gateway as the WAN edge switch. Because of that, the question has a gateway as the WAN edge switch. Because of that, the
NVE's IP-VRF within each data center need not maintain (host) routes NVE's IP-VRF within each data center need not maintain (host) routes
to individual TS's outside of the data center. to individual TS's outside of the data center.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
IRB interface of the MAC-VRF associated with that EVI. IRB interface of the MAC-VRF associated with that EVI.
2. Each NVE of a given EVPN instance uses its own default gateway IP 2. Each NVE of a given EVPN instance uses its own default gateway IP
and MAC addresses, and these addresses are aliased to the same and MAC addresses, and these addresses are aliased to the same
conceptual gateway through the use of the Default Gateway extended conceptual gateway through the use of the Default Gateway extended
community as specified in [EVPN], which is carried in the EVPN MAC community as specified in [EVPN], which is carried in the EVPN MAC
Advertisement routes. On each NVE, this default gateway IP/MAC Advertisement routes. On each NVE, this default gateway IP/MAC
address correspond to the IRB interface of the MAC-VRF associated address correspond to the IRB interface of the MAC-VRF associated
with that EVI. with that EVI.
Both of these models enable a packet forwarding paradigm for Both of these models enable a packet forwarding paradigm for both
asymmetric IRB forwarding where a packet can bypass the IP-VRF symmetric and asymmetric IRB forwarding. In case of asymmetric IRB, a
processing on the egress (i.e. disposition) NVE. The egress NVE packet is forwarded through the MAC-VRF followed by the IP-VRF on the
merely needs to perform a lookup in the associated MAC-VRF and ingress NVE, and then forwarded through the the MAC-VRF on the egress
forward the Ethernet frames unmodified, i.e. without rewriting the (disposition) NVE. The egress NVE merely needs to perform a lookup in
source MAC address. This is different from symmetric IRB forwarding the associated MAC-VRF and forward the Ethernet frames unmodified,
where a packet is forwarded through the MAC-VRF followed by the IP- i.e. without rewriting the source MAC address. This is different
VRF on the ingress NVE, and then forwarded through the IP-VRF from symmetric IRB forwarding where a packet is forwarded through the
followed by the MAC-VRF on the egress NVE. MAC-VRF followed by the IP-VRF on the ingress NVE, and then forwarded
through the IP-VRF followed by the MAC-VRF on the egress NVE.
It is worth noting that if the applications that are running on the It is worth noting that if the applications that are running on the
TS's are employing or relying on any form of MAC security, then the TS's are employing or relying on any form of MAC security, then the
first model (i.e. using anycast addresses) would be required to first model (i.e. using anycast addresses) would be required to
ensure that the applications receive traffic from the same source MAC ensure that the applications receive traffic from the same source MAC
address that they are sending to. address that they are sending to.
3.2 Heterogeneous Environment 3.2 Heterogeneous Environment
For large data centers with thousands of servers and ToR (or Access) For large data centers with thousands of servers and ToR (or Access)
switches, some of them may not have the capability of maintaining or switches, some of them may not have the capability of maintaining or
enforcing policies for inter-subnet switching. Even though policies enforcing policies for inter-subnet switching. Even though policies
among multiple subnets belonging to same tenant can be simpler, hosts among multiple subnets belonging to same tenant can be simpler, hosts
belonging to one tenant can also send traffic to peers belonging to belonging to one tenant can also send traffic to peers belonging to
different tenants or security zones. A L3GW not only needs to enforce different tenants or security zones. In such scenarios, a L3GW may
policies for communication among subnets belonging to a single not only need to enforce policies for communication among subnets
tenant, but also it needs to know how to handle traffic destined belonging to a single tenant, but also it may need to know how to
towards peers in different tenants. Therefore, there can be a mixed handle traffic destined towards peers in different tenants.
environment where an NVE performs inter-subnet switching for some Therefore, there can be a mixed environment where an NVE performs
EVPN instances but not others. inter-subnet switching for some EVPN instances and the L3GW for
others.
4 Operational Models for Asymmetric Inter-Subnet Forwarding 4 Operational Models for Asymmetric Inter-Subnet Forwarding
4.1 Among EVPN NVEs within a DC 4.1 Among EVPN NVEs within a DC
When an EVPN MAC advertisement route is received by the NVE, the IP When an EVPN MAC advertisement route is received by the NVE, the IP
address associated with the route is used to populate the IP-VRF address associated with the route is used to populate the IP-VRF
table, whereas the MAC address associated with the route is used to table, whereas the MAC address associated with the route is used to
populate both the MAC-VRF table, as well as the adjacency associated populate both the MAC-VRF table, as well as the adjacency associated
with the IP route in the IP-VRF table. with the IP route in the IP-VRF table.
 End of changes. 10 change blocks. 
30 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/