Hi Bruno, Thanks for catching this. Fixed both in the latest revision.
Neeraj On Mon, May 10, 2021 at 5:54 AM <bruno.decra...@orange.com> 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:neeraj.i...@gmail.com] > *Sent:* Saturday, May 8, 2021 1:29 AM > *To:* Sergey Fomin <i...@sergey.dev> > *Cc:* DECRAENE Bruno TGI/OLN <bruno.decra...@orange.com>; Rabadan, Jorge > (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; > slitkows.i...@gmail.com; BESS <bess@ietf.org> > *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 <i...@sergey.dev> 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" <neeraj.i...@gmail.com>: > > > > 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 <i...@sergey.dev> 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 <bess-boun...@ietf.org> *On Behalf Of * > bruno.decra...@orange.com > *Sent:* Thursday, May 6, 2021 5:46 AM > *To:* Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; > Neeraj Malhotra <neeraj.i...@gmail.com> > *Cc:* slitkows.i...@gmail.com; bess@ietf.org > *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:jorge.raba...@nokia.com <jorge.raba...@nokia.com>] > *Sent:* Thursday, May 6, 2021 10:36 AM > *To:* DECRAENE Bruno TGI/OLN <bruno.decra...@orange.com>; Neeraj Malhotra > <neeraj.i...@gmail.com> > *Cc:* slitkows.i...@gmail.com; bess@ietf.org > *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 <bess-boun...@ietf.org> on behalf of > bruno.decra...@orange.com <bruno.decra...@orange.com> > *Date: *Thursday, May 6, 2021 at 10:04 AM > *To: *Neeraj Malhotra <neeraj.i...@gmail.com> > *Cc: *slitkows.i...@gmail.com <slitkows.i...@gmail.com>, bess@ietf.org < > bess@ietf.org> > *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:neeraj.i...@gmail.com > <neeraj.i...@gmail.com>] > *Sent:* Thursday, May 6, 2021 7:41 AM > *To:* DECRAENE Bruno TGI/OLN <bruno.decra...@orange.com> > *Cc:* slitkows.i...@gmail.com; bess@ietf.org > *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 <bruno.decra...@orange.com> 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:bess-boun...@ietf.org] *On Behalf Of * > slitkows.i...@gmail.com > *Sent:* Monday, May 3, 2021 9:21 AM > *To:* bess@ietf.org > *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 > BESS@ietf.org > 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 > BESS@ietf.org > 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. > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
