Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df

[Luc André Burdet <[e-mail]>]

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 | [e-mail] | [phone]
.:|:.:|:. Cisco Systems Canada Inc.


On Tue, Sep 1, 2020 at 1:25 AM Rabadan, Jorge (Nokia - US/Mountain View) <
[e-mail]> wrote:

> Hi Stephane,
>
>
>
> Please see in-line with [jorge2].
>
> Thank you!
>
> Jorge
>
>
>
> *From: *[e-mail] <[e-mail]>
> *Date: *Monday, August 31, 2020 at 11:49 AM
> *To: *Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *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) <[e-mail]>
>
> *Sent:* vendredi 19 juin 2020 20:37
> *To:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *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: *"[e-mail]" <[e-mail]>
> *Date: *Wednesday, February 26, 2020 at 3:20 PM
> *To: *"[e-mail]" <
> [e-mail]>, 'BESS' <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Shepherd's Review of draft-ietf-bess-evpn-pref-df
> *Resent-From: *<[e-mail]>
> *Resent-To: *<[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>