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