Subject: Re: [bess] New Extended Community for draft-ietf-bess-evpn-unequal-lb

From: Neeraj Malhotra <[email-masked]>
Date: Tue, 10 Nov 2020 08:47:39 -0800

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-masked]> 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) <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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Nov 2020 15:09:24 -0500

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 used a similar code point with the transitive behavior.  This does create an interoperability problem between the published non-transitive and Juniper's transitive extended community.

Part of that discussion was with regards to whether this was motivation for Juniper to help clean up that situation.  I believe that based on the text in your current draft that making using of the transitive code point used by Juniper is likely not a good fit for your EVPN use case.  Based on that, I believe the request in the Internet-Draft for a new transitive code point is appropriate and I have no objections or further concerns. 

By using split code points for general purpose BGP link bandwidth and EVPN link bandwidth, we accommodate not only load balancing at the EVPN level, but help avoid confusion when EVPN routes' nexthops may recursively resolve in some situations across other BGP transport routes that may have their own link bandwidth available.  Exactly how that interaction in recursive resolution is implemented will likely be somewhat vendor dependent as it currently is for existing BGP use cases of link-bandwidth.

Section 4.2 notes that the signaling may be used in an inter-as situation.  If my reading of the draft is correct, then the expected use case is primarily to add the new EVPN link bandwidth route on Type 1 routes.  If so, containing the scoping of the distribution of those routes is mostly limited to a set of EVPN domains that interact with each other.  You may wish to consider whether guidance for stripping this new Extended Community at such domain borders is necessary or not.

Thanks for addressing my concerns.

-- Jeff

> On Oct 14, 2020, at 2:24 PM, Neeraj Malhotra <[email-masked]> 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 <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt__;!!NEt6yMaO-gk!WpGNLTp80vY1SOBO7xUowqXjTj64Jwdl9QBfcynQ1zzzTYjC43p-e0M7uc4hpSk$>. Please do let us know if there are any further concerns.
> 
> On Thu, Jul 30, 2020 at 11:14 PM Ali Sajassi (sajassi) <sajassi=[email-masked] <mailto:[email-masked]>> wrote:
> John, Jeff:
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/bess <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!WpGNLTp80vY1SOBO7xUowqXjTj64Jwdl9QBfcynQ1zzzTYjC43p-e0M78itEAgE$>

---

From: Neeraj Malhotra <[email-masked]>
Date: Thu, 12 Nov 2020 18:13:19 -0800

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 within and across EVPN domains. It would not be stripped at
the domain border. Will update the text to make sure this is clear.

Thanks,
Neeraj

On Wed, Nov 11, 2020 at 12:09 PM Jeffrey Haas <[email-masked]> wrote:

> Part of the comments I'd given at prior BESS sessions at the microphone
> was that Juniper has used a similar code point with the transitive
> behavior.  This does create an interoperability problem between the
> published non-transitive and Juniper's transitive extended community.
>
> Part of that discussion was with regards to whether this was motivation
> for Juniper to help clean up that situation.  I believe that based on the
> text in your current draft that making using of the transitive code point
> used by Juniper is likely not a good fit for your EVPN use case.  Based on
> that, I believe the request in the Internet-Draft for a new transitive code
> point is appropriate and I have no objections or further concerns.
>
> By using split code points for general purpose BGP link bandwidth and EVPN
> link bandwidth, we accommodate not only load balancing at the EVPN level,
> but help avoid confusion when EVPN routes' nexthops may recursively resolve
> in some situations across other BGP transport routes that may have their
> own link bandwidth available.  Exactly how that interaction in recursive
> resolution is implemented will likely be somewhat vendor dependent as it
> currently is for existing BGP use cases of link-bandwidth.
>
> Section 4.2 notes that the signaling may be used in an inter-as
> situation.  If my reading of the draft is correct, then the expected use
> case is primarily to add the new EVPN link bandwidth route on Type 1
> routes.  If so, containing the scoping of the distribution of those routes
> is mostly limited to a set of EVPN domains that interact with each other.
> You may wish to consider whether guidance for stripping this new Extended
> Community at such domain borders is necessary or not.
>
> 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
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt__;!!NEt6yMaO-gk!WpGNLTp80vY1SOBO7xUowqXjTj64Jwdl9QBfcynQ1zzzTYjC43p-e0M7uc4hpSk$>.
> Please do let us know if there are any further concerns.
>
>> 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
>>
>>
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!WpGNLTp80vY1SOBO7xUowqXjTj64Jwdl9QBfcynQ1zzzTYjC43p-e0M78itEAgE$>
>>
>
>