Internet DRAFT - draft-chen-bess-evpn-wtr-on-fast-df-recovery
draft-chen-bess-evpn-wtr-on-fast-df-recovery
BESS WG R. Chen
Internet-Draft Y. Wang
Intended status: Standards Track ZTE Corporation
Expires: 11 January 2024 10 July 2023
WTR signaling on Fast DF Recovery of Single-Active ESIs
draft-chen-bess-evpn-wtr-on-fast-df-recovery-00
Abstract
The non-DF of a Single-Active Ethernet Segment (SA-ES) can filter
both unicast traffic and BUM traffic. In such case, when a specific
Single-Active ES performs fast DF recovery, the corresponding
revertive FRR switching should be performed on the ingress PEs that
are not adjacent to this ES. This revertive FRR switching needs to
be performed immediately after the A-D per EVI route with the "P=1"
is received from the new DF node. In other words, the revertive FRR
switching cannot perform the WTR procedures, otherwise unicast
traffic will be dropped on the new NDF node during the WTR.
In this draft, the SCT-EC is extended to the A-D per EVI routes, so
that the ingress PEs can perform the revertive FRR switching based on
the time specified by the SCT-EC for the non-adjacent ESes that
support the fast DF recovery.
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 11 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chen & Wang Expires 11 January 2024 [Page 1]
Internet-Draft WTR on Fast DF Recovery July 2023
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. NDF-behavior of SA-ES . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. SCT-Approach for A-D per EVI Routes . . . . . . . . . . . 5
3.2. Control Plane Procedures . . . . . . . . . . . . . . . . 5
3.2.1. Service Carving Timestamp in A-D per EVI Routes . . . 6
3.2.2. SCT-based WTR Capability Advertisement . . . . . . . 6
3.2.3. WTR Advertisement on PE1/PE2 . . . . . . . . . . . . 7
3.2.4. SCT-based WTR Procedures on PE3 . . . . . . . . . . . 7
3.2.5. A-D per EVI Route Advertisement after SCT-Time . . . 7
4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The non-DF of a Single-Active Ethernet Segment (SA-ES) can filter
both unicast traffic and BUM traffic. In such case, when a specific
Single-Active ES performs fast DF recovery, the corresponding
revertive FRR switching should be performed on the ingress PEs that
are not adjacent to this ES. This revertive FRR switching needs to
be performed immediately after the A-D per EVI route with the "P=1"
is received from the new DF node. In other words, the revertive FRR
switching cannot perform the WTR procedures, otherwise unicast
traffic will be dropped on the old DF (new NDF) node during the WTR.
However, on the other hand, lack of the WTR procedures also causes
the unicast flows to be discarded on the newly activated path of the
FRR until all corresponding forwarding entries on the newly activated
path are completely installed. As a PE node that is not adjacent to
a specified group of ESes, the ingress PE cannot know which ESes in
that group are enabled with SCT-based fast DF recovery. If the
Chen & Wang Expires 11 January 2024 [Page 2]
Internet-Draft WTR on Fast DF Recovery July 2023
ingress PEs stop executing the WTR procedures of the FRR of all non-
adjacent ESes due to this reason, the traffic loss will be even
worse.That is, the ESes that do not enable the SCT-based fast DF
recovery at all will bear traffic loss due to the lack of WTR
procedures.
In this draft, the DF Election Capabilities EC is extended to the A-D
per ES routes, so that the ingress PEs can distinguish the non-
adjacent ESes that support the fast DF recovery from the non-adjacent
ESes that do not support the fast DF recovery. In this draft, the
SCT-EC is extended to the A-D per EVI routes, so that the ingress PEs
can perform the revertive FRR switching based on the time specified
by the SCT-EC for the non-adjacent ESes that support the fast DF
recovery.
1.1. NDF-behavior of SA-ES
The behavior of a non-DF AC is called NDF-behavior in this draft.
The NDF-behavior of a SA-ES is different from the NDF-behavior of a
All-Active ES.
The SA-ES topology is illustrated in the following figure. In that
figure, the topology of Ethernet Segment ES21 is a MHN.
+---------+
+-------------+ | |
| | | |
CE1------+ (AC1) PE1 |----| | +-------------+
+ ^ | | | MPLS/ | | |---CE3
| | +-------------+ | VxLAN/ | | PE3 |
| ES21 | Cloud | | |
| | +-------------+ | |---| |
+ v | | | | +-------------+
CE2------+ (AC2) PE2 |----| |
| | | |
+-------------+ | |
+---------+
Figure 1: MHN (CE1+CE2) multihomed to PE1 and PE2
The DF filtering rules for SA-ES is different than the rules for AA-
ES. The details are described in the following:
Directionality- DF filtering for MHN is applied for traffic both
ingress and egress on the access-facing Ethernet interfaces;
whereas, DF filtering for AA-ES is applied only to traffic that
egress the access-facing interfaces.
Chen & Wang Expires 11 January 2024 [Page 3]
Internet-Draft WTR on Fast DF Recovery July 2023
Traffic Type- DF filtering for MHN impacts both unicast as well as
flooded multi-destination traffic; whereas, DF filtering for AA-ES
only applies to flooded multi-destination traffic..
1.2. Terminology
Most of the terminology used in this documents comes from
[I-D.ietf-bess-rfc7432bis] and [I-D.ietf-bess-evpn-fast-df-recovery]
except for the following:
* MHN: Multi-Homed Network. The "multi-homed network" concept is
defined in [RFC7275].
* SA-ES: A Single-Active Ethernet Segment (ES).
* AA-ES: An All-Active Ethernet Segment (ES).
* NDF: non-DF.
* SCT: Service Carving Timestamp.
* SCT-EC: Service Carving Timestamp Extended Community.
* SCT-Time: The absolute time indicated by the timestamp in a SCT-
EC.
* P flag: The P flag in L2 Attr Extended Community of [RFC8214].
* B flag: The B flag in L2 Attr Extended Community of [RFC8214].
* T bit: The T bit in DF Election Capabilities Extended Community.
* RT-1: The Ethernet Auto-Discovery Route.
* RT-4: The Ethernet Segment Route.
* RT-1 per ES: The Ethernet Auto-Discovery per ES Route, or A-D per
ES route.
* RT-1 per EVI: The Ethernet Auto-Discovery per EVI Route, or A-D
per EVI route.
Chen & Wang Expires 11 January 2024 [Page 4]
Internet-Draft WTR on Fast DF Recovery July 2023
2. Requirements
When a A-D per EVI route R1 is advertised to PE3 by PE1/PE2, PE3 will
receive it after X ms. Now we can assume that X will be a random
number from 1 ms to N ms in the network of Figure 1. In this
example, we can assume that N will be as much as 60000 (ms) and the
Ethernet Segment ES21 is a SA-ES.
In this example, the requirement is that, the packet-loss should be
controlled at a less-than-10-ms level.
3. Solution
3.1. SCT-Approach for A-D per EVI Routes
Based on the Service Carving Time (SCT) approach for Ethernet A-D per
EVI Routes:
1. Initial state: The ES interface where AC2 is located is in steady
state, and the ES interface where AC1 is located is is
recovering. PE3 sends unicast flows to PE2 where AC2 is located.
2. The ES interface where the AC1 is located recovers at absolute
time t=99.
3. PE1 advertises the RT-4 route (sent at the time t=100) for the ES
interface where AC1 is located, carrying the target SCT value
t=199. PE1 advertises the A-D per EVI route (sent at the time
t=100) for AC1, carrying the target SCT value t=199 and "B=1" to
the peer PE3 and PE2.
4. PE3 receives the A-D per EVI route on absolute time t=155.
5. PE3 executes FRR-revertion at absolute time t=199, while PE1 and
PE2 execute service carving at absolute time t=199.
Using SCT approach, the negative effect of the lack of WTR procedures
is mitigated. Furthermore, the BGP Ethernet Auto-discovery route
(RT-1) transmission delay (from PE1 to PE3) becomes a non-issue. The
use of SCT approach also remedies the problem associated with
inconsistent pace between fast DF recovery (on PE1 and PE2) and FRR-
revertion (on PE3): Revertive FRR switching on PE3 is now performed
at the same absolute time as fast DF recovery on PE1 and PE2.
3.2. Control Plane Procedures
Chen & Wang Expires 11 January 2024 [Page 5]
Internet-Draft WTR on Fast DF Recovery July 2023
3.2.1. Service Carving Timestamp in A-D per EVI Routes
In case of fast DF recovery of a SA-ES, the Service Carving Timestamp
Extended Community of [I-D.ietf-bess-evpn-fast-df-recovery] may be
carried along with a A-D per EVI route.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Sub-Type(0x0F)| Timestamp Seconds ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Timestamp Seconds | Timestamp Fractional Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Service Carving Timestamp Extended Community
3.2.2. SCT-based WTR Capability Advertisement
The Time Synchronization bit (T bit) of
[I-D.ietf-bess-evpn-fast-df-recovery] may also be carried along with
the A-D per ES route before that SCT-EC is advertised . That T bit
is carried in the DF Election Capabilities Extended Community per
[RFC8584].
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Sub-Type(0x06)| RSV | DF Alg | |A| |T| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bitmap | Reserved = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Time Synchronization (T bit)
In the case where one or more PEs attached to the Ethernet Segment do
not signal T=1 in RT-4, all PEs in the Ethernet Segment SHALL revert
back to the RT-1 per ES routes without the DF Election Capabilities
Extended Community.
In the case where one of the non-adjacent PEs of the ES has signaled
T=1 in its RT-1 per EVI, all PEs in that ES MAY advertise SCT-EC in
their RT-1 per EVI routes. Although other PEs which are non-adjacent
to that ES can't recognize the T bit in RT-1 per EVI route, their
traffic loss will not be worse than current.
Chen & Wang Expires 11 January 2024 [Page 6]
Internet-Draft WTR on Fast DF Recovery July 2023
3.2.3. WTR Advertisement on PE1/PE2
When AC1 recovers and PE1 decides to takeover the DF-role, and PE2
decides to takeover the NDF-role, PE1 will update its A-D per EVI
Advertisement, and carry the SCT-EC and "B=1" along with that A-D per
EVI route. PE2 will not update its previous A-D per EVI route (which
carry the "P=1") until the time indicated by the SCT-EC.
3.2.4. SCT-based WTR Procedures on PE3
When the SCT-EC of a A-D per EVI route still indicate a time in the
future, the SCT-EC will not be used to select the best path for the
corresponding ESI and ET-ID until the time indicated by the SCT-EC.
After the time indicated by the SCT-EC, PE3 will select the A-D per
EVI route with that SCT-EC as the best path for the corresponding ESI
and Ethernet Tag ID, no matter wthether the "B=1" or "P=1" is
signaled along with that A-D per EVI.
In the example of Figure 1:
* When PE3 has two A-D per EVI routes for the same ESI and ET-ID,
one of which carries the "P=1" and the other carries a SCT-EC
whose timestamp indicates a time in the future, the route with the
SCT-EC will not be selected as the best route until the time
indicated by the SCT-EC. After the time indicated by the SCT-EC,
the route with the SCT-EC will be selected as the best route.
* When PE3 has two A-D per EVI routes for the same ESI and ET-ID,
both of which carry the "B=1" along with themselves but one of
which carries a SCT-EC whose timestamp indicates a time in the
future, the route with the SCT-EC will not be selected as the best
route until the time indicated by the SCT-EC.
3.2.5. A-D per EVI Route Advertisement after SCT-Time
Y ms after AC1 actually works as DF-role, PE1 should update the A-D
per EVI route for AC1. In the updated A-D per EVI route, no SCT-EC
should be included, and the P flag should be set.
4. Backwards Compatibility
It is possible that some non-adjacent PEs of a given ES continue to
use the existing RT-1 per EVI route procedures and do not rely on the
new SCT BGP extended community. PEs running a baseline RT-1 per EVI
route procedures will simply discard the SCT BGP extended community
as unrecognized.
Chen & Wang Expires 11 January 2024 [Page 7]
Internet-Draft WTR on Fast DF Recovery July 2023
A PE on a given ES can indicate its willingness to support clock-
synched WTR by signaling the SCT-EC along with the RT-1 per EVI
route. A PE which is not adjacent to that ES may discard the SCT BGP
extended community as unrecognized, thus when the SCT-time comes that
PE will do nothing because its "B=1" will not be updated before SCT-
time. But a little bit later than the SCT-time, that PE will receive
a RT-1 per EVI route with "P=1", and that RT-1 per EVI route will
trigger the revertive FRR switching immediately. At least, this will
not be worse than when the SCT-EC is not advertised.
5. Security Considerations
TBD.
6. IANA Considerations
There is no IANA consideration needed.
7. Normative References
[I-D.ietf-bess-evpn-fast-df-recovery]
Brissette, P., Sajassi, A., Burdet, L. A., Drake, J., and
J. Rabadan, "Fast Recovery for EVPN Designated Forwarder
Election", Work in Progress, Internet-Draft, draft-ietf-
bess-evpn-fast-df-recovery-07, 26 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-fast-df-recovery-07>.
[I-D.ietf-bess-rfc7432bis]
Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan,
"BGP MPLS-Based Ethernet VPN", Work in Progress, Internet-
Draft, draft-ietf-bess-rfc7432bis-07, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
rfc7432bis-07>.
[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>.
[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
Chen & Wang Expires 11 January 2024 [Page 8]
Internet-Draft WTR on Fast DF Recovery July 2023
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M.,
Matsushima, S., and T. Nadeau, "Inter-Chassis
Communication Protocol for Layer 2 Virtual Private Network
(L2VPN) Provider Edge (PE) Redundancy", RFC 7275,
DOI 10.17487/RFC7275, June 2014,
<https://www.rfc-editor.org/info/rfc7275>.
Authors' Addresses
Ran Chen
ZTE Corporation
No. 50 Software Ave, Yuhuatai Distinct
Nanjing
China
Email: chen.ran@zte.com.cn
Yubao Wang
ZTE Corporation
No. 68 of Zijinghua Road, Yuhuatai Distinct
Nanjing
China
Email: wang.yubao2@zte.com.cn
Chen & Wang Expires 11 January 2024 [Page 9]
