draft-ietf-bess-evpn-prefix-advertisement-07.txt   draft-ietf-bess-evpn-prefix-advertisement-08.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: April 22, 2018 October 19, 2017 Expires: April 23, 2018 October 20, 2017
IP Prefix Advertisement in EVPN IP Prefix Advertisement in EVPN
draft-ietf-bess-evpn-prefix-advertisement-07 draft-ietf-bess-evpn-prefix-advertisement-08
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 MPLS and/or NVO-based network. In some networks, connectivity in an MPLS and/or NVO-based network. In some networks,
there is also a need for a dynamic and efficient inter-subnet there is also a need for a dynamic and efficient inter-subnet
connectivity across Tenant Systems and End Devices that can be connectivity across Tenant Systems and End Devices that can be
physical or virtual and do not necessarily participate in dynamic physical or virtual and do not necessarily participate in dynamic
routing protocols. This document defines a new EVPN route type for routing protocols. This document defines a new EVPN route type for
the advertisement of IP Prefixes and explains some use-case examples the advertisement of IP Prefixes and explains some use-case examples
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 April 20, 2018. This Internet-Draft will expire on April 23, 2018.
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 39 skipping to change at page 2, line 39
2.2 The Requirement for a New EVPN Route Type . . . . . . . . . 7 2.2 The Requirement for a New EVPN Route Type . . . . . . . . . 7
3. The BGP EVPN IP Prefix Route . . . . . . . . . . . . . . . . . 8 3. The BGP EVPN IP Prefix Route . . . . . . . . . . . . . . . . . 8
3.1 IP Prefix Route Encoding . . . . . . . . . . . . . . . . . . 9 3.1 IP Prefix Route Encoding . . . . . . . . . . . . . . . . . . 9
3.2 Overlay Indexes and Recursive Lookup Resolution . . . . . . 10 3.2 Overlay Indexes and Recursive Lookup Resolution . . . . . . 10
4. Overlay Index Use-Cases . . . . . . . . . . . . . . . . . . . . 13 4. Overlay Index Use-Cases . . . . . . . . . . . . . . . . . . . . 13
4.1 TS IP Address Overlay Index Use-Case . . . . . . . . . . . . 13 4.1 TS IP Address Overlay Index Use-Case . . . . . . . . . . . . 13
4.2 Floating IP Overlay Index Use-Case . . . . . . . . . . . . . 15 4.2 Floating IP Overlay Index Use-Case . . . . . . . . . . . . . 15
4.3 Bump-in-the-Wire Use-Case . . . . . . . . . . . . . . . . . 17 4.3 Bump-in-the-Wire Use-Case . . . . . . . . . . . . . . . . . 17
4.4 IP-VRF-to-IP-VRF Model . . . . . . . . . . . . . . . . . . . 20 4.4 IP-VRF-to-IP-VRF Model . . . . . . . . . . . . . . . . . . . 20
4.4.1 Interface-less IP-VRF-to-IP-VRF Model . . . . . . . . . 21 4.4.1 Interface-less IP-VRF-to-IP-VRF Model . . . . . . . . . 21
4.4.2 Interface-ful IP-VRF-to-IP-VRF with SBD-facing IRB . . . 24 4.4.2 Interface-ful IP-VRF-to-IP-VRF with SBD IRB . . . . . . 24
4.4.3 Interface-ful IP-VRF-to-IP-VRF with Unnumbered 4.4.3 Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB . 27
SBD-facing IRB . . . . . . . . . . . . . . . . . . . . . 27
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Conventions used in this document . . . . . . . . . . . . . . . 31 6. Conventions used in this document . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 31
9.2 Informative References . . . . . . . . . . . . . . . . . . . 31 9.2 Informative References . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
skipping to change at page 10, line 40 skipping to change at page 10, line 40
ipv6) and the type of GW IP address (ipv4 or ipv6). Note that the 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 64 or 256 IP Prefix + the GW IP should have a length of either 64 or 256
bits, but never 160 bits (ipv4 and ipv6 mixed values are not bits, but never 160 bits (ipv4 and ipv6 mixed values are not
allowed). allowed).
The RD, Eth-Tag ID, IP Prefix Length and IP Prefix will be part of The RD, 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 the route key used by BGP to compare routes. The rest of the fields
will not be part of the route key. will not be part of the route key.
An IP Prefix Route MAY be sent along with a Router's MAC Extended An IP Prefix Route MAY be sent along with a Router's MAC Extended
Community (defined in [EVPN-INTERSUBNET]). Community (defined in [EVPN-INTERSUBNET]) to carry the MAC address
that is used as the overlay index. Note that the MAC address may be
that of an TS.
3.2 Overlay Indexes and Recursive Lookup Resolution 3.2 Overlay Indexes and Recursive Lookup Resolution
RT-5 routes support recursive lookup resolution through the use of RT-5 routes support recursive lookup resolution through the use of
Overlay Indexes as follows: Overlay Indexes as follows:
o An Overlay Index can be an ESI, IP address in the address space of 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 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 for a given IP Prefix. An Overlay Index always needs a recursive
route resolution on the NVE/PE that installs the RT-5 into one of route resolution on the NVE/PE that installs the RT-5 into one of
skipping to change at page 11, line 42 skipping to change at page 11, line 44
the IP address field of its NLRI. the IP address field of its NLRI.
. If the RT-5 specifies a MAC address as the Overlay Index, . If the RT-5 specifies a MAC address as the Overlay Index,
recursive resolution can only be done if the NVE has received and recursive resolution can only be done if the NVE has received and
installed an RT-2 (MAC/IP route) specifying that MAC address in installed an RT-2 (MAC/IP route) specifying that MAC address in
the MAC address field of its NLRI. the MAC address field of its NLRI.
Note that the RT-1 or RT-2 routes needed for the recursive Note that the RT-1 or RT-2 routes needed for the recursive
resolution may arrive before or after the given RT-5 route. resolution may arrive before or after the given RT-5 route.
o Irrespective of the recursive resolution, if there is no IGP or BGP o Irrespective of the recursive resolution, if there is no IGP or BGP
route to the BGP next-hop of an RT-5, BGP should fail to install route to the BGP next-hop of an RT-5, BGP SHOULD fail to install
the RT-5 even if the Overlay Index can be resolved. the RT-5 even if the Overlay Index can be resolved.
o The ESI and GW IP fields MAY both be zero, however they MUST NOT o The ESI and GW IP fields MAY both be zero, however they MUST NOT
both be non-zero at the same time. A route containing a non-zero GW both be non-zero at the same time. A route containing a non-zero GW
IP and a non-zero ESI (at the same time) will be treated as- IP and a non-zero ESI (at the same time) will be treated as-
withdraw. withdraw.
The indirection provided by the Overlay Index and its recursive The indirection provided by the Overlay Index and its recursive
lookup resolution is required to achieve fast convergence in case of lookup resolution is required to achieve fast convergence in case of
a failure of the object represented by the Overlay Index (see the a failure of the object represented by the Overlay Index (see the
skipping to change at page 21, line 28 skipping to change at page 21, line 28
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. described in this section is a symmetric IRB model.
Note that, in an IP-VRF-to-IP-VRF scenario, out of the many subnets Note that, in an IP-VRF-to-IP-VRF scenario, out of the many subnets
that a tenant may have, it may be the case that only a few are that a tenant may have, it may be the case that only a few are
attached to a given NVE/PE's IP-VRF. In order to provide inter-subnet attached to a given NVE/PE's IP-VRF. In order to provide inter-subnet
connectivity among the set of NVE/PEs where the tenant is connected, connectivity among the set of NVE/PEs where the tenant is connected,
a new "Supplementary Broadcast Domain" (SBD) is created on all of a new "Supplementary Broadcast Domain" (SBD) is created on all of
them. This SBD is instantiated as a regular BD (with no ACs) in each them if recursive resolution is needed. This SBD is instantiated as a
NVE/PE and has a IRB interfaces that connect the SBD to the IP-VRF. regular BD (with no ACs) in each NVE/PE and has a IRB interfaces that
If no recursive resolution is needed, the SBD may not be needed and connect the SBD to the IP-VRF. The IRB interface's IP or MAC address
the IP-VRFs may be connected directly by Ethernet or IP NVO tunnels. is used as the overlay index for recursive resolution.
Depending on the existence and characteristics of the SBD and IRB Depending on the existence and characteristics of the SBD and IRB
interfaces for the IP-VRFs, there are three different IP-VRF-to-IP- interfaces for the IP-VRFs, there are three different IP-VRF-to-IP-
VRF scenarios identified and described in this document: VRF scenarios identified and described in this document:
1) Interface-less model: no SBD and no overlay indexes required. 1) Interface-less model: no SBD and no overlay indexes required.
2) Interface-ful with SBD-facing IRB model: it requires SBD, as well 2) Interface-ful with SBD IRB model: it requires SBD, as well as GW
as GW IP addresses as overlay indexes. IP addresses as overlay indexes.
3) Interface-ful with unnumbered SBD-facing IRB model: it requires 3) Interface-ful with unnumbered SBD IRB model: it requires SBD, as
SBD, as well as MAC addresses as overlay indexes. well as MAC addresses as overlay indexes.
Inter-subnet IP multicast is outside the scope of this document. Inter-subnet IP multicast is outside the scope of this document.
4.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+----| (BD-1) | DGW1(M3) IP1+----| (BD-1) | DGW1(M3)
skipping to change at page 24, line 41 skipping to change at page 24, line 41
Label (the Destination inner MAC is not needed to identify the Label (the Destination inner MAC is not needed to identify the
IP-VRF). 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 BD-2. A turns out to be a local subnet associated to BD-2. A
subsequent lookup in the ARP table and the BD FIB will provide subsequent lookup in the ARP table and the BD FIB will provide
the forwarding information for the packet in BD-2. the forwarding information for the packet in BD-2.
The model described above is called Interface-less model since the The model described above is called Interface-less model since the
IP-VRFs are connected directly through tunnels and they don't require IP-VRFs are connected directly through tunnels and they don't require
those tunnels to be terminated in core BDs instead, like in sections those tunnels to be terminated in SBDs instead, like in sections
4.4.2 or 4.4.3. An EVPN IP-VRF-to-IP-VRF implementation is REQUIRED 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 to support the ingress and egress procedures described in this
section. section.
4.4.2 Interface-ful IP-VRF-to-IP-VRF with SBD-facing IRB 4.4.2 Interface-ful IP-VRF-to-IP-VRF with SBD 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
IP10+---+(BD-1) | +---------------+ +------------+ IP10+---+(BD-1) | +---------------+ +------------+
| \ | | | | | | \ | | | | |
|(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+ |(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+
| / IRB(IP1/M1) IRB(IP3/M3) | | | / IRB(IP1/M1) IRB(IP3/M3) | |
+---+(BD-2) | | | +------------+ _+_ +---+(BD-2) | | | +------------+ _+_
skipping to change at page 25, line 23 skipping to change at page 25, line 23
SN1| | VXLAN/ | ( WAN )--H1 SN1| | VXLAN/ | ( WAN )--H1
| NVE2 | nvGRE/ | (___) | NVE2 | nvGRE/ | (___)
| +------------+ | MPLS | DGW2 + | +------------+ | MPLS | DGW2 +
+---+(BD-2) | | | +------------+ | +---+(BD-2) | | | +------------+ |
| \ | | | | | | | \ | | | | | |
|(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+ |(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+
| / IRB(IP2/M2) IRB(IP4/M4) | | / IRB(IP2/M2) IRB(IP4/M4) |
SN2+----+(BD-3) | +---------------+ +------------+ SN2+----+(BD-3) | +---------------+ +------------+
+------------+ +------------+
Figure 7 Interface-ful with core-facing IRB model Figure 7 Interface-ful with SBD IRB model
In this model: In this model:
a) As in section 4.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 sitting 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 the SBD instance. The IP-VRFs use IRB tunnels terminated in the SBD instance. The IP-VRFs use IRB
interfaces for their connectivity to the SBD. interfaces for their connectivity to the SBD.
c) Each SBD-facing IRB has an IP and a MAC address, where the IP c) Each SBD IRB has an IP and a MAC address, where the IP address
address must be reachable from other NVEs or DGWs. must be reachable from other NVEs or DGWs.
d) The SBD is attached to all the NVE/DGWs in the tenant domain BDs. d) The SBD is attached to all the NVE/DGWs in the tenant domain BDs.
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 SBD- EVPN RT-2 routes will advertise the MAC/IP addresses of each SBD IRB
facing IRB interface. Each NVE/DGW will advertise an RT-5 for each of interface. Each NVE/DGW will advertise an RT-5 for each of its
its prefixes with the following fields: prefixes with the following fields:
o RD as per [RFC7432]. o RD as per [RFC7432].
o Eth-Tag ID=0. 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).
skipping to change at page 26, line 31 skipping to change at page 26, line 31
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): forward packets to SN1/24 (ipv4 prefix advertised from NVE1):
(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, Label= 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 (sBD 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 SBD IRB) containing:
containing:
. ML=48, M=M1, IPL=32, IP=IP1, Label=10. . ML=48, M=M1, IPL=32, IP=IP1, Label=10.
. A [RFC5512] BGP Encapsulation Extended Community. . A [RFC5512] BGP Encapsulation Extended Community.
. Route-target identifying the SBD. This route-target MAY be . Route-target identifying the SBD. This route-target MAY be
the same as the one used with the RT-5. 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:
skipping to change at page 27, line 29 skipping to change at page 27, line 28
(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
Label 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 BD-2. A turns out to be a local subnet associated to BD-2. A
subsequent lookup in the ARP table and the BD FIB will provide subsequent lookup in the ARP table and the BD FIB will provide
the forwarding information for the packet in BD-2. the forwarding information for the packet in BD-2.
The model described above is called 'Interface-ful with SBD-facing The model described above is called 'Interface-ful with SBD IRB
IRB model' since the tunnels connecting the DGWs and NVEs need to be model' since the tunnels connecting the DGWs and NVEs need to be
terminated into the SBD. The SBD is connected to the IP-VRFs via terminated into the SBD. The SBD is connected to the IP-VRFs via SBD
core-facing IRB interfaces, and that allows the recursive resolution IRB interfaces, and that allows the recursive resolution of RT-5s to
of RT-5s to GW IP addresses. An EVPN IP-VRF-to-IP-VRF implementation GW IP addresses. An EVPN IP-VRF-to-IP-VRF implementation is REQUIRED
is REQUIRED to support the ingress and egress procedures described in to support the ingress and egress procedures described in this
this section. section.
4.4.3 Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD-facing IRB 4.4.3 Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD 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 4.4.2, only this model is similar to the one described in section 4.4.2, only
without IP addresses on the SBD-facing IRB interfaces. without IP addresses on the SBD IRB interfaces.
NVE1 NVE1
+------------+ DGW1 +------------+ DGW1
IP1+----+(BD-1) | +---------------+ +------------+ IP1+----+(BD-1) | +---------------+ +------------+
| \ | | | | | | \ | | | | |
|(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+ |(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+
| / IRB(M1)| | IRB(M3) | | | / IRB(M1)| | IRB(M3) | |
+---+(BD-2) | | | +------------+ _+_ +---+(BD-2) | | | +------------+ _+_
| +------------+ | | ( ) | +------------+ | | ( )
SN1| | VXLAN/ | ( WAN )--H1 SN1| | VXLAN/ | ( WAN )--H1
| NVE2 | nvGRE/ | (___) | NVE2 | nvGRE/ | (___)
| +------------+ | MPLS | DGW2 + | +------------+ | MPLS | DGW2 +
+---+(BD-2) | | | +------------+ | +---+(BD-2) | | | +------------+ |
| \ | | | | | | | \ | | | | | |
|(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+ |(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+
| / IRB(M2)| | IRB(M4) | | / IRB(M2)| | IRB(M4) |
SN2+----+(BD-3) | +---------------+ +------------+ SN2+----+(BD-3) | +---------------+ +------------+
+------------+ +------------+
Figure 8 Interface-ful with unnumbered core-facing IRB model Figure 8 Interface-ful with unnumbered SBD IRB model
In this model: In this model:
a) As in section 4.4.1 and 4.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 sitting 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 4.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 the SBD instance. The IP-VRFs use IRB NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB
interfaces for their connectivity to the SBD. interfaces for their connectivity to the SBD.
c) However, each SBD-facing IRB has a MAC address only, and no IP c) However, each SBD IRB has a MAC address only, and no IP address
address (that is why the model refers to an 'unnumbered' SBD- (that is why the model refers to an 'unnumbered' SBD IRB). In this
facing IRB). In this model, there is no need to have IP model, there is no need to have IP reachability to the SBD IRB
reachability to the SBD-facing IRB interfaces themselves and there interfaces themselves and there is a requirement to save IP
is a requirement to save IP addresses on those interfaces. addresses on those interfaces.
d) As in section 4.4.2, the SBD is composed of all the NVE/DGW BDs of d) As in section 4.4.2, the SBD is composed of all the NVE/DGW BDs of
the tenant that need inter-subnet-forwarding. the tenant that need inter-subnet-forwarding.
e) As in section 4.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 SBD-facing IRB RT-2 routes will advertise the MAC addresses of each SBD IRB
interface (this time without an IP). interface (this time without an IP).
Each NVE/DGW will advertise an RT-5 for each of its prefixes with the Each NVE/DGW will advertise an RT-5 for each of its prefixes with the
same fields as described in 4.4.2 except for: 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.
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 SBD-facing IRB interface. This MAC address MAY address associated to SBD IRB interface. This MAC address MAY be re-
be re-used for all the IP-VRFs in the NVE. used for all the IP-VRFs in the NVE.
The example is similar to the one in section 4.4.2: The example is similar to the one in section 4.4.2:
(1) NVE1 advertises the following BGP routes: (1) NVE1 advertises the following BGP routes:
o Route type 5 (IP Prefix route) containing the same values as o Route type 5 (IP Prefix route) containing the same values as
in the example in section 4.4.2, except for: in the example in section 4.4.2, except for:
. 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).
o Route type 2 (MAC route for the core-facing IRB) with the same o Route type 2 (MAC route for the SBD IRB) with the same values
values as in section 4.4.2 except for: as in section 4.4.2 except for:
. ML=48, M=M1, IPL=0, Label=10. . ML=48, M=M1, IPL=0, Label=10.
(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
skipping to change at page 30, line 18 skipping to change at page 30, line 18
(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
Label 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 BD-2. A turns out to be a local subnet associated to BD-2. A
subsequent lookup in the ARP table and the BD FIB will provide subsequent lookup in the ARP table and the BD FIB will provide
the forwarding information for the packet in BD-2. the forwarding information for the packet in BD-2.
The model described above is called Interface-ful with SBD-facing IRB The model described above is called Interface-ful with SBD IRB model
model (as in section 4.4.2), only this time the SBD-facing IRB does (as in section 4.4.2), only this time the SBD IRB does not have an IP
not have an IP address. This model is OPTIONAL for an EVPN IP-VRF-to- address. This model is OPTIONAL for an EVPN IP-VRF-to-IP-VRF
IP-VRF implementation. implementation.
5. 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 the Data Center (or NVO-based role from the RT-2 route and addresses the Data Center (or NVO-based
networks in general) inter-subnet connectivity scenarios described in networks in general) inter-subnet connectivity scenarios described in
this document. Using this new RT-5, an IP Prefix may be advertised this document. Using this new RT-5, an IP Prefix may be advertised
along with an Overlay Index that can be a GW IP address, a MAC or an along with an Overlay Index that can be a GW IP address, a MAC or an
ESI, or without an Overlay Index, in which case the BGP next-hop will ESI, or without an Overlay Index, in which case the BGP next-hop will
 End of changes. 24 change blocks. 
51 lines changed or deleted 52 lines changed or added

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