draft-ietf-bess-evpn-prefix-advertisement-01.txt   draft-ietf-bess-evpn-prefix-advertisement-02.txt 
BESS Workgroup J. Rabadan, Ed. BESS Workgroup J. Rabadan, Ed.
Internet Draft W. Henderickx Internet Draft W. Henderickx
S. Palislamovic S. Palislamovic
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
J. Drake F. Balus J. Drake A. Isaac
W. Lin Nuage Networks W. Lin Bloomberg
Juniper Juniper
A. Isaac
A. Sajassi Bloomberg A. Sajassi
Cisco Cisco
Expires: September 10, 2015 March 9, 2015 Expires: March 17, 2016 September 14, 2015
IP Prefix Advertisement in EVPN IP Prefix Advertisement in EVPN
draft-ietf-bess-evpn-prefix-advertisement-01 draft-ietf-bess-evpn-prefix-advertisement-02
Abstract Abstract
EVPN provides a flexible control plane that allows intra-subnet EVPN provides a flexible control plane that allows intra-subnet
connectivity in an IP/MPLS and/or an NVO-based network. In NVO connectivity in an IP/MPLS and/or an NVO-based network. In NVO
networks, there is also a need for a dynamic and efficient inter- networks, there is also a need for a dynamic and efficient inter-
subnet connectivity across Tenant Systems and End Devices that can be subnet connectivity across Tenant Systems and End Devices that can be
physical or virtual and may not support their own routing protocols. physical or virtual and may not support their own routing protocols.
This document defines a new EVPN route type for the advertisement of This document defines a new EVPN route type for the advertisement of
IP Prefixes and explains some use-case examples where this new route- IP Prefixes and explains some use-case examples where this new route-
skipping to change at page 2, line 9 skipping to change at page 2, line 9
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 10, 2015. This Internet-Draft will expire on March 17, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and problem statement . . . . . . . . . . . . . . 3 2. Introduction and problem statement . . . . . . . . . . . . . . 3
2.1 Inter-subnet connectivity requirements in Data Centers . . . 4 2.1 Inter-subnet connectivity requirements in Data Centers . . . 4
2.2 The requirement for a new EVPN route type . . . . . . . . . 6 2.2 The requirement for a new EVPN route type . . . . . . . . . 6
3. The BGP EVPN IP Prefix route . . . . . . . . . . . . . . . . . 7 3. The BGP EVPN IP Prefix route . . . . . . . . . . . . . . . . . 7
3.1 IP Prefix Route encoding . . . . . . . . . . . . . . . . . . 8 3.1 IP Prefix Route encoding . . . . . . . . . . . . . . . . . . 8
4. Benefits of using the EVPN IP Prefix route . . . . . . . . . . 10 4. Benefits of using the EVPN IP Prefix route . . . . . . . . . . 10
5. IP Prefix index use-cases . . . . . . . . . . . . . . . . . . . 11 5. IP Prefix overlay index use-cases . . . . . . . . . . . . . . . 11
5.1 TS IP address index use-case . . . . . . . . . . . . . . . . 11 5.1 TS IP address overlay index use-case . . . . . . . . . . . . 11
5.2 Floating IP index use-case . . . . . . . . . . . . . . . . . 14 5.2 Floating IP overlay index use-case . . . . . . . . . . . . . 14
5.3 ESI index ("Bump in the wire") use-case . . . . . . . . . . 16 5.3 ESI overlay index ("Bump in the wire") use-case . . . . . . 16
5.4 IRB forwarding on NVEs for Subnets (IP-VRF-to-IP-VRF) . . . 18 5.4 IRB forwarding on NVEs for Subnets (IP-VRF-to-IP-VRF) . . . 18
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Conventions used in this document . . . . . . . . . . . . . . . 22 7. Conventions used in this document . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1 Normative References . . . . . . . . . . . . . . . . . . . 23 10.1 Normative References . . . . . . . . . . . . . . . . . . . 23
10.2 Informative References . . . . . . . . . . . . . . . . . . 23 10.2 Informative References . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
1. Terminology 1. Terminology
GW IP: Gateway IP Address GW IP: Gateway IP Address
IPL: IP address length IPL: IP address length
IRB: Integrated Routing and Bridging interface IRB: Integrated Routing and Bridging interface
ML: MAC address length ML: MAC address length
skipping to change at page 10, line 12 skipping to change at page 10, line 12
ESI field is different from zero, the GW IP field will be zero, and ESI field is different from zero, the GW IP field will be zero, and
vice versa. The following table shows the different inter-subnet use- vice versa. The following table shows the different inter-subnet use-
cases described in this document and the corresponding coding of the cases described in this document and the corresponding coding of the
overlay index in the route type 5 (RT-5). The IP-VRF-to-IP-VRF or IRB overlay index in the route type 5 (RT-5). The IP-VRF-to-IP-VRF or IRB
forwarding on NVEs case is a special use-case, where there may be no forwarding on NVEs case is a special use-case, where there may be no
need for overlay index, since the actual next-hop is given by the BGP need for overlay index, since the actual next-hop is given by the BGP
next-hop. When an overlay index is present in the RT-5, the receiving next-hop. When an overlay index is present in the RT-5, the receiving
NVE will need to perform a recursive route resolution to find out to NVE will need to perform a recursive route resolution to find out to
which egress NVE to forward the packets. which egress NVE to forward the packets.
+----------------------------+----------------------------------+ +----------------------------+--------------------------------------+
| Use-case | Index in the RT-5 BGP update | | Use-case | Overlay Index in the RT-5 BGP update |
+----------------------------+----------------------------------+ +----------------------------+--------------------------------------+
| TS IP address | GW IP Address | | TS IP address | Overlay GW IP Address |
| Floating IP address | GW IP Address | | Floating IP address | Overlay GW IP Address |
| "Bump in the wire" | ESI | | "Bump in the wire" | ESI |
| IP-VRF-to-IP-VRF | GW IP or N/A | | IP-VRF-to-IP-VRF | Overlay GW IP or N/A |
+----------------------------+----------------------------------+ +----------------------------+--------------------------------------+
4. Benefits of using the EVPN IP Prefix route 4. Benefits of using the EVPN IP Prefix route
This section clarifies the different functions accomplished by the This section clarifies the different functions accomplished by the
EVPN RT-2 and RT-5 routes, and provides a list of benefits derived EVPN RT-2 and RT-5 routes, and provides a list of benefits derived
from using a separate route type for the advertisement of IP Prefixes from using a separate route type for the advertisement of IP Prefixes
in EVPN. in EVPN.
[RFC7432] describes the content of the BGP EVPN RT-2 specific NLRI, [RFC7432] describes the content of the BGP EVPN RT-2 specific NLRI,
i.e. MAC/IP Advertisement Route, where the IP address length (IPL) i.e. MAC/IP Advertisement Route, where the IP address length (IPL)
skipping to change at page 11, line 25 skipping to change at page 11, line 27
the MAC address associated to TS2 or TS3. This is easily the MAC address associated to TS2 or TS3. This is easily
accomplished in the RT-5 by including only the IP information in accomplished in the RT-5 by including only the IP information in
the route key. the route key.
d) By decoupling the MAC from the IP Prefix advertisement procedures, d) By decoupling the MAC from the IP Prefix advertisement procedures,
we can leave the IP Prefix advertisements out of the MAC mobility we can leave the IP Prefix advertisements out of the MAC mobility
procedures defined in [RFC7432] for MACs. In addition, this allows procedures defined in [RFC7432] for MACs. In addition, this allows
us to have an indirection mechanism for IP Prefixes advertised us to have an indirection mechanism for IP Prefixes advertised
from a MAC/IP that can move between hypervisors. E.g. if there are from a MAC/IP that can move between hypervisors. E.g. if there are
1,000 prefixes seating behind TS2 (figure 1), NVE2 will advertise 1,000 prefixes seating behind TS2 (figure 1), NVE2 will advertise
all those prefixes in RT-5 routes associated to the index IP2. all those prefixes in RT-5 routes associated to the overlay index
Should TS2 move to a different NVE, a single MAC/IP advertisement IP2. Should TS2 move to a different NVE, a single MAC/IP
route withdraw for the M2/IP2 route from NVE2 will invalidate the advertisement route withdraw for the M2/IP2 route from NVE2 will
1,000 prefixes, as opposed to have to wait for each individual invalidate the 1,000 prefixes, as opposed to have to wait for each
prefix to be withdrawn. This may be easily accomplished by using individual prefix to be withdrawn. This may be easily accomplished
IP Prefix routes that are not tied to a MAC address, and use a by using IP Prefix routes that are not tied to a MAC address, and
different MAC/IP route to advertise the location and resolution of use a different MAC/IP route to advertise the location and
the overlay index to a MAC address. resolution of the overlay index to a MAC address.
5. IP Prefix index use-cases 5. IP Prefix overlay index use-cases
The IP Prefix route can use a GW IP or an ESI as an overlay index as The IP Prefix route can use a GW IP or an ESI as an overlay index as
well as no overlay index whatsoever. This section describes some use- well as no overlay index whatsoever. This section describes some use-
cases for these index types. cases for these index types.
5.1 TS IP address index use-case 5.1 TS IP address overlay index use-case
The following figure illustrates an example of inter-subnet The following figure illustrates an example of inter-subnet
forwarding for subnets seating behind Virtual Appliances (on TS2 and forwarding for subnets seating behind Virtual Appliances (on TS2 and
TS3). TS3).
SN1---+ NVE2 DGW1 SN1---+ NVE2 DGW1
| +-----------+ +---------+ +-------------+ | +-----------+ +---------+ +-------------+
SN2---TS2(VA)--|(MAC-VRF10)|-| |----|(MAC-VRF10) | SN2---TS2(VA)--|(MAC-VRF10)|-| |----|(MAC-VRF10) |
| IP2/M2 +-----------+ | | | IRB1\ | | IP2/M2 +-----------+ | | | IRB1\ |
IP4---+ | | | (IP-VRF)|---+ IP4---+ | | | (IP-VRF)|---+
skipping to change at page 12, line 52 skipping to change at page 12, line 52
ESI=0, GW IP address=IP3 (and BGP Encapsulation Extended ESI=0, GW IP address=IP3 (and BGP Encapsulation Extended
Community). Community).
(3) DGW1 and DGW2 import both received routes based on the (3) DGW1 and DGW2 import both received routes based on the
route-targets: route-targets:
o Based on the MAC-VRF10 route-target in DGW1 and DGW2, the o Based on the MAC-VRF10 route-target in DGW1 and DGW2, the
MAC/IP route is imported and M2 is added to the MAC-VRF10 MAC/IP route is imported and M2 is added to the MAC-VRF10
along with its corresponding tunnel information. For instance, along with its corresponding tunnel information. For instance,
if VXLAN is used, the VTEP will be derived from the MAC/IP if VXLAN is used, the VTEP will be derived from the MAC/IP
route BGP next-hop (underlay next-hop) and VNI from the route BGP next-hop (underlay next-hop) and VNI from the MPLS
VNI/VSID field. IP2 - M2 is added to the ARP table. Label1 field. IP2 - M2 is added to the ARP table.
o Based on the MAC-VRF10 route-target in DGW1 and DGW2, the IP o Based on the MAC-VRF10 route-target in DGW1 and DGW2, the IP
Prefix route is also imported and SN1/24 is added to the IP- Prefix route is also imported and SN1/24 is added to the IP-
VRF with index IP2 pointing at the local MAC-VRF10. Should VRF with overlay index IP2 pointing at the local MAC-VRF10.
ECMP be enabled in the IP-VRF, SN1/24 would also be added to Should ECMP be enabled in the IP-VRF, SN1/24 would also be
the routing table with overlay index IP3. added to the routing table with overlay index IP3.
(4) When DGW1 receives a packet from the WAN with destination IPx, (4) When DGW1 receives a packet from the WAN with destination IPx,
where IPx belongs to SN1/24: where IPx belongs to SN1/24:
o A destination IP lookup is performed on the DGW1 IP-VRF o A destination IP lookup is performed on the DGW1 IP-VRF
routing table and index=IP2 is found. Since IP2 is an overlay routing table and overlay index=IP2 is found. Since IP2 is an
index a recursive route resolution is required for IP2. overlay index a recursive route resolution is required for
IP2.
o IP2 is resolved to M2 in the ARP table, and M2 is resolved to o IP2 is resolved to M2 in the ARP table, and M2 is resolved to
the tunnel information given by the MAC-VRF FIB (e.g. remote the tunnel information given by the MAC-VRF FIB (e.g. remote
VTEP and VNI for the VXLAN case). VTEP and VNI for the VXLAN case).
o The IP packet destined to IPx is encapsulated with: o The IP packet destined to IPx is encapsulated with:
. Source inner MAC = IRB1 MAC. . Source inner MAC = IRB1 MAC.
. Destination inner MAC = M2. . Destination inner MAC = M2.
skipping to change at page 13, line 46 skipping to change at page 13, line 47
o Encapsulation is stripped-off and based on a MAC lookup o Encapsulation is stripped-off and based on a MAC lookup
(assuming MAC forwarding on the egress NVE), the packet is (assuming MAC forwarding on the egress NVE), the packet is
forwarded to TS2, where it will be properly routed. forwarded to TS2, where it will be properly routed.
(6) Should TS2 move from NVE2 to NVE3, MAC Mobility procedures will (6) Should TS2 move from NVE2 to NVE3, MAC Mobility procedures will
be applied to the MAC route IP2/M2, as defined in [RFC7432]. be applied to the MAC route IP2/M2, as defined in [RFC7432].
Route type 5 prefixes are not subject to MAC mobility procedures, Route type 5 prefixes are not subject to MAC mobility procedures,
hence no changes in the DGW IP-VRF routing table will occur for hence no changes in the DGW IP-VRF routing table will occur for
TS2 mobility, i.e. all the prefixes will still be pointing at IP2 TS2 mobility, i.e. all the prefixes will still be pointing at IP2
as index. There is an indirection for e.g. SN1/24, which still as overlay index. There is an indirection for e.g. SN1/24, which
points at index IP2 in the routing table, but IP2 will be simply still points at overlay index IP2 in the routing table, but IP2
resolved to a different tunnel, based on the outcome of the MAC will be simply resolved to a different tunnel, based on the
mobility procedures for the MAC/IP route IP2/M2. outcome of the MAC mobility procedures for the MAC/IP route
IP2/M2.
Note that in the opposite direction, TS2 will send traffic based on Note that in the opposite direction, TS2 will send traffic based on
its static-route next-hop information (IRB1 and/or IRB2), and regular its static-route next-hop information (IRB1 and/or IRB2), and regular
EVPN procedures will be applied. EVPN procedures will be applied.
5.2 Floating IP index use-case 5.2 Floating IP overlay index use-case
Sometimes Tenant Systems (TS) work in active/standby mode where an Sometimes Tenant Systems (TS) work in active/standby mode where an
upstream floating IP - owned by the active TS - is used as the index upstream floating IP - owned by the active TS - is used as the
to get to some subnets behind. This redundancy mode, already overlay index to get to some subnets behind. This redundancy mode,
introduced in section 2.1 and 2.2, is illustrated in Figure 3. already introduced in section 2.1 and 2.2, is illustrated in Figure
3.
NVE2 DGW1 NVE2 DGW1
+-----------+ +---------+ +-------------+ +-----------+ +---------+ +-------------+
+---TS2(VA)--|(MAC-VRF10)|-| |----|(MAC-VRF10) | +---TS2(VA)--|(MAC-VRF10)|-| |----|(MAC-VRF10) |
| IP2/M2 +-----------+ | | | IRB1\ | | IP2/M2 +-----------+ | | | IRB1\ |
| <-+ | | | (IP-VRF)|---+ | <-+ | | | (IP-VRF)|---+
| | | | +-------------+ _|_ | | | | +-------------+ _|_
SN1 vIP23 (floating) | VXLAN/ | ( ) SN1 vIP23 (floating) | VXLAN/ | ( )
| | | nvGRE | DGW2 ( WAN ) | | | nvGRE | DGW2 ( WAN )
| <-+ NVE3 | | +-------------+ (___) | <-+ NVE3 | | +-------------+ (___)
| IP3/M3 +-----------+ | |----|(MAC-VRF10) | | | IP3/M3 +-----------+ | |----|(MAC-VRF10) | |
+---TS3(VA)--|(MAC-VRF10)|-| | | IRB2\ | | +---TS3(VA)--|(MAC-VRF10)|-| | | IRB2\ | |
+-----------+ +---------+ | (IP-VRF)|---+ +-----------+ +---------+ | (IP-VRF)|---+
+-------------+ +-------------+
Figure 3 Floating IP index for redundant TS Figure 3 Floating IP overlay index for redundant TS
In this example, assuming TS2 is the active TS and owns IP23: In this example, assuming TS2 is the active TS and owns IP23:
(1) NVE2 advertises the following BGP routes for TS2: (1) NVE2 advertises the following BGP routes for TS2:
o Route type 2 (MAC/IP route) containing: ML=48, M=M2, IPL=32, o Route type 2 (MAC/IP route) containing: ML=48, M=M2, IPL=32,
IP=IP23 (and BGP Encapsulation Extended Community). IP=IP23 (and BGP Encapsulation Extended Community).
o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1,
ESI=0, GW IP address=IP23 (and BGP Encapsulation Extended ESI=0, GW IP address=IP23 (and BGP Encapsulation Extended
skipping to change at page 15, line 7 skipping to change at page 15, line 10
Community). Community).
(3) DGW1 and DGW2 import both received routes based on the route- (3) DGW1 and DGW2 import both received routes based on the route-
target: target:
o M2 is added to the MAC-VRF10 FIB along with its corresponding o M2 is added to the MAC-VRF10 FIB along with its corresponding
tunnel information. For the VXLAN use case, the VTEP will be tunnel information. For the VXLAN use case, the VTEP will be
derived from the MAC/IP route BGP next-hop and VNI from the derived from the MAC/IP route BGP next-hop and VNI from the
VNI/VSID field. IP23 - M2 is added to the ARP table. VNI/VSID field. IP23 - M2 is added to the ARP table.
o SN1/24 is added to the IP-VRF in DGW1 and DGW2 with index IP23 o SN1/24 is added to the IP-VRF in DGW1 and DGW2 with overlay
pointing at the local MAC-VRF10. index IP23 pointing at the local MAC-VRF10.
(4) When DGW1 receives a packet from the WAN with destination IPx, (4) When DGW1 receives a packet from the WAN with destination IPx,
where IPx belongs to SN1/24: where IPx belongs to SN1/24:
o A destination IP lookup is performed on the DGW1 IP-VRF o A destination IP lookup is performed on the DGW1 IP-VRF
routing table and index=IP23 is found. Since IP23 is an routing table and overlay index=IP23 is found. Since IP23 is
overlay index, a recursive route resolution for IP23 is an overlay index, a recursive route resolution for IP23 is
required. required.
o IP23 is resolved to M2 in the ARP table, and M2 is resolved to o IP23 is resolved to M2 in the ARP table, and M2 is resolved to
the tunnel information given by the MAC-VRF (remote VTEP and the tunnel information given by the MAC-VRF (remote VTEP and
VNI for the VXLAN case). VNI for the VXLAN case).
o The IP packet destined to IPx is encapsulated with: o The IP packet destined to IPx is encapsulated with:
. Source inner MAC = IRB1 MAC. . Source inner MAC = IRB1 MAC.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
forwarded to TS2, where it will be properly routed. forwarded to TS2, where it will be properly routed.
(6) When the redundancy protocol running between TS2 and TS3 appoints (6) When the redundancy protocol running between TS2 and TS3 appoints
TS3 as the new active TS for SN1, TS3 will now own the floating TS3 as the new active TS for SN1, TS3 will now own the floating
IP23 and will signal this new ownership (GARP message or IP23 and will signal this new ownership (GARP message or
similar). Upon receiving the new owner's notification, NVE3 will similar). Upon receiving the new owner's notification, NVE3 will
issue a route type 2 for M3-IP23. DGW1 and DGW2 will update their issue a route type 2 for M3-IP23. DGW1 and DGW2 will update their
ARP tables with the new MAC resolving the floating IP. No changes ARP tables with the new MAC resolving the floating IP. No changes
are carried out in the IP-VRF routing table. are carried out in the IP-VRF routing table.
5.3 ESI index ("Bump in the wire") use-case 5.3 ESI overlay index ("Bump in the wire") use-case
Figure 5 illustrates an example of inter-subnet forwarding for an IP Figure 5 illustrates an example of inter-subnet forwarding for an IP
Prefix route that carries a subnet SN1 and uses an ESI as an overlay Prefix route that carries a subnet SN1 and uses an ESI as an overlay
index (ESI23). In this use-case, TS2 and TS3 are layer-2 VA devices index (ESI23). In this use-case, TS2 and TS3 are layer-2 VA devices
without any IP address that can be included as an overlay index in without any IP address that can be included as an overlay index in
the GW IP field of the IP Prefix route. Their MAC addresses are M2 the GW IP field of the IP Prefix route. Their MAC addresses are M2
and M3 respectively and are connected to EVI-10. Note that IRB1 and and M3 respectively and are connected to EVI-10. Note that IRB1 and
IRB2 (in DGW1 and DGW2 respectively) have IP addresses in a subnet IRB2 (in DGW1 and DGW2 respectively) have IP addresses in a subnet
different than SN1. different than SN1.
skipping to change at page 16, line 30 skipping to change at page 16, line 30
| + | | | (IP-VRF)|---+ | + | | | (IP-VRF)|---+
| | | | +-------------+ _|_ | | | | +-------------+ _|_
SN1 | | VXLAN/ | ( ) SN1 | | VXLAN/ | ( )
| | | nvGRE | DGW2 ( WAN ) | | | nvGRE | DGW2 ( WAN )
| + NVE3 | | +-------------+ (___) | + NVE3 | | +-------------+ (___)
| ESI23 +-----------+ | |----|(MAC-VRF10) | | | ESI23 +-----------+ | |----|(MAC-VRF10) | |
+---TS3(VA)--|(MAC-VRF10)|-| | | IRB2\ | | +---TS3(VA)--|(MAC-VRF10)|-| | | IRB2\ | |
M3 +-----------+ +---------+ | (IP-VRF)|---+ M3 +-----------+ +---------+ | (IP-VRF)|---+
+-------------+ +-------------+
Figure 5 ESI index use-case Figure 5 ESI overlay index use-case
Since neither TS2 nor TS3 can run any routing protocol and have no IP Since neither TS2 nor TS3 can run any routing protocol and have no IP
address assigned, an ESI, i.e. ESI23, will be provisioned on the address assigned, an ESI, i.e. ESI23, will be provisioned on the
attachment ports of NVE2 and NVE3. This model supports VA redundancy attachment ports of NVE2 and NVE3. This model supports VA redundancy
in a similar way as the one described in section 5.2 for the floating in a similar way as the one described in section 5.2 for the floating
IP index use-case, only using the EVPN Ethernet A-D route instead of IP overlay index use-case, only using the EVPN Ethernet A-D route
the MAC advertisement route to advertise the location of the overlay instead of the MAC advertisement route to advertise the location of
index. The procedure is explained below: the overlay index. The procedure is explained below:
(1) NVE2 advertises the following BGP routes for TS2: (1) NVE2 advertises the following BGP routes for TS2:
o Route type 1 (Ethernet A-D route for EVI-10) containing: o Route type 1 (Ethernet A-D route for EVI-10) containing:
ESI=ESI23 and the corresponding tunnel information (VNI/VSID ESI=ESI23 and the corresponding tunnel information (VNI/VSID
field), as well as the BGP Encapsulation Extended Community as field), as well as the BGP Encapsulation Extended Community as
per [EVPN-OVERLAY]. per [EVPN-OVERLAY].
o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1,
ESI=ESI23, GW IP address=0 (and BGP Encapsulation Extended ESI=ESI23, GW IP address=0 (and BGP Encapsulation Extended
skipping to change at page 17, line 30 skipping to change at page 17, line 30
SN1 seats. SN1 seats.
(3) DGW1 and DGW2 import the received routes based on the route- (3) DGW1 and DGW2 import the received routes based on the route-
target: target:
o The tunnel information to get to ESI23 is installed in DGW1 o The tunnel information to get to ESI23 is installed in DGW1
and DGW2. For the VXLAN use case, the VTEP will be derived and DGW2. For the VXLAN use case, the VTEP will be derived
from the Ethernet A-D route BGP next-hop and VNI from the from the Ethernet A-D route BGP next-hop and VNI from the
VNI/VSID field (see [EVPN-OVERLAY]). VNI/VSID field (see [EVPN-OVERLAY]).
o SN1/24 is added to the IP-VRF in DGW1 and DGW2 with index o SN1/24 is added to the IP-VRF in DGW1 and DGW2 with overlay
ESI23. index ESI23.
(4) When DGW1 receives a packet from the WAN with destination IPx, (4) When DGW1 receives a packet from the WAN with destination IPx,
where IPx belongs to SN1/24: where IPx belongs to SN1/24:
o A destination IP lookup is performed on the DGW1 IP-VRF o A destination IP lookup is performed on the DGW1 IP-VRF
routing table and index=ESI23 is found. Since ESI23 is an routing table and overlay index=ESI23 is found. Since ESI23 is
overlay index, a recursive route resolution is required to an overlay index, a recursive route resolution is required to
find the egress NVE where ESI23 resides. find the egress NVE where ESI23 resides.
o The IP packet destined to IPx is encapsulated with: o The IP packet destined to IPx is encapsulated with:
. Source inner MAC = IRB1 MAC. . Source inner MAC = IRB1 MAC.
. Destination inner MAC = M2 (this MAC will be obtained . Destination inner MAC = M2 (this MAC will be obtained
from the Router's MAC Extended Community received along from the Router's MAC Extended Community received along
with the RT-5 for SN1). with the RT-5 for SN1).
skipping to change at page 21, line 17 skipping to change at page 21, line 17
. Route-target identifying the tenant. This route-target MAY . Route-target identifying the tenant. This route-target MAY
be the same one used with the RT-5. be the same one used with the RT-5.
(2) DGW1 imports the received routes from NVE1: (2) DGW1 imports the received routes from NVE1:
o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5
route-target. route-target.
. If GW IP is different from zero, the GW IP - IRB-1-IP1 - . If GW IP is different from zero, the GW IP - IRB-1-IP1 -
will be used as the index for the recursive route resolution will be used as the overlay index for the recursive route
to the RT-2 carrying IRB-1-IP1. resolution to the RT-2 carrying IRB-1-IP1.
. If GW IP=0, an implementation MAY use the VNI and next-hop . If GW IP=0, an implementation MAY use the VNI and next-hop
of the RT-5, as well as the MAC address conveyed in the of the RT-5, as well as the MAC address conveyed in the
Router's MAC Extended Community (as inner destination MAC Router's MAC Extended Community (as inner destination MAC
address). address).
(3) When DGW1 receives a packet from the WAN with destination IPx, (3) When DGW1 receives a packet from the WAN with destination IPx,
where IPx belongs to SN1/24: where IPx belongs to SN1/24:
o A destination IP lookup is performed on the DGW1 IP-VRF o A destination IP lookup is performed on the DGW1 IP-VRF
routing table that yields SN1/24. routing table that yields SN1/24.
. If RT-5 for SN1/24 had a GW IP=IRB-1-IP1, this GW IP will be . If RT-5 for SN1/24 had a GW IP=IRB-1-IP1, this GW IP will be
used as an index that will be recursively resolved to the used as an overlay index that will be recursively resolved
tunnel information received from the RT-2. to the tunnel information received from the RT-2.
. If the RT-5 for SN1/24 had a GW IP=0, DGW1 MAY not refer to . If the RT-5 for SN1/24 had a GW IP=0, DGW1 MAY not refer to
the RT-2. the RT-2.
o The IP packet destined to IPx is encapsulated with: Source o The IP packet destined to IPx is encapsulated with: Source
inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer
IP (source VTEP) = DGW1 IP, Destination outer IP (destination IP (source VTEP) = DGW1 IP, Destination outer IP (destination
VTEP) = NVE1 IP. VTEP) = NVE1 IP.
(4) When the packet arrives at NVE1: (4) When the packet arrives at NVE1:
skipping to change at page 22, line 35 skipping to change at page 22, line 35
in an NLRI with no MAC addresses in the route key, so that only IP in an NLRI with no MAC addresses in the route key, so that only IP
information is used in BGP route comparisons. information is used in BGP route comparisons.
b) Since the route type is different from the MAC/IP Advertisement b) Since the route type is different from the MAC/IP Advertisement
route, the advertisement of prefixes will be excluded from all the route, the advertisement of prefixes will be excluded from all the
procedures defined for the advertisement of VM MACs, e.g. MAC procedures defined for the advertisement of VM MACs, e.g. MAC
Mobility or aliasing. As a result of that, the current EVPN Mobility or aliasing. As a result of that, the current EVPN
procedures do not need to be modified. procedures do not need to be modified.
c) Allows a flexible implementation where the prefix can be linked to c) Allows a flexible implementation where the prefix can be linked to
different types of indexes: overlay IP address, overlay ESI, different types of overlay indexes: overlay IP address, overlay
underlay IP next-hops, etc. ESI, underlay IP next-hops, etc.
d) An EVPN implementation not requiring IP Prefixes can simply d) An EVPN implementation not requiring IP Prefixes can simply
discard them by looking at the route type value. An unknown route discard them by looking at the route type value. An unknown route
type MUST be ignored by the receiving NVE/PE. type MUST be ignored by the receiving NVE/PE.
7. Conventions used in this document 7. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
skipping to change at page 23, line 18 skipping to change at page 23, line 18
as follows: as follows:
Value Description Reference Value Description Reference
5 IP Prefix route [this document] 5 IP Prefix route [this document]
6-255 Unassigned 6-255 Unassigned
10. References 10. References
10.1 Normative References 10.1 Normative References
[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,
February 2015, <http://www.rfc-editor.org/info/rfc7432>.
[RFC4364]Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364]Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc- Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
editor.org/info/rfc4364>. <http://www.rfc-editor.org/info/rfc4364>.
[RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
editor.org/info/rfc7432>.
10.2 Informative References 10.2 Informative References
[EVPN-OVERLAY] Sajassi-Drake et al., "A Network Virtualization [EVPN-OVERLAY] Sajassi-Drake et al., "A Network Virtualization
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-00.txt, Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-01.txt,
work in progress, November, 2014 work in progress, February, 2015
[EVPN-INTERSUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in [EVPN-INTERSUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in
EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-00.txt, work in EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-00.txt, work in
progress, November, 2014 progress, November, 2014
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Mukul Katiyar and Senthil Sathappan The authors would like to thank Mukul Katiyar and Senthil Sathappan
for their valuable feedback and contributions. The following people for their valuable feedback and contributions. The following people
also helped improving this document with their feedback: Antoni also helped improving this document with their feedback: Tony
Przygienda and Thomas Morin. Przygienda and Thomas Morin.
12. Authors' Addresses 12. Contributors
In addition to the authors listed on the front page, the following
co-authors have also contributed to this document:
Florin Balus
13. Authors' Addresses
Jorge Rabadan Jorge Rabadan
Alcatel-Lucent Alcatel-Lucent
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@alcatel-lucent.com Email: jorge.rabadan@alcatel-lucent.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@alcatel-lucent.com
Florin Balus
Nuage Networks
Email: florin@nuagenetworks.net
Aldrin Isaac Aldrin Isaac
Bloomberg Bloomberg
Email: aisaac71@bloomberg.net Email: aisaac71@bloomberg.net
Senad Palislamovic Senad Palislamovic
Alcatel-Lucent Alcatel-Lucent
Email: senad.palislamovic@alcatel-lucent.com Email: senad.palislamovic@alcatel-lucent.com
John E. Drake John E. Drake
Juniper Networks Juniper Networks
 End of changes. 35 change blocks. 
78 lines changed or deleted 88 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/