Hi Jorge,
Sorry for the imprecise language, this was indeed about Highest-Preference vs.
Lowest-Preference algo.
Seems we can agree on Option 2.
I think my wording below betrayed what my preference was đ and option 2 is
definitely the best approach in my book (easiest backward-compatibility and
fallback to 7432).
Itâs obviously best to have values 2 & 3 side by side but I acknowledge that
may not be possible... TBD for the Algo value is fine for now.
I *think* 3 is free, the only place I see it mentioned is in the Multicast-DF
draft and thatâs claiming 4 & 5. It refers to 3 which is actually just the
NTP-capability flag not a DF-Algo.
Regards,
Luc André
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>
Date: Monday, March 8, 2021 at 11:02
To: Luc André Burdet <laburdet.i...@gmail.com>, "slitkows.i...@gmail.com"
<slitkows.i...@gmail.com>
Cc: "draft-ietf-bess-evpn-pref...@ietf.org"
<draft-ietf-bess-evpn-pref...@ietf.org>, "bess-cha...@ietf.org"
<bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df
Hi Luc,
Thanks for your email.
A few comments:
1. You mention the lowest-ip vs highest-ip debate, but I donât think there
is any debate about the PEâs IP. In the document the PEâs IP is used as a last
resort tie-breaker, and it is always the lowest IP the one chosen assuming
Preference and DP are equal. There was never ambiguity about that. If you want
to use the lowest vs highest IP as the input for DF election I would suggest
you use another Alg value and define it. However I donât see much value on it,
since the PEâs IP is not very useful for DF election (it is not easy to change
and it is common to all the ESes).
1. Then you are talking about highest vs lowest weight. I *guess* you mean
the âDF Preferenceâ value? Note there is no âweight" defined in
draft-ietf-bess-evpn-pref-df
1. Assuming (2) is a yes, about your three options:
* Iâm personally ok to signal highest vs lowest preference (option 2). I
can make the change and run it by the other authors.
* I think Option 3 has issues since, remember there have been
implementations for quite a long time now, and those implementations didnât use
any flag to indicate lowest-pref.
* If you do this with option (3), suppose you have an existing
implementation using type 2 with flag=0 (PE1), and a new one using type 2 with
flag=1 (PE2).
* When PE1 and PE2 exchange ES routes, you want them to fall back to
default Alg as in RFC8584. However PE1 will never do that.
* If we do (2), PE1 and PE2 can fall back to the default Alg.
1. Suppose we agree on defining a new Alg for lowest-preference. Note that
value 3 *may not* be available. For the moment we should use a TBD value.
About the âDâ capability, this document should state that it does not change
anything for Alg 0 or 1, which are the ones in RFC8584. Other documents will
have to define whether âDâ applies to other DF types other than 2 (and the new
TBD for lowest-preference).
Let me know your thoughts please.
Thanks.
Jorge
From: Luc André Burdet <laburdet.i...@gmail.com>
Date: Wednesday, March 3, 2021 at 2:42 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>,
slitkows.i...@gmail.com <slitkows.i...@gmail.com>
Cc: draft-ietf-bess-evpn-pref...@ietf.org
<draft-ietf-bess-evpn-pref...@ietf.org>, bess-cha...@ietf.org
<bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>
Subject: Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df
Hi Jorge,
Stéphane, Satya and I have gone over this draft again and propose the following
regarding the Lowest-IP vs. Highest-IP debate.
Option 1
Pick one, e.g. draft explicitly states highest-weight wins. Removes all
ambiguity.
Option 2:
Support Lowest-weight and Highest-weight both, and it must be signaled.
Signaling is done using DF-Algorithm types:
- DF-Type=2 : Preference-DF, Highest-weight
- DF-Type=3 : Preference DF, Lowest-weight
. Example/precedent for this approach:
draft-ietf-bess-evpn-per-mcast-flow-df-election
claims 2 DF-Types for each S,G and *,G DF election (ignoring that the draft
is in serious need of revision)
. 7432-fallback if non-agreement (type2<>type3)
. forward-compatible with existing implementations: DF-Type 2 with default
Highest-wt.
Option 3:
Support Lowest-weight and Highest-weight both, and it must be signaled.
Signaling is done using a Flag in the DF-Elect extcomm
- DF-Type=2 : Preference-DF
- DF-Elect ExtComm: specify a Flag: 0=Highest, 1=Lowest.
. 7432-fallback if non-agreement (flag) is more complicated on an EC
. doesnâ match other WG documentsâ approach
. forward-compatible with existing implementations: DF-Type 2 with Fl=0.
. minimal support would be alarming based on flag mismatch
. must use âReservedâ and NOT capability bitmap because that would require
analysis against all other DF Algo modes.
Speaking for myself, I would add that âDâ bit capability is a generic flag
across DF Type Algos. Evaluation against all existing DF-types must be done
but... I would remove the âall other DF-types SHOULD ignoreâ.
Many other DF types may want to leverage and I think it is a good addition as a
generic capability..
Regards,
Luc André
Luc André Burdet | Cisco | laburdet.i...@gmail.com | Tel: +1 613 254 4814
From: Luc André Burdet <laburdet.i...@gmail.com>
Date: Wednesday, November 18, 2020 at 14:05
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>,
"slitkows.i...@gmail.com" <slitkows.i...@gmail.com>
Cc: "draft-ietf-bess-evpn-pref...@ietf.org"
<draft-ietf-bess-evpn-pref...@ietf.org>, "bess-cha...@ietf.org"
<bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df
Hi Stéphane, Jorge,
On the issue of tie-breaking, I would agree with Stéphane.
It is too easy for peering PEs to be misconfigured / in disagreement as to Hi
or Lo and this should be signaled if at least in an error reporting capacity.
I would propose to go even further. This DF Election algorithm compares fields
in a given order:
· Field 1: Preference Weight
· Field 2: IP Address Tie-break if Field1 is a tie, and hope all PEs
use same Hi or Lo.
The algorithm could be made very generic in terms of tie break and provide for
a cascading order or skipping a field entirely:
· Field 1: Preference Weight
· Optional Tie-break Method X: IP Address Field, Highest-IP
· Optional Tie-break Method Y: IP Address Field, Lowest-IP
· Optional Tie-break Method Z: Local-Policy ( see section 4.1(g) )
We could potentially mandate at least one MUST be provided and signaled incl
order of resolving tie-break?
Basically my point is that IP is unique but also an arbitrary Field to use,
many more could be better suited for tie-break dép. use-case. There are
practical examples where local policies will affect weight but perhaps that
local-policy itself serves as a tie-break.
One could split the Reserved field of section 3 into 2 nibbles: Tie-break-1,
Tie-break-2 for mismatch detection, and this draft defines "well-known values"
IP-Hi=0 and IP-Lo=1 (leaving all others to implementation-specific values
(non-assigned) and ONLY for error detection.
Luc André Burdet | laburdet.i...@gmail.com<mailto:laburdet.i...@gmail.com> | +1
613 254 48 14
.:|:.:|:. Cisco Systems Canada Inc.
On Tue, Sep 1, 2020 at 1:25 AM Rabadan, Jorge (Nokia - US/Mountain View)
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote:
Hi Stephane,
Please see in-line with [jorge2].
Thank you!
Jorge
From: slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>
<slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>>
Date: Monday, August 31, 2020 at 11:49 AM
To: Rabadan, Jorge (Nokia - US/Mountain View)
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>,
draft-ietf-bess-evpn-pref...@ietf.org<mailto:draft-ietf-bess-evpn-pref...@ietf.org>
<draft-ietf-bess-evpn-pref...@ietf.org<mailto:draft-ietf-bess-evpn-pref...@ietf.org>>,
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>,
bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: Shepherd's Review of draft-ietf-bess-evpn-pref-df
Hi Jorge,
Please find additional feedback inline.
(Stripping things we agree on)
Stephane
From: Rabadan, Jorge (Nokia - US/Mountain View)
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Sent: vendredi 19 juin 2020 20:37
To: slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>;
draft-ietf-bess-evpn-pref...@ietf.org<mailto:draft-ietf-bess-evpn-pref...@ietf.org>;
bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>;
bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: Shepherd's Review of draft-ietf-bess-evpn-pref-df
Hi Stephane,
Thanks for the review and my apologies for the delay.
We just posted a new revision.
As usual, very good points. Please see in-line.
Thx
Jorge
From: "slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>"
<slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>>
Date: Wednesday, February 26, 2020 at 3:20 PM
To:
"draft-ietf-bess-evpn-pref...@ietf.org<mailto:draft-ietf-bess-evpn-pref...@ietf.org>"
<draft-ietf-bess-evpn-pref...@ietf.org<mailto:draft-ietf-bess-evpn-pref...@ietf.org>>,
'BESS' <bess@ietf.org<mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>"
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>
Subject: Shepherd's Review of draft-ietf-bess-evpn-pref-df
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>,
<senthil.sathap...@nokia.com<mailto:senthil.sathap...@nokia.com>>,
<p...@juniper.net<mailto:p...@juniper.net>>,
<w...@juniper.net<mailto:w...@juniper.net>>,
<jdr...@juniper.net<mailto:jdr...@juniper.net>>,
<saja...@cisco.com<mailto:saja...@cisco.com>>,
<satya...@cisco.com<mailto:satya...@cisco.com>>
Resent-Date: Wednesday, February 26, 2020 at 3:20 PM
Section 4.1:
â Note that, by default, the Highest-Preference is chosen for each
ES or vES, however the ES configuration can be changed to the
Lowest-Preference algorithm as long as this option is consistent
in all the PEs in the ES.
I donât think it is a good idea to open this modification. People can play with
preference values to achieve the required behavior while always keeping high
pref.
We have no way to ensure consistency, except if we advertise the behavior as
part of the exct. Consistency of DF election is key and needs to be ensured as
much as we can.
[Jorge] the idea is have the highest preference as default (maybe use normative
language?), which means that it will work fine. Opening to lowest is to give
more flexibility, knowing that if the user has to change the config from the
default, they will do it in all the PEs of the ES.
[SLI] I donât think this is a good idea, consistency is really important, if
you absolutely want to do both lowest and highest, you can allocate a new DF
Alg for lowest so we ensure that everybody uses the same algorithm. But I donât
think this is necessary, having highest preference is enough. I donât remember
any feature using a preference that can do both highest and lowest, it is
usually one or the other.
[Jorge2] ok, we can leave just the highest-preference in section 4.1. Weâll fix
it in the next revision. Note that in 4.2 we still need to have highest and
lowest pref per ethernet tag range to make sure there is load balancing.
âWhen PE3's vES2 comes back up, PE3 will start a boot-timer (if
booting up) or hold-timer (if the port or EVC recovers). That
timer will allow some time for PE3 to receive the ES routes from
PE1 and PE2. »
Are you changing the way the DF election works ? Usually, PE advertises its
route and then wait to receive other routes.
[Jorge] those timers are on top of the FSM defined in RFC8584, e.g. we need to
give some extra time before the ES goes up and we advertise the ES route, if
the ES is configured with the DP capability. This is because the advertised
preference and DP values may not be the same as the configured ones, and the
âin-useâ values will depend on the other ES routes in the ES. If we advertise
the ES route immediately after the ES is up, we may not have received the other
ES routes and we donât know what âin-useâ values to advertise in order to avoid
preemption in the ES. I added some text on point 5 (section 4.3).
[SLI] As we are updating the FSM, could we have new state and events defined to
update the FSM similarly as we have in RFC8584 ?
[jorge2] not sure if we should update the FSM, the reason being that those hold
timers are generic for any redundancy mechanism, to avoid attracting traffic
from the access before the core IGP/BGP are up and have all the required routes
available. Some implementations use fixed timers, others configurable timers,
others watch when the IGP/BGP come up and leave an additional delta. I thought
the current text is generic enough to allow all those implementations.
What happens if all PEs on the ES are failing at the same time or the ES
booting up on all the PEs at the same time ? you have no way to hear what is
the pref from the remote.
[Jorge] The non-revertive capability makes sense when there is at least one PE
alive in the ES and we donât want to preempt it so that there is no traffic
impact. If all the PEs fail, there is traffic impact anyway, so there is really
no non-revertive behavior, but an initialization in all the PEs.
[SLI] Letâs say that you have a CE attached to 3 PEs (same ESI). PE1 pref 100,
PE2 pref 200, PE3 pref 300. PE1 to 3 are configured with DP set. PE4 is a
remote PE.
T0:CE fails and boots up.
T1:PE1 to PE3 starts their HOLD_TIMER
T2: PE1 HOLD_TIMER expires, advertises ES route and starts DF_TIMER
T3: PE4 discovers ES from PE1 and starts DF_TIMER
[jorge2] I assume you mean PE3 here.
T4: PE2 HOLD_TIMER expires, advertises ES route and starts DF_TIMER, does it
advertises with Pref100 and DP=0 as it knows from PE1 route even if PE1 is not
DF yet ?
[jorge2] this is an example in which all PEs are âinitializingâ at the same
time, so there is traffic impact anyway because the CE reboots. So it would be
more like an initialization example. Nevertheless, PE2 in this case should
advertise the ES route with in-use pref 100 and DP=0.
Brgds,
Stephane
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
