Subject: [bess] draft-ietf-bess-evpn-unequal-lb / meeting agenda

From: "Neeraj Malhotra (nmalhotr)" <[email-masked]>
Date: Tue, 10 Nov 2020 02:15:02 +0000

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

Subject: Fwd: [bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb
From: Neeraj Malhotra <[email-masked]>
To: <[email-masked]>
Date: Mon, 9 Nov 2020 18:09:36 -0800

---------- Forwarded message ---------
From: Neeraj Malhotra <[email-masked]>
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) <sajassi=[email-masked]>
Cc: John Scudder <[email-masked]>, Jeff Haas <[email-masked]>, [email-masked] <[email-masked]>

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-masked]> 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-masked]
https://www.ietf.org/mailman/listinfo/bess