< draft-ietf-bess-evpn-prefix-advertisement-04.txt | draft-ietf-bess-evpn-prefix-advertisement-05.txt > | |||
---|---|---|---|---|
skipping to change at page 1, line 14 ¶ | skipping to change at page 1, line 14 ¶ | |||
Internet Draft W. Henderickx | Internet Draft W. Henderickx | |||
Intended status: Standards Track Nokia | Intended status: Standards Track Nokia | |||
J. Drake | J. Drake | |||
W. Lin | W. Lin | |||
Juniper | Juniper | |||
A. Sajassi | A. Sajassi | |||
Cisco | Cisco | |||
Expires: August 17, 2017 February 13, 2017 | Expires: September 23, 2017 March 22, 2017 | |||
IP Prefix Advertisement in EVPN | IP Prefix Advertisement in EVPN | |||
draft-ietf-bess-evpn-prefix-advertisement-04 | draft-ietf-bess-evpn-prefix-advertisement-05 | |||
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 some | |||
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 do not necessarily participate in dynamic | |||
This document defines a new EVPN route type for the advertisement of | routing protocols. This document defines a new EVPN route type for | |||
IP Prefixes and explains some use-case examples where this new route- | the advertisement of IP Prefixes and explains some use-case examples | |||
type is used. | where this new route-type is used. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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. | |||
skipping to change at page 2, line 7 ¶ | skipping to change at page 2, line 7 ¶ | |||
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 August 17, 2017. | This Internet-Draft will expire on September 22, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 30 ¶ | skipping to change at page 2, line 30 ¶ | |||
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 . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 8 | 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 | 3.2 Overlay Indexes and Recursive Lookup Resolution . . . . . . 10 | |||
5. IP Prefix overlay index use-cases . . . . . . . . . . . . . . . 11 | 4. IP Prefix Overlay Index use-cases . . . . . . . . . . . . . . . 11 | |||
5.1 TS IP address overlay index use-case . . . . . . . . . . . . 11 | 4.1 TS IP address Overlay Index use-case . . . . . . . . . . . . 11 | |||
5.2 Floating IP overlay index use-case . . . . . . . . . . . . . 14 | 4.2 Floating IP Overlay Index use-case . . . . . . . . . . . . . 14 | |||
5.3 ESI overlay index ("Bump in the wire") use-case . . . . . . 15 | 4.3 Bump-in-the-wire use-case . . . . . . . . . . . . . . . . . 16 | |||
5.4 IP-VRF-to-IP-VRF model . . . . . . . . . . . . . . . . . . . 18 | 4.4 IP-VRF-to-IP-VRF model . . . . . . . . . . . . . . . . . . . 18 | |||
5.4.1 Interface-less IP-VRF-to-IP-VRF model . . . . . . . . . 19 | 4.4.1 Interface-less IP-VRF-to-IP-VRF model . . . . . . . . . 19 | |||
5.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB . . 22 | 4.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB . . 22 | |||
5.4.3 Interface-full IP-VRF-to-IP-VRF with unnumbered | 4.4.3 Interface-full IP-VRF-to-IP-VRF with unnumbered | |||
core-facing IRB . . . . . . . . . . . . . . . . . . . . 24 | core-facing IRB . . . . . . . . . . . . . . . . . . . . 25 | |||
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
7. Conventions used in this document . . . . . . . . . . . . . . . 28 | 6. Conventions used in this document . . . . . . . . . . . . . . . 29 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 28 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 29 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 29 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
10.1 Normative References . . . . . . . . . . . . . . . . . . . 29 | 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 | |||
10.2 Informative References . . . . . . . . . . . . . . . . . . 29 | 9.2 Informative References . . . . . . . . . . . . . . . . . . . 30 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 | 12. 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 27 ¶ | skipping to change at page 3, line 27 ¶ | |||
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 | AC: Attachment Circuit | |||
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, | ||||
and identifies a pointer yielded by the IP route lookup at the | ||||
routing context importing the route. An overlay index always needs a | ||||
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 | ||||
packets. | ||||
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 | ||||
used at the receiving NVE as the VXLAN destination VTEP or NVGRE | ||||
destination end-point. | ||||
Ethernet NVO tunnel: it refers to Network Virtualization Overlay | Ethernet NVO tunnel: it refers to Network Virtualization Overlay | |||
tunnels with Ethernet payload. Examples of this type of tunnels are | tunnels with Ethernet payload. Examples of this type of tunnels are | |||
VXLAN or nvGRE. | VXLAN or nvGRE. | |||
IP NVO tunnel: it refers to Network Virtualization Overlay tunnels | IP NVO tunnel: it refers to Network Virtualization Overlay tunnels | |||
with IP payload (no MAC header in the payload). Examples of IP NVO | with IP payload (no MAC header in the payload). | |||
tunnels are VXLAN GPE or MPLSoGRE (both with IP payload). | ||||
MAC-VRF: A Virtual Routing and Forwarding table for Media Access | ||||
Control (MAC) addresses on an NVE/PE, as per [RFC7432]. | ||||
IP-VRF: A VPN Routing and Forwarding tables for IP addresses on an | ||||
NVE/PE, similar to the VRF concept defined in [RFC4364], however, in | ||||
this document, the IP routes are always populated by the EVPN address | ||||
family. | ||||
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 | |||
aggregation in the IP-VRF tables, as opposed to program individual | aggregation in the IP-VRF tables, as opposed to program individual | |||
host routes. This document complements the scenarios described in | host routes. This document complements the scenarios described in | |||
[EVPN-INTERSUBNET] and defines how EVPN may be used to advertise IP | [EVPN-INTERSUBNET] and defines how EVPN may be used to advertise IP | |||
Prefixes. | Prefixes. Interoperability between EVPN and L3VPN [RFC4364] IP Prefix | |||
routes is out of the scope of this document. | ||||
Section 2.1 describes the inter-subnet connectivity requirements in | Section 2.1 describes the inter-subnet connectivity requirements in | |||
Data Centers. Section 2.2 explains why a new EVPN route type is | Data Centers. Section 2.2 explains why a new EVPN route type is | |||
required for IP Prefix advertisements. Once the need for a new EVPN | required for IP Prefix advertisements. Once the need for a new EVPN | |||
route type is justified, sections 3, 4 and 5 will describe this route | route type is justified, sections 3, 4 and 5 will describe this route | |||
type and how it is used in some specific use cases. | type and how it is used in some specific use cases. | |||
2.1 Inter-subnet connectivity requirements in Data Centers | 2.1 Inter-subnet connectivity requirements in Data Centers | |||
[RFC7432] is used as the control plane for a Network Virtualization | [RFC7432] is used as the control plane for a Network Virtualization | |||
Overlay (NVO3) solution in Data Centers (DC), where Network | Overlay (NVO3) solution in Data Centers (DC), where Network | |||
Virtualization Edge (NVE) devices can be located in Hypervisors or | Virtualization Edge (NVE) devices can be located in Hypervisors or | |||
TORs, as described in [EVPN-OVERLAY]. | TORs, as described in [EVPN-OVERLAY]. | |||
If we use the term Tenant System (TS) to designate a physical or | If we use the term Tenant System (TS) to designate a physical or | |||
virtual system identified by MAC and IP addresses, and connected to | virtual system identified by MAC and IP addresses, and connected to a | |||
an EVPN instance, the following considerations apply: | MAC-VRF by an Attachment Circuit, the following considerations apply: | |||
o The Tenant Systems may be Virtual Machines (VMs) that generate | o The Tenant Systems may be Virtual Machines (VMs) that generate | |||
traffic from their own MAC and IP. | traffic from their own MAC and IP. | |||
o The Tenant Systems may be Virtual Appliance entities (VAs) that | o The Tenant Systems may be Virtual Appliance entities (VAs) that | |||
forward traffic to/from IP addresses of different End Devices | forward traffic to/from IP addresses of different End Devices | |||
seating behind them. | sitting behind them. | |||
o These VAs can be firewalls, load balancers, NAT devices, other | o These VAs can be firewalls, load balancers, NAT devices, other | |||
appliances or virtual gateways with virtual routing instances. | appliances or virtual gateways with virtual routing instances. | |||
o These VAs do not have their own routing protocols and hence | o These VAs do not necessarily participate in dynamic routing | |||
rely on the EVPN NVEs to advertise the routes on their behalf. | protocols and hence rely on the EVPN NVEs to advertise the | |||
routes on their behalf. | ||||
o In all these cases, the VA will forward traffic to the Data | o In all these cases, the VA will forward traffic to other TSes | |||
Center using its own source MAC but the source IP will be the | using its own source MAC but the source IP will be the one | |||
one associated to the End Device seating behind or a | associated to the End Device sitting behind or a translated IP | |||
translated IP address (part of a public NAT pool) if the VA is | address (part of a public NAT pool) if the VA is performing | |||
performing NAT. | NAT. | |||
o Note that the same IP address could exist behind two of these | o Note that the same IP address could exist behind two of these | |||
TS. One example of this would be certain appliance resiliency | TS. One example of this would be certain appliance resiliency | |||
mechanisms, where a virtual IP or floating IP can be owned by | mechanisms, where a virtual IP or floating IP can be owned by | |||
one of the two VAs running the resiliency protocol (the master | one of the two VAs running the resiliency protocol (the master | |||
VA). VRRP is one particular example of this. Another example | VA). VRRP is one particular example of this. Another example | |||
is multi-homed subnets, i.e. the same subnet is connected to | is multi-homed subnets, i.e. the same subnet is connected to | |||
two VAs. | two VAs. | |||
o Although these VAs provide IP connectivity to VMs and subnets | o Although these VAs provide IP connectivity to VMs and subnets | |||
behind them, they do not always have their own IP interface | behind them, they do not always have their own IP interface | |||
connected to the EVPN NVE, e.g. layer-2 firewalls are examples | connected to the EVPN NVE, e.g. layer-2 firewalls are examples | |||
of VAs not supporting IP interfaces. | of VAs not supporting IP interfaces. | |||
The following figure illustrates some of the examples described | The Figure 1 illustrates some of the examples described above. | |||
above. | ||||
NVE1 | NVE1 | |||
+-----------+ | +-----------+ | |||
TS1(VM)--|(MAC-VRF10)|-----+ | TS1(VM)--|(MAC-VRF10)|-----+ | |||
IP1/M1 +-----------+ | DGW1 | IP1/M1 +-----------+ | DGW1 | |||
+---------+ +-------------+ | +---------+ +-------------+ | |||
| |----|(MAC-VRF10) | | | |----|(MAC-VRF10) | | |||
SN1---+ NVE2 | | | IRB1\ | | SN1---+ NVE2 | | | IRB1\ | | |||
| +-----------+ | | | (IP-VRF)|---+ | | +-----------+ | | | (IP-VRF)|---+ | |||
SN2---TS2(VA)--|(MAC-VRF10)|-| | +-------------+ _|_ | SN2---TS2(VA)--|(MAC-VRF10)|-| | +-------------+ _|_ | |||
| IP2/M2 +-----------+ | VXLAN/ | ( ) | | IP2/M2 +-----------+ | VXLAN/ | ( ) | |||
skipping to change at page 6, line 12 ¶ | skipping to change at page 6, line 7 ¶ | |||
NVE1, NVE2, NVE3, NVE4, NVE5, DGW1 and DGW2 share the same EVI for a | NVE1, NVE2, NVE3, NVE4, NVE5, DGW1 and DGW2 share the same EVI for a | |||
particular tenant. EVI-10 is comprised of the collection of MAC-VRF10 | particular tenant. EVI-10 is comprised of the collection of MAC-VRF10 | |||
instances defined in all the NVEs. All the hosts connected to EVI-10 | instances defined in all the NVEs. All the hosts connected to EVI-10 | |||
belong to the same IP subnet. The hosts connected to EVI-10 are | belong to the same IP subnet. The hosts connected to EVI-10 are | |||
listed below: | listed below: | |||
o TS1 is a VM that generates/receives traffic from/to IP1, where | o TS1 is a VM that generates/receives traffic from/to IP1, where | |||
IP1 belongs to the EVI-10 subnet. | IP1 belongs to the EVI-10 subnet. | |||
o TS2 and TS3 are Virtual Appliances (VA) that generate/receive | o TS2 and TS3 are Virtual Appliances (VA) that generate/receive | |||
traffic from/to the subnets and hosts seating behind them | traffic from/to the subnets and hosts sitting behind them | |||
(SN1, SN2, SN3, IP4 and IP5). Their IP addresses (IP2 and IP3) | (SN1, SN2, SN3, IP4 and IP5). Their IP addresses (IP2 and IP3) | |||
belong to the EVI-10 subnet and they can also generate/receive | belong to the EVI-10 subnet and they can also generate/receive | |||
traffic. When these VAs receive packets destined to their own | traffic. When these VAs receive packets destined to their own | |||
MAC addresses (M2 and M3) they will route the packets to the | MAC addresses (M2 and M3) they will route the packets to the | |||
proper subnet or host. These VAs do not support routing | proper subnet or host. These VAs do not support routing | |||
protocols to advertise the subnets connected to them and can | protocols to advertise the subnets connected to them and can | |||
move to a different server and NVE when the Cloud Management | move to a different server and NVE when the Cloud Management | |||
System decides to do so. These VAs may also support redundancy | System decides to do so. These VAs may also support redundancy | |||
mechanisms for some subnets, similar to VRRP, where a floating | mechanisms for some subnets, similar to VRRP, where a floating | |||
IP is owned by the master VA and only the master VA forwards | IP is owned by the master VA and only the master VA forwards | |||
skipping to change at page 6, line 42 ¶ | skipping to change at page 6, line 37 ¶ | |||
the DC or at the other end of the WAN). | the DC or at the other end of the WAN). | |||
o TS4 is a layer-2 VA that provides connectivity to subnets SN5, | o TS4 is a layer-2 VA that provides connectivity to subnets SN5, | |||
SN6 and SN7, but does not have an IP address itself in the | SN6 and SN7, but does not have an IP address itself in the | |||
EVI-10. TS4 is connected to a physical port on NVE5 assigned | EVI-10. TS4 is connected to a physical port on NVE5 assigned | |||
to Ethernet Segment Identifier 4. | to Ethernet Segment Identifier 4. | |||
All the above DC use cases require inter-subnet forwarding and | All the above DC use cases require inter-subnet forwarding and | |||
therefore the individual host routes and subnets: | therefore the individual host routes and subnets: | |||
a) MUST be advertised from the NVEs (since VAs and VMs do not run | a) MUST be advertised from the NVEs (since VAs and VMs do not | |||
routing protocols) and | participate in dynamic routing protocols) and | |||
b) MAY be associated to an overlay index that can be a VA IP address, | b) MAY be associated to an Overlay Index that can be a VA IP address, | |||
a floating IP address or an ESI. | a floating IP address or an ESI. An Overlay Index is a next-hop | |||
that requires a recursive resolution and it is described in | ||||
section 3.2. | ||||
2.2 The requirement for a new EVPN route type | 2.2 The requirement for a new EVPN route type | |||
[RFC7432] defines a MAC/IP route (also referred as RT-2) where a MAC | [RFC7432] defines a MAC/IP route (also referred as RT-2) where a MAC | |||
address can be advertised together with an IP address length (IPL) | address can be advertised together with an IP address length (IPL) | |||
and IP address (IP). While a variable IPL might have been used to | and IP address (IP). While a variable IPL might have been used to | |||
indicate the presence of an IP prefix in a route type 2, there are | indicate the presence of an IP prefix in a route type 2, there are | |||
several specific use cases in which using this route type to deliver | several specific use cases in which using this route type to deliver | |||
IP Prefixes is not suitable. | IP Prefixes is not suitable. | |||
One example of such use cases is the "floating IP" example described | One example of such use cases is the "floating IP" example described | |||
in section 2.1. In this example we need to decouple the advertisement | in section 2.1. In this example we need to decouple the advertisement | |||
of the prefixes from the advertisement of the floating IP (vIP23 in | of the prefixes from the advertisement of the floating IP (vIP23 in | |||
figure 1) and MAC associated to it, otherwise the solution gets | Figure 1) and MAC associated to it, otherwise the solution gets | |||
highly inefficient and does not scale. | highly inefficient and does not scale. | |||
E.g.: if we are advertising 1k prefixes from M2 (using RT-2) and the | E.g.: if we are advertising 1k prefixes from M2 (using RT-2) and the | |||
floating IP owner changes from M2 to M3, we would need to withdraw 1k | floating IP owner changes from M2 to M3, we would need to withdraw 1k | |||
routes from M2 and re-advertise 1k routes from M3. However if we use | routes from M2 and re-advertise 1k routes from M3. However if we use | |||
a separate route type, we can advertise the 1k routes associated to | a separate route type, we can advertise the 1k routes associated to | |||
the floating IP address (vIP23) and only one RT-2 for advertising the | the floating IP address (vIP23) and only one RT-2 for advertising the | |||
ownership of the floating IP, i.e. vIP23 and M2 in the route type 2. | ownership of the floating IP, i.e. vIP23 and M2 in the route type 2. | |||
When the floating IP owner changes from M2 to M3, a single RT-2 | When the floating IP owner changes from M2 to M3, a single RT-2 | |||
withdraw/update is required to indicate the change. The remote DGW | withdraw/update is required to indicate the change. The remote DGW | |||
will not change any of the 1k prefixes associated to vIP23, but will | will not change any of the 1k prefixes associated to vIP23, but will | |||
only update the ARP resolution entry for vIP23 (now pointing at M3). | only update the ARP resolution entry for vIP23 (now pointing at M3). | |||
Other reasons to decouple the IP Prefix advertisement from the MAC/IP | Other reasons to decouple the IP Prefix advertisement from the MAC/IP | |||
route are listed below: | route are listed below: | |||
o Clean identification, operation of troubleshooting of IP | o Clean identification, operation and troubleshooting of IP | |||
Prefixes, not subject to interpretation and independent of the | Prefixes, independent of and not subject to the interpretation | |||
IPL and the IP value. E.g.: a default IP route 0.0.0.0/0 must | of the IPL and the IP value. E.g.: a default IP route | |||
always be easily and clearly distinguished from the absence of | 0.0.0.0/0 must always be easily and clearly distinguished from | |||
IP information. | the absence of IP information. | |||
o MAC address information must not be compared by BGP when | o MAC address information must not be compared by BGP when | |||
selecting two IP Prefix routes. If IP Prefixes were to be | choosing which of several IP Prefix routes to install in a | |||
advertised using MAC/IP routes, the MAC information would | given IP-VRF. If IP Prefixes were to be advertised using | |||
always be present and part of the route key. | MAC/IP routes, the MAC information would always be present and | |||
part of the route key. | ||||
o IP Prefix routes must not be subject to MAC/IP route | ||||
procedures such as MAC mobility or aliasing. Prefixes | ||||
advertised from two different ESIs do not mean mobility; MACs | ||||
advertised from two different ESIs do mean mobility. Similarly | ||||
load balancing for IP prefixes is achieved through IP | ||||
mechanisms such as ECMP, and not through MAC route mechanisms | ||||
such as aliasing. | ||||
o NVEs that do not require processing IP Prefixes must have an | ||||
easy way to identify an update with an IP Prefix and ignore | ||||
it, rather than processing the MAC/IP route to find out only | ||||
later that it carries a Prefix that must be ignored. | ||||
The following sections describe how EVPN is extended with a new route | The following sections describe how EVPN is extended with a new route | |||
type for the advertisement of IP prefixes and how this route is used | type for the advertisement of IP prefixes and how this route is used | |||
to address the current and future inter-subnet connectivity | to address the current and future inter-subnet connectivity | |||
requirements existing in the Data Center. | requirements existing in the Data Center. | |||
3. The BGP EVPN IP Prefix route | 3. The BGP EVPN IP Prefix route | |||
The current BGP EVPN NLRI as defined in [RFC7432] is shown below: | The current BGP EVPN NLRI as defined in [RFC7432] is shown below: | |||
+-----------------------------------+ | +-----------------------------------+ | |||
| Route Type (1 octet) | | | Route Type (1 octet) | | |||
+-----------------------------------+ | +-----------------------------------+ | |||
| Length (1 octet) | | | Length (1 octet) | | |||
+-----------------------------------+ | +-----------------------------------+ | |||
| Route Type specific (variable) | | | Route Type specific (variable) | | |||
+-----------------------------------+ | +-----------------------------------+ | |||
Where the route type field can contain one of the following specific | Where the route type field can contain one of the following specific | |||
values: | values (refer to the IANA "EVPN Route Types registry): | |||
+ 1 - Ethernet Auto-Discovery (A-D) route | + 1 - Ethernet Auto-Discovery (A-D) route | |||
+ 2 - MAC/IP advertisement route | + 2 - MAC/IP advertisement route | |||
+ 3 - Inclusive Multicast Route | + 3 - Inclusive Multicast Route | |||
+ 4 - Ethernet Segment Route | + 4 - Ethernet Segment Route | |||
This document defines an additional route type that will be used for | This document defines an additional route type that IANA has added to | |||
the advertisement of IP Prefixes: | the registry, and will be used for the advertisement of IP Prefixes: | |||
+ 5 - IP Prefix Route | + 5 - IP Prefix Route | |||
The support for this new route type is OPTIONAL. | The support for this new route type is OPTIONAL. | |||
Since this new route type is OPTIONAL, an implementation not | Since this new route type is OPTIONAL, an implementation not | |||
supporting it MUST ignore the route, based on the unknown route type | supporting it MUST ignore the route, based on the unknown route type | |||
value. | value, as specified by Section 5.4 in [RFC7606]. | |||
The detailed encoding of this route and associated procedures are | The detailed encoding of this route and associated procedures are | |||
described in the following sections. | described in the following sections. | |||
3.1 IP Prefix Route encoding | 3.1 IP Prefix Route encoding | |||
An IP Prefix advertisement route NLRI consists of the following | An IP Prefix advertisement route NLRI consists of the following | |||
fields: | fields: | |||
+---------------------------------------+ | +---------------------------------------+ | |||
skipping to change at page 9, line 27 ¶ | skipping to change at page 9, line 27 ¶ | |||
+---------------------------------------+ | +---------------------------------------+ | |||
| MPLS Label (3 octets) | | | MPLS Label (3 octets) | | |||
+---------------------------------------+ | +---------------------------------------+ | |||
Where: | Where: | |||
o RD, Ethernet Tag ID and MPLS Label fields will be used as | o RD, Ethernet Tag ID and MPLS Label fields will be used as | |||
defined in [RFC7432] and [EVPN-OVERLAY]. | defined in [RFC7432] and [EVPN-OVERLAY]. | |||
o The Ethernet Segment Identifier will be a non-zero 10-byte | o The Ethernet Segment Identifier will be a non-zero 10-byte | |||
identifier if the ESI is used as an overlay index. It will be | identifier if the ESI is used as an overlay index (see the | |||
zero otherwise. | definition of overlay index in section 3.2). It will be 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, and specifies | |||
the number of bits in the Prefix. | ||||
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). | |||
The size of this field does not depend on the value of the IP | ||||
Prefix Length field. | ||||
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 SHOULD be zero if it is not used as | Prefixes. The GW IP field SHOULD be zero if it is not used as | |||
an overlay index. | an overlay index. Refer to section 3.2 for the definition and | |||
use of the Overlay Index. | ||||
o The MPLS Label field is encoded as 3 octets, where the high- | o The MPLS Label field is encoded as 3 octets, where the high- | |||
order 20 bits contain the label value. The value SHOULD be | order 20 bits contain the label value. The value SHOULD be | |||
null when the IP Prefix route is used for a recursive lookup | null (zero) when the IP Prefix route is used for a recursive | |||
resolution. | lookup resolution. If the received MPLS Label value is not | |||
null, the route MUST still be used for recursive lookup | ||||
resolution if the local policy instructs the ingress NVE to do | ||||
so. | ||||
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. | |||
The route will contain a single overlay index at most, i.e. if the | 3.2 Overlay Indexes and Recursive Lookup Resolution | |||
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- | RT-5 routes support recursive lookup resolution through the use of | |||
cases described in this document and the corresponding coding of the | Overlay Indexes as follows: | |||
o An Overlay Index can be an ESI, IP address (in the address | ||||
space of the tenant) or MAC address and it is used by an NVE | ||||
as the next-hop for a given IP Prefix. An Overlay Index always | ||||
needs a 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 packets. The egress NVE may not be the | ||||
same NVE that originated the RT-5. | ||||
o The Overlay Index is indicated along with the RT-5 in the ESI | ||||
field, GW IP field or Router's MAC Extended Community, | ||||
depending on whether the IP Prefix next-hop is an ESI, IP | ||||
address or MAC address in the tenant space. The Overlay Index | ||||
for a given IP Prefix is set by local policy (typically | ||||
managed by the Cloud Management System). | ||||
o In order to enable the recursive lookup resolution at the | ||||
ingress NVE, the egress NVE that owns the Overlay Index must | ||||
advertise the location of the Overlay Index. For instance, if | ||||
the IP Prefix originating NVE sends an RT-5 with ESI-1 as | ||||
Overlay Index, then the ingress NVE will expect an RT-1 (Auto- | ||||
Discovery per-EVI route) with ESI-1 to be received from the | ||||
egress NVE. If the Overlay Index is encoded in the GW IP field | ||||
or the Router's MAC Extended Community, the ingress NVE will | ||||
expect an RT-2 (MAC/IP route) from the egress NVE so that the | ||||
Overlay Index can be resolved. | ||||
o If the ESI field is different than zero, the GW IP field will | ||||
be zero, and vice versa. A route containing a non-zero GW IP | ||||
and a non-zero ESI will be treated as-withdraw. | ||||
The use of Overlay Indexes decouples the origination of the RT-5 from | ||||
the desired egress NVE for the IP Prefix. The indirection provided by | ||||
the Overlay Index and its recursive lookup resolution is required to | ||||
achieve fast convergence in case of a failure of the object | ||||
represented by the Overlay Index. For instance: in Figure 1, let's | ||||
assume NVE2/NVE3 advertise 1k RT-5 routes associated to the floating | ||||
IP address (GWIP=vIP23) and NVE2 advertises an RT-2 claiming the | ||||
ownership of the floating IP, i.e. NVE2 encodes vIP23 and M2 in the | ||||
RT-2. When the floating IP owner changes from M2 to M3, a single RT-2 | ||||
withdraw/update is required to indicate the change. The remote DGW | ||||
will not change any of the 1k prefixes associated to vIP23, but will | ||||
only update the ARP resolution entry for vIP23 (now pointing at M3). | ||||
The following table shows the different inter-subnet use-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 the | |||
which egress NVE to forward the packets. | 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 or MAC | | |||
| IP-VRF-to-IP-VRF | Overlay GW IP, MAC or N/A | | | IP-VRF-to-IP-VRF | Overlay GW IP, MAC or N/A | | |||
+----------------------------+--------------------------------------+ | +----------------------------+--------------------------------------+ | |||
4. Benefits of using the EVPN IP Prefix route | The above use-cases are representative of the different Overlay | |||
Indexes supported by RT-5 (GW IP, ESI, MAC or N/A). Any other use- | ||||
This section clarifies the different functions accomplished by the | case using a given Overlay Index, SHOULD follow the procedures | |||
EVPN RT-2 and RT-5 routes, and provides a list of benefits derived | described in this document for the same Overlay Index. | |||
from using a separate route type for the advertisement of IP Prefixes | ||||
in EVPN. | ||||
[RFC7432] describes the content of the BGP EVPN RT-2 specific NLRI, | ||||
i.e. MAC/IP Advertisement Route, where the IP address length (IPL) | ||||
and IP address (IP) of a specific advertised MAC are encoded. The | ||||
subject of the MAC advertisement route is the MAC address (M) and MAC | ||||
address length (ML) encoded in the route. The MAC mobility and other | ||||
procedures are defined around that MAC address. The IP address | ||||
information carries the host IP address required for the ARP | ||||
resolution of the MAC according to [RFC7432] and the host route to be | ||||
programmed in the IP-VRF [EVPN-INTERSUBNET]. | ||||
The BGP EVPN route type 5 defined in this document, i.e. IP Prefix | ||||
Advertisement route, decouples the advertisement of IP prefixes from | ||||
the advertisement of any MAC address related to it. This brings some | ||||
major benefits to NVO-based networks where certain inter-subnet | ||||
forwarding scenarios are required. Some of those benefits are: | ||||
a) Upon receiving a route type 2 or type 5, an egress NVE can easily | ||||
distinguish MACs and IPs from IP Prefixes. E.g. an IP prefix with | ||||
IPL=32 being advertised from two different ingress NVEs (as RT-5) | ||||
can be identified as such and be imported in the designated | ||||
routing context as two ECMP routes, as opposed to two MACs | ||||
competing for the same IP. | ||||
b) Similarly, upon receiving a route, an ingress NVE not supporting | ||||
processing of IP Prefixes can easily ignore the update, based on | ||||
the route type. | ||||
c) A MAC route includes the ML, M, IPL and IP in the route key that | ||||
is used by BGP to compare routes, whereas for IP Prefix routes, | ||||
only IPL and IP (as well as Ethernet Tag ID) are part of the route | ||||
key. Advertised IP Prefixes are imported into the designated | ||||
routing context, where there is no MAC information associated to | ||||
IP routes. In the example illustrated in figure 1, subnet SN1 | ||||
should be advertised by NVE2 and NVE3 and interpreted by DGW1 as | ||||
the same route coming from two different next-hops, regardless of | ||||
the MAC address associated to TS2 or TS3. This is easily | ||||
accomplished in the RT-5 by including only the IP information in | ||||
the route key. | ||||
d) By decoupling the MAC from the IP Prefix advertisement procedures, | ||||
we can leave the IP Prefix advertisements out of the MAC mobility | ||||
procedures defined in [RFC7432] for MACs. In addition, this allows | ||||
us to have an indirection mechanism for IP Prefixes advertised | ||||
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 | ||||
all those prefixes in RT-5 routes associated to the overlay index | ||||
IP2. Should TS2 move to a different NVE, a single MAC/IP | ||||
advertisement route withdraw for the M2/IP2 route from NVE2 will | ||||
invalidate the 1,000 prefixes, as opposed to have to wait for each | ||||
individual prefix to be withdrawn. This may be easily accomplished | ||||
by using IP Prefix routes that are not tied to a MAC address, and | ||||
use a different MAC/IP route to advertise the location and | ||||
resolution of the overlay index to a MAC address. | ||||
5. IP Prefix overlay index use-cases | 4. IP Prefix Overlay Index use-cases | |||
The IP Prefix route can use a GW IP or an ESI as an overlay index as | This section describes some use-cases for the Overlay Index types. | |||
well as no overlay index whatsoever. This section describes some use- | ||||
cases for these index types. | ||||
5.1 TS IP address overlay index use-case | 4.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 sitting 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)|---+ | |||
| | +-------------+ _|_ | | | +-------------+ _|_ | |||
| VXLAN/ | ( ) | | VXLAN/ | ( ) | |||
| nvGRE | DGW2 ( WAN ) | | nvGRE | DGW2 ( WAN ) | |||
SN1---+ NVE3 | | +-------------+ (___) | SN1---+ NVE3 | | +-------------+ (___) | |||
| IP3/M3 +-----------+ | |----|(MAC-VRF10) | | | | IP3/M3 +-----------+ | |----|(MAC-VRF10) | | | |||
SN3---TS3(VA)--|(MAC-VRF10)|-| | | IRB2\ | | | SN3---TS3(VA)--|(MAC-VRF10)|-| | | IRB2\ | | | |||
| +-----------+ +---------+ | (IP-VRF)|---+ | | +-----------+ +---------+ | (IP-VRF)|---+ | |||
IP5---+ +-------------+ | IP5---+ +-------------+ | |||
Figure 2 TS IP address use-case | Figure 2 TS IP address use-case | |||
An example of inter-subnet forwarding between subnet SN1/24 and a | An example of inter-subnet forwarding between subnet SN1/24 and a | |||
subnet seating in the WAN is described below. NVE2, NVE3, DGW1 and | subnet sitting in the WAN is described below. NVE2, NVE3, DGW1 and | |||
DGW2 are running BGP EVPN. TS2 and TS3 do not support routing | DGW2 are running BGP EVPN. TS2 and TS3 do not participate in dynamic | |||
protocols, only a static route to forward the traffic to the WAN. | routing protocols, and they only have a static route to forward the | |||
traffic to the WAN. | ||||
In this case, a GW IP is used as an Overlay Index. Although a | ||||
different Overlay Index type could have been used, this use-case | ||||
assumes that the operator knows the VA's IP addresses beforehand, | ||||
whereas the VA's MAC address is unknown and the VA's ESI is zero. | ||||
Because of this, the GW IP is the suitable Overlay Index to be used | ||||
with the RT-5s. The NVEs know the GW IP to be used for a given Prefix | ||||
by policy. | ||||
(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. The MAC and IP addresses may be | |||
learned via ARP-snooping (ND-snooping if IPv6). | ||||
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. | ESI=0, GW IP address=IP2. The prefix and GW IP are learned by | |||
policy. | ||||
(2) NVE3 advertises the following BGP routes on behalf of TS3: | (2) Similarly, 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. | ESI=0, GW IP address=IP3. | |||
(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 and VNI from the MPLS Label1 field. IP2 - | |||
Label1 field. IP2 - M2 is added to the ARP table. | 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 overlay index IP2 pointing at the local MAC-VRF10. | VRF with Overlay Index IP2 pointing at the local MAC-VRF10. | |||
Should ECMP be enabled in the IP-VRF, SN1/24 would also be | Should ECMP be enabled in the IP-VRF, SN1/24 would also be | |||
added to 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 overlay index=IP2 is found. Since IP2 is an | routing table and Overlay Index=IP2 is found. Since IP2 is an | |||
overlay index a recursive route resolution is required for | Overlay Index a recursive route resolution is required for | |||
IP2. | 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. | |||
skipping to change at page 13, line 46 ¶ | skipping to change at page 14, line 10 ¶ | |||
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 overlay index. There is an indirection for e.g. SN1/24, which | as Overlay Index. There is an indirection for e.g. SN1/24, which | |||
still points at overlay index IP2 in the routing table, but IP2 | still points at Overlay Index IP2 in the routing table, but IP2 | |||
will be simply resolved to a different tunnel, based on the | will be simply resolved to a different tunnel, based on the | |||
outcome of the MAC mobility procedures for the MAC/IP route | outcome of the MAC mobility procedures for the MAC/IP route | |||
IP2/M2. | 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 overlay index use-case | 4.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 | upstream floating IP - owned by the active TS - is used as the | |||
overlay index to get to some subnets behind. This redundancy mode, | Overlay Index to get to some subnets behind. This redundancy mode, | |||
already introduced in section 2.1 and 2.2, is illustrated in Figure | already introduced in section 2.1 and 2.2, is illustrated in Figure | |||
3. | 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 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 use-case, a GW IP is used as an Overlay Index for the same | |||
reasons as in 4.1. However, this GW IP is a floating IP that belongs | ||||
to the active TS. 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). The MAC | |||
and IP addresses may be learned via ARP-snooping. | ||||
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. | ESI=0, GW IP address=IP23. The prefix and GW IP are learned by | |||
policy. | ||||
(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. | ESI=0, GW IP address=IP23. The prefix and GW IP are learned by | |||
policy. | ||||
(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 | |||
index IP23 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 overlay index=IP23 is found. Since IP23 is | routing table and Overlay Index=IP23 is found. Since IP23 is | |||
an 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 15, line 43 ¶ | skipping to change at page 16, line 11 ¶ | |||
MAC-VRF10 context is identified for a MAC lookup. | MAC-VRF10 context is identified for a MAC lookup. | |||
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) 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 (and NVE2 will withdraw the RT-2 | |||
ARP tables with the new MAC resolving the floating IP. No changes | for M2-IP23). DGW1 and DGW2 will update their ARP tables with the | |||
are carried out in the IP-VRF routing table. | new MAC resolving the floating IP. No changes are made in the IP- | |||
VRF routing table. | ||||
5.3 ESI overlay index ("Bump in the wire") use-case | 4.3 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. In this use-case, TS2 and TS3 | |||
index (ESI23). In this use-case, TS2 and TS3 are layer-2 VA devices | are layer-2 VA devices without any IP address that can be included as | |||
without any IP address that can be included as an overlay index in | an Overlay Index in the GW IP field of the IP Prefix route. Their MAC | |||
the GW IP field of the IP Prefix route. Their MAC addresses are M2 | addresses are M2 and M3 respectively and are connected to EVI-10. | |||
and M3 respectively and are connected to EVI-10. Note that IRB1 and | Note that IRB1 and IRB2 (in DGW1 and DGW2 respectively) have IP | |||
IRB2 (in DGW1 and DGW2 respectively) have IP addresses in a subnet | addresses in a subnet different than SN1. | |||
different than SN1. | ||||
NVE2 DGW1 | NVE2 DGW1 | |||
M2 +-----------+ +---------+ +-------------+ | M2 +-----------+ +---------+ +-------------+ | |||
+---TS2(VA)--|(MAC-VRF10)|-| |----|(MAC-VRF10) | | +---TS2(VA)--|(MAC-VRF10)|-| |----|(MAC-VRF10) | | |||
| ESI23 +-----------+ | | | IRB1\ | | | ESI23 +-----------+ | | | IRB1\ | | |||
| + | | | (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 overlay index use-case | Figure 5 Bump-in-the-wire use-case | |||
Since neither TS2 nor TS3 can run any routing protocol and have no IP | Since neither TS2 nor TS3 can participate in any dynamic routing | |||
address assigned, an ESI, i.e. ESI23, will be provisioned on the | protocol and have no IP address assigned, there are two potential | |||
attachment ports of NVE2 and NVE3. This model supports VA redundancy | Overlay Index types that can be used when advertising SN1: | |||
in a similar way as the one described in section 5.2 for the floating | ||||
IP overlay index use-case, only using the EVPN Ethernet A-D route | ||||
instead of the MAC advertisement route to advertise the location of | ||||
the overlay index. The procedure is explained below: | ||||
(1) NVE2 advertises the following BGP routes for TS2: | a) an ESI, i.e. ESI23, that can be provisioned on the attachment | |||
ports of NVE2 and NVE3, as shown in Figure 5. | ||||
b) or the VA's MAC address, that can be added to NVE2 and NVE3 by | ||||
policy. | ||||
The advantage of using an ESI as Overlay Index as opposed to the VA's | ||||
MAC address, is that the forwarding to the egress NVE can be done | ||||
purely based on the state of the AC in the ES (notified by the AD | ||||
per-EVI route) and all the EVPN multi-homing redundancy mechanisms | ||||
can be re-used. For instance, the [RFC7432] mass-withdrawal mechanism | ||||
for fast failure detection and propagation can be used. This section | ||||
assumes that an ESI Overlay Index is used in this use-case but it | ||||
does not prevent the use of the VA's MAC address as an Overlay Index. | ||||
If a MAC is used as Overlay Index, the control plane must follow the | ||||
procedures described in section 4.4.3. | ||||
The model supports VA redundancy in a similar way as the one | ||||
described in section 4.2 for the floating IP Overlay Index use-case, | ||||
only using the EVPN Ethernet A-D per-EVI route instead of the MAC | ||||
advertisement route to advertise the location of the Overlay Index. | ||||
The procedure is explained below: | ||||
(1) Assuming TS2 is the active TS in ESI23, NVE2 advertises the | ||||
following BGP routes: | ||||
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. The Router's MAC Extended | ESI=ESI23, GW IP address=0. The Router's MAC Extended | |||
Community defined in [EVPN-INTERSUBNET] is added and carries | Community defined in [EVPN-INTERSUBNET] is added and carries | |||
the MAC address (M2) associated to the TS behind which SN1 | the MAC address (M2) associated to the TS behind which SN1 | |||
seats. | sits. M2 may be learned by policy. | |||
(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: | ||||
ESI=ESI23 and the corresponding tunnel information (VNI/VSID | ||||
field), as well as the 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=23, GW IP address=0. The Router's MAC Extended Community | ESI=23, GW IP address=0. The Router's MAC Extended Community | |||
is added and carries the MAC address (M3) associated to the TS | is added and carries the MAC address (M3) associated to the TS | |||
behind which SN1 seats. | behind which SN1 sits. M3 may be learned by policy. | |||
(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 | |||
index 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 overlay index=ESI23 is found. Since ESI23 is | routing table and Overlay Index=ESI23 is found. Since ESI23 is | |||
an 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 18, line 17 ¶ | skipping to change at page 18, line 48 ¶ | |||
(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's AC will become active and issue a | owner's notification, NVE3's AC will become active and issue a | |||
route type 1 for ESI23, whereas NVE2 will withdraw its Ethernet | route type 1 for ESI23, whereas NVE2 will withdraw its Ethernet | |||
A-D route for ESI23. DGW1 and DGW2 will update their tunnel | A-D route for ESI23. DGW1 and DGW2 will update their tunnel | |||
information to resolve ESI23. The destination inner MAC will be | information to resolve ESI23. The destination inner MAC will be | |||
changed to M3. | changed to M3. | |||
5.4 IP-VRF-to-IP-VRF model | 4.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. | only host routes. | |||
In the examples described in sections 5.1, 5.2 and 5.3, the MAC-VRF | In the examples described in sections 4.1, 4.2 and 4.3, the MAC-VRF | |||
instance can connect IRB interfaces and any other Tenant Systems | instance can connect IRB interfaces and any other Tenant Systems | |||
connected to it. EVPN provides connectivity for: | connected to it. EVPN provides connectivity for: | |||
1. Traffic destined to the IRB IP interfaces as well as | 1. Traffic destined to the IRB or TS IP interfaces as well as | |||
2. Traffic destined to IP subnets seating behind the TS, e.g. SN1 or | 2. Traffic destined to IP subnets sitting behind the TS, e.g. SN1 or | |||
SN2. | SN2. | |||
In order to provide connectivity for (1), 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 or TS MACs and IPs can be distributed. | |||
(2) is accomplished by the exchange of IP Prefix routes (RT-5) for | Connectivity type (2) is accomplished by the exchange of IP Prefix | |||
IPs and subnets seating behind certain overlay indexes, e.g. GW IP or | routes (RT-5) for IPs and subnets sitting behind certain Overlay | |||
ESI. | Indexes, e.g. GW IP or 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. We refer to this use-case as the "IP-VRF-to- | sitting behind an IRB, and EVPN is the only enabled SAFI in the | |||
IP-VRF" model. | network. We refer to this use-case as the "IP-VRF-to-IP-VRF" model. | |||
[EVPN-INTERSUBNET] defines an asymmetric IRB model and a symmetric | [EVPN-INTERSUBNET] defines an asymmetric IRB model and a symmetric | |||
IRB model, based on the required lookups at the ingress and egress | 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 | 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 | 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 | 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 | 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 | described in this section is a symmetric IRB model. | |||
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 | Note that, in an IP-VRF-to-IP-VRF scenario, out of the many subnets | |||
that a tenant may have, only a few are attached to a given NVE/PE's | ||||
IP-VRF. In order to provide inter-subnet connectivity across multiple | ||||
NVE/PEs, a shared core EVI may be configured in all the tenant | ||||
NVE/PEs. This core EVI has a core-facing IRB interface that connects | ||||
the core MAC-VRF to the IP-VRF on each NVE/PE. Based on the | ||||
characteristics of this core-facing IRB interface, there are three | ||||
different IP-VRF-to-IP-VRF scenarios identified and described in this | different IP-VRF-to-IP-VRF scenarios identified and described in this | |||
document: | document: | |||
1) Interface-less model | 1) Interface-less model | |||
2) Interface-full with core-facing IRB model | 2) Interface-full with core-facing IRB model | |||
3) Interface-full with unnumbered core-facing IRB model | 3) Interface-full with unnumbered core-facing IRB model | |||
5.4.1 Interface-less IP-VRF-to-IP-VRF model | 4.4.1 Interface-less IP-VRF-to-IP-VRF model | |||
Figure 6 will be used for the description of this model. | Figure 6 will be used for the description of this model. | |||
NVE1(M1) | NVE1(M1) | |||
+------------+ | +------------+ | |||
IP1+----|(MAC-VRF1) | DGW1(M3) | IP1+----|(MAC-VRF1) | DGW1(M3) | |||
| \ | +---------+ +--------+ | | \ | +---------+ +--------+ | |||
| (IP-VRF)|----| |-|(IP-VRF)|----+ | | (IP-VRF)|----| |-|(IP-VRF)|----+ | |||
| / | | | +--------+ | | | / | | | +--------+ | | |||
+---|(MAC-VRF2) | | | _+_ | +---|(MAC-VRF2) | | | _+_ | |||
skipping to change at page 19, line 38 ¶ | skipping to change at page 20, line 25 ¶ | |||
| +------------+ | MPLS | + | | +------------+ | MPLS | + | |||
+---|(MAC-VRF2) | | | DGW2(M4) | | +---|(MAC-VRF2) | | | DGW2(M4) | | |||
| \ | | | +--------+ | | | \ | | | +--------+ | | |||
| (IP-VRF)|----| |-|(IP-VRF)|----+ | | (IP-VRF)|----| |-|(IP-VRF)|----+ | |||
| / | +---------+ +--------+ | | / | +---------+ +--------+ | |||
SN2+----|(MAC-VRF3) | | SN2+----|(MAC-VRF3) | | |||
+------------+ | +------------+ | |||
Figure 6 Interface-less IP-VRF-to-IP-VRF model | Figure 6 Interface-less IP-VRF-to-IP-VRF model | |||
In this case, the requirements are the following: | In this case: | |||
a) The NVEs and DGWs must provide connectivity between hosts in SN1, | a) The NVEs and DGWs must provide connectivity between hosts in SN1, | |||
SN2, IP1 and hosts seating at the other end of the WAN. | SN2, IP1 and hosts sitting at the other end of the WAN. | |||
b) The IP-VRF instances in the NVE/DGWs are directly connected | b) The IP-VRF instances in the NVE/DGWs are directly connected | |||
through NVO tunnels, and no IRBs and/or MAC-VRF instances are | through NVO tunnels, and no IRBs and/or MAC-VRF instances are | |||
defined at the core. | instantiated to connect the IP-VRFs. | |||
c) The solution must provide layer-3 connectivity among the IP-VRFs | c) The solution must provide layer-3 connectivity among the IP-VRFs | |||
for Ethernet NVO tunnels, for instance, VXLAN or nvGRE. | for Ethernet NVO tunnels, for instance, VXLAN or nvGRE. | |||
d) The solution may provide layer-3 connectivity among the IP-VRFs | d) The solution may provide layer-3 connectivity among the IP-VRFs | |||
for IP NVO tunnels, for example, VXLAN GPE (with IP payload). | for IP NVO tunnels, for example, VXLAN GPE (with IP payload). | |||
In order to meet the above requirements, the EVPN route type 5 will | 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 | be used to advertise the IP Prefixes, along with the Router's MAC | |||
Extended Community as defined in [EVPN-INTERSUBNET] if the | Extended Community as defined in [EVPN-INTERSUBNET] if the | |||
advertising NVE/DGW uses Ethernet NVO tunnels. Each NVE/DGW will | advertising NVE/DGW uses Ethernet NVO tunnels. Each NVE/DGW will | |||
advertise an RT-5 for each of its prefixes with the following fields: | 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. | |||
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= SHOULD be set to 0. | o GW IP address=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. | |||
skipping to change at page 20, line 47 ¶ | skipping to change at page 21, line 31 ¶ | |||
[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 route is | Router's MAC Extended Community MUST be sent if the route is | |||
associated to an Ethernet NVO tunnel, for instance, VXLAN. If | associated to an Ethernet NVO tunnel, for instance, VXLAN. If | |||
the route is associated to an IP NVO tunnel, for instance | the route is associated to an IP NVO tunnel, for instance | |||
VXLAN GPE with IP payload, the Router's MAC Extended Community | VXLAN GPE with IP payload, the Router's MAC Extended Community | |||
SHOULD NOT be sent. | SHOULD NOT be sent. | |||
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): | |||
VXLAN tunnels: | ||||
(1) NVE1 advertises the following BGP route: | (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, Label=10. | |||
. GW IP= SHOULD be set to 0. | . GW IP= SHOULD be set to 0. | |||
. [RFC5512] BGP Encapsulation Extended Community with Tunnel- | . [RFC5512] BGP Encapsulation Extended Community. | |||
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). | |||
(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. | |||
o Since GW IP=0 and the VNI is a valid value, DGW1 will use the | o Since GW IP=0 and the Label is a valid value, DGW1 will use | |||
VNI and next-hop of the RT-5, as well as the MAC address | the Label and next-hop of the RT-5, as well as the MAC address | |||
conveyed in the Router's MAC Extended Community (as inner | conveyed in the Router's MAC Extended Community (as inner | |||
destination MAC address) to encapsulate the routed IP packets. | destination MAC address) to set up the forwarding state and | |||
later encapsulate the routed IP packets. | ||||
(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. The lookup yields SN1/24. | 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 | o Since the RT-5 for SN1/24 had a GW IP=0 and a valid Label and | |||
next-hop (used as destination VTEP), DGW1 will not need a | next-hop, DGW1 will not need a recursive lookup to resolve the | |||
recursive lookup to resolve the route. | route. | |||
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. The Source and Destination inner MAC | |||
addresses are not needed if IP NVO tunnels are used. | ||||
(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. | Label (the Destination inner MAC is not needed to identify the | |||
IP-VRF). | ||||
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 this Interface-less model is REQUIRED. | The model described above is called Interface-less model since the | |||
IP-VRFs are connected directly through tunnels and they don't require | ||||
those tunnels to be terminated in core MAC-VRFs instead, like in | ||||
sections 4.4.2 or 4.4.3. An EVPN IP-VRF-to-IP-VRF implementation is | ||||
REQUIRED to support the ingress and egress procedures described in | ||||
this section. | ||||
5.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB | 4.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB | |||
Figure 7 will be used for the description of this model. | Figure 7 will be used for the description of this model. | |||
NVE1 | NVE1 | |||
+------------+ DGW1 | +------------+ DGW1 | |||
IP1+----+(MAC-VRF1) | +---------------+ +------------+ | IP1+----+(MAC-VRF1) | +---------------+ +------------+ | |||
| \ (core) (core) | | | \ (core) (core) | | |||
|(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+ | |(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+ | |||
| / IRB(IP1/M1) IRB(IP3/M3) | | | | / IRB(IP1/M1) IRB(IP3/M3) | | | |||
+---+(MAC-VRF2) | | | +------------+ _+_ | +---+(MAC-VRF2) | | | +------------+ _+_ | |||
skipping to change at page 22, line 29 ¶ | skipping to change at page 23, line 25 ¶ | |||
| +------------+ | MPLS | DGW2 + | | +------------+ | MPLS | DGW2 + | |||
+---+(MAC-VRF2) | | | +------------+ | | +---+(MAC-VRF2) | | | +------------+ | | |||
| \ (core) (core) | | | | \ (core) (core) | | | |||
|(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+ | |(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+ | |||
| / IRB(IP2/M2) IRB(IP4/M4) | | | / IRB(IP2/M2) IRB(IP4/M4) | | |||
SN2+----+(MAC-VRF3) | +---------------+ +------------+ | SN2+----+(MAC-VRF3) | +---------------+ +------------+ | |||
+------------+ | +------------+ | |||
Figure 7 Interface-full with core-facing IRB model | Figure 7 Interface-full with core-facing IRB model | |||
In this model, the requirements are the following: | In this model: | |||
a) As in section 5.4.1, the NVEs and DGWs must provide connectivity | a) As in section 4.4.1, the NVEs and DGWs must provide connectivity | |||
between hosts in SN1, SN2, IP1 and hosts seating at the other end | between hosts in SN1, SN2, IP1 and hosts sitting at the other end | |||
of the WAN. | of the WAN. | |||
b) However, the NVE/DGWs are now connected through Ethernet NVO | b) However, the NVE/DGWs are now connected through Ethernet NVO | |||
tunnels terminated in core-MAC-VRF instances. The IP-VRFs use IRB | tunnels terminated in core-MAC-VRF instances. The IP-VRFs use IRB | |||
interfaces for their connectivity to the core MAC-VRFs. | interfaces for their connectivity to the core MAC-VRFs. | |||
c) Each core-facing IRB has an IP and a MAC address, where the IP | c) Each core-facing IRB has an IP and a MAC address, where the IP | |||
address must be reachable from other NVEs or DGWs. | address must be reachable from other NVEs or DGWs. | |||
d) The core EVI is composed of the NVE/DGW MAC-VRFs and may contain | d) The core EVI is composed of the NVE/DGW MAC-VRFs and may contain | |||
skipping to change at page 23, line 10 ¶ | skipping to change at page 24, line 5 ¶ | |||
e) The solution must provide layer-3 connectivity for Ethernet NVO | e) The solution must provide layer-3 connectivity for Ethernet NVO | |||
tunnels, for instance, VXLAN or nvGRE. | tunnels, for instance, VXLAN or nvGRE. | |||
EVPN type 5 routes will be used to advertise the IP Prefixes, whereas | 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- | 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 | facing IRB interface. Each NVE/DGW will advertise an RT-5 for each of | |||
its prefixes with the following fields: | 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. | |||
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=IRB-IP (this is the overlay index that will be | o GW IP address=IRB-IP (this is the Overlay Index that will be | |||
used for the recursive route resolution). | used for the recursive route resolution). | |||
o ESI=0 | o ESI=0 | |||
o MPLS label or VNI corresponding to the IP-VRF. Note that the | o Label value SHOULD be zero since the RT-5 route requires a | |||
value SHOULD be zero since the RT-5 route requires a recursive | recursive lookup resolution to an RT-2 route. The MPLS label | |||
lookup resolution to an RT-2 route. The MPLS label or VNI to | or VNI to be used when forwarding packets will be derived from | |||
be used when forwarding packets will be derived from the RT- | the RT-2's MPLS Label1 field. The RT-5's Label field will be | |||
2's MPLS Label1 field. | ignored on reception. | |||
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). The Router's MAC Extended Community SHOULD NOT be sent in | (IP-VRF). The Router's MAC Extended Community SHOULD NOT be sent in | |||
this case. | this case. | |||
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): | |||
VXLAN tunnels: | ||||
(1) NVE1 advertises the following BGP routes: | (1) NVE1 advertises the following BGP routes: | |||
o Route type 5 (IP Prefix route) containing: | o Route type 5 (IP Prefix route) containing: | |||
. IPL=24, IP=SN1, VNI= SHOULD be set to 0. | . IPL=24, IP=SN1, Label= SHOULD be set to 0. | |||
. GW IP=IP1 (core-facing IRB's IP) | . GW IP=IP1 (core-facing IRB's IP) | |||
. Route-target identifying the tenant (IP-VRF). | . Route-target identifying the tenant (IP-VRF). | |||
o Route type 2 (MAC/IP route for the core-facing IRB) | o Route type 2 (MAC/IP route for the core-facing IRB) | |||
containing: | containing: | |||
. ML=48, M=M1, IPL=32, IP=IP1, VNI=10. | . ML=48, M=M1, IPL=32, IP=IP1, Label=10. | |||
. A [RFC5512] BGP Encapsulation Extended Community with | . A [RFC5512] BGP Encapsulation Extended Community. | |||
Tunnel-type= VXLAN. | ||||
. Route-target identifying the tenant. This route-target MAY | . Route-target identifying the core MAC-VRF. This route-target | |||
be the same as the one used with the RT-5. | MAY 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. | |||
. Since GW IP is different from zero, the GW IP (IP1) will be | . Since GW IP is different from zero, the GW IP (IP1) will be | |||
used as the overlay index for the recursive route resolution | used as the Overlay Index for the recursive route resolution | |||
to the RT-2 carrying IP1. | to the RT-2 carrying IP1. | |||
(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. The lookup yields SN1/24, which is associated | routing table. The lookup yields SN1/24, which is associated | |||
to the overlay index IP1. The forwarding information is | to the Overlay Index IP1. The forwarding information is | |||
derived from the RT-2 received for IP1. | derived from the RT-2 received for IP1. | |||
o The IP packet destined to IPx is encapsulated with: Source | o The IP packet destined to IPx is encapsulated with: Source | |||
inner MAC = M3, Destination inner MAC = M1, Source outer IP | inner MAC = M3, Destination inner MAC = M1, Source outer 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 and the inner MAC DA. | Label and the inner MAC DA. | |||
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 core-facing IRB model | The model described above is called Interface-full with core-facing | |||
is REQUIRED. | IRB model since the tunnels connecting the DGWs and NVEs need to be | |||
terminated into the core MAC-VRFs. Those MAC-VRFs are connected to | ||||
the IP-VRFs via core-facing IRB interfaces. An EVPN IP-VRF-to-IP-VRF | ||||
implementation is REQUIRED to support the ingress and egress | ||||
procedures described in this section. | ||||
5.4.3 Interface-full IP-VRF-to-IP-VRF with unnumbered core-facing IRB | 4.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 | 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 | this model is similar to the one described in section 4.4.2, only | |||
without IP addresses on the core-facing IRB interfaces. | without IP addresses on the core-facing IRB interfaces. | |||
NVE1 | NVE1 | |||
+------------+ DGW1 | +------------+ DGW1 | |||
IP1+----+(MAC-VRF1) | +---------------+ +------------+ | IP1+----+(MAC-VRF1) | +---------------+ +------------+ | |||
| \ (core) (core) | | | \ (core) (core) | | |||
|(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+ | |(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+ | |||
| / IRB(M1)| | IRB(M3) | | | | / IRB(M1)| | IRB(M3) | | | |||
+---+(MAC-VRF2) | | | +------------+ _+_ | +---+(MAC-VRF2) | | | +------------+ _+_ | |||
| +------------+ | | ( ) | | +------------+ | | ( ) | |||
skipping to change at page 25, line 25 ¶ | skipping to change at page 26, line 25 ¶ | |||
| +------------+ | MPLS | DGW2 + | | +------------+ | MPLS | DGW2 + | |||
+---+(MAC-VRF2) | | | +------------+ | | +---+(MAC-VRF2) | | | +------------+ | | |||
| \ (core) (core) | | | | \ (core) (core) | | | |||
|(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+ | |(IP-VRF)(MAC-VRF) (MAC-VRF)(IP-VRF)|-----+ | |||
| / IRB(M2)| | IRB(M4) | | | / IRB(M2)| | IRB(M4) | | |||
SN2+----+(MAC-VRF3) | +---------------+ +------------+ | SN2+----+(MAC-VRF3) | +---------------+ +------------+ | |||
+------------+ | +------------+ | |||
Figure 8 Interface-full with unnumbered core-facing IRB model | Figure 8 Interface-full with unnumbered core-facing IRB model | |||
In this model, the requirements are the following: | In this model: | |||
a) As in section 5.4.1 and 5.4.2, the NVEs and DGWs must provide | a) As in section 4.4.1 and 4.4.2, the NVEs and DGWs must provide | |||
connectivity between hosts in SN1, SN2, IP1 and hosts seating at | connectivity between hosts in SN1, SN2, IP1 and hosts sitting at | |||
the other end of the WAN. | the other end of the WAN. | |||
b) As in section 5.4.2, the NVE/DGWs are connected through Ethernet | b) As in section 4.4.2, the NVE/DGWs are connected through Ethernet | |||
NVO tunnels terminated in core-MAC-VRF instances. The IP-VRFs use | NVO tunnels terminated in core-MAC-VRF instances. The IP-VRFs use | |||
IRB interfaces for their connectivity to the core MAC-VRFs. | IRB interfaces for their connectivity to the core MAC-VRFs. | |||
c) However, each core-facing IRB has a MAC address only, and no IP | 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- | address (that is why the model refers to an 'unnumbered' core- | |||
facing IRB). In this model, there is no need to have IP | facing IRB). In this model, there is no need to have IP | |||
reachability to the core-facing IRB interfaces themselves and | reachability to the core-facing IRB interfaces themselves and | |||
there is a requirement to save IP addresses on those interfaces. | 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- | d) As in section 4.4.2, the core EVI is composed of the NVE/DGW MAC- | |||
VRFs and may contain other MAC-VRFs. | VRFs and may contain other MAC-VRFs. | |||
e) As in section 5.4.2, the solution must provide layer-3 | e) As in section 4.4.2, the solution must provide layer-3 | |||
connectivity for Ethernet NVO tunnels, for instance, VXLAN or | connectivity for Ethernet NVO tunnels, for instance, VXLAN or | |||
nvGRE. | nvGRE. | |||
This model will also make use of the RT-5 recursive resolution. EVPN | 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 | type 5 routes will advertise the IP Prefixes along with the Router's | |||
MAC Extended Community used for the recursive lookup, whereas EVPN | MAC Extended Community used for the recursive lookup, whereas EVPN | |||
RT-2 routes will advertise the MAC addresses of each core-facing IRB | 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 | interface (this time without an IP). | |||
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 | Each NVE/DGW will advertise an RT-5 for each of its prefixes with the | |||
sections. | same fields as described in 4.4.2 except for: | |||
o GW IP address= SHOULD be set to 0. | 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 | 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 | (IP-VRF) and the Router's MAC Extended Community containing the MAC | |||
address associated to core-facing IRB interface. This MAC address MAY | address associated to core-facing IRB interface. This MAC address MAY | |||
be re-used for all the IP-VRFs in the NVE. | be re-used for all the IP-VRFs in the NVE. | |||
The following example illustrates the procedure to advertise and | The example is similar to the one in section 4.4.2: | |||
forward packets to SN1/24 (ipv4 prefix advertised from NVE1) for | ||||
VXLAN tunnels: | ||||
(1) NVE1 advertises the following BGP routes: | (1) NVE1 advertises the following BGP routes: | |||
o Route type 5 (IP Prefix route) containing: | o Route type 5 (IP Prefix route) containing the same values as | |||
in the example in section 4.4.2, except for: | ||||
. IPL=24, IP=SN1, VNI= SHOULD be set to 0. | ||||
. GW IP= SHOULD be set to 0. | . GW IP= SHOULD be set to 0. | |||
. Router's MAC Extended Community containing M1 (this will be | . Router's MAC Extended Community containing M1 (this will be | |||
used for the recursive lookup to a RT-2). | 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) with the same | |||
values as in section 4.4.2 except for: | ||||
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 | . ML=48, M=M1, IPL=0, Label=10. | |||
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. | |||
. The MAC contained in the Router's MAC Extended Community | . The MAC contained in the Router's MAC Extended Community | |||
sent along with the RT-5 (M1) will be used as the overlay | sent along with the RT-5 (M1) will be used as the Overlay | |||
index for the recursive route resolution to the RT-2 | Index for the recursive route resolution to the RT-2 | |||
carrying M1. | carrying M1. | |||
(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. The lookup yields SN1/24, which is associated | routing table. The lookup yields SN1/24, which is associated | |||
to the overlay index M1. The forwarding information is derived | to the Overlay Index M1. The forwarding information is derived | |||
from the RT-2 received for M1. | 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 = M3, Destination inner MAC = M1, Source outer IP | inner MAC = M3, Destination inner MAC = M1, Source outer 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 and the inner MAC DA. | Label and the inner MAC DA. | |||
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 | The model described above is called Interface-full with core-facing | |||
IRB model is OPTIONAL. | IRB model (as in section 4.4.2), only this time the core-facing IRB | |||
does not have an IP address. This model is OPTIONAL for an EVPN IP- | ||||
VRF-to-IP-VRF implementation. | ||||
6. Conclusions | 5. Conclusions | |||
An 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 the Data Center (or NVO-based | |||
based networks in general) inter-subnet connectivity scenarios in | networks in general) inter-subnet connectivity scenarios described in | |||
which an IP Prefix advertisement is required. Using this new RT-5, an | this document. Using this new RT-5, an IP Prefix may be advertised | |||
IP Prefix may be advertised along with an overlay index that can be a | along with an Overlay Index that can be a GW IP address, a MAC or an | |||
GW IP address, a MAC or an ESI, or without an overlay index, in which | ESI, or without an Overlay Index, in which case the BGP next-hop will | |||
case the BGP next-hop will point at the egress NVE and the MAC in the | point at the egress NVE/ASBR/ABR and the MAC in the Router's MAC | |||
Router's MAC Extended Community will provide the inner MAC | Extended Community will provide the inner MAC destination address to | |||
destination address to be used. As discussed throughout the document, | be used. As discussed throughout the document, the EVPN RT-2 does not | |||
the EVPN RT-2 does not meet the requirements for all the DC use | meet the requirements for all the DC use cases, therefore this EVPN | |||
cases, therefore this EVPN route type 5 is required. | 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. | |||
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 current [RFC7432] procedures do not need to be | |||
procedures defined for the advertisement of VM MACs, e.g. MAC | modified. | |||
Mobility or aliasing. As a result of that, the current [RFC7432] | ||||
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 | |||
MAC addresses, overlay ESI, underlay IP next-hops, etc. | MAC addresses, overlay ESI, underlay BGP 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. | |||
type MUST be ignored by the receiving NVE/PE. | ||||
7. Conventions used in this document | 6. 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 | 7. Security Considerations | |||
The security considerations discussed in [RFC7432] apply to this | The security considerations discussed in [RFC7432] apply to this | |||
document. | document. | |||
9. IANA Considerations | 8. 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]: | |||
as follows: | ||||
Value Description Reference | Value Description Reference | |||
5 IP Prefix route [this document] | 5 IP Prefix route [this document] | |||
6-255 Unassigned | ||||
10. References | 9. References | |||
10.1 Normative References | 9.1 Normative References | |||
[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, DOI 10.17487/RFC4364, February 2006, | Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, | |||
<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>. | |||
[RFC7606]Chen, E., Scudder, J., Mohapatra, P., and K. Patel, "Revised | ||||
Error Handling for BGP UPDATE Messages", RFC 7606, August 2015, | ||||
<http://www.rfc-editor.org/info/rfc7606>. | ||||
[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-03.txt, work in | EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt, work in | |||
progress, February, 2017 | progress, February, 2017 | |||
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-07.txt, | Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-07.txt, | |||
work in progress, November, 2016 | work in progress, November, 2016 | |||
11. Acknowledgments | 9.2 Informative References | |||
The authors would like to thank Mukul Katiyar for their valuable | 10. Acknowledgments | |||
feedback and contributions. The following people also helped | ||||
improving this document with their feedback: Tony Przygienda and | ||||
Thomas Morin. | ||||
12. Contributors | The authors would like to thank Mukul Katiyar, Eric Rosen and Jeffrey | |||
Zhang for their valuable feedback and contributions. The following | ||||
people also helped improving this document with their feedback: Tony | ||||
Przygienda and Thomas Morin. | ||||
11. 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 | Senthil Sathappan | |||
Florin Balus | Florin Balus | |||
Aldrin Isaac | Aldrin Isaac | |||
Senad Palislamovic | Senad Palislamovic | |||
13. Authors' Addresses | 12. Authors' Addresses | |||
Jorge Rabadan (Editor) | Jorge Rabadan (Editor) | |||
Nokia | Nokia | |||
777 E. Middlefield Road | 777 E. Middlefield Road | |||
Mountain View, CA 94043 USA | Mountain View, CA 94043 USA | |||
Email: jorge.rabadan@nokia.com | Email: jorge.rabadan@nokia.com | |||
Wim Henderickx | Wim Henderickx | |||
Nokia | Nokia | |||
Email: wim.henderickx@nokia.com | Email: wim.henderickx@nokia.com | |||
End of changes. 140 change blocks. | ||||
366 lines changed or deleted | 367 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/ |