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) <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
>
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to