Re: [bess] Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11: (with DISCUSS and COMMENT)

[Warren Kumari <[e-mail]>]

On Fri, Oct 06, 2023 at 3:53 PM, Jorge Rabadan <[e-mail]>
wrote:

> Hi Warren,
>
>
>
> Thank you for reviewing.
>
>
>
> We published version 12, which hopefully addresses most of the comments
> and discuss.
>
>
>
> About why two algorithms:
>
>
>
> Initially only highest-preference was defined and implemented, however,
> there was feedback from the Shepherd and others in the WG that defining the
> Lowest-Preference algorithm would provide more flexibility for the
> operator. For instance, the operator could define the same preference value
> for two Ethernet Segments in a PE1, but, by using highest-preference in ES1
> and lowest-preference in ES2, we could achieve different DF election
> results per Ethernet Segmen and therefore have some DF distribution.
>


Urgh, that sounds very much like creeping featurism, but if the WG has
consensus that the additional complexity is worth the win, then ¯\_(ツ)_/¯.

I hadn't considered the "if you set one high and one low you get DF
distribution" aspect, nor did I see this explained in the doc (but perhaps
I missed it).

It seems like it would be *mush* less confusing to just set the priorities
how you want them, but…

It still all seems like needless additional operational complexity, but, if
the WG has consensus on this, I'll clear…

W



>
> Other than that, there is no difference between both, they are
> functionally equivalent. Only that one selects the highest value, and the
> other the lowest one.
>
>
>
> Since the algorithm itself is signaled in the ES routes, and we explain
> how inconsistencies among PEs are handled, we think there is no additional
> complexity or risks.
>
>
>
> If the above explanation is not enough, could you suggest any kind of text
> or guidance that could help clear your DISCUSS?
>
>
>
> Thank you!
>
> Jorge
>
>
>
>
>
> *From: *Warren Kumari via Datatracker <[e-mail]>
> *Date: *Monday, August 7, 2023 at 3:55 PM
> *To: *The IESG <[e-mail]>
> *Cc: *[e-mail] <draft-ietf-bess-evpn-pref-df@
> ietf.org>, [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, Stephane Litkowski <[e-mail]>, slitkows.
> [e-mail] <[e-mail]>
> *Subject: *Warren Kumari's Discuss on draft-ietf-bess-evpn-pref-df-11:
> (with DISCUSS and COMMENT)
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URLnok.it/ext for additional
> information.
>
>
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-bess-evpn-pref-df-11: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-pref-df/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Why are there two algorithms (Highest-Preference and Lowest-Preference)?[0]
> This seems operationally dangerous and will lead to additional operational
> complexity, tricky to debug behaviors, additional implementation
> complexity,
> etc. Assuming that there *is* a good reason (and "Well, we couldn't
> decide,,
> so... ¯\_(ツ)_/¯" isn't one) these should be a section helping operators
> decide
> which algorithm they should deploy, and the pro's and con's of each.
>
> [0]: I did try and find this, but the closest I got was a note in the
> Shepherd
> Writeup saying: "There was a "last minute" agreement on managing the
> highest/lowest pref algorithm using different DF algs rather than a single
> one+local configs." -- this doesn't actually answer the question.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support John Scudder's DISCUSS, as well as his comments -- the
> Introduction
> seems quite incomplete, and just sort of throws the reader into the deep
> end.
>