Jorge,
Lots of thanks for a very encouraging response!
Regards,
Sasha
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com>
Sent: Wednesday, July 6, 2022, 17:11
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Cc: bess@ietf.org <bess@ietf.org>; draft-ietf-bess-evpn-pref-df....@ietf.org
<draft-ietf-bess-evpn-pref-df....@ietf.org>
Subject: [EXTERNAL] Re: Queries on draft-ietf-bess-evpn-pref-df
Hi Sasha,
Sorry for the big delay.
That was indeed a bug, fixed in version 09, just posted.
Thank you very much for letting us know.
Thanks.
Jorge
From: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Date: Monday, February 21, 2022 at 4:04 PM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-pref-df....@ietf.org
<draft-ietf-bess-evpn-pref-df....@ietf.org>
Subject: RE: Queries on draft-ietf-bess-evpn-pref-df
Jorge,
Lots of thanks for your response and apologies for my delay.
My colleagues and I have yet another question pertaining to non-preemptive mode
of preference-based DF election.
The draft says that if the administrative preference of the “recovering” PE is
neither higher than that of the “highest PE” nor lower than that of “lowest
PE”, the “recovering” PE shall advertise its EVPN Type 4 with its
administrative preference and DP set to 1.
To me this means that if all the PEs have been configured with the same
preference and “don’t preempt me”, the recovering PE would preempt the current
DF if its PE-IP address happens to be lower than that of the current DF.
This situation could be easily avoided if the checks would be for “higher or
equal” for the “highest PE” and “lower or equal” for the “lowest PE” and not as
in the draft.
What, if anything, did I miss?
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@rbbn.com
From: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com>
Sent: Sunday, February 6, 2022 1:41 PM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>;
draft-ietf-bess-evpn-pref-df....@ietf.org
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: Queries on draft-ietf-bess-evpn-pref-df
Hi Sasha,
Sorry for the delay, this email fell through the cracks..
Please see in-line.
Thanks for the feedback.
Jorge
From: Alexander Vainshtein
<alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>
Date: Thursday, December 9, 2021 at 1:12 PM
To:
draft-ietf-bess-evpn-pref-df....@ietf.org<mailto:draft-ietf-bess-evpn-pref-df....@ietf.org>
<draft-ietf-bess-evpn-pref-df....@ietf.org<mailto:draft-ietf-bess-evpn-pref-df....@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Queries on draft-ietf-bess-evpn-pref-df
Hi,
I have a few questions with regard to
draft-ietf-bess-evpn-pref-df<https://clicktime.symantec.com/37ewCUKVGbh8X8MfAqTwzjU6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-pref-df-08>:
1. The first statement in Section 4.4 of the draft says that “a
capability to NOT preempt the existing DF for a given Ethernet Tag is required
and therefore added to the DF Election extended community”. This statement
looks problematic to me because:
a. Section 2.2 of RFC
8584<https://clicktime.symantec.com/3HQMSxs53p4ou5AY9C168dE6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8584%23section-2.2>
says that “A PE SHOULD attach the DF Election Extended Community to any
advertised ES route”
b. To the best of my understanding, the ES route in the quoted statement
means an EVPN Ethernet Segment (Type 4) route defined in Section-7.4 of RFC
7432<https://clicktime.symantec.com/38bwvVphDuuzE8PmMmfv97g6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7432%23section-7.4>
c. The NLRI of this route does not contain information about any
Ethernet Tag and, to the best of my understanding, just a single copy of this
route per MH ES to which a given PE is attached is advertised by the PE
d. My conclusion is that non-preemption of the existing DF can be only
advertised per ES/virtual ES and can only be applied to all EVI and all
Ethernet tags that are attached to this MH ES. Is this understanding correct?
i. If not, can you please clarify what I am
missing
ii. If yes, may I suggest that you update the
draft accordingly?
[jorge] yes, that’s a fair point. We changed the text to:
“a capability to NOT preempt the existing DF (for all the Ethernet Tags in the
ES) is required and therefore added to the DF Election extended community.”
2. The description of the non-preemptive DF Election procedure in item#5
of Section 4.4. of the draft says that, upon recovery of a previously failed
multi-homed ES, the supporting PE shall start a bott timer (or a hold timer)
that is “applied between the INIT and the DF_WAIT states in the DF Election
Finite State Machine described in [RFC8584]”. From my POV:
a. This description is equivalent to introduction of a new state in the
DF Election Finite State Machine defined in Section 2.2 of RFC 8584
[jorge] I think the use of a boot timer is a normal practice in any multihoming
scenario (not only EVPN based), so that the PE starts the multi-homing
procedures only when the infrastructure protocols are up and running. As an
example, this boot timer would prevent a PE from running DF Election and take
over too soon, if the underlay IGP has not converged yet or BGP is still
converging. As such, IMO it is applicable to any DF Election and not only this
document. Maybe a topic for rfc-7432bis?
b. As a consequence, a formal definition of the modified DF Election
Finite State Machine should be added to the draft, preferably preserving the
style of RFC 8584. The following points require explicit clarification IMHO:
i. In which cases the new DF Election FSM
should be used (e.g., I assume that it should not be used if non-preemptive DF
election mode is not configured). One scenario that deserves special attention
is the scenario in which Non-Preemptive DF Election mode has been advertised by
some, but not all PEs attached to the specific MH ES
ii. Whether the ES route for the recovered ES
representative eventually should be re-advertised with the configured
preference and configured DF mode, and, if yes, when should this happen.
[jorge] as discussed above, if the boot timer is applicable to all DF Algs (I
think it is), that modification may belong to rfc-7432bis instead. This
document should focus on the DF Election Algorithm details only. Also, about
the mix of non-revertive and revertive PEs in the same ES, the text strongly
recommends not to do that.
Your timely feedback will be highly appreciated.
Regards, and lots of thanks in advance,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments.
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments.
Notice: This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential and/or
proprietary for the sole use of the intended recipient. Any review, disclosure,
reliance or distribution by others or forwarding without express permission is
strictly prohibited. If you are not the intended recipient, please notify the
sender immediately and then delete all copies, including any attachments.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess