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)
2. 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]
Sent: Thursday, May 6, 2021 10:36 AM
To: DECRAENE Bruno TGI/OLN <bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com> >; Neeraj Malhotra <neeraj.i...@gmail.com
<mailto:neeraj.i...@gmail.com> >
Cc: slitkows.i...@gmail.com <mailto:slitkows.i...@gmail.com> ; bess@ietf.org
<mailto: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 <mailto:bess-boun...@ietf.org> > on behalf of
bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>
<bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> >
Date: Thursday, May 6, 2021 at 10:04 AM
To: Neeraj Malhotra <neeraj.i...@gmail.com <mailto:neeraj.i...@gmail.com> >
Cc: slitkows.i...@gmail.com <mailto:slitkows.i...@gmail.com>
<slitkows.i...@gmail.com <mailto:slitkows.i...@gmail.com> >, bess@ietf.org
<mailto:bess@ietf.org> <bess@ietf.org <mailto: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]
Sent: Thursday, May 6, 2021 7:41 AM
To: DECRAENE Bruno TGI/OLN <bruno.decra...@orange.com
<mailto:bruno.decra...@orange.com> >
Cc: slitkows.i...@gmail.com <mailto:slitkows.i...@gmail.com> ; bess@ietf.org
<mailto: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
<mailto: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 <mailto:bess-boun...@ietf.org> ] On
Behalf Of slitkows.i...@gmail.com <mailto:slitkows.i...@gmail.com>
Sent: Monday, May 3, 2021 9:21 AM
To: bess@ietf.org <mailto: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 <mailto: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
