AC-Influenced DF Election per EVI
draft-wang-bess-evpn-ac-df-per-evi-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Yubao Wang | ||
| Last updated | 2021-05-07 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-bess-evpn-ac-df-per-evi-00
BESS WG Y. Wang
Internet-Draft ZTE Corporation
Intended status: Standards Track 7 May 2021
Expires: 8 November 2021
AC-Influenced DF Election per EVI
draft-wang-bess-evpn-ac-df-per-evi-00
Abstract
The AC-influenced DF Election (AC-DF) per [RFC8584] is too dependent
on EAD/EVI routes. For example, when no failures occured on an ESI,
that AC-DF procedures will give incorrect results if no EAD/EVI
routes are advertised. But in some light-weighted EVPNs (i.e. PBB
EVPNs), no EAD/EVI routes will be advertised at all.
This draft proposes some new extensions to support AC-influenced DF
Election without any EAD/EVI routes advertised in advance of any
<ESI, EVI> failures.
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 8 November 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Wang Expires 8 November 2021 [Page 1]
Internet-Draft AC-DF per EVI May 2021
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. AC-DF per EVI . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. AC-DF per EVI Capability . . . . . . . . . . . . . . . . 4
2.2.1. Capability Negotiation Procedures . . . . . . . . . . 4
2.2.2. AC-DF Capability vs AC-DF per EVI Capability . . . . 4
2.3. DF Election Procedures . . . . . . . . . . . . . . . . . 4
2.3.1. Initiation of AC-DF per EVI Mode . . . . . . . . . . 4
2.3.2. Reverse EAD/EVI Route . . . . . . . . . . . . . . . . 5
2.3.3. DF Election Rules . . . . . . . . . . . . . . . . . . 5
2.3.4. Route Filtering and RT Constraints Mechanism . . . . 5
3. Other considerations . . . . . . . . . . . . . . . . . . . . 6
3.1. Why no EAD/EVI Routes Advertised . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. New DF Election Capability . . . . . . . . . . . . . . . 6
5.2. New EVPN Layer 2 Attributes Control Flags . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
When the EAD/EVI route is not advertised before the corresponding ESI
sub-interface fails, The AC-influenced DF Election procedures should
elect the right DF before and after that failure.
Note that according to [RFC8584], the AC-influenced DF Election will
be incorrect when no EAD/EVI route is advertised, even if no ESI sub-
interface has failed at all.
This draft proposes some extension to DF-Capability negotiation and
DF-Election procedures to support AC-influenced DF-election when no
EAD/EVI routes are advertised.
1.1. Terminology
Most of the terminology used in this documents comes from [RFC8584]
and [RFC7623] except for the following:
Wang Expires 8 November 2021 [Page 2]
Internet-Draft AC-DF per EVI May 2021
* Light-weighted EVPN: The EVPN solution without EAD/EVI Route
advertisedment.
* EAD/ES: Ethernet A-D route per EVI, or RT-1 per ES route.
* EAD/EVI: Ethernet A-D route per EVI, or RT-1 per EVI route.
2. AC-DF per EVI
2.1. Use Case
The ethernet segment ES1's ESI is ESI1, AC1/AC2 is two sub-interfaces
on ES1, and AC3/AC4 is two sub-interfaces on ES2. AC1 and AC3 are
attached to EVPN Instance EVI1, while AC2 and AC4 are attached to
EVI2. The redundancy mode of ES1 is all-active.
+----------+
PE1 | |
+-------------+ | |
| AC1 | | | PE3
/| AC2 |----| | +-------------+
/ | | | | | |
LAG / +-------------+ | | | AC3 |---CE2
CE1===== | PSN | | AC4 |
\ +-------------+ | |---| |
\ | | | | +-------------+
\| AC2 |----| |
| AC1 | | |
+-------------+ | |
PE2 | |
+----------+
Figure 1: AC-DF per EVI Usecase
EVI1 and EVI2 are two EVPN Instances, and there are no EAD/EVI routes
advertised for them. Such EVPN Instances are called Light-weighted
EVPNs in this draft. For example, EVI1 and EVI2 can be the
I-Components of PBB EVPNs, because no EAD/EVI routes are advertised
for these I-Components.
Initially PE1 is the DF for <ESI1, EVI1>, and PE2 is the DF for
<ESI1, EVI2>. When the AC1 of PE1 fails (but ESI1 and AC2 of PE1
still works well), the DF for <ESI1, EVI1> should switch to PE2.
Wang Expires 8 November 2021 [Page 3]
Internet-Draft AC-DF per EVI May 2021
The DF-election should be done without any EAD/EVI routes advertised
before any ESI sub-interface fails. Otherwise those EAD/EVI routes
are advertised just for the adaptation of AC-influenced DF-election
procedures per [RFC8584], but will do nothing good for the unicast
packet forwarding in data plane (because data plane MAC learning
don't use EAD/EVI routes).
2.2. AC-DF per EVI Capability
We introduce a new bit named "AC-DF per EVI" in the "bitmap" field of
the DF Election extended community. The "AC-DF per EVI" bit means
that the DF-Election for an <ESI, EVI> will not take EAD/EVI routes
into considerations untill a Reverse EAD/EVI route for that <ESI,
EVI> is received from any of the PEs.
2.2.1. Capability Negotiation Procedures
Only when all RT-4 routes of the same ESI indicate the "AC-DF per
EVI" Capability, The DF Election will be executed in "AD-DF per EVI"
mode. We can say that the DF Election mode for that ESI is
negotiated as "AC-DF per EVI" mode.
Note that when any of the PEs on that ES is an old PE that don't
support "AC-DF per EVI" mode, the RT-4 route from that PE will not
indicate the "AC-DF per EVI" Capability, So the DF election will not
be executed in "AD-DF per EVI" mode. This is for compatibility
purpose.
2.2.2. AC-DF Capability vs AC-DF per EVI Capability
When all RT-4 routes of the same ESI indicate both the "AC-DF per
EVI" Capability and the old AC-DF Capability, The DF Election will be
executed in "AD-DF per EVI" mode.
Note that when any of the PEs on that ES is an old PE that don't
support "AC-DF per EVI" mode, the RT-4 route from that PE may
indicate the "old AC-DF" Capability only, So the DF election will
still be executed in old AD-DF mode per [RFC8584]. This is for
compatibility purpose.
2.3. DF Election Procedures
2.3.1. Initiation of AC-DF per EVI Mode
According to [RFC8584], the AC-influenced DF Election will be
incorrect when no EAD/EVI route is advertised, even if no ESI sub-
interface has failed at all.
Wang Expires 8 November 2021 [Page 4]
Internet-Draft AC-DF per EVI May 2021
But when the DF Election mode for an ESI is negotiated as AC-DF per
EVI mode, no normal EAD/EVI routes can impact the DF Election
procedures. The DF election will be done following that ESI's RT-4
routes only until at least one reverse EAD/EVI route is received.
2.3.2. Reverse EAD/EVI Route
In order to do AC-influenced DF election after a sub-interface of
that ES fails, we introduce the "Reverse EAD/EVI Route". The reverse
EAD/EVI Route is a special type of EAD/EVI Route that is advertised
on the failure of corresponding <ESI, EVI>, not on the activation of
that <ESI, EVI>.
Reverse EAD/EVI routes can use the same format as EAD/EVI Routes
except for the following differences:
* A Reverse EAD/EVI Route carries an EVPN Layer 2 Attributes
Extended Community whose "Control Flags" field includes a new flag
named "AC Failure". The "AC Failure" flag means that the
corresponding AC (for which the Reverse EAD/EVI route is
advertised) is in failure.
* A Reverse EAD/EVI Route carries an ES-Import RT ([RFC7432]) and an
EVI-RT ([I-D.ietf-bess-evpn-igmp-mld-proxy]), no traditional
Route-Targets have to be carried.
* A Reverse EAD/EVI Route should make its MPLS label field be set to
zero.
2.3.3. DF Election Rules
When a Reverse EAD/EVI Route for an <ESI, EVI> is received from a
remote PE X, the RT-4 Route of that PE x are expelled from that <ESI,
EVI>'s DF election. Then the DF election for that <ESI, EVI> will be
updated according to the corresponding DF Alg.
Note that the DF election for other <ESI, EVI>s will not be affected
by that Reverse EAD/EVI Route.
2.3.4. Route Filtering and RT Constraints Mechanism
When PE Y receives a reverse EAD/EVI route from PE X, and the ES-
Import RT of that route can't match any local ES of PE Y, PE Y will
not import that route into the EVI that is identified by that route's
EVI-RT.
Wang Expires 8 November 2021 [Page 5]
Internet-Draft AC-DF per EVI May 2021
When RT Constraints Mechanism is enabled, each reverse EAD/EVI route
will be distributed to the adjacent PEs of its ES only. Because that
only the ES-Import RT are visible to the RT Constraints Mechanism,
The EVI-RT is not visible to the RT Constraints Mechanism.
3. Other considerations
3.1. Why no EAD/EVI Routes Advertised
When no RT-2 Routes advertised, no EAD/EVI routes need to be
advertised either. PBB EVPN is an example of that. In PBB EVPN, the
C-MACs are learnt in the data plane.
Other light-weighted EVPNs also do data plane C-MAC learning, so they
don't have to advertise EAD/EVI routes either. In such EVPNs, AC-DF
per EVI will help.
4. Security Considerations
Security considerations will be added in future versions.
5. IANA Considerations
5.1. New DF Election Capability
IANA will be requested to allocate a new DF Election Capability in
the "DF Election Capabilities" Registry. This capability is called
"AC-DF per EVI Capability".
Bit Name Reference
---- ---------------- -------------
0 Unassigned
1 AC-DF Capability [RFC8584]
4 AC-DF per EVI Capability This draft
Figure 2: AC-DF per EVI Capability
5.2. New EVPN Layer 2 Attributes Control Flags
IANA will be requested to allocate a new Control Flag in the "EVPN
Layer 2 Attributes Control Flags" Registry. This Control Flag is
called "F" Flag, where "F" means AC-Failure.
Wang Expires 8 November 2021 [Page 6]
Internet-Draft AC-DF per EVI May 2021
Bit Name Reference
---- ---------------- -------------
P Advertising PE is the primary PE. [RFC8214]
B Advertising PE is the backup PE. [RFC8214]
C Control word [RFC4448] MUST be present. [RFC8214]
F AC-Failure on Advertising PE This Draft
Figure 3: AC Failure Flag
6. Acknowledgements
The authors would like to thank the following for their comments and
review of this document:
Chunning Dai.
7. Normative References
[I-D.ietf-bess-evpn-igmp-mld-proxy]
Sajassi, A., Thoria, S., Drake, J., and W. Lin, "IGMP and
MLD Proxy for EVPN", Work in Progress, Internet-Draft,
draft-ietf-bess-evpn-igmp-mld-proxy-06, 25 January 2021,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-
mld-proxy-06>.
[I-D.ietf-bess-srv6-services]
Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R.,
Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based
Overlay services", Work in Progress, Internet-Draft,
draft-ietf-bess-srv6-services-06, 9 March 2021,
<https://tools.ietf.org/html/draft-ietf-bess-srv6-
services-06>.
[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>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
Wang Expires 8 November 2021 [Page 7]
Internet-Draft AC-DF per EVI May 2021
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
8. Informative References
[RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
"Extensions to the Virtual Private LAN Service (VPLS)
Provider Edge (PE) Model for Provider Backbone Bridging",
RFC 7041, DOI 10.17487/RFC7041, November 2013,
<https://www.rfc-editor.org/info/rfc7041>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[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>.
Author's Address
Yubao Wang
ZTE Corporation
No.68 of Zijinghua Road, Yuhuatai Distinct
Nanjing
China
Email: wang.yubao2@zte.com.cn
Wang Expires 8 November 2021 [Page 8]