BESS WG Y. Wang
Internet-Draft Z. Zhang
Intended status: Standards Track ZTE Corporation
Expires: 19 March 2021 15 September 2020
EVPN VPWS as VRF Attachment Circuit
draft-wz-bess-evpn-vpws-as-vrf-ac-00
Abstract
When a VRF Attachment Cirucit (VRF-AC) is far away from its IP-VRF
instance, we can deploy an EVPN VPWS ([RFC8214]) between that VRF-AC
and its IP-VRF instance. From the viewpoint of the IP-VRF instance,
a local virtual interface takes the place of that remote "VRF-AC".
The intended IP address for that VRF-AC is now configured to the
virtual interface, in other words, the virtual interface is the
actual VRF-AC of the IP-VRF instance. The virtual interface is also
the AC of that VPWS instance, in other words, the virtual interface
is cross-connected to that remote "VRF-AC" by the VPWS instance.
This document proposes an extension to [RFC7432] to support this
scenario.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 March 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang & Zhang Expires 19 March 2021 [Page 1]
Internet-Draft EVPN VPWS as VRF-AC September 2020
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Integrated Routing and Cross-connecting . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. ARP/ND Synching and IP Prefix Synching . . . . . . . . . . . 5
2.1. Constructing MAC/IP Advertisement Route . . . . . . . . . 6
2.2. Constructing Ethernet A-D Route . . . . . . . . . . . . . 6
2.3. Constructing IP Prefix Advertisement Route . . . . . . . 6
3. Packet Walk Through . . . . . . . . . . . . . . . . . . . . . 7
4. Fast Convergence for Routed Traffic . . . . . . . . . . . . . 8
5. Considerations on ABRs and Route Reflectors . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
When a VRF Attachment Cirucit (VRF-AC) is far away from its IP-VRF
instance, we can deploy an EVPN VPWS ([RFC8214]) between that VRF-AC
and its IP-VRF instance. From the viewpoint of the IP-VRF instance,
a local virtual interface takes the place of that remote "VRF-AC".
The intended IP address for that VRF-AC is now configured to the
virtual interface, in other words, the virtual interface is the
actual VRF-AC of the IP-VRF instance. The virtual interface is also
the AC of that VPWS instance, in other words, the virtual interface
is cross-connected to that remote "VRF-AC" by the VPWS instance.
The requirements of this scenario is described in Section 1.1.
Wang & Zhang Expires 19 March 2021 [Page 2]
Internet-Draft EVPN VPWS as VRF-AC September 2020
1.1. Integrated Routing and Cross-connecting
When an IP-VRF instance and an EVPN VPWS instance are connected by an
virtual-interface, We call such scenarios as Integrated Routing and
Cross-connecting (IRC) use-case, and the virtual-interface connecting
EVPN VPWS and IP-VRF is called as IRC interface, because that the
packets received from the virtual-interface is routed in the IP-VRF
and the data packets sent to the virtual-interface is cross-connected
to the remote AC of that EVPN VPWS.
The IRC use case are illustrated by the following figure:
PE1
+---------------------+
| IRC1=10.1 |
| +-----+ +------+ |.
.| |VPWS1|---|IPVRF1| | .
. | +-----+ +------+ | .
PE4 . | | . PE3
+--------+. +---------------------+ +---------+
| | | | |
|+-----+ | | RT-2 |+------+ |
||VPWS1| | | <10.2, N1> ||IPVRF1| |
|+-----+ | | label2=IPVRF1 |+------+ |
| | | | label1=NULL | | |
+---|----+. | .+---|-----+
| . PE2 V . |
| . +---------------------+ . |
| .| IRC2=10.1 |. |
N1=10.2 | +-----+ +------+ | N2=20.2
| |VPWS1|---|IPVRF1| |
Behind N1: | +-----+ +------+ |
60.0/24 | |
70.0/24 +---------------------+
Figure 1: ARP/ND Synchronizing for IRC Interfaces
There are four PE nodes named PE1/PE2/PE3/PE4 in the above network.
PE4 is a pure EVPN VPWS PE, there may be no IP-VRFs on it. PE3 is a
pure L3 EVPN PE, there may be no VPWSes or MAC-VRFs on it. PE1 and
PE2 are the border of the EVPN VPWS domain and the L3 EVPN domain, so
they are both EVPN VPWS PE and L3 EVPN PE, there will be both EVPN
IP-VRFs and EVPN VPWSes on them. N1/N2/N3/N4 may be a host or an IP
router. N1/N3/N4 is in the subnet 10.0/24. N2 is in the subnet
20.0/24. When N1/N2/N3/N4 is a host, it is also called H1/H2/H3/H4
in this document. When N1/N2/N3/N4 is a router, it is also called
R1/R2/R3/R4 in this document. When N1 is a Router, there are two
subnets behind N1, these subnets are 60.0/24 and 70.0/24.
Wang & Zhang Expires 19 March 2021 [Page 3]
Internet-Draft EVPN VPWS as VRF-AC September 2020
Note that there may be L2 switches between N1/N2/N3/N4 and their PEs.
These switches are not shown in Figure 1.
Note that the IRC interfaces are considered as AC interfaces in EVPN
VPWS instances. At the same time, they are considered as VRF-ACs in
IP-VRF instances.
When N1 sends an ARP Request REQ_P1, then REQ_P1 will be forwarded by
PE4 to either PE1 or PE2, not to the both. Both the IRC1 on PE1 and
IRC2 on PE2 are N1's subnet-gateway(SNGW). But when N2 send an ARP
Reply REP_P2 to N1, then PE3 may load-balance REP_P2 to either PE1 or
PE2, not to the both.
When REQ_P1 is load-balanced to PE1, not to PE2, but PE3 load-balance
REP_P2 to PE2, The ARP entry of N1 will not be prepared on PE2 for
REP_P2. So the fowarding of REP_P2 will be delayed due to ARP
missing.
We use RT-2 routes to advertise the ARP entry of N1 from PE2 to PE3.
But there SHOULD be no RT-2 advertisement in EVPN VPWS according to
[RFC8214]. So the RT-2 routes from PE2 to PE3 SHOULD not carry any
export-RTs of VPWS1, and the MPLS label1 field of these RT-2 routes
should be set to NULL, not VPWS1.
Note that an ESI may be assigned to IRC1 and IRC2, But it is not
necessary to advertise that ESI in the L3 EVPN domain. The ESI may
be advertised in the EVPN VPWS domain only.
1.2. Terminology
Most of the terminology used in this documents comes from [RFC7432]
and [I-D.ietf-bess-evpn-prefix-advertisement] except for the
following:
VRF AC: VRF Attachment Circuit, An Attachment Circuit (AC) that
attaches a CE to an IP-VRF. It is defined in [RFC4364].
IRC: Integrated Routing and Cross-connecting, thus a IRC interface is
the virtual interface connecting an IP-VRF and an EVPN VPWS.
L3 EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN which contains VRF ACs and maybe contains
IRB interfaces or IRC interfaces.
IP-AD/EVI: Ethernet Auto-Discovery route per EVI, and the EVI here is
an IP-VRF.
Wang & Zhang Expires 19 March 2021 [Page 4]
Internet-Draft EVPN VPWS as VRF-AC September 2020
IP-AD/ES: Ethernet Auto-Discovery route per ES, and the EVI for one
of its route targets is an IP-VRF.
CE-BGP: The BGP session between PE and CE. Note that CE-BGP route
doesn't have a RD or Route-Target.
RMAC: Router's MAC, which is signaled in the Router's MAC extended
community.
RT-2E: A MAC/IP Advertisement Route with a non-reserved ESI.
RT-5E: An EVPN Prefix Advertisement Route with a non-reserved ESI.
RT-5G: An EVPN Prefix Advertisement Route with a zero ESI and a non-
zero GW-IP.
RT-5L: An EVPN Prefix Advertisement Route with both zero ESI and zero
GW-IP, but a valid MPLS label.
2. ARP/ND Synching and IP Prefix Synching
Host IP-MAC relations are learnt by PEs on the access side via a
control plane protocol like ARP. In case where N1 is multihomed to
multiple L3 EVPN PE nodes by an All-Active EVPN VPWS, N1's Host IP/
MAC will be learnt and advertised in the MAC/IP Advertisement only by
the PE that receives the ARP packet. The MAC/ IP Advertisement with
non-zero ESI will be received by the other multihomed PE.
As a result, after PE2 receives the MAC/IP Advertisement and imports
it to the L3 EVI, PE2 installs an ARP entry to the VRF interface
whose subnet matches the IP Address from the MAC/IP Advertisement.
Such ARP entry is called remote synched ARP Entry in this document.
Note that the PE3 follows the DGW1 behavior of
[I-D.ietf-bess-evpn-prefix-advertisement]'s section 4.3 to achieve
the load balancing procedures based on the recursive route resolution
by the ESI Overlay Index.
When PE3 load balance the traffic towards PE1/PE2, both PE1 and PE2
would have been prepared with corresponding ARP entry yet because of
the following ARP synching procedures.
Wang & Zhang Expires 19 March 2021 [Page 5]
Internet-Draft EVPN VPWS as VRF-AC September 2020
2.1. Constructing MAC/IP Advertisement Route
This draft introduces a new usage/construction of MAC/IP
Advertisement route to enable ARP/ND synching for IP addresses in
EVPN IRC use-cases. The usage/construction of this route remains
similar to that described in RFC 7432 with a few notable exceptions
as below.
* The Route-Distinguisher should be set to the corresponding IP-VRF
context.
* The Ethernet Tag should be set to 0.
* The MAC/IP Advertisement SHOULD carry one or more IP VRF Route-
Target (RT) attributes.
* The ESI can be simply set to zero.
Note that we use the subnet consistency between the host IP
address and the IRC interface to determine which interface the
synched ARP/ND entry should be installed to.
* The MPLS Label1 should be set to NULL.
Note that the NULL value of MPLS label1 in MPLS EVPN should be
implicit-null. The NULL value of MPLS label1 in VXLAN EVPN should
be 0.
* The MPLS Label2 should be set to IPVRF1.
* The RMAC Extended Community attribute SHOULD be carried in VXLAN
EVPN.
2.2. Constructing Ethernet A-D Route
The ESI of the IRC interface is mainly use in the EVPN VPWS domain.
That ESI has nothing to do with the fundamental function of the L3
EVPN domain.
Note that the Ethernet A-D route advertisement in the EVPN VPWS
domain still follows [RFC8214]. The IRC interface is considered as
an ordinary AC in the EVPN VPWS domain.
2.3. Constructing IP Prefix Advertisement Route
There may be two types of IP prefixes on PE1/PE2. The first type is
the prefix of the IRC interface itself. The second type is the
prefixes behind N1 (especially when N1 is a router).
Wang & Zhang Expires 19 March 2021 [Page 6]
Internet-Draft EVPN VPWS as VRF-AC September 2020
Given that PE1/PE2 can install synced ARP entries to its proper IRC
interface benefitting from the RT-2 route of Section 2. This ensures
that both PE1 and PE2 will know all hosts of the IRC interface's own
subnet. So it is not necessary for PE1/PE2 to advertise per-host IP
prefixes of that subnet to PE3 by RT-2 routes. It is recommended
that PE1/PE2 advertise a single RT-5 route of that subnet to PE3
instead. The ESI of these RT-5 routes can be simply set to zero,
because when PE3 receives such RT-5 routes from both PE1 and PE2, PE3
can consider them as ECMP or FRR even when their ESI is zero.
Note that N1 may be a host or a router, when it is a router, there
may be some prefixes behind N1 on PE1. Those prefixes will be learnt
via a PE-CE route protocol. N1's IP address may be considered as the
overlay nexthop of those prefixes. The overlay nexthop of those
prefixes will be carried in the RT-5 route's GW-IP field. Those RT-5
routes are called as RT-5G routes because their Overlay Indexes are
their GW-IPs (and their ESI and label are zero).
Note that those RT-5G routes are advertised by PE1 to both PE2 and
PE3. If the IRC1 interface fails, the prefixes of the second type
will achieve more faster convergency on PE3 by the withdraw (from
PE1) of the corresponding prefix of the first type.
3. Packet Walk Through
The procedures for local/remote host learning and MAC/IP
Advertisement route constructing are described above.
When R2(N2) send a data packet P21 to a host 60.1 whose location is
behind R1(N1), P21 will matches prefix 60.0/24 on PE3. The RT-5G
route for 60.0/24 will be used. The GW-IP of that RT-5G route is
10.1 (R1). So PE3 use 10.1 to do recursive route resolution and
matches the RT-5L route of 10.0/24.
Note that the recursive route resolution follows the DGW1 behavior of
[I-D.ietf-bess-evpn-prefix-advertisement]'s section 4.1.
Both PE1 and PE2 have advertised the RT-5L route of 10.0/24 to PE3.
PE3 may consider them as ECMP or FRR, depending on their route
attributes. Then PE3 should forward P21 to PE1 or PE2, depending on
the ECMP/FRR procedures.
We can assume that it is PE2 that will receive P21 from PE3. The
destination IP of P21 is in prefix 60.0/24. That prefix has been
installed into IPVRF1 on PE2. PE2 previously received that prefix
either from a PE-CE route protocol or from a RT-5G route from PE1.
The overlay nexthop or GW-IP of prefix 60.0/24 is 10.1 (R1). The
outgoing interface for P21 is IRC2 interface.
Wang & Zhang Expires 19 March 2021 [Page 7]
Internet-Draft EVPN VPWS as VRF-AC September 2020
The ARP entry for 10.1 is a synched ARP entry, because PE1 sent the
ARP Request only to PE1. It is intalled to IRC2 interface just
because it is the ARP entry of a host of IRC2's subnet.
Then P21 is encapsulated with a ethernet header and becomes an
ethernet packet P21E. The destination MAC address of P21E is N1's
MAC address which is determined by that ARP entry. The source MAC
address of P21E is IRC2's MAC address. Then P21E is sent to IRC2
interface.
After P21E is sent to IRC2 interface, it will be forwarded to PE4 in
the EVPN VPWS instance according to [RFC8214]
4. Fast Convergence for Routed Traffic
When IRC1 interface goes down, PE1 will withdraw the RT-5L route of
10.0/24. And the RT-5G routes of 60.0/24 and 70.0/24 will be just
changed to stale state. When PE3 receives the withdraw of that RT-5L
route, it will stop to forward the data packets of those two subnets
to PE1 again.
5. Considerations on ABRs and Route Reflectors
When a Route Reflector (RR) receives a MAC/IP Advertisement Route
whose MPLS label1 field is NULL, It should reflect that route to its
clients as a normal route. It should not consider that route as
malformed.
When a ABR or ASBR receives a MAC/IP Advertisement Route whose MPLS
label1 field is NULL, It should re-advertise that route and that
route's nexthop will be changed to itself. It should not consider
that route as malformed. It should not allocate a new label for the
MPLS label1 field. That field should be kept NULL during the re-
advertisement. But the MPLS label2 field should be rewritten along
with the nexthop-rewritting.
6. Security Considerations
This document does not introduce any new security considerations
other than already discussed in [RFC7432] and
[I-D.ietf-bess-evpn-prefix-advertisement].
7. IANA Considerations
There is no IANA consideration needed.
8. Normative References
Wang & Zhang Expires 19 March 2021 [Page 8]
Internet-Draft EVPN VPWS as VRF-AC September 2020
[I-D.dawra-bess-srv6-services]
Dawra, G., Filsfils, C., Brissette, P., Agrawal, S.,
Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Decraene, B., Matsushima, S., Zhuang, S., and J. Rabadan,
"SRv6 BGP based Overlay services", Work in Progress,
Internet-Draft, draft-dawra-bess-srv6-services-02, 8 July
2019, <https://tools.ietf.org/html/draft-dawra-bess-srv6-
services-02>.
[I-D.ietf-bess-evpn-prefix-advertisement]
Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
Sajassi, "IP Prefix Advertisement in EVPN", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-prefix-
advertisement-11, 18 May 2018,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-
advertisement-11>.
[I-D.ietf-bess-evpn-inter-subnet-forwarding]
Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in EVPN", Work
in Progress, Internet-Draft, draft-ietf-bess-evpn-inter-
subnet-forwarding-10, 3 September 2020,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-
subnet-forwarding-10>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
9. Informative References
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/info/rfc8214>.
Authors' Addresses
Wang & Zhang Expires 19 March 2021 [Page 9]
Internet-Draft EVPN VPWS as VRF-AC September 2020
Yubao Wang
ZTE Corporation
No. 68 of Zijinghua Road, Yuhuatai Distinct
Nanjing
China
Email: yubao.wang2008@hotmail.com
Zheng(Sandy) Zhang
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: zzhang_ietf@hotmail.com
Wang & Zhang Expires 19 March 2021 [Page 10]