draft-ietf-bess-evpn-prefix-advertisement-02.txt   draft-ietf-bess-evpn-prefix-advertisement-03.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 Nokia
J. Drake A. Isaac A. Isaac
W. Lin Bloomberg J. Drake
Juniper W. Lin
Juniper
A. Sajassi A. Sajassi
Cisco Cisco
Expires: March 17, 2016 September 14, 2015 Expires: March 17, 2017 September 13, 2016
IP Prefix Advertisement in EVPN IP Prefix Advertisement in EVPN
draft-ietf-bess-evpn-prefix-advertisement-02 draft-ietf-bess-evpn-prefix-advertisement-03
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 1, line 45 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 March 17, 2016. This Internet-Draft will expire on March 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and problem statement . . . . . . . . . . . . . . 3 2. Introduction and problem statement . . . . . . . . . . . . . . 4
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 . . . . . . . . . 7
3. The BGP EVPN IP Prefix route . . . . . . . . . . . . . . . . . 7 3. The BGP EVPN IP Prefix route . . . . . . . . . . . . . . . . . 8
3.1 IP Prefix Route encoding . . . . . . . . . . . . . . . . . . 8 3.1 IP Prefix Route encoding . . . . . . . . . . . . . . . . . . 9
4. Benefits of using the EVPN IP Prefix route . . . . . . . . . . 10 4. Benefits of using the EVPN IP Prefix route . . . . . . . . . . 11
5. IP Prefix overlay index use-cases . . . . . . . . . . . . . . . 11 5. IP Prefix overlay index use-cases . . . . . . . . . . . . . . . 12
5.1 TS IP address overlay index use-case . . . . . . . . . . . . 11 5.1 TS IP address overlay index use-case . . . . . . . . . . . . 12
5.2 Floating IP overlay index use-case . . . . . . . . . . . . . 14 5.2 Floating IP overlay index use-case . . . . . . . . . . . . . 15
5.3 ESI overlay 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 IP-VRF-to-IP-VRF model . . . . . . . . . . . . . . . . . . . 19
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4.1 Interface-less IP-VRF-to-IP-VRF model . . . . . . . . . 20
7. Conventions used in this document . . . . . . . . . . . . . . . 22 5.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 5.4.3 Interface-full IP-VRF-to-IP-VRF with unnumbered
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 core-facing IRB . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1 Normative References . . . . . . . . . . . . . . . . . . . 23 7. Conventions used in this document . . . . . . . . . . . . . . . 29
10.2 Informative References . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 29
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 10.1 Normative References . . . . . . . . . . . . . . . . . . . 30
10.2 Informative References . . . . . . . . . . . . . . . . . . 30
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
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 3, line 25 skipping to change at page 3, line 29
NVE: Network Virtualization Edge NVE: Network Virtualization Edge
TS: Tenant System TS: Tenant System
VA: Virtual Appliance VA: Virtual Appliance
RT-2: EVPN route type 2, i.e. MAC/IP advertisement route RT-2: EVPN route type 2, i.e. MAC/IP advertisement route
RT-5: EVPN route type 5, i.e. IP Prefix route RT-5: EVPN route type 5, i.e. IP Prefix route
AC: Attachment Circuit
Overlay index: object used in the IP Prefix route, as described in Overlay index: object used in the IP Prefix route, as described in
this document. It can be an IP address in the tenant space or an ESI, this document. It can be an IP address in the tenant space or an ESI,
and identifies a pointer yielded by the IP route lookup at the and identifies a pointer yielded by the IP route lookup at the
routing context importing the route. An overlay index always needs a routing context importing the route. An overlay index always needs a
recursive route resolution on the NVE receiving the IP Prefix route, recursive route resolution on the NVE receiving the IP Prefix route,
so that the NVE knows to which egress NVE it needs to forward the so that the NVE knows to which egress NVE it needs to forward the
packets. packets.
Underlay next-hop: IP address sent by BGP along with any EVPN route, Underlay next-hop: IP address sent by BGP along with any EVPN route,
i.e. BGP next-hop. It identifies the NVE sending the route and it is i.e. BGP next-hop. It identifies the NVE sending the route and it is
used at the receiving NVE as the VXLAN destination VTEP or NVGRE used at the receiving NVE as the VXLAN destination VTEP or NVGRE
destination end-point. destination end-point.
Ethernet NVO tunnel: it refers to Network Virtualization Overlay
tunnels with Ethernet payload. Examples of this type of tunnels are
VXLAN or nvGRE.
IP NVO tunnel: it refers to Network Virtualization Overlay tunnels
with IP payload (no MAC header in the payload). Examples of IP NVO
tunnels are VXLAN GPE or MPLSoGRE (both with IP payload).
2. Introduction and problem statement 2. Introduction and problem statement
Inter-subnet connectivity is required for certain tenants within the Inter-subnet connectivity is required for certain tenants within the
Data Center. [EVPN-INTERSUBNET] defines some fairly common inter- Data Center. [EVPN-INTERSUBNET] defines some fairly common inter-
subnet forwarding scenarios where TSes can exchange packets with TSes subnet forwarding scenarios where TSes can exchange packets with TSes
located in remote subnets. In order to meet this requirement, located in remote subnets. In order to meet this requirement,
[EVPN-INTERSUBNET] describes how MAC/IPs encoded in TS RT-2 routes [EVPN-INTERSUBNET] describes how MAC/IPs encoded in TS RT-2 routes
are not only used to populate MAC-VRF and overlay ARP tables, but are not only used to populate MAC-VRF and overlay ARP tables, but
also IP-VRF tables with the encoded TS host routes (/32 or /128). In also IP-VRF tables with the encoded TS host routes (/32 or /128). In
some cases, EVPN may advertise IP Prefixes and therefore provide some cases, EVPN may advertise IP Prefixes and therefore provide
skipping to change at page 9, line 37 skipping to change at page 10, line 37
identifier if the ESI is used as an overlay index. It will be identifier if the ESI is used as an overlay index. It will be
zero otherwise. zero otherwise.
o The IP Prefix Length can be set to a value between 0 and 32 o The IP Prefix Length can be set to a value between 0 and 32
(bits) for ipv4 and between 0 and 128 for ipv6. (bits) for ipv4 and between 0 and 128 for ipv6.
o The IP Prefix will be a 32 or 128-bit field (ipv4 or ipv6). o The IP Prefix will be a 32 or 128-bit field (ipv4 or ipv6).
o The GW IP (Gateway IP Address) will be a 32 or 128-bit field o The GW IP (Gateway IP Address) will be a 32 or 128-bit field
(ipv4 or ipv6), and will encode an overlay IP index for the IP (ipv4 or ipv6), and will encode an overlay IP index for the IP
Prefixes. The GW IP field can be zero if it is not used as an Prefixes. The GW IP field SHOULD be zero if it is not used as
overlay index. an overlay index.
o The MPLS Label field is encoded as 3 octets, where the high-
order 20 bits contain the label value. The value SHOULD be
null when the IP Prefix route is used for a recursive lookup
resolution.
o The total route length will indicate the type of prefix (ipv4 o The total route length will indicate the type of prefix (ipv4
or ipv6) and the type of GW IP address (ipv4 or ipv6). Note or ipv6) and the type of GW IP address (ipv4 or ipv6). Note
that the IP Prefix + the GW IP should have a length of either that the IP Prefix + the GW IP should have a length of either
64 or 256 bits, but never 160 bits (ipv4 and ipv6 mixed values 64 or 256 bits, but never 160 bits (ipv4 and ipv6 mixed values
are not allowed). are not allowed).
The Eth-Tag ID, IP Prefix Length and IP Prefix will be part of the The Eth-Tag ID, IP Prefix Length and IP Prefix will be part of the
route key used by BGP to compare routes. The rest of the fields will route key used by BGP to compare routes. The rest of the fields will
not be part of the route key. not be part of the route key.
skipping to change at page 10, line 18 skipping to change at page 11, line 23
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 | Overlay Index in the RT-5 BGP update | | Use-case | Overlay Index in the RT-5 BGP update |
+----------------------------+--------------------------------------+ +----------------------------+--------------------------------------+
| TS IP address | Overlay GW IP Address | | TS IP address | Overlay GW IP Address |
| Floating IP address | Overlay 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 | Overlay GW IP or N/A | | IP-VRF-to-IP-VRF | Overlay GW IP, MAC 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,
skipping to change at page 12, line 33 skipping to change at page 13, line 33
DGW2 are running BGP EVPN. TS2 and TS3 do not support routing DGW2 are running BGP EVPN. TS2 and TS3 do not support routing
protocols, only a static route to forward the traffic to the WAN. protocols, only a static route to forward the traffic to the WAN.
(1) NVE2 advertises the following BGP routes on behalf of TS2: (1) NVE2 advertises the following BGP routes on behalf of 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=IP2 and [RFC5512] BGP Encapsulation Extended Community with IP=IP2 and [RFC5512] BGP Encapsulation Extended Community with
the corresponding Tunnel-type. the corresponding Tunnel-type.
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=IP2 (and BGP Encapsulation Extended ESI=0, GW IP address=IP2.
Community).
(2) NVE3 advertises the following BGP routes on behalf of TS3: (2) NVE3 advertises the following BGP routes on behalf of TS3:
o Route type 2 (MAC/IP route) containing: ML=48, M=M3, IPL=32, o Route type 2 (MAC/IP route) containing: ML=48, M=M3, IPL=32,
IP=IP3 (and BGP Encapsulation Extended Community). IP=IP3 (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=IP3 (and BGP Encapsulation Extended ESI=0, GW IP address=IP3.
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 MPLS route BGP next-hop (underlay next-hop) and VNI from the MPLS
Label1 field. IP2 - M2 is added to the ARP table. Label1 field. IP2 - M2 is added to the ARP table.
skipping to change at page 14, line 41 skipping to change at page 15, line 39
Figure 3 Floating IP overlay 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.
Community).
(2) NVE3 advertises the following BGP routes for TS3: (2) NVE3 advertises the following BGP routes for TS3:
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.
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 overlay o SN1/24 is added to the IP-VRF in DGW1 and DGW2 with overlay
skipping to change at page 16, line 48 skipping to change at page 17, line 42
the overlay 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. The Router's MAC Extended
Community). The Router's MAC Extended Community defined in Community defined in [EVPN-INTERSUBNET] is added and carries
[EVPN-INTERSUBNET] is added and carries the MAC address (M2) the MAC address (M2) associated to the TS behind which SN1
associated to the TS behind which SN1 seats. seats.
(2) NVE3 advertises the following BGP routes for TS3: (2) NVE3 advertises the following BGP routes for TS3:
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. field), as well as the BGP Encapsulation Extended Community.
Note that if the resiliency mechanism for TS2 and TS3 is in
all-active mode, both NVE2 and NVE3 will send the A-D route.
Otherwise, that is, the resiliency is single-active, only the
NVE owning the active ESI will advertise the Ethernet A-D
route for ESI23.
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=23, GW IP address=0 (and BGP Encapsulation Extended ESI=23, GW IP address=0. The Router's MAC Extended Community
Community). The Router's MAC Extended Community is added and is added and carries the MAC address (M3) associated to the TS
carries the MAC address (M3) associated to the TS behind which behind which 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 overlay o SN1/24 is added to the IP-VRF in DGW1 and DGW2 with overlay
skipping to change at page 18, line 7 skipping to change at page 18, line 44
. 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).
. Tunnel information for the NVO tunnel is provided by the . Tunnel information for the NVO tunnel is provided by the
Ethernet A-D route per-EVI for ESI23 (VNI and VTEP IP for Ethernet A-D route per-EVI for ESI23 (VNI and VTEP IP for
the VXLAN case). the VXLAN case).
(5) When the packet arrives at NVE2: (5) When the packet arrives at NVE2:
o Based on the tunnel information (VNI for the VXLAN case), the o Based on the tunnel demultiplexer information (VNI for the
MAC-VRF10 context is identified for a MAC lookup (assuming MAC VXLAN case), the MAC-VRF10 context is identified for a MAC
lookup (assuming MAC disposition model) or the VNI MAY
directly identify the egress interface (for a label or VNI
disposition model). disposition model).
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) or a VNI lookup
forwarded to TS2, where it will be forwarded to SN1. (in case of VNI forwarding), the packet is forwarded to TS2,
where it will be forwarded to SN1.
(6) If the redundancy protocol running between TS2 and TS3 follows an (6) If the redundancy protocol running between TS2 and TS3 follows an
active/standby model and there is a failure, appointing TS3 as active/standby model and there is a failure, appointing TS3 as
the new active TS for SN1, TS3 will now own the connectivity to the new active TS for SN1, TS3 will now own the connectivity to
SN1 and will signal this new ownership. Upon receiving the new SN1 and will signal this new ownership. Upon receiving the new
owner's notification, NVE3 will issue a route type 1 for ESI23, owner's notification, NVE3's AC will become active and issue a
whereas NVE2 will withdraw its Ethernet A-D route for ESI23. DGW1 route type 1 for ESI23, whereas NVE2 will withdraw its Ethernet
and DGW2 will update their tunnel information to resolve ESI23. A-D route for ESI23. DGW1 and DGW2 will update their tunnel
The destination inner MAC will be changed to M3. information to resolve ESI23. The destination inner MAC will be
changed to M3.
5.4 IRB forwarding on NVEs for Subnets (IP-VRF-to-IP-VRF) 5.4 IP-VRF-to-IP-VRF model
This use-case is similar to the scenario described in "IRB forwarding This use-case is similar to the scenario described in "IRB forwarding
on NVEs for Tenant Systems" in [EVPN-INTERSUBNET], however the new on NVEs for Tenant Systems" in [EVPN-INTERSUBNET], however the new
requirement here is the advertisement of IP Prefixes as opposed to requirement here is the advertisement of IP Prefixes as opposed to
only host routes. In the previous examples, the MAC-VRF instance can only host routes.
connect IRB interfaces and any other Tenant Systems connected to it.
EVPN provides connectivity for:
a) Traffic destined to the IRB IP interfaces as well as In the examples described in sections 5.1, 5.2 and 5.3, the MAC-VRF
instance can connect IRB interfaces and any other Tenant Systems
connected to it. EVPN provides connectivity for:
b) Traffic destined to IP subnets seating behind the TS, e.g. SN1 or 1. Traffic destined to the IRB IP interfaces as well as
2. Traffic destined to IP subnets seating behind the TS, e.g. SN1 or
SN2. SN2.
In order to provide connectivity for (a), MAC/IP routes (RT-2) are In order to provide connectivity for (1), MAC/IP routes (RT-2) are
needed so that IRB MACs and IPs can be distributed. Connectivity type needed so that IRB MACs and IPs can be distributed. Connectivity type
(b) is accomplished by the exchange of IP Prefix routes (RT-5) for (2) is accomplished by the exchange of IP Prefix routes (RT-5) for
IPs and subnets seating behind certain overlay indexes, e.g. GW IP or IPs and subnets seating behind certain overlay indexes, e.g. GW IP or
ESI. ESI.
In some cases, IP Prefix routes may be advertised for subnets and IPs In some cases, IP Prefix routes may be advertised for subnets and IPs
seating behind an IRB. This use case is depicted in the diagram below seating behind an IRB. We refer to this use-case as the "IP-VRF-to-
and we refer to it as the "IRB forwarding on NVEs for Subnets" or IP-VRF" model.
"IP-VRF-to-IP-VRF" use-case:
NVE1 [EVPN-INTERSUBNET] defines an asymmetric IRB model and a symmetric
IRB model, based on the required lookups at the ingress and egress
NVE: the asymmetric model requires an ip-lookup and a mac-lookup at
the ingress NVE, whereas only a mac-lookup is needed at the egress
NVE; the symmetric model requires ip and mac lookups at both, ingress
and egress NVE. From that perspective, the IP-VRF-to-IP-VRF use-case
described in this section is a symmetric IRB model. Note that in an
IP-VRF-to-IP-VRF scenario, a PE may not be configured with any MAC-
VRF for a given tenant, in which case it will only be doing IP
lookups and forwarding for that tenant.
Based on the way the IP-VRFs are interconnected, there are three
different IP-VRF-to-IP-VRF scenarios identified and described in this
document:
1) Interface-less model
2) Interface-full with core-facing IRB model
3) Interface-full with unnumbered core-facing IRB model
5.4.1 Interface-less IP-VRF-to-IP-VRF model
Figure 6 will be used for the description of this model.
NVE1(M1)
+------------+ +------------+
IP1-----|(MAC-VRF1) | DGW1 IP1+----|(MAC-VRF1) | DGW1(M3)
| \ IRB-1(M1)---------+ +--------+ | \ | +---------+ +--------+
| (IP-VRF)|----| |-|(IP-VRF)|----+ | (IP-VRF)|----| |-|(IP-VRF)|----+
| / | | | +--------+ | | / | | | +--------+ |
|---|(MAC-VRF2) | | | _|_ +---|(MAC-VRF2) | | | _+_
| +------------+ | | ( ) | +------------+ | | ( )
SN1| | VXLAN/ | ( WAN ) SN1| | VXLAN/ | ( WAN )
| NVE2 | nvGRE | (___) | NVE2(M2) | nvGRE/ | (___)
| +------------+ | | | | +------------+ | MPLS | +
|---|(MAC-VRF2) | | | DGW2 | +---|(MAC-VRF2) | | | DGW2(M4) |
| \ IRB-2(M2) | +--------+ | | \ | | | +--------+ |
| (IP-VRF)|----| |-|(IP-VRF)|----+ | (IP-VRF)|----| |-|(IP-VRF)|----+
| / | +---------+ +--------+ | / | +---------+ +--------+
SN2-----|(MAC-VRF3) | SN2+----|(MAC-VRF3) |
+------------+ +------------+
Figure 6 Inter-subnet forwarding on NVEs for Subnets Figure 6 Interface-less IP-VRF-to-IP-VRF model
In this case, we need to provide connectivity from/to IP hosts in In this case, the requirements are the following:
SN1, SN2, IP1 and hosts seating at the other end of the WAN.
The solution must provide connectivity in this use case, irrespective a) The NVEs and DGWs must provide connectivity between hosts in SN1,
of whether the data plane between IP-VRFs requires an inner layer-2 SN2, IP1 and hosts seating at the other end of the WAN.
header.
The EVPN route type 5 will be used to advertise the IP Prefixes, b) The IP-VRF instances in the NVE/DGWs are directly connected
along with the Router's MAC Extended Community as defined in [EVPN- through NVO tunnels, and no IRBs and/or MAC-VRF instances are
INTERSUBNET]. Each NVE/DGW will advertise an RT-5 for each of its defined at the core.
prefixes with the following fields:
c) The solution must provide layer-3 connectivity among the IP-VRFs
for Ethernet NVO tunnels, for instance, VXLAN or nvGRE.
d) The solution may provide layer-3 connectivity among the IP-VRFs
for IP NVO tunnels, for example, VXLAN GPE (with IP payload).
In order to meet the above requirements, the EVPN route type 5 will
be used to advertise the IP Prefixes, along with the Router's MAC
Extended Community as defined in [EVPN-INTERSUBNET] if the
advertising NVE/DGW uses Ethernet NVO tunnels. Each NVE/DGW will
advertise an RT-5 for each of its prefixes with the following fields:
o RD as per [RFC7432]. o RD as per [RFC7432].
o Eth-Tag ID = 0 assuming VLAN-based service. o Eth-Tag ID=0 assuming VLAN-based service.
o IP address length and IP address, as explained in the previous o IP address length and IP address, as explained in the previous
sections. sections.
o GW IP address= 0 or IRB-IP (see below for further explanation) o GW IP address= SHOULD be set to 0.
o ESI=0 o ESI=0
o MPLS label or VNI corresponding to the IP-VRF. o MPLS label or VNI corresponding to the IP-VRF.
Each RT-5 will be sent with a route-target identifying the tenant Each RT-5 will be sent with a route-target identifying the tenant
(IP-VRF) and two BGP extended communities: (IP-VRF) and two BGP extended communities:
o The first one is the BGP Encapsulation Extended Community, as o The first one is the BGP Encapsulation Extended Community, as
per [RFC5512], identifying the tunnel type. per [RFC5512], identifying the tunnel type.
o The second one is the Router's MAC Extended Community as per o The second one is the Router's MAC Extended Community as per
[EVPN-INTERSUBNET] containing the MAC address associated to [EVPN-INTERSUBNET] containing the MAC address associated to
the NVE advertising the route. This MAC address identifies the the NVE advertising the route. This MAC address identifies the
NVE/DGW and MAY be re-used for all the IP-VRFs in the NVE. The NVE/DGW and MAY be re-used for all the IP-VRFs in the NVE. The
Router's MAC Extended Community MUST be sent if the associated Router's MAC Extended Community MUST be sent if the route is
RT-5's GW IP Address is zero. associated to an Ethernet NVO tunnel, for instance, VXLAN. If
the route is associated to an IP NVO tunnel, for instance
If the data plane between IP-VRFs does not require an inner layer-2 VXLAN GPE with IP payload, the Router's MAC Extended Community
header (e.g. VXLAN GPE) NVE1 and NVE2 will only send a RT-5 per IP SHOULD NOT be sent.
Prefix that they have attached to their respective IP-VRF, e.g. IP1,
SN1 and SN2.
If the data plane between IP-VRFs requires an inner layer-2 header
(e.g. VXLAN or nvGRE) NVE1 and NVE2 will additionally send an RT-2
for their IRB interface interconnecting the IP-VRFs for the same
tenant. In Figure 6, the IRB interfaces interconnecting IP-VRFs in
NVE1 and NVE2 are referred to as IRB-1 and IRB-2 and have the MAC
addresses M1 and M2 respectively.
The following example illustrates the procedure to advertise and The following example illustrates the procedure to advertise and
forward packets to SN1/24 (ipv4 prefix advertised from NVE1) for forward packets to SN1/24 (ipv4 prefix advertised from NVE1) for
VXLAN tunnels: VXLAN tunnels:
(1) NVE1 advertises the following BGP routes: (1) NVE1 advertises the following BGP route:
o Route type 5 (IP Prefix route) containing: o Route type 5 (IP Prefix route) containing:
. IPL=24, IP=SN1, VNI=10. . IPL=24, IP=SN1, VNI=10.
. GW IP=0 if IRB-1 is NOT IP-reachable or GW IP=IRB-1-IP if . GW IP= SHOULD be set to 0.
IRB-1 is IP-reachable.
. [RFC5512] BGP Encapsulation Extended Community with Tunnel- . [RFC5512] BGP Encapsulation Extended Community with Tunnel-
type= VXLAN. type=VXLAN.
. Router's MAC Extended Community that contains M1. . Router's MAC Extended Community that contains M1.
. Route-target identifying the tenant (IP-VRF). . Route-target identifying the tenant (IP-VRF).
o Route type 2 (MAC/IP route for IRB-1) containing: (2) DGW1 imports the received routes from NVE1:
. ML=48, M=M1, IPL= 0 or 32, VNI=10. o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5
route-target.
. IP= null (if IRB-1 is not IP-reachable) or IRB-1-IP1 (if o Since GW IP=0 and the VNI is a valid value, DGW1 will use the
IRB-1 is IP-reachable). VNI and next-hop of the RT-5, as well as the MAC address
conveyed in the Router's MAC Extended Community (as inner
destination MAC address) to encapsulate the routed IP packets.
(3) When DGW1 receives a packet from the WAN with destination IPx,
where IPx belongs to SN1/24:
o A destination IP lookup is performed on the DGW1 IP-VRF
routing table. The lookup yields SN1/24.
o Since the RT-5 for SN1/24 had a GW IP=0 and a valid VNI and
next-hop (used as destination VTEP), DGW1 will not need a
recursive lookup to resolve the route.
o The IP packet destined to IPx is encapsulated with: Source
inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer
IP (source VTEP) = DGW1 IP, Destination outer IP (destination
VTEP) = NVE1 IP.
(4) When the packet arrives at NVE1:
o NVE1 will identify the IP-VRF for an IP-lookup based on the
VNI.
o An IP lookup is performed in the routing context, where SN1
turns out to be a local subnet associated to MAC-VRF2. A
subsequent lookup in the ARP table and the MAC-VRF FIB will
provide the forwarding information for the packet in MAC-VRF2.
The implementation of this Interface-less model is REQUIRED.
5.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB
Figure 7 will be used for the description of this model.
NVE1
+------------+ DGW1
IP1+----+(MAC-VRF1) | +---------------+ +------------+
| \ (core) (core) |
|(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+
| / IRB(IP1/M1) IRB(IP3/M3) | |
+---+(MAC-VRF2) | | | +------------+ _+_
| +------------+ | | ( )
SN1| | VXLAN/ | ( WAN )
| NVE2 | nvGRE/ | (___)
| +------------+ | MPLS | DGW2 +
+---+(MAC-VRF2) | | | +------------+ |
| \ (core) (core) | |
|(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+
| / IRB(IP2/M2) IRB(IP4/M4) |
SN2+----+(MAC-VRF3) | +---------------+ +------------+
+------------+
Figure 7 Interface-full with core-facing IRB model
In this model, the requirements are the following:
a) As in section 5.4.1, the NVEs and DGWs must provide connectivity
between hosts in SN1, SN2, IP1 and hosts seating at the other end
of the WAN.
b) However, the NVE/DGWs are now connected through Ethernet NVO
tunnels terminated in core-MAC-VRF instances. The IP-VRFs use IRB
interfaces for their connectivity to the core MAC-VRFs.
c) Each core-facing IRB has an IP and a MAC address, where the IP
address must be reachable from other NVEs or DGWs.
d) The core EVI is composed of the NVE/DGW MAC-VRFs and may contain
other MAC-VRFs without IRB interfaces. Those non-IRB MAC-VRFs will
typically connect TSes that need layer-3 connectivity to remote
subnets.
e) The solution must provide layer-3 connectivity for Ethernet NVO
tunnels, for instance, VXLAN or nvGRE.
EVPN type 5 routes will be used to advertise the IP Prefixes, whereas
EVPN RT-2 routes will advertise the MAC/IP addresses of each core-
facing IRB interface. Each NVE/DGW will advertise an RT-5 for each of
its prefixes with the following fields:
o RD as per [RFC7432].
o Eth-Tag ID=0 assuming VLAN-based service.
o IP address length and IP address, as explained in the previous
sections.
o GW IP address=IRB-IP (this is the overlay index that will be
used for the recursive route resolution).
o ESI=0
o MPLS label or VNI corresponding to the IP-VRF. Note that the
value SHOULD be zero since the RT-5 route requires a recursive
lookup resolution to an RT-2 route. The MPLS label or VNI to
be used when forwarding packets will be derived from the RT-
2's MPLS Label1 field.
Each RT-5 will be sent with a route-target identifying the tenant
(IP-VRF). The Router's MAC Extended Community SHOULD NOT be sent in
this case.
The following example illustrates the procedure to advertise and
forward packets to SN1/24 (ipv4 prefix advertised from NVE1) for
VXLAN tunnels:
(1) NVE1 advertises the following BGP routes:
o Route type 5 (IP Prefix route) containing:
. IPL=24, IP=SN1, VNI= SHOULD be set to 0.
. GW IP=IP1 (core-facing IRB's IP)
. Route-target identifying the tenant (IP-VRF).
o Route type 2 (MAC/IP route for the core-facing IRB)
containing:
. ML=48, M=M1, IPL=32, IP=IP1, VNI=10.
. A [RFC5512] BGP Encapsulation Extended Community with . A [RFC5512] BGP Encapsulation Extended Community with
Tunnel-type= VXLAN. Tunnel-type= VXLAN.
. 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 as the 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 - . Since GW IP is different from zero, the GW IP (IP1) will be
will be used as the overlay index for the recursive route used as the overlay index for the recursive route resolution
resolution to the RT-2 carrying IRB-1-IP1. to the RT-2 carrying IP1.
. 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
Router's MAC Extended Community (as inner destination MAC
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. The lookup yields SN1/24, which is associated
to the overlay index IP1. The forwarding information is
derived from the RT-2 received for IP1.
. If RT-5 for SN1/24 had a GW IP=IRB-1-IP1, this GW IP will be o The IP packet destined to IPx is encapsulated with: Source
used as an overlay index that will be recursively resolved inner MAC = M3, Destination inner MAC = M1, Source outer IP
to the tunnel information received from the RT-2. (source VTEP) = DGW1 IP, Destination outer IP (destination
VTEP) = NVE1 IP.
. If the RT-5 for SN1/24 had a GW IP=0, DGW1 MAY not refer to (4) When the packet arrives at NVE1:
the RT-2.
o NVE1 will identify the IP-VRF for an IP-lookup based on the
VNI and the inner MAC DA.
o An IP lookup is performed in the routing context, where SN1
turns out to be a local subnet associated to MAC-VRF2. A
subsequent lookup in the ARP table and the MAC-VRF FIB will
provide the forwarding information for the packet in MAC-VRF2.
The implementation of the Interface-full with core-facing IRB model
is REQUIRED.
5.4.3 Interface-full IP-VRF-to-IP-VRF with unnumbered core-facing IRB
Figure 8 will be used for the description of this model. Note that
this model is similar to the one described in section 5.4.2, only
without IP addresses on the core-facing IRB interfaces.
NVE1
+------------+ DGW1
IP1+----+(MAC-VRF1) | +---------------+ +------------+
| \ (core) (core) |
|(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+
| / IRB(M1)| | IRB(M3) | |
+---+(MAC-VRF2) | | | +------------+ _+_
| +------------+ | | ( )
SN1| | VXLAN/ | ( WAN )
| NVE2 | nvGRE/ | (___)
| +------------+ | MPLS | DGW2 +
+---+(MAC-VRF2) | | | +------------+ |
| \ (core) (core) | |
|(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+
| / IRB(M2)| | IRB(M4) |
SN2+----+(MAC-VRF3) | +---------------+ +------------+
+------------+
Figure 8 Interface-full with unnumbered core-facing IRB model
In this model, the requirements are the following:
a) As in section 5.4.1 and 5.4.2, the NVEs and DGWs must provide
connectivity between hosts in SN1, SN2, IP1 and hosts seating at
the other end of the WAN.
b) As in section 5.4.2, the NVE/DGWs are connected through Ethernet
NVO tunnels terminated in core-MAC-VRF instances. The IP-VRFs use
IRB interfaces for their connectivity to the core MAC-VRFs.
c) However, each core-facing IRB has a MAC address only, and no IP
address (that is why the model refers to an 'unnumbered' core-
facing IRB). In this model, there is no need to have IP
reachability to the core-facing IRB interfaces themselves and
there is a requirement to save IP addresses on those interfaces.
d) As in section 5.4.2, the core EVI is composed of the NVE/DGW MAC-
VRFs and may contain other MAC-VRFs.
e) As in section 5.4.2, the solution must provide layer-3
connectivity for Ethernet NVO tunnels, for instance, VXLAN or
nvGRE.
This model will also make use of the RT-5 recursive resolution. EVPN
type 5 routes will advertise the IP Prefixes along with the Router's
MAC Extended Community used for the recursive lookup, whereas EVPN
RT-2 routes will advertise the MAC addresses of each core-facing IRB
interface (this time without an IP). Each NVE/DGW will advertise an
RT-5 for each of its prefixes with the following fields:
o RD as per [RFC7432].
o Eth-Tag ID=0 assuming VLAN-based service.
o IP address length and IP address, as explained in the previous
sections.
o GW IP address= SHOULD be set to 0.
o ESI=0
o MPLS label or VNI corresponding to the IP-VRF. Note that the
value SHOULD be zero since the RT-5 route requires a recursive
lookup resolution to an RT-2 route. The MPLS label or VNI to
be used when forwarding packets will be derived from the RT-
2's MPLS Label1 field.
Each RT-5 will be sent with a route-target identifying the tenant
(IP-VRF) and the Router's MAC Extended Community containing the MAC
address associated to core-facing IRB interface. This MAC address MAY
be re-used for all the IP-VRFs in the NVE.
The following example illustrates the procedure to advertise and
forward packets to SN1/24 (ipv4 prefix advertised from NVE1) for
VXLAN tunnels:
(1) NVE1 advertises the following BGP routes:
o Route type 5 (IP Prefix route) containing:
. IPL=24, IP=SN1, VNI= SHOULD be set to 0.
. GW IP= SHOULD be set to 0.
. Router's MAC Extended Community containing M1 (this will be
used for the recursive lookup to a RT-2).
. Route-target identifying the tenant (IP-VRF).
o Route type 2 (MAC route for the core-facing IRB) containing:
. ML=48, M=M1, IPL=0, VNI=10.
. A [RFC5512] BGP Encapsulation Extended Community with
Tunnel-type=VXLAN.
. Route-target identifying the tenant. This route-target MAY
be the same as the one used with the RT-5.
(2) DGW1 imports the received routes from NVE1:
o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5
route-target.
. The MAC contained in the Router's MAC Extended Community
sent along with the RT-5 (M1) will be used as the overlay
index for the recursive route resolution to the RT-2
carrying M1.
(3) When DGW1 receives a packet from the WAN with destination IPx,
where IPx belongs to SN1/24:
o A destination IP lookup is performed on the DGW1 IP-VRF
routing table. The lookup yields SN1/24, which is associated
to the overlay index M1. The forwarding information is derived
from the RT-2 received for M1.
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 = M3, Destination inner MAC = M1, Source outer IP
IP (source VTEP) = DGW1 IP, Destination outer IP (destination (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:
o NVE1 will identify the IP-VRF for an IP-lookup based on the o NVE1 will identify the IP-VRF for an IP-lookup based on the
VNI or the VNI and the inner MAC DA (this is implementation VNI and the inner MAC DA.
specific).
o An IP lookup is performed in the routing context, where SN1 o An IP lookup is performed in the routing context, where SN1
turns out to be a local subnet associated to MAC-VRF2. A turns out to be a local subnet associated to MAC-VRF2. A
subsequent lookup in the ARP table and the MAC-VRF FIB will subsequent lookup in the ARP table and the MAC-VRF FIB will
provide the forwarding information for the packet in MAC-VRF2. provide the forwarding information for the packet in MAC-VRF2.
The implementation of the Interface-full with unnumbered core-facing
IRB model is OPTIONAL.
6. Conclusions 6. Conclusions
A new EVPN route type 5 for the advertisement of IP Prefixes is An EVPN route (type 5) for the advertisement of IP Prefixes is
described in this document. This new route type has a differentiated described in this document. This new route type has a differentiated
role from the RT-2 route and addresses all the Data Center (or NVO- role from the RT-2 route and addresses all the Data Center (or NVO-
based networks in general) inter-subnet connectivity scenarios in based networks in general) inter-subnet connectivity scenarios in
which an IP Prefix advertisement is required. Using this new RT-5, an which an IP Prefix advertisement is required. Using this new RT-5, an
IP Prefix may be advertised along with an overlay index that can be a IP Prefix may be advertised along with an overlay index that can be a
GW IP address or an ESI, or without an overlay index, in which case GW IP address, a MAC or an ESI, or without an overlay index, in which
the BGP next-hop will point at the egress NVE and the MAC in the case the BGP next-hop will point at the egress NVE and the MAC in the
Router's MAC Extended Community will provide the inner MAC Router's MAC Extended Community will provide the inner MAC
destination address to be used. As discussed throughout the document, destination address to be used. As discussed throughout the document,
the EVPN RT-2 does not meet the requirements for all the DC use the EVPN RT-2 does not meet the requirements for all the DC use
cases, therefore this EVPN route type is required. cases, therefore this EVPN route type 5 is required.
The EVPN route type 5 decouples the IP Prefix advertisements from the The EVPN route type 5 decouples the IP Prefix advertisements from the
MAC/IP route advertisements in EVPN, hence: MAC/IP route advertisements in EVPN, hence:
a) Allows the clean and clear advertisements of ipv4 or ipv6 prefixes a) Allows the clean and clear advertisements of ipv4 or ipv6 prefixes
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 [RFC7432]
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 overlay indexes: overlay IP address, overlay different types of overlay indexes: overlay IP address, overlay
ESI, underlay IP next-hops, etc. MAC addresses, overlay 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].
8. Security Considerations 8. Security Considerations
The security considerations discussed in [RFC7432] apply to this
document.
9. IANA Considerations 9. IANA Considerations
This document requests the allocation of value 5 in the "EVPN Route This document requests the allocation of value 5 in the "EVPN Route
Types" registry defined by [RFC7432] and modification of the registry Types" registry defined by [RFC7432] and modification of the registry
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
skipping to change at page 23, line 30 skipping to change at page 30, line 22
<http://www.rfc-editor.org/info/rfc4364>. <http://www.rfc-editor.org/info/rfc4364>.
[RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc- VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
editor.org/info/rfc7432>. 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-01.txt, Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-04.txt,
work in progress, February, 2015 work in progress, June, 2016
[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-01.txt, work in
progress, November, 2014 progress, October, 2015
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Mukul Katiyar and Senthil Sathappan The authors would like to thank Mukul Katiyar for their valuable
for their valuable feedback and contributions. The following people feedback and contributions. The following people also helped
also helped improving this document with their feedback: Tony improving this document with their feedback: Tony Przygienda and
Przygienda and Thomas Morin. Thomas Morin.
12. Contributors 12. Contributors
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
co-authors have also contributed to this document: co-authors have also contributed to this document:
Senthil Sathappan
Florin Balus Florin Balus
13. Authors' Addresses 13. Authors' Addresses
Jorge Rabadan Jorge Rabadan (Editor)
Alcatel-Lucent Nokia
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@nokia.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@nokia.com
Aldrin Isaac Aldrin Isaac
Bloomberg Juniper
Email: aisaac71@bloomberg.net Email: aisaac@juniper.net
Senad Palislamovic Senad Palislamovic
Alcatel-Lucent Nokia
Email: senad.palislamovic@alcatel-lucent.com Email: senad.palislamovic@nokia.com
John E. Drake John E. Drake
Juniper Networks Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Wen Lin Wen Lin
Juniper Networks Juniper
Email: wlin@juniper.net Email: wlin@juniper.net
 End of changes. 75 change blocks. 
161 lines changed or deleted 457 lines changed or added

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