Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb

[Neeraj Malhotra <[e-mail]>]

Hi Bruno,

Thanks for catching this. Fixed both in the latest revision.

Neeraj

On Mon, May 10, 2021 at 5:54 AM <[e-mail]> wrote:

> Hi Neeraj, co-authors,
>
>
>
> Thanks for taking into account the comments.
>
> -11 addresses my comments.
>
>
>
> Two comments on the new text:
>
> “EVPN Link Bandwidth Extended Community value field is to be treated
>
>    as a 6 octet unsigned integer representing total bandwidth of PE's
>
>    all physical links in an ethernet segment, expressed in Mbits/sec
>
>    (MegabitsPerSecond). »
>
>
>
>
>
> Actually with your latest change introducing the new field “Value-unit”,
> bandwidth is encoded in only 5 octets (not 6). (I’m assuming that the new
> field “Value-unit” is not to be used when computing the ratio of bandwidth
> as this would make no sense).
>
>
>
> §5.2 Does not say anything with regards to the new field “Value-unit”. A
> priori, the ratio of bandwidth is only to be computed on bandwidth/EC using
> the same unit, no?
>
>
>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> *From**:* Neeraj Malhotra [mailto:[e-mail]]
> *Sent:* Saturday, May 8, 2021 1:29 AM
> *To:* Sergey Fomin <[e-mail]>
> *Cc:* DECRAENE Bruno TGI/OLN <[e-mail]>; Rabadan, Jorge
> (Nokia - US/Mountain View) <[e-mail]>;
> [e-mail]; BESS <[e-mail]>
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
>
>
> Hi Sergey, Bruno,
>
>
>
> Many thanks for the detailed review and comments. Discussed with
> co-authors and have enhanced the 'value' encoding to explicitly encode
> weight units as default or generalized as suggested below. I have
> published a revision that incorporates all comments discussed on this
> thread, as well as some additional editorial comments from Jorge. Please
> let me know if there are any additional comments (in particular on section
> 4).
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> On Fri, May 7, 2021 at 12:33 PM Sergey Fomin <[e-mail]> wrote:
>
> Hi Neeraj,
>
> thank you for the feedback.
>
>
>
> I agree that allocating a new code point for every possible calculation
> method would be cumbersome.
>
> How about a middle ground solution, with allocation of just a few values
> (even 2 would suffice: 1 for BW in whatever units we decide; the other
> "catch-all" generalized weight)?
>
> This way operators will get at least basic visibility & cfg. error
> prevention mechanism in place (I have a preference towards explicit
> signaling from ops point of view; but would be glad to hear operators
> opinion on this one).
>
>
>
> My concern with the current text is, while striving for maximum
> flexibility, we may end up in a situation where 2 implementations won't be
> able to interoperate with each other (e.g. vendor X decides to implement
> link BW as a metric, vendor Y decides to implement link count as a metric -
> since support for any method of weight calculation is completely
> optional). I believe we, as a technical community, should give guidance on
> implementing sensible defaults (i.e. "an implementation SHOULD support BW
> weight calculation method") where it makes sense.
>
>
>
> --
>
> Sergey
>
>
>
>
>
> 07.05.2021, 09:18, "Neeraj Malhotra" <[e-mail]>:
>
>
>
> Hi Sergey,
>
>
>
> Thanks for the comments. We would like to avoid adding another code point
> within the value field, as every new encoding of the "weight" will require
> a new code point. Agree that we should specify the default units (for which
> the consensus on the thread appears to be Mbps), but would rather leave it
> to implementations to support any additional units such as number of links,
> configured weight, or anything else, than have a standardized code point
> for each unit. Please let me know if this sounds fine. I will fix the units
> in section 5.2, and the text in section 4.1 as suggested by you and Bruno.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> On Thu, May 6, 2021 at 9:19 PM <[e-mail]> wrote:
>
> Hi Bruno, Jorge, et al.,
>
>
>
> Jorge,
>
> *> Among the co-authors we also discussed the possibility of defining two
> ECs: one for BW and one for a generalized-weight, so that the remote PE can
> catch if the multi-homed PEs were indeed using the same meaning of the
> weight. However, we thought it was easier/simpler to use a generalized
> value in a single EC sub-type, and add the sentence below. *
>
> Have you considered reserving a byte in the value field to signal a weight
> type? Similar to how it is done with DF election framework (and allocate a
> few right away, e.g. 0 for physical link BW, 1 for link count, 2 for
> manually configured weight, ...). This would help not only with interop
> cases, but to prevent & diagnose potential configuration mistakes as well.
>
>
>
> For interop reasons, I would support Bruno & argue that it makes sense to
> use "SHOULD" normative language at least for one way of calculation (e.g.
> BW).
>
>
>
> A couple of minor comments on newly-introduced text in -09 and -10:
>
>    1. Revision -10 introduced a curious change in section 5.2 “Remote PE
>    Behavior”, replacing “1000 Mbps” with “1000 megabytes” in an example. It is
>    not correct in the current form, since right above it there is an explicit
>    statement that links are Gigabit Ethernet: *"As an example, for a CE
>    dual-homed to PE-1, PE-2, PE-3 via 2, 1, and 1 GE physical links
>    respectively".*
>
> (keeping the Mbps units there would be appropriate, since this is a weight
> calculation, not a community encoding example)
>
>    1. Section 4.1 “Usage of EVPN Link Bandwidth Extended Community”:
>
> *“An implementation may support one or more of the above ways of encoding
> the value."* -> I would assume this should be "MUST support at least
> one", since every other possible option is included in bullet#2?
>
>
>
> --
>
> Sergey
>
> *From:* BESS <[e-mail]> *On Behalf Of *
> [e-mail]
> *Sent:* Thursday, May 6, 2021 5:46 AM
> *To:* Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>;
> Neeraj Malhotra <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
> Hi Jorge,
>
>
>
> Thanks for the feedback.
>
>
>
> Regarding the first point, I can live with the current text. But I think I
> would prefer that the text favour one option, and leave it to the
> responsibility of the SP for others usages. E.g.
>
>
>
> OLD:
>
> EVPN Link Bandwidth Extended Community value field is to be treated
>
>    as a 6 octet unsigned integer that may be set to:
>
>
>
>    o  total bandwidth of PE's all physical links in an ethernet segment,
>
>       expressed in bytes/sec.
>
>
>
>    o  or a generalized weight that may be set to link count, locally
>
>       configured weight, or a value computed based on an attribute other
>
>       than link bandwidth.
>
>
>
>    An implementation may support one or more of the above ways of
>
>    encoding the value.  Operator MUST ensure consistent encoding of this
>
>    value across all PEs in an ethernet segment.  Procedures related to
>
>    signaling and handling of this extended community defined in this
>
>    document use "total bandwidth in bytes/sec" encoding as an example to
>
>    illustrate its usage.
>
>
>
> NEW:
>
>    EVPN Link Bandwidth Extended Community value field is to be treated
>
>    as a 6 octet unsigned integer representing total bandwidth of PE's all
> physical links in an ethernet segment,
>
>       expressed in bytes/sec.
>
>
>
> Note however that the load balancing algorithm defines in this document
> uses ratio of Link Bandwidths hence the operator may choose a different
> unit or use the community as
>
>     a generalized weight that may be set to link count, locally
>
>       configured weight, or a value computed based on an attribute other
>
>       than link bandwidth. In such case, the operator MUST ensure
> consistent usage of the unit
>
> across all PEs in an ethernet segment. This may involve multiple routing
> domains/Autonomous Systems.
>
>
>
>
>
> But I leave this to you.
>
>
>
> Thanks,
>
> --Bruno
>
>
>
> *From:* Rabadan, Jorge (Nokia - US/Mountain View) [
> mailto:[e-mail] <[e-mail]>]
> *Sent:* Thursday, May 6, 2021 10:36 AM
> *To:* DECRAENE Bruno TGI/OLN <[e-mail]>; Neeraj Malhotra
> <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
> Hi Bruno,
>
>
>
> Thanks for your comments.
>
>
>
> About the first point, we do have use cases where the bandwidth is not
> what we want to encode in the EC but rather a generalized weight that is
> derived from the link count, logical weight or simply a configured value.
> Among the co-authors we also discussed the possibility of defining two ECs:
> one for BW and one for a generalized-weight, so that the remote PE can
> catch if the multi-homed PEs were indeed using the same meaning of the
> weight. However, we thought it was easier/simpler to use a generalized
> value in a single EC sub-type, and add the sentence below.
>
>
>
> The sentence can be modified/fixed. But the gist is that the multi-homed
> PEs may support multiple meanings for the weight (BW, link-count, etc), but
> at least one of those MUST be common across all PEs and the multi-homed
> routes must use it consistently. Would it be enough if we fix it?
>
>
>
> About existing implementations, a new EVPN sub-type was defined only a
> couple of revisions ago, where, before, the existing non-transitive link BW
> EC was used, so there’s been some churn in the use of the EC anyway. I
> think it is important to get it as soon as possible, but get it right
> rather than finding gaps later once the document is done. But let us know
> your thoughts too.
>
>
>
> Thank you.
>
> Jorge
>
>
>
>
>
> *From: *BESS <[e-mail]> on behalf of
> [e-mail] <[e-mail]>
> *Date: *Thursday, May 6, 2021 at 10:04 AM
> *To: *Neeraj Malhotra <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
> Hi Neeraj,
>
>
>
> Thanks for considering my comments.
>
> Much better from my perspective. Thank you.
>
>
>
> I have two comments on the changes:
>
> - Regarding deployments
>
> §4.1 allows two rather incompatible encodings/usages with no way to detect
> which one is used: some PE could advertise the bandwidth in bytes, while
> some other PE could advertise a general weight. I understand that both
> works, but to me there is a significant risk of issues over time or between
> domain/SP. I’d prefer that you only chose one in order to favour
> consistency in deployments and usage and I would prefer the real bandwidth
> (at least for consistency with the name of the community, but also because
> this is not subjective)  (And if a SP really wants to put an arbitrary
> value, I think he will figure out by himself, that it can do so).
>
> If you disagree with the above, then I would have a comment on the two
> below sentences:
>
> An implementation may support one or more of the above ways of
>
>    encoding the value.  Operator MUST ensure consistent encoding of this
>
>    value across all PEs in an ethernet segment.
>
> Logic dictates that the second sentence (MUST) can only be fulfilled if
> the first sentence mandates that all implementations MUST support both
> options, or one specifically defined.
>
>
>
> - Regarding existing implementations:
>
> previous version of the draft did not really specify the format of the
> EVPN EC. I had personally assumed that the format was similar to the
> draft-ietf-idr-link-bandwidth link bandwidth community hence encoded in
> IEEE floating point format. Latest version of the draft defines it in
> unsigned integer. Integer looks good to me, but for an existing
> implementation this may be seen as an incompatible change very late in the
> process. Obviously, if there are no implementation, there is no issue. In
> which case, you could also express the bandwidth in unit of bit/s _*if
> you*_ wish to. (I have no preference). However given that the draft had
> indicated a codepoint, there seem to be a risk of existing implementations
> hence incompatible change. BTW the codepoint is squatted even though the
> registry is FCFS hence easy to request.
>
>
>
> Thanks,
>
> --Bruno
>
>
>
>
>
> *From:* Neeraj Malhotra [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Thursday, May 6, 2021 7:41 AM
> *To:* DECRAENE Bruno TGI/OLN <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
>
>
> Hi Bruno,
>
>
>
> Many thanks for the review comments. We have revised the draft addressing
> your comments.
>
>
>
> More inline.
>
>
>
> Thanks,
>
> Neeraj
>
>
>
> On Mon, May 3, 2021 at 2:20 AM <[e-mail]> wrote:
>
> Hi Stéphane, authors,
>
>
>
> I have not followed the discussions on this document, but I’ll nonetheless
> raise one point  regarding the bandwidth community (better safe than sorry).
>
> - why has [BGP-LINK-BW] been moved to informational reference while its
> reading seem mandatory?
>
>
>
> [NM]: There was a leftover reference to this in one of the sections that
> has been fixed now to use new EVPN EC. With this, reference to
> [BGP-LINK-BW] is purely informational (as was intended).
>
>
>
> - A new EVPN Link Bandwidth extended community is defined, but I could not
> find its specification. I guess that this is the same format as
> [BGP-LINK-BW] but transitive. Could this be explicitly stated?
>
>
>
> [NM]: clarified in section 4.
>
>
>
> - [BGP-LINK-BW] advertises the bandwidth in unit of bytes (not bits!) per
> second. Could the unit of the new EVPN Link Bandwidth extended community be
> also clearly spelled out? Especially give the history on this (cf below).
> Also in order to avoid misleading the readers could the examples use the
> correct unit (vs bits per seconds as writen)
>
>
>
> [NM]: done.
>
>
>
> - 10 years ago or so, I had raised a similar point (distinction between
> bits and bytes) on [BGP-LINK-BW] in the IDR WG. And it turned out that 1
> major implementation had implemented and deployed “bytes per second” as per
> the spec, while another implementation had implemented and deployed “bits
> per second” which is the typical unit of link bandwidth. Given the
> deployments, none was willing to change its implementation as it would be a
> non-backward compatible change with themselves. What’s the status on this?
> Could we have an implementation status on this?
>
>
>
> [NM]: I don't have this information. Perhaps someone else could comment.
>
>
>
>
>
> Thanks
>
> Regards,
>
> --Bruno
>
>
>
>
>
> *From:* BESS [mailto:[e-mail]] *On Behalf Of *
> [e-mail]
> *Sent:* Monday, May 3, 2021 9:21 AM
> *To:* [e-mail]
> *Subject:* [bess] New short WGLC for draft-ietf-bess-evpn-unequal-lb
>
>
>
> Hi WG,
>
>
>
>
>
> We got final updates from authors on draft-ietf-bess-evpn-unequal-lb.
>
>
>
> I'm opening a new short Working Group Last Call (to be closed on 5/10) to
>
> get any last comments before moving to the next step.
>
> However, the document having normative references to EVPN PREF DF, and PER-MCAST-FLOW-DF, the draft will not be sent to IESG until these drafts are ready.
>
>
>
>  Feel free to send comments to the list before next Monday.
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Stephane
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/
>
>
>
>
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> ,
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>