Thank you Matthew, will update shortly
Regards,
Luc André
Luc André Burdet | lbur...@cisco.com<mailto:lbur...@cisco.com> | Tel: +1
613 254 4814
From: Bocci, Matthew (Nokia - GB)
Date: Monday, August 8, 2022 at 10:46
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org
, bess@ietf.org
Subject: Document shepherd review of draft-ietf-bess-evpn-fast-df-recovery-05
Authors
As is customary, please find below my document shepherd review of this draft.
The comments are mainly of an editorial nature or suggest improvements to aid
readability.
Please treat these comments (prepended with MB>) as you would any other working
group last call comments.
Best regards
Matthew
===
Fast Recovery for EVPN Designated Forwarder Election
draft-ietf-bess-evpn-fast-df-recovery-05
Abstract
Ethernet Virtual Private Network (EVPN) solution provides Designated
MB> /Ethernet/The Ethernet
Forwarder election procedures for multihomed Ethernet Segments.
These procedures have been enhanced further by applying Highest
Random Weight (HRW) Algorithm for Designated Forwarded election in
order to avoid unnecessary DF status changes upon a failure. This
draft improves these procedures by providing a fast Designated
MB> /draft/document
Forwarder (DF) election upon recovery of the failed link or node
associated with the multihomed Ethernet Segment. The solution is
independent of number of EVIs associated with that Ethernet Segment
MB> /of number/of the number
and it is performed via a simple signaling between the recovered PE
and each of the other PEs in the multihoming group.
[...]
1. Introduction
Ethernet Virtual Private Network (EVPN) solution [RFC7432] is
MB> /Ethernet/The Ethernet
becoming pervasive in data center (DC) applications for Network
Virtualization Overlay (NVO) and DC interconnect (DCI) services, and
in service provider (SP) applications for next generation virtual
private LAN services.
[...]
The EVPN specification [RFC7432] describes DF election procedures for
MB> I think you just need to say [RFC7432] describes...
multihomed Ethernet Segments. These procedures are enhanced further
in [RFC8584] by applying Highest Random Weight Algorithm for DF
election in order to avoid DF status change unnecessarily upon a link
or node failure associated with the multihomed Ethernet Segment.
MB> I found the above hard to parse. Maybe replace it with:
"These procedures are enhanced further
in [RFC8584] by applying Highest Random Weight Algorithm for DF
election in order to avoid unnecessary DF status changes upon a link
or node failure associated with the multihomed Ethernet Segment."
[...]
1.1. Terminology
Provider Edge (PE): A device that sits in the boundary of Provider
and Customer networks and performs encap/decap of data from L2 to
L3 and vice-versa.
MB> Not sure you need to define PE as it is a well known term, but in any case
I think
Your definition differs from ones I could find I previous RFCs. Maybe you can
just delete it.
Designated Forwarder (DF): A PE that is currently forwarding
(encapsulating/decapsulating) traffic for a given VLAN in and out
of a site.
2. Challenges with Existing Solution
In EVPN technology, multiple PE devices have the ability to encap and
decap data belonging to the same VLAN. In certain situations, this
may cause L2 duplicates and even loops if there is a momentary
overlap of forwarding roles between two or more PE devices, leading
to broadcast storms.
EVPN [RFC7432] currently uses timer based synchronization among PE
devices in redundancy group that can result in duplications (and even
loops) because of multiple DFs if the timer is too short or
blackholing if the timer is too long.
Using split-horizon filtering (Section 8.3 of [RFC7432]) can prevent
loops (but not duplicates), however if there are overlapping DFs in
MB> I suggest you split the sentence to make it more readable:
"...(but not duplicates). However, if there are..."
two different sites at the same time for the same VLAN, the site
identifier will be different upon re-entry of the packet and hence
the split-horizon check will fail, leading to L2 loops.
[...]
However, upon PE insertion or port bring-up (recovery event), HRW
MB> Do you mean "...or port bring-up following a recovery event,"?
also cannot help as a transfer of DF role to the newly inserted
device/port must occur while the old DF is still active.
+-+
+-+| |
| || |
/ |PE1 || | +-+
/ | || MPLS/ | | |---CE3
/ +-+| VxLAN/
