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 | [email protected] | +1 613 254 48 14 .:|:.:|:. Cisco Systems Canada Inc. On Tue, Sep 1, 2020 at 1:25 AM Rabadan, Jorge (Nokia - US/Mountain View) < [email protected]> wrote: > Hi Stephane, > > > > Please see in-line with [jorge2]. > > Thank you! > > Jorge > > > > *From: *[email protected] <[email protected]> > *Date: *Monday, August 31, 2020 at 11:49 AM > *To: *Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]>, > [email protected] < > [email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]> > *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) <[email protected]> > > *Sent:* vendredi 19 juin 2020 20:37 > *To:* [email protected]; [email protected]; > [email protected]; [email protected] > *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: *"[email protected]" <[email protected]> > *Date: *Wednesday, February 26, 2020 at 3:20 PM > *To: *"[email protected]" < > [email protected]>, 'BESS' <[email protected]> > *Cc: *"[email protected]" <[email protected]> > *Subject: *Shepherd's Review of draft-ietf-bess-evpn-pref-df > *Resent-From: *<[email protected]> > *Resent-To: *<[email protected]>, <[email protected]>, < > [email protected]>, <[email protected]>, <[email protected]>, < > [email protected]>, <[email protected]> > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
