Hi Stephane, Mankamana,
Regarding "draft-ietf-bess-evpn-unequal-lb", I don't think we need a dedicated
slot for this in the meeting next week, but we would like to ask for WGLC. This
draft has been revised to address the concerns that were raised in the last
BESS meeting, specifically related to link BW attribute definition (please see
attached thread).
Could you please put on your agenda for next week's meeting to poll the WG that
there are no further concerns?
Thanks,
Neeraj
--- Begin Message ---
---------- Forwarded message ---------
From: Neeraj Malhotra <[email protected]>
Date: Wed, Oct 14, 2020 at 11:24 AM
Subject: Re: [bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb
To: Ali Sajassi (sajassi) <[email protected]>
Cc: John Scudder <[email protected]>, Jeff Haas <[email protected]>,
[email protected] <[email protected]>
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 Community
A new EVPN Link Bandwidth extended community is defined to signal
local ES link bandwidth to remote PEs. This extended-community is
defined of type 0x06 (EVPN). IANA is requested to assign a sub-type
value of 0x10 for the EVPN Link bandwidth extended community, of type
0x06 (EVPN). EVPN Link Bandwidth extended community is defined as
transitive.
Link bandwidth extended community described in [BGP-LINK-BW] for
layer 3 VPNs was considered for re-use here. This Link bandwidth
extended community is however defined in [BGP-LINK-BW] as optional
non-transitive. Since it is not possible to change deployed behavior
of extended-community defined in [BGP-LINK-BW], it was decided to
define a new one. In inter-AS scenarios, link-bandwidth needs to be
signaled to eBGP neighbors. When signaled across AS boundary, this
attribute can be used to achieve optimal load-balancing towards
source PEs from a different AS. This is applicable both when next-
hop is changed or unchanged across AS boundaries.
Thanks,
Neeraj
On Thu, Jul 30, 2020 at 11:14 PM Ali Sajassi (sajassi)
<[email protected]> wrote:
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 conditional and we will
correct this in the next rev of the draft. So, the EC is simply transitive at
all time. Given the EC defined in draft-ietf-idr-link-bandwidth-07.txt is
non-transitive, we cannot use this EC for our application. That’s why we are
defining a new one.
Cheers,
Ali
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
--- End Message ---
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
