Hi Jeff,
Many thanks for the confirmation and detailed explanation / review. We will
move forward with the new code point for EVPN.
With respect to your comment in the last paragraph, your understanding is
correct - primary use case for this attribute is for it to be carried in
Type 1 route
Neeraj,
Thanks for reminding me to comment on the draft's Link Bandwidth procedures.
The existing link bandwidth feature, defined in an expired Internet-Draft, is a
non-transitive extended community.
Part of the comments I'd given at prior BESS sessions at the microphone was
that Juniper has
Hi John, Jeff,
Could you please confirm that you are fine with the revised text below or if
you have any further input?
Thanks,
Neeraj
> On Oct 14, 2020, at 11:24 AM, Neeraj Malhotra wrote:
>
>
>
> Hi John, Jeff,
>
> FYI - latest revision of this draft corrects the BW attribute to be
>
Hi John, Jeff,
FYI - latest revision of this draft corrects the BW attribute to be
transitive inline with Ali's explanation below:
https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt.
Please do let us know if there are any further concerns.
4.2. EVPN Link Bandwidth Extended
John, Jeff:
During the presentation of draft-ietf-bess-evpn-unequal-lb -03 at the BESS WG
meeting, you had a question/concern regarding why we are defining a new EC if
we are doing conditional transitive. First, I’d like to make a correction to
the preso by saying that the transitivity is not
