Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Vivek Venkatraman]

The implementation of Link Bandwidth in FRR uses a transitive community to 
signal & perform an automatic accumulation at the AS boundary. This seems 
useful as it obviates the need for additional info (configuration) at each AS 
boundary to generate a new community using accumulated values.

From: Arie Vayner 
Sent: Tuesday, July 6, 2021 10:13 PM
To: Jeff Tantsura 
Cc: bess@ietf.org; Satya Mohanty (satyamoh) 
; Gyan Mishra ; 
vi...@cumulusnetworks.com
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

External email: Use caution opening links or attachments

The way I see this implementation, this is not really a transitive community. 
The values are consumed within the local AS, and then a new community is 
generated, based on accumulated values, at the AS boundary.

Tnx
Arie

On Fri, Jul 2, 2021 at 2:52 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Arie,

The way the draft reads, it is quite clear that IANA allocated Link Bandwidth 
Ext. Community (0x4004) should be used (and formally changed to transitive), 
I'd be rather surprised if it is not the case ( that would make implementations 
non interoperable).
I'm in the process of reviewing all existing implementations and will come back 
on this one. Implementers - please do respond (FRR incl)
Practically  - if there's wg consensus (I don't think this is needed, given 
there's a number of working implementations) to use a new extended community 
the document should become standard track with the formal IANA allocation 
request.

Thanks,
Jeff


On Tue, May 25, 2021 at 1:16 PM Arie Vayner 
mailto:ar...@vayner.net>> wrote:
Jeff,

Actually, the way this draft is written, and how the implementations I'm aware 
of are implemented, this is not really a transitive community. It is a new 
community that is being generated on the AS boundary.
The community value is not carried over, but is calculated based on an 
cumulative value of other received communities, and then advertised as a new 
value across the AS boundary.

Tnx,
Arie

On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Hi,

I support adoption of the draft as Informational, please note, that request to 
change transitivity characteristics of the community is requested in another 
draft.
Gyan  - please note, while pretty much every vendor has implemented the 
community and relevant data-plane constructs, initial draft defines the 
community as non transititive, some vendors have followed that while some other 
have implemented it a transitive (to support obvious use case - eBGP in DC).


Cheers,
Jeff
On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) 
mailto:40cisco@dmarc.ietf.org>>, wrote:

Hi all,

On behalf of all the authors, we request a discussion of the draft 
https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mohanty-bess-ebgp-dmz-03=04%7C01%7Cvivek%40nvidia.com%7Cbd4da59efe9f4e1f0d9f08d94105eae1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612316410191808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=PviDsxhP3fdpeiaJ7kpLTfHhvW7CnRKckImnUhiR4PY%3D=0>
  and subsequent WG adoption.
This draft extends the usage of the DMZ link bandwidth to scenarios where the 
cumulative link bandwidth needs to be advertised to a BGP speaker.
Additionally, there is provision to send the link bandwidth extended community 
to EBGP speakers via configurable knobs. Please refer to section 3 and 4 for 
the use cases.

This feature has multiple-vendor implementations and has been deployed by 
several customers in their networks.

Best Regards,
--Satya
___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess=04%7C01%7Cvivek%40nvidia.com%7Cbd4da59efe9f4e1f0d9f08d94105eae1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612316410191808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=HWlek2Zt35r0IgoR1MBAx5DHb0%2BWHFHprK83YMfVJrg%3D=0>
___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess=04%7C01%7Cvivek%40nvidia.com%7Cbd4da59efe9f4e1f0d9f08d94105eae1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612316410201802%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=gTiNHeeaBSHI4ElNKHprFeU%2FrvYc4A6dvW6mSkaMVCE%3D=0>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[JeffT]

Hi, I’d like to see the community formally being transitive (not just as an implementation knob), in a multi-stage leaf-spine network, some stages might not have HW/SW to support UCMP, basic propagation of the community (rather than regeneration) would still work (use case – super-spines generate the community/spines propagate the community to the leafs/leafs load-share weighted per plane).I recall Robert’ proposal to use a new community for that, I’d not go that way, simply because of backwards compatibility issues. Having knob that changes transitivity to non-transitive  if desired to limit the propagation is an implementation detail (useful one). Cheers,Jeff  From: Gyan MishraSent: Thursday, July 8, 2021 7:25 AMTo: Satya Mohanty (satyamoh)Cc: Arie Vayner; Jeff Tantsura; Robert Raszuk; UTTARO, JAMES; bess@ietf.orgSubject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft Hi Satya Welcome.   As Jeff and Arie pointed out the distinct difference between the dmz link bandwidth extended community and cumulative link bandwidth is that the original link bandwidth extended community is non transitive and only supports 2 octet AS, where the cumulative link bandwidth is an aggregation of link bandwidths updated at every hop in the fabric and regenerated at the AS boundary border node.   That would be great to add an addendum with each of the vendor implementations. Kind Regards  Gyan On Wed, Jul 7, 2021 at 6:52 PM Satya Mohanty (satyamoh) <satya...@cisco.com> wrote:Gyan, Thanks for your interest. Sorry for replying late on this.Thanks Arie and Jeff for your clarifications. We have not changed the definition of the Link Bandwidth Ext. Community (0x4004) or it definition as non-transitive.As Arie mentioned previously, we are actually originating it at the AS boundary. BTW, the cumulative link-bandwidth feature first went in XR in 6.1.1. We can incorporate that in the addendum as well get the similar information from other vendors. Thanks,--Satya From: Gyan Mishra <hayabusa...@gmail.com>Date: Saturday, July 3, 2021 at 8:34 AMTo: Jeff Tantsura <jefftant.i...@gmail.com>Cc: Arie Vayner <ar...@vayner.net>, Robert Raszuk <rob...@raszuk.net>, "Satya Mohanty (satyamoh)" <satya...@cisco.com>, "UTTARO, JAMES" <ju1...@att.com>, "bess@ietf.org" <bess@ietf.org>Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft  Thanks Jeff for the clarification. Thanks  GyanOn Fri, Jul 2, 2021 at 6:05 PM Jeff Tantsura <jefftant.i...@gmail.com> wrote:Gyan, you are mixing use of BW community as such with cumulative propagation (the theme of the draft).The original community is defined in "Non-Transitive Two-Octet AS-Specific Extended Community Sub-Types" IANA section and that has to be changed to allow eBGP use cases.Aggregation is a very useful feature when the prefix with the community attached is traversing the fabric and is being regenerated and potentially transformed at every hop traversed.  The alternative with add-path and potentially path explosion (not to talk about operational complexity of add-path and bugs in the implementations) is a rather unattractive solution for DC fabrics. Cheers,Jeff On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra <hayabusa...@gmail.com> wrote:Hi Satya  For EBGP DCs with multi-stage clos I understand this can be used, however with Cisco & Juniper & Nokia & Arista  and maybe other vendor implementations seem to combine the non transitive link bw extended community and transitive cumulative link bw extended community into a single feature that works for UCMP intra AS and inter AS.  Please confirm. These two drafts seem to be combined by implementations into a single UCMP feature for both eBGP and iBGP. https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03 Cisco: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853 Juniper: https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html Nokia: https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html  Arista: https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621 Kind Regards  Gyan On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) <satya...@cisco.com> wrote:Hi Jim, No, they do not.  This draft under discussion is a way to aggregate the link bandwidth in EBGP DCs and advertise it upstream. It works well in multi-stage clos topology fabrics.Traffic is demultiplexed (multi-path load balanced) when it arrives at a node of each stage (unless the sink). The draft you are mentioning, https://tools.ietf.org/id/draft-ietf-bes

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Hi Satya

Welcome.

As Jeff and Arie pointed out the distinct difference between the dmz link
bandwidth extended community and cumulative link bandwidth is that the
original link bandwidth extended community is non transitive and only
supports 2 octet AS, where the cumulative link bandwidth is an aggregation
of link bandwidths updated at every hop in the fabric and regenerated at
the AS boundary border node.

That would be great to add an addendum with each of the vendor
implementations.

Kind Regards

Gyan

On Wed, Jul 7, 2021 at 6:52 PM Satya Mohanty (satyamoh) 
wrote:

> Gyan,
>
>
>
> Thanks for your interest. Sorry for replying late on this.
>
> Thanks Arie and Jeff for your clarifications.
>
>
>
> We have not changed the definition of the Link Bandwidth Ext. Community
> (0x4004) or it definition as non-transitive.
>
> As Arie mentioned previously, we are actually originating it at the AS
> boundary.
>
>
>
> BTW, the cumulative link-bandwidth feature first went in XR in 6.1.1. We
> can incorporate that in the addendum as well get the similar information
> from other vendors.
>
>
>
> Thanks,
>
> --Satya
>
>
>
> *From: *Gyan Mishra 
> *Date: *Saturday, July 3, 2021 at 8:34 AM
> *To: *Jeff Tantsura 
>
> *Cc: *Arie Vayner , Robert Raszuk ,
> "Satya Mohanty (satyamoh)" , "UTTARO, JAMES" <
> ju1...@att.com>, "bess@ietf.org" 
> *Subject: *Re: [bess] Request discussion on Cumulative Link Bandwidth
> Draft
>
>
>
>
>
> Thanks Jeff for the clarification.
>
>
>
> Thanks
>
>
>
> Gyan
>
> On Fri, Jul 2, 2021 at 6:05 PM Jeff Tantsura 
> wrote:
>
> Gyan,
>
>
>
> you are mixing use of BW community as such with cumulative propagation
> (the theme of the draft).
>
> The original community is defined in "Non-Transitive Two-Octet AS-Specific
> Extended Community Sub-Types" IANA section and that has to be changed to
> allow eBGP use cases.
>
> Aggregation is a very useful feature when the prefix with the
> community attached is traversing the fabric and is being regenerated and
> potentially transformed at every hop traversed.
>
>
>
> The alternative with add-path and potentially path explosion (not to talk
> about operational complexity of add-path and bugs in the implementations)
> is a rather unattractive solution for DC fabrics.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra  wrote:
>
> Hi Satya
>
>
>
> For EBGP DCs with multi-stage clos I understand this can be used, however
> with Cisco & Juniper & Nokia & Arista  and maybe other vendor
> implementations seem to combine the non transitive link bw extended
> community and transitive cumulative link bw extended community into a
> single feature that works for UCMP intra AS and inter AS.  Please confirm.
>
>
>
> These two drafts seem to be combined by implementations into a single UCMP
> feature for both eBGP and iBGP.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07
>
>
>
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>
>
>
> Cisco:
>
>
>
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html
>
>
>
>
> https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853
>
>
>
> Juniper:
>
>
>
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html
>
>
>
> Nokia:
>
>
>
>
> https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html
>
>
>
>
>
> Arista:
>
>
>
> https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) <
> satya...@cisco.com> wrote:
>
> Hi Jim,
>
>
>
> No, they do not.
>
>
>
> This draft under discussion is a way to aggregate the link bandwidth in
> EBGP DCs and advertise it upstream.
>
> It works well in multi-stage clos topology fabrics.
>
> Traffic is demultiplexed (multi-path load balanced) when it arrives at a
> node of each stage (unless the sink).
>
>
>
> The draft you are mentioning,
> https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is
> really a way to communicate the link-bandwidth across EBGP boundaries.
>
> It is mostly geared from an Inter-AS Option C viewpoint (next-hop
> unc

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Satya Mohanty (satyamoh)]

Gyan,

Thanks for your interest. Sorry for replying late on this.
Thanks Arie and Jeff for your clarifications.

We have not changed the definition of the Link Bandwidth Ext. Community 
(0x4004) or it definition as non-transitive.
As Arie mentioned previously, we are actually originating it at the AS boundary.

BTW, the cumulative link-bandwidth feature first went in XR in 6.1.1. We can 
incorporate that in the addendum as well get the similar information from other 
vendors.

Thanks,
--Satya

From: Gyan Mishra 
Date: Saturday, July 3, 2021 at 8:34 AM
To: Jeff Tantsura 
Cc: Arie Vayner , Robert Raszuk , "Satya 
Mohanty (satyamoh)" , "UTTARO, JAMES" , 
"bess@ietf.org" 
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft


Thanks Jeff for the clarification.

Thanks

Gyan
On Fri, Jul 2, 2021 at 6:05 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Gyan,

you are mixing use of BW community as such with cumulative propagation (the 
theme of the draft).
The original community is defined in "Non-Transitive Two-Octet AS-Specific 
Extended Community Sub-Types" IANA section and that has to be changed to allow 
eBGP use cases.
Aggregation is a very useful feature when the prefix with the community 
attached is traversing the fabric and is being regenerated and potentially 
transformed at every hop traversed.

The alternative with add-path and potentially path explosion (not to talk about 
operational complexity of add-path and bugs in the implementations) is a rather 
unattractive solution for DC fabrics.

Cheers,
Jeff

On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:
Hi Satya

For EBGP DCs with multi-stage clos I understand this can be used, however with 
Cisco & Juniper & Nokia & Arista  and maybe other vendor implementations seem 
to combine the non transitive link bw extended community and transitive 
cumulative link bw extended community into a single feature that works for UCMP 
intra AS and inter AS.  Please confirm.

These two drafts seem to be combined by implementations into a single UCMP 
feature for both eBGP and iBGP.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03

Cisco:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html

https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853

Juniper:

https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html

Nokia:

https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html


Arista:

https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621

Kind Regards

Gyan

On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) 
mailto:satya...@cisco.com>> wrote:
Hi Jim,

No, they do not.

This draft under discussion is a way to aggregate the link bandwidth in EBGP 
DCs and advertise it upstream.
It works well in multi-stage clos topology fabrics.
Traffic is demultiplexed (multi-path load balanced) when it arrives at a node 
of each stage (unless the sink).

The draft you are mentioning, 
https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is really a 
way to communicate the link-bandwidth across EBGP boundaries.
It is mostly geared from an Inter-AS Option C viewpoint (next-hop unchanged) 
although it also applies to Option B deployments (next-hop-self).
There is no notion of aggregating bandwidth here.

HTH.

Best Regards,
--Satya


From: "UTTARO, JAMES" mailto:ju1...@att.com>>
Date: Wednesday, May 26, 2021 at 5:38 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>, Robert 
Raszuk mailto:rob...@raszuk.net>>
Cc: Jeff Tantsura mailto:jefftant.i...@gmail.com>>, 
Arie Vayner mailto:ar...@vayner.net>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, 
"Satya Mohanty (satyamoh)" mailto:satya...@cisco.com>>
Subject: RE: [bess] Request discussion on Cumulative Link Bandwidth Draft

Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing address 
the same field of use?

Thanks,
  Jim Uttaro

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Gyan Mishra
Sent: Wednesday, May 26, 2021 12:57 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Arie Vayner mailto:ar...@vayner.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Satya Mohanty (satyamoh) 
mailto:40cisco@dmarc.ietf.org>>
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

Across the DC space in general most providers use NVO3 and vxlan source port 
entropy L2/L3/L4 hash which provides per packet unif

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Arie Vayner]

The way I see this implementation, this is not really a transitive
community. The values are consumed within the local AS, and then a new
community is generated, based on accumulated values, at the AS boundary.

Tnx
Arie

On Fri, Jul 2, 2021 at 2:52 PM Jeff Tantsura 
wrote:

> Arie,
>
> The way the draft reads, it is quite clear that IANA allocated Link
> Bandwidth Ext. Community (0x4004) should be used (and formally changed to
> transitive), I'd be rather surprised if it is not the case ( that would
> make implementations non interoperable).
> I'm in the process of reviewing all existing implementations and will come
> back on this one. Implementers - please do respond (FRR incl)
> Practically  - if there's wg consensus (I don't think this is needed,
> given there's a number of working implementations) to use a new extended
> community the document should become standard track with the formal IANA
> allocation request.
>
> Thanks,
> Jeff
>
>
> On Tue, May 25, 2021 at 1:16 PM Arie Vayner  wrote:
>
>> Jeff,
>>
>> Actually, the way this draft is written, and how the implementations I'm
>> aware of are implemented, this is not really a transitive community. It is
>> a new community that is being generated on the AS boundary.
>> The community value is not carried over, but is calculated based on an
>> cumulative value of other received communities, and then advertised as a
>> new value across the AS boundary.
>>
>> Tnx,
>> Arie
>>
>> On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
>> wrote:
>>
>>> Hi,
>>>
>>> I support adoption of the draft as Informational, please note, that
>>> request to change transitivity characteristics of the community is
>>> requested in another draft.
>>> Gyan  - please note, while pretty much every vendor has implemented the
>>> community and relevant data-plane constructs, initial draft defines the
>>> community as non transititive, some vendors have followed that while some
>>> other have implemented it a transitive (to support obvious use case - eBGP
>>> in DC).
>>>
>>>
>>> Cheers,
>>> Jeff
>>> On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) >> 40cisco@dmarc.ietf.org>, wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> On behalf of all the authors, we request a discussion of the draft
>>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>>  and subsequent WG adoption.
>>>
>>> This draft extends the usage of the DMZ link bandwidth to scenarios
>>> where the cumulative link bandwidth needs to be advertised to a BGP speaker.
>>>
>>> Additionally, there is provision to send the link bandwidth extended
>>> community to EBGP speakers via configurable knobs. Please refer to section
>>> 3 and 4 for the use cases.
>>>
>>>
>>>
>>> This feature has multiple-vendor implementations and has been deployed
>>> by several customers in their networks.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> --Satya
>>> ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>>> ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Thanks Jeff for the clarification.

Thanks

Gyan
On Fri, Jul 2, 2021 at 6:05 PM Jeff Tantsura 
wrote:

> Gyan,
>
> you are mixing use of BW community as such with cumulative propagation
> (the theme of the draft).
> The original community is defined in "Non-Transitive Two-Octet AS-Specific
> Extended Community Sub-Types" IANA section and that has to be changed to
> allow eBGP use cases.
> Aggregation is a very useful feature when the prefix with the
> community attached is traversing the fabric and is being regenerated and
> potentially transformed at every hop traversed.
>
> The alternative with add-path and potentially path explosion (not to talk
> about operational complexity of add-path and bugs in the implementations)
> is a rather unattractive solution for DC fabrics.
>
> Cheers,
> Jeff
>
> On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra  wrote:
>
>> Hi Satya
>>
>> For EBGP DCs with multi-stage clos I understand this can be used, however
>> with Cisco & Juniper & Nokia & Arista  and maybe other vendor
>> implementations seem to combine the non transitive link bw extended
>> community and transitive cumulative link bw extended community into a
>> single feature that works for UCMP intra AS and inter AS.  Please confirm.
>>
>> These two drafts seem to be combined by implementations into a single
>> UCMP feature for both eBGP and iBGP.
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07
>>
>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>
>> Cisco:
>>
>>
>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html
>>
>>
>> https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853
>>
>> Juniper:
>>
>>
>> https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html
>>
>> Nokia:
>>
>>
>> https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html
>>
>>
>> Arista:
>>
>> https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) <
>> satya...@cisco.com> wrote:
>>
>>> Hi Jim,
>>>
>>>
>>>
>>> No, they do not.
>>>
>>>
>>>
>>> This draft under discussion is a way to aggregate the link bandwidth in
>>> EBGP DCs and advertise it upstream.
>>>
>>> It works well in multi-stage clos topology fabrics.
>>>
>>> Traffic is demultiplexed (multi-path load balanced) when it arrives at a
>>> node of each stage (unless the sink).
>>>
>>>
>>>
>>> The draft you are mentioning,
>>> https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is
>>> really a way to communicate the link-bandwidth across EBGP boundaries.
>>>
>>> It is mostly geared from an Inter-AS Option C viewpoint (next-hop
>>> unchanged) although it also applies to Option B deployments (next-hop-self).
>>>
>>> There is no notion of aggregating bandwidth here.
>>>
>>>
>>>
>>> HTH.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> --Satya
>>>
>>>
>>>
>>>
>>>
>>> *From: *"UTTARO, JAMES" 
>>> *Date: *Wednesday, May 26, 2021 at 5:38 AM
>>> *To: *Gyan Mishra , Robert Raszuk <
>>> rob...@raszuk.net>
>>> *Cc: *Jeff Tantsura , Arie Vayner <
>>> ar...@vayner.net>, "bess@ietf.org" , "Satya Mohanty
>>> (satyamoh)" 
>>> *Subject: *RE: [bess] Request discussion on Cumulative Link Bandwidth
>>> Draft
>>>
>>>
>>>
>>> *Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing
>>> address the same field of use? *
>>>
>>>
>>>
>>> *Thanks,*
>>>
>>> *  Jim Uttaro *
>>>
>>>
>>>
>>> *From:* BESS  *On Behalf Of * Gyan Mishra
>>> *Sent:* Wednesday, May 26, 2021 12:57 AM
>>> *To:* Robert Raszuk 
>>> *Cc:* Jeff Tantsura ; Arie Vayner <
>>> ar...@vayner.net>; bess@ietf.org; Satya Mohanty (satyamoh) >> 40cisco@dmarc.ietf.org>
>>> *Subject:* Re: [bess] Req

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Jeff Tantsura]

Gyan,

you are mixing use of BW community as such with cumulative propagation (the
theme of the draft).
The original community is defined in "Non-Transitive Two-Octet AS-Specific
Extended Community Sub-Types" IANA section and that has to be changed to
allow eBGP use cases.
Aggregation is a very useful feature when the prefix with the
community attached is traversing the fabric and is being regenerated and
potentially transformed at every hop traversed.

The alternative with add-path and potentially path explosion (not to talk
about operational complexity of add-path and bugs in the implementations)
is a rather unattractive solution for DC fabrics.

Cheers,
Jeff

On Fri, Jul 2, 2021 at 12:17 PM Gyan Mishra  wrote:

> Hi Satya
>
> For EBGP DCs with multi-stage clos I understand this can be used, however
> with Cisco & Juniper & Nokia & Arista  and maybe other vendor
> implementations seem to combine the non transitive link bw extended
> community and transitive cumulative link bw extended community into a
> single feature that works for UCMP intra AS and inter AS.  Please confirm.
>
> These two drafts seem to be combined by implementations into a single UCMP
> feature for both eBGP and iBGP.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07
>
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>
> Cisco:
>
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html
>
>
> https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853
>
> Juniper:
>
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html
>
> Nokia:
>
>
> https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html
>
>
> Arista:
>
> https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621
>
> Kind Regards
>
> Gyan
>
> On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) <
> satya...@cisco.com> wrote:
>
>> Hi Jim,
>>
>>
>>
>> No, they do not.
>>
>>
>>
>> This draft under discussion is a way to aggregate the link bandwidth in
>> EBGP DCs and advertise it upstream.
>>
>> It works well in multi-stage clos topology fabrics.
>>
>> Traffic is demultiplexed (multi-path load balanced) when it arrives at a
>> node of each stage (unless the sink).
>>
>>
>>
>> The draft you are mentioning,
>> https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is
>> really a way to communicate the link-bandwidth across EBGP boundaries.
>>
>> It is mostly geared from an Inter-AS Option C viewpoint (next-hop
>> unchanged) although it also applies to Option B deployments (next-hop-self).
>>
>> There is no notion of aggregating bandwidth here.
>>
>>
>>
>> HTH.
>>
>>
>>
>> Best Regards,
>>
>> --Satya
>>
>>
>>
>>
>>
>> *From: *"UTTARO, JAMES" 
>> *Date: *Wednesday, May 26, 2021 at 5:38 AM
>> *To: *Gyan Mishra , Robert Raszuk <
>> rob...@raszuk.net>
>> *Cc: *Jeff Tantsura , Arie Vayner <
>> ar...@vayner.net>, "bess@ietf.org" , "Satya Mohanty
>> (satyamoh)" 
>> *Subject: *RE: [bess] Request discussion on Cumulative Link Bandwidth
>> Draft
>>
>>
>>
>> *Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing
>> address the same field of use? *
>>
>>
>>
>> *Thanks,*
>>
>> *  Jim Uttaro *
>>
>>
>>
>> *From:* BESS  *On Behalf Of * Gyan Mishra
>> *Sent:* Wednesday, May 26, 2021 12:57 AM
>> *To:* Robert Raszuk 
>> *Cc:* Jeff Tantsura ; Arie Vayner <
>> ar...@vayner.net>; bess@ietf.org; Satya Mohanty (satyamoh) > 40cisco@dmarc.ietf.org>
>> *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth
>> Draft
>>
>>
>>
>> Across the DC space in general most providers use NVO3 and vxlan source
>> port entropy L2/L3/L4 hash which provides per packet uniform 50/50 load
>> balancing at the L2 VNI overlay layer, which translates into underlay load
>> balancing of flows and thus no polarization.
>>
>>
>>
>> Across the DC space speaking from an operators perspective as under the
>> floor fiber is not at a premium compare to 100G facilities costs the net
>> addition of bandwidth can be done fairly quickly so you are ahead of the
>> co

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Hi Satya

For EBGP DCs with multi-stage clos I understand this can be used, however
with Cisco & Juniper & Nokia & Arista  and maybe other vendor
implementations seem to combine the non transitive link bw extended
community and transitive cumulative link bw extended community into a
single feature that works for UCMP intra AS and inter AS.  Please confirm.

These two drafts seem to be combined by implementations into a single UCMP
feature for both eBGP and iBGP.

https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07

https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03

Cisco:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-link-bandwidth.html

https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-unequal-cost-multipath-ucmp-dmz-link/ta-p/3138853

Juniper:

https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-multipath-unequal-understanding.html

Nokia:

https://documentation.nokia.com/html/0_add-h-f/93-0074-HTML/7750_SR_OS_Routing_Protols_Guide/bgp.html


Arista:

https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp#xx1418621

Kind Regards

Gyan

On Wed, May 26, 2021 at 3:21 PM Satya Mohanty (satyamoh) 
wrote:

> Hi Jim,
>
>
>
> No, they do not.
>
>
>
> This draft under discussion is a way to aggregate the link bandwidth in
> EBGP DCs and advertise it upstream.
>
> It works well in multi-stage clos topology fabrics.
>
> Traffic is demultiplexed (multi-path load balanced) when it arrives at a
> node of each stage (unless the sink).
>
>
>
> The draft you are mentioning,
> https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is
> really a way to communicate the link-bandwidth across EBGP boundaries.
>
> It is mostly geared from an Inter-AS Option C viewpoint (next-hop
> unchanged) although it also applies to Option B deployments (next-hop-self).
>
> There is no notion of aggregating bandwidth here.
>
>
>
> HTH.
>
>
>
> Best Regards,
>
> --Satya
>
>
>
>
>
> *From: *"UTTARO, JAMES" 
> *Date: *Wednesday, May 26, 2021 at 5:38 AM
> *To: *Gyan Mishra , Robert Raszuk <
> rob...@raszuk.net>
> *Cc: *Jeff Tantsura , Arie Vayner <
> ar...@vayner.net>, "bess@ietf.org" , "Satya Mohanty
> (satyamoh)" 
> *Subject: *RE: [bess] Request discussion on Cumulative Link Bandwidth
> Draft
>
>
>
> *Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing
> address the same field of use? *
>
>
>
> *Thanks,*
>
> *  Jim Uttaro *
>
>
>
> *From:* BESS  *On Behalf Of * Gyan Mishra
> *Sent:* Wednesday, May 26, 2021 12:57 AM
> *To:* Robert Raszuk 
> *Cc:* Jeff Tantsura ; Arie Vayner <
> ar...@vayner.net>; bess@ietf.org; Satya Mohanty (satyamoh)  40cisco@dmarc.ietf.org>
> *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth
> Draft
>
>
>
> Across the DC space in general most providers use NVO3 and vxlan source
> port entropy L2/L3/L4 hash which provides per packet uniform 50/50 load
> balancing at the L2 VNI overlay layer, which translates into underlay load
> balancing of flows and thus no polarization.
>
>
>
> Across the DC space speaking from an operators perspective as under the
> floor fiber is not at a premium compare to 100G facilities costs the net
> addition of bandwidth can be done fairly quickly so you are ahead of the
> congestion curve and can be proactive versus reactively upgrading bandwidth
> piecemeal here and there ad hoc.
>
>
>
> There still maybe cases that still arise as even if you have the fiber
> infrastructure available, it’s not easy to upgrade and flash every link
> simultaneously in the DC in one or multiple maintenance windows, so you
> could still be left with some uneven bandwidth across the DC that could
> utilize this feature.
>
>
>
> DC comes into play for PE-CE “wan links”as well  use case for unequal cost
> load balancing use of the cumulative link bandwidth community regenerated.
>
>
>
>
>
> I think the use case where both the iBGP P core P-P links  or eBGP PE - PE
> inter-as are all wan links where link upgrades tend to not get done in
> unison uniformly, and in those cases both iBGP link bandwidth community can
> be heavily utilized as well as eBGP cumulative regenerated link bandwidth
> community for unequal cost  load balancing.  Across the core as well it is
> hard to flash all links even under floor fiber to the same bandwidth all at
> once you are left with the requirement for unequal coat load balancing.
>
>
>
> As operators upgrade their DC as well as core infrastructure to IPv6
> forwardi

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[JeffT]

Dear co-authors, Could you please publish a list of known implementations(vendor/platform/1st SW release supported), either on wiki/implementation report or as an appendix?  Thanks in advance Cheers,Jeff  From: Jeff TantsuraSent: Tuesday, May 25, 2021 12:55 PMTo: bess@ietf.org; Satya Mohanty (satyamoh); Gyan MishraSubject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft Hi,I support adoption of the draft as Informational, please note, that request to change transitivity characteristics of the community is requested in another draft. Gyan  - please note, while pretty much every vendor has implemented the community and relevant data-plane constructs, initial draft defines the community as non transititive, some vendors have followed that while some other have implemented it a transitive (to support obvious use case - eBGP in DC).   Cheers, JeffOn May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) , wrote:Hi all, On behalf of all the authors, we request a discussion of the draft https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and subsequent WG adoption.This draft extends the usage of the DMZ link bandwidth to scenarios where the cumulative link bandwidth needs to be advertised to a BGP speaker.Additionally, there is provision to send the link bandwidth extended community to EBGP speakers via configurable knobs. Please refer to section 3 and 4 for the use cases. This feature has multiple-vendor implementations and has been deployed by several customers in their networks. Best Regards,--Satya___BESS mailing listBESS@ietf.orghttps://www.ietf.org/mailman/listinfo/bess 
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Satya Mohanty (satyamoh)]

Hi Jim,

No, they do not.

This draft under discussion is a way to aggregate the link bandwidth in EBGP 
DCs and advertise it upstream.
It works well in multi-stage clos topology fabrics.
Traffic is demultiplexed (multi-path load balanced) when it arrives at a node 
of each stage (unless the sink).

The draft you are mentioning, 
https://tools.ietf.org/id/draft-ietf-bess-evpn-unequal-lb-06.html is really a 
way to communicate the link-bandwidth across EBGP boundaries.
It is mostly geared from an Inter-AS Option C viewpoint (next-hop unchanged) 
although it also applies to Option B deployments (next-hop-self).
There is no notion of aggregating bandwidth here.

HTH.

Best Regards,
--Satya


From: "UTTARO, JAMES" 
Date: Wednesday, May 26, 2021 at 5:38 AM
To: Gyan Mishra , Robert Raszuk 
Cc: Jeff Tantsura , Arie Vayner , 
"bess@ietf.org" , "Satya Mohanty (satyamoh)" 
Subject: RE: [bess] Request discussion on Cumulative Link Bandwidth Draft

Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing address 
the same field of use?

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Gyan Mishra
Sent: Wednesday, May 26, 2021 12:57 AM
To: Robert Raszuk 
Cc: Jeff Tantsura ; Arie Vayner ; 
bess@ietf.org; Satya Mohanty (satyamoh) 
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

Across the DC space in general most providers use NVO3 and vxlan source port 
entropy L2/L3/L4 hash which provides per packet uniform 50/50 load balancing at 
the L2 VNI overlay layer, which translates into underlay load balancing of 
flows and thus no polarization.

Across the DC space speaking from an operators perspective as under the floor 
fiber is not at a premium compare to 100G facilities costs the net addition of 
bandwidth can be done fairly quickly so you are ahead of the congestion curve 
and can be proactive versus reactively upgrading bandwidth piecemeal here and 
there ad hoc.

There still maybe cases that still arise as even if you have the fiber 
infrastructure available, it’s not easy to upgrade and flash every link 
simultaneously in the DC in one or multiple maintenance windows, so you could 
still be left with some uneven bandwidth across the DC that could utilize this 
feature.

DC comes into play for PE-CE “wan links”as well  use case for unequal cost load 
balancing use of the cumulative link bandwidth community regenerated.


I think the use case where both the iBGP P core P-P links  or eBGP PE - PE 
inter-as are all wan links where link upgrades tend to not get done in unison 
uniformly, and in those cases both iBGP link bandwidth community can be heavily 
utilized as well as eBGP cumulative regenerated link bandwidth community for 
unequal cost  load balancing.  Across the core as well it is hard to flash all 
links even under floor fiber to the same bandwidth all at once you are left 
with the requirement for unequal coat load balancing.

As operators upgrade their DC as well as core infrastructure to IPv6 forwarding 
plane in the move towards SRv6, they can now take advantage of flow label 
entropy stateless uniform load balancing and elimination of polarization.  
However, the wan link upgrades of core and DC PE-CE still exists and thus may 
be done piecemeal, so then both of the drafts are an extremely helpful tool for 
operators that much need the unequal cost load balancing capability.

I support both drafts.

Have most vendors implemented this to support both 2 byte and 4 byte AS 
extended community.  The drafts state 2 byte AS support.

Thanks

Gyan

On Tue, May 25, 2021 at 7:00 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Arie,

Draft  draft-ietf-idr-link-bandwidth talks about advertising towards IBGP. It 
does not talk about advertising over EBGP.

While I do support your use case I think it would be much cleaner to just ask 
for new ext. community type.

Reason being that as you illustrate you may want to accumulate BGP path's bw 
across few EBGP hops in the DC. Today there is no way to do so unless you want 
to completely hijack current lb ext community.

Also I see an analogy here to AIGP RFC although it clearly fits rather poorly 
for those who use BGP as IGP :).

Best, R.

On Wed, May 26, 2021 at 12:22 AM Arie Vayner 
mailto:ar...@vayner.net>> wrote:
Jeff,

Actually, the way this draft is written, and how the implementations I'm aware 
of are implemented, this is not really a transitive community. It is a new 
community that is being generated on the AS boundary.
The community value is not carried over, but is calculated based on an 
cumulative value of other received communities, and then advertised as a new 
value across the AS boundary.

Tnx,
Arie

On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Hi,

I support adoption of the draft as Informational, please note, that request to 
change transitivity characteristics of the community is requested in anothe

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[UTTARO, JAMES]

Does this work and Weighted Multi-Path Procedures for EVPN Multi-homing address 
the same field of use?

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Gyan Mishra
Sent: Wednesday, May 26, 2021 12:57 AM
To: Robert Raszuk 
Cc: Jeff Tantsura ; Arie Vayner ; 
bess@ietf.org; Satya Mohanty (satyamoh) 
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

Across the DC space in general most providers use NVO3 and vxlan source port 
entropy L2/L3/L4 hash which provides per packet uniform 50/50 load balancing at 
the L2 VNI overlay layer, which translates into underlay load balancing of 
flows and thus no polarization.

Across the DC space speaking from an operators perspective as under the floor 
fiber is not at a premium compare to 100G facilities costs the net addition of 
bandwidth can be done fairly quickly so you are ahead of the congestion curve 
and can be proactive versus reactively upgrading bandwidth piecemeal here and 
there ad hoc.

There still maybe cases that still arise as even if you have the fiber 
infrastructure available, it’s not easy to upgrade and flash every link 
simultaneously in the DC in one or multiple maintenance windows, so you could 
still be left with some uneven bandwidth across the DC that could utilize this 
feature.

DC comes into play for PE-CE “wan links”as well  use case for unequal cost load 
balancing use of the cumulative link bandwidth community regenerated.


I think the use case where both the iBGP P core P-P links  or eBGP PE - PE 
inter-as are all wan links where link upgrades tend to not get done in unison 
uniformly, and in those cases both iBGP link bandwidth community can be heavily 
utilized as well as eBGP cumulative regenerated link bandwidth community for 
unequal cost  load balancing.  Across the core as well it is hard to flash all 
links even under floor fiber to the same bandwidth all at once you are left 
with the requirement for unequal coat load balancing.

As operators upgrade their DC as well as core infrastructure to IPv6 forwarding 
plane in the move towards SRv6, they can now take advantage of flow label 
entropy stateless uniform load balancing and elimination of polarization.  
However, the wan link upgrades of core and DC PE-CE still exists and thus may 
be done piecemeal, so then both of the drafts are an extremely helpful tool for 
operators that much need the unequal cost load balancing capability.

I support both drafts.

Have most vendors implemented this to support both 2 byte and 4 byte AS 
extended community.  The drafts state 2 byte AS support.

Thanks

Gyan

On Tue, May 25, 2021 at 7:00 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Arie,

Draft  draft-ietf-idr-link-bandwidth talks about advertising towards IBGP. It 
does not talk about advertising over EBGP.

While I do support your use case I think it would be much cleaner to just ask 
for new ext. community type.

Reason being that as you illustrate you may want to accumulate BGP path's bw 
across few EBGP hops in the DC. Today there is no way to do so unless you want 
to completely hijack current lb ext community.

Also I see an analogy here to AIGP RFC although it clearly fits rather poorly 
for those who use BGP as IGP :).

Best, R.

On Wed, May 26, 2021 at 12:22 AM Arie Vayner 
mailto:ar...@vayner.net>> wrote:
Jeff,

Actually, the way this draft is written, and how the implementations I'm aware 
of are implemented, this is not really a transitive community. It is a new 
community that is being generated on the AS boundary.
The community value is not carried over, but is calculated based on an 
cumulative value of other received communities, and then advertised as a new 
value across the AS boundary.

Tnx,
Arie

On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Hi,

I support adoption of the draft as Informational, please note, that request to 
change transitivity characteristics of the community is requested in another 
draft.
Gyan  - please note, while pretty much every vendor has implemented the 
community and relevant data-plane constructs, initial draft defines the 
community as non transititive, some vendors have followed that while some other 
have implemented it a transitive (to support obvious use case - eBGP in DC).


Cheers,
Jeff
On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) 
mailto:40cisco@dmarc.ietf.org>>, wrote:

Hi all,

On behalf of all the authors, we request a discussion of the draft 
https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03__;!!BhdT!0b982PpfH6BN3cZfnleSv0ex_IJjKEMUOXi42a_RhyGg6nB17aWOnm6zLkY$>
  and subsequent WG adoption.
This draft extends the usage of the DMZ link bandwidth to scenarios where the 
cumulative link bandwidth needs to be advertised to a BGP speaker.
Additionally, there is provision to send the lin

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Across the DC space in general most providers use NVO3 and vxlan source
port entropy L2/L3/L4 hash which provides per packet uniform 50/50 load
balancing at the L2 VNI overlay layer, which translates into underlay load
balancing of flows and thus no polarization.

Across the DC space speaking from an operators perspective as under the
floor fiber is not at a premium compare to 100G facilities costs the net
addition of bandwidth can be done fairly quickly so you are ahead of the
congestion curve and can be proactive versus reactively upgrading bandwidth
piecemeal here and there ad hoc.

There still maybe cases that still arise as even if you have the fiber
infrastructure available, it’s not easy to upgrade and flash every link
simultaneously in the DC in one or multiple maintenance windows, so you
could still be left with some uneven bandwidth across the DC that could
utilize this feature.

DC comes into play for PE-CE “wan links”as well  use case for unequal cost
load balancing use of the cumulative link bandwidth community regenerated.


I think the use case where both the iBGP P core P-P links  or eBGP PE - PE
inter-as are all wan links where link upgrades tend to not get done in
unison uniformly, and in those cases both iBGP link bandwidth community can
be heavily utilized as well as eBGP cumulative regenerated link bandwidth
community for unequal cost  load balancing.  Across the core as well it is
hard to flash all links even under floor fiber to the same bandwidth all at
once you are left with the requirement for unequal coat load balancing.

As operators upgrade their DC as well as core infrastructure to IPv6
forwarding plane in the move towards SRv6, they can now take advantage of
flow label entropy stateless uniform load balancing and elimination of
polarization.  However, the wan link upgrades of core and DC PE-CE still
exists and thus may be done piecemeal, so then both of the drafts are an
extremely helpful tool for operators that much need the unequal cost load
balancing capability.

I support both drafts.

Have most vendors implemented this to support both 2 byte and 4 byte AS
extended community.  The drafts state 2 byte AS support.

Thanks

Gyan

On Tue, May 25, 2021 at 7:00 PM Robert Raszuk  wrote:

> Hi Arie,
>
> Draft  draft-ietf-idr-link-bandwidth talks about advertising towards
> IBGP. It does not talk about advertising over EBGP.
>
> While I do support your use case I think it would be much cleaner to just
> ask for new ext. community type.
>
> Reason being that as you illustrate you may want to accumulate BGP path's
> bw across few EBGP hops in the DC. Today there is no way to do so unless
> you want to completely hijack current lb ext community.
>
> Also I see an analogy here to AIGP RFC although it clearly fits rather
> poorly for those who use BGP as IGP :).
>
> Best, R.
>
> On Wed, May 26, 2021 at 12:22 AM Arie Vayner  wrote:
>
>> Jeff,
>>
>> Actually, the way this draft is written, and how the implementations I'm
>> aware of are implemented, this is not really a transitive community. It is
>> a new community that is being generated on the AS boundary.
>> The community value is not carried over, but is calculated based on an
>> cumulative value of other received communities, and then advertised as a
>> new value across the AS boundary.
>>
>> Tnx,
>> Arie
>>
>> On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
>> wrote:
>>
>>> Hi,
>>>
>>> I support adoption of the draft as Informational, please note, that
>>> request to change transitivity characteristics of the community is
>>> requested in another draft.
>>> Gyan  - please note, while pretty much every vendor has implemented the
>>> community and relevant data-plane constructs, initial draft defines the
>>> community as non transititive, some vendors have followed that while some
>>> other have implemented it a transitive (to support obvious use case - eBGP
>>> in DC).
>>>
>>>
>>> Cheers,
>>> Jeff
>>> On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) >> 40cisco@dmarc.ietf.org>, wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> On behalf of all the authors, we request a discussion of the draft
>>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>>  and subsequent WG adoption.
>>>
>>> This draft extends the usage of the DMZ link bandwidth to scenarios
>>> where the cumulative link bandwidth needs to be advertised to a BGP speaker.
>>>
>>> Additionally, there is provision to send the link bandwidth extended
>>> community to EBGP speakers via configurable knobs. Please refer to section
>>> 3 and 4 for the use cases.
>>>
>>>
>>>
>>> This feature has multiple-vendor implementations and has been deployed
>>> by several customers in their networks.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> --Satya
>>> ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>>> ___
>>> BESS mailing list
>>> 

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Robert Raszuk]

Hi Arie,

Draft  draft-ietf-idr-link-bandwidth talks about advertising towards IBGP.
It does not talk about advertising over EBGP.

While I do support your use case I think it would be much cleaner to just
ask for new ext. community type.

Reason being that as you illustrate you may want to accumulate BGP path's
bw across few EBGP hops in the DC. Today there is no way to do so unless
you want to completely hijack current lb ext community.

Also I see an analogy here to AIGP RFC although it clearly fits rather
poorly for those who use BGP as IGP :).

Best, R.

On Wed, May 26, 2021 at 12:22 AM Arie Vayner  wrote:

> Jeff,
>
> Actually, the way this draft is written, and how the implementations I'm
> aware of are implemented, this is not really a transitive community. It is
> a new community that is being generated on the AS boundary.
> The community value is not carried over, but is calculated based on an
> cumulative value of other received communities, and then advertised as a
> new value across the AS boundary.
>
> Tnx,
> Arie
>
> On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
> wrote:
>
>> Hi,
>>
>> I support adoption of the draft as Informational, please note, that
>> request to change transitivity characteristics of the community is
>> requested in another draft.
>> Gyan  - please note, while pretty much every vendor has implemented the
>> community and relevant data-plane constructs, initial draft defines the
>> community as non transititive, some vendors have followed that while some
>> other have implemented it a transitive (to support obvious use case - eBGP
>> in DC).
>>
>>
>> Cheers,
>> Jeff
>> On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) > 40cisco@dmarc.ietf.org>, wrote:
>>
>> Hi all,
>>
>>
>>
>> On behalf of all the authors, we request a discussion of the draft
>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>  and subsequent WG adoption.
>>
>> This draft extends the usage of the DMZ link bandwidth to scenarios where
>> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>>
>> Additionally, there is provision to send the link bandwidth extended
>> community to EBGP speakers via configurable knobs. Please refer to section
>> 3 and 4 for the use cases.
>>
>>
>>
>> This feature has multiple-vendor implementations and has been deployed by
>> several customers in their networks.
>>
>>
>>
>> Best Regards,
>>
>> --Satya
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Arie Vayner]

Jeff,

Actually, the way this draft is written, and how the implementations I'm
aware of are implemented, this is not really a transitive community. It is
a new community that is being generated on the AS boundary.
The community value is not carried over, but is calculated based on an
cumulative value of other received communities, and then advertised as a
new value across the AS boundary.

Tnx,
Arie

On Tue, May 25, 2021 at 12:55 PM Jeff Tantsura 
wrote:

> Hi,
>
> I support adoption of the draft as Informational, please note, that
> request to change transitivity characteristics of the community is
> requested in another draft.
> Gyan  - please note, while pretty much every vendor has implemented the
> community and relevant data-plane constructs, initial draft defines the
> community as non transititive, some vendors have followed that while some
> other have implemented it a transitive (to support obvious use case - eBGP
> in DC).
>
>
> Cheers,
> Jeff
> On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh)  40cisco@dmarc.ietf.org>, wrote:
>
> Hi all,
>
>
>
> On behalf of all the authors, we request a discussion of the draft
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and
> subsequent WG adoption.
>
> This draft extends the usage of the DMZ link bandwidth to scenarios where
> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>
> Additionally, there is provision to send the link bandwidth extended
> community to EBGP speakers via configurable knobs. Please refer to section
> 3 and 4 for the use cases.
>
>
>
> This feature has multiple-vendor implementations and has been deployed by
> several customers in their networks.
>
>
>
> Best Regards,
>
> --Satya
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Jeff Tantsura]

Hi,

I support adoption of the draft as Informational, please note, that request to 
change transitivity characteristics of the community is requested in another 
draft.
Gyan  - please note, while pretty much every vendor has implemented the 
community and relevant data-plane constructs, initial draft defines the 
community as non transititive, some vendors have followed that while some other 
have implemented it a transitive (to support obvious use case - eBGP in DC).


Cheers,
Jeff
On May 22, 2021, 8:38 AM -0700, Satya Mohanty (satyamoh) 
, wrote:
> Hi all,
>
> On behalf of all the authors, we request a discussion of the draft 
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and 
> subsequent WG adoption.
> This draft extends the usage of the DMZ link bandwidth to scenarios where the 
> cumulative link bandwidth needs to be advertised to a BGP speaker.
> Additionally, there is provision to send the link bandwidth extended 
> community to EBGP speakers via configurable knobs. Please refer to section 3 
> and 4 for the use cases.
>
> This feature has multiple-vendor implementations and has been deployed by 
> several customers in their networks.
>
> Best Regards,
> --Satya
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Hi Robert

Very good point on millions of mice flows that can take advantage of
unequal cost lb,  versus a small number of elephant flows.

Good point on further granularity with  TE bandwidth management .

Gyan

On Tue, May 25, 2021 at 2:06 PM Robert Raszuk  wrote:

> Gyan,
>
> It is always helpful to an assessment into right scale.
>
> Yes if you take few flows perhaps even a few big ones may suffer from
> polarization. But the feature here is about hashing millions of micro
> flows. With that in mind polarization effects are insignificant at
> decent operational scale.
>
> I support this draft.
>
> Cheers,
> Robert
>
> PS. Also keep in mind that for handling elephant flows there are bunch of
> TE like solutions in place which can be used which in turn give you very
> fine control.
>
> On Tue, May 25, 2021 at 9:23 AM Gyan Mishra  wrote:
>
>>
>> Hi Satya
>>
>> I read the draft and have a few questions.
>>
>> IPv4 does not support per flow per packet load balancing as all packets
>> belonging to the same flow must hash to the same path to prevent out of
>> order packets and thus is subject to polarization of flows as high
>> bandwidth flows may hash to the same path and low bandwidth flows as well
>> to the same path resulting in very uneven load balancing.  Do to this issue
>> it does not make either iBGP or eBGP can really benefit from link bandwidth
>> extended community weight based load sharing.
>>
>> IPV6 flow label RFC 6437 stateless locally significant 5-tuple header
>> hash generated 20 byte key input to hash function results in uniform 50/50
>> load balancing over EGP or IGP ECMP paths.
>>
>> I think it maybe a good idea to reference the IPv4 polarization issue
>> with flow based load balancing and that only with IPv6 flow label can true
>> 50/50 uniform load balancing be achieved.
>>
>> I noticed that the normative draft referenced was adopted but has not
>> progressed.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>>
>> Has the draft been implemented by Cisco or any other vendors ?
>>
>> Kind Regards
>>
>> Gyan
>>
>>
>> On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh) > 40cisco@dmarc.ietf.org> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> On behalf of all the authors, we request a discussion of the draft
>>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>>  and subsequent WG adoption.
>>>
>>> This draft extends the usage of the DMZ link bandwidth to scenarios
>>> where the cumulative link bandwidth needs to be advertised to a BGP
>>> speaker.
>>>
>>> Additionally, there is provision to send the link bandwidth extended
>>> community to EBGP speakers via configurable knobs. Please refer to section
>>> 3 and 4 for the use cases.
>>>
>>>
>>>
>>> This feature has multiple-vendor implementations and has been deployed
>>> by several customers in their networks.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> --Satya
>>> ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>> --
>>
>> 
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mis...@verizon.com *
>>
>>
>>
>> *M 301 502-1347*
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Arie

Thanks for responding on the polarization question and I agree it can
enhance ECMP capability and maybe even counter or reduce effects of
polarization.

Thanks

Gyan

On Tue, May 25, 2021 at 1:26 PM Arie Vayner  wrote:

> The flow polarization or elephant flow issues are well known industry
> items and they apply to both equal and unequal cost multi-path approaches.
>
> The objective of this proposal is to enhance ECMP, and enable unequal cost
> multi-pathing, which is very useful when a service is offered by a
> multitude of endpoints, which may or may not have the same capacity.
> This solution has been implemented in production, and offers a real option
> for traffic load management.
>
> Tnx
> Arie
>
> On Tue, May 25, 2021 at 9:48 AM Jakob Heitz (jheitz)  40cisco@dmarc.ietf.org> wrote:
>
>> The link bandwidth community has been implemented by Cisco and deployed by
>>
>> our customers for several years.
>>
>> Polarization of flows in multipath is a well known problem, but it hasn't
>> deterred
>>
>> people from using it.
>>
>>
>>
>> Regards,
>>
>> Jakob.
>>
>>
>>
>> *From:* BESS  *On Behalf Of * Gyan Mishra
>> *Sent:* Tuesday, May 25, 2021 12:24 AM
>> *To:* Satya Mohanty (satyamoh) 
>> *Cc:* bess@ietf.org
>> *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth
>> Draft
>>
>>
>>
>>
>>
>> Hi Satya
>>
>>
>>
>> I read the draft and have a few questions.
>>
>>
>>
>> IPv4 does not support per flow per packet load balancing as all packets
>> belonging to the same flow must hash to the same path to prevent out of
>> order packets and thus is subject to polarization of flows as high
>> bandwidth flows may hash to the same path and low bandwidth flows as well
>> to the same path resulting in very uneven load balancing.  Do to this issue
>> it does not make either iBGP or eBGP can really benefit from link bandwidth
>> extended community weight based load sharing.
>>
>>
>>
>> IPV6 flow label RFC 6437 stateless locally significant 5-tuple header
>> hash generated 20 byte key input to hash function results in uniform 50/50
>> load balancing over EGP or IGP ECMP paths.
>>
>>
>>
>> I think it maybe a good idea to reference the IPv4 polarization issue
>> with flow based load balancing and that only with IPv6 flow label can true
>> 50/50 uniform load balancing be achieved.
>>
>>
>>
>> I noticed that the normative draft referenced was adopted but has not
>> progressed.
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>>
>>
>>
>> Has the draft been implemented by Cisco or any other vendors ?
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Gyan
>>
>>
>>
>>
>>
>> On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh) > 40cisco@dmarc.ietf.org> wrote:
>>
>> Hi all,
>>
>>
>>
>> On behalf of all the authors, we request a discussion of the draft
>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>  and subsequent WG adoption.
>>
>> This draft extends the usage of the DMZ link bandwidth to scenarios where
>> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>>
>> Additionally, there is provision to send the link bandwidth extended
>> community to EBGP speakers via configurable knobs. Please refer to section
>> 3 and 4 for the use cases.
>>
>>
>>
>> This feature has multiple-vendor implementations and has been deployed by
>> several customers in their networks.
>>
>>
>>
>> Best Regards,
>>
>> --Satya
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email gyan.s.mis...@verizon.com *
>>
>> *M 301 502-1347 <(301)%20502-1347>*
>>
>>
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

That’s great  news that Cisco had implemented and customers have deployed
for years!

I see it’s supported in IOS and XR

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16/irg-xe-16-book/bgp-link-bandwidth.html

https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5000/bgp/65x/b-bgp-cg-ncs5000-65x/b-bgp-cg-ncs5000-65x_chapter_010.html


Thanks!!

Gyan


On Tue, May 25, 2021 at 12:48 PM Jakob Heitz (jheitz) 
wrote:

> The link bandwidth community has been implemented by Cisco and deployed by
>
> our customers for several years.
>
> Polarization of flows in multipath is a well known problem, but it hasn't
> deterred
>
> people from using it.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* BESS  *On Behalf Of * Gyan Mishra
> *Sent:* Tuesday, May 25, 2021 12:24 AM
> *To:* Satya Mohanty (satyamoh) 
> *Cc:* bess@ietf.org
> *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth
> Draft
>
>
>
>
>
> Hi Satya
>
>
>
> I read the draft and have a few questions.
>
>
>
> IPv4 does not support per flow per packet load balancing as all packets
> belonging to the same flow must hash to the same path to prevent out of
> order packets and thus is subject to polarization of flows as high
> bandwidth flows may hash to the same path and low bandwidth flows as well
> to the same path resulting in very uneven load balancing.  Do to this issue
> it does not make either iBGP or eBGP can really benefit from link bandwidth
> extended community weight based load sharing.
>
>
>
> IPV6 flow label RFC 6437 stateless locally significant 5-tuple header hash
> generated 20 byte key input to hash function results in uniform 50/50 load
> balancing over EGP or IGP ECMP paths.
>
>
>
> I think it maybe a good idea to reference the IPv4 polarization issue with
> flow based load balancing and that only with IPv6 flow label can true 50/50
> uniform load balancing be achieved.
>
>
>
> I noticed that the normative draft referenced was adopted but has not
> progressed.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>
>
>
> Has the draft been implemented by Cisco or any other vendors ?
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh)  40cisco@dmarc.ietf.org> wrote:
>
> Hi all,
>
>
>
> On behalf of all the authors, we request a discussion of the draft
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and
> subsequent WG adoption.
>
> This draft extends the usage of the DMZ link bandwidth to scenarios where
> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>
> Additionally, there is provision to send the link bandwidth extended
> community to EBGP speakers via configurable knobs. Please refer to section
> 3 and 4 for the use cases.
>
>
>
> This feature has multiple-vendor implementations and has been deployed by
> several customers in their networks.
>
>
>
> Best Regards,
>
> --Satya
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mis...@verizon.com *
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Robert Raszuk]

Gyan,

It is always helpful to an assessment into right scale.

Yes if you take few flows perhaps even a few big ones may suffer from
polarization. But the feature here is about hashing millions of micro
flows. With that in mind polarization effects are insignificant at
decent operational scale.

I support this draft.

Cheers,
Robert

PS. Also keep in mind that for handling elephant flows there are bunch of
TE like solutions in place which can be used which in turn give you very
fine control.

On Tue, May 25, 2021 at 9:23 AM Gyan Mishra  wrote:

>
> Hi Satya
>
> I read the draft and have a few questions.
>
> IPv4 does not support per flow per packet load balancing as all packets
> belonging to the same flow must hash to the same path to prevent out of
> order packets and thus is subject to polarization of flows as high
> bandwidth flows may hash to the same path and low bandwidth flows as well
> to the same path resulting in very uneven load balancing.  Do to this issue
> it does not make either iBGP or eBGP can really benefit from link bandwidth
> extended community weight based load sharing.
>
> IPV6 flow label RFC 6437 stateless locally significant 5-tuple header hash
> generated 20 byte key input to hash function results in uniform 50/50 load
> balancing over EGP or IGP ECMP paths.
>
> I think it maybe a good idea to reference the IPv4 polarization issue with
> flow based load balancing and that only with IPv6 flow label can true 50/50
> uniform load balancing be achieved.
>
> I noticed that the normative draft referenced was adopted but has not
> progressed.
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>
> Has the draft been implemented by Cisco or any other vendors ?
>
> Kind Regards
>
> Gyan
>
>
> On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh)  40cisco@dmarc.ietf.org> wrote:
>
>> Hi all,
>>
>>
>>
>> On behalf of all the authors, we request a discussion of the draft
>> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03
>>  and subsequent WG adoption.
>>
>> This draft extends the usage of the DMZ link bandwidth to scenarios where
>> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>>
>> Additionally, there is provision to send the link bandwidth extended
>> community to EBGP speakers via configurable knobs. Please refer to section
>> 3 and 4 for the use cases.
>>
>>
>>
>> This feature has multiple-vendor implementations and has been deployed by
>> several customers in their networks.
>>
>>
>>
>> Best Regards,
>>
>> --Satya
>> ___
>> BESS mailing list
>> BESS@ietf.org
>> https://www.ietf.org/mailman/listinfo/bess
>>
> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Jakob Heitz (jheitz)]

The link bandwidth community has been implemented by Cisco and deployed by
our customers for several years.
Polarization of flows in multipath is a well known problem, but it hasn't 
deterred
people from using it.

Regards,
Jakob.

From: BESS  On Behalf Of Gyan Mishra
Sent: Tuesday, May 25, 2021 12:24 AM
To: Satya Mohanty (satyamoh) 
Cc: bess@ietf.org
Subject: Re: [bess] Request discussion on Cumulative Link Bandwidth Draft


Hi Satya

I read the draft and have a few questions.

IPv4 does not support per flow per packet load balancing as all packets 
belonging to the same flow must hash to the same path to prevent out of order 
packets and thus is subject to polarization of flows as high bandwidth flows 
may hash to the same path and low bandwidth flows as well to the same path 
resulting in very uneven load balancing.  Do to this issue it does not make 
either iBGP or eBGP can really benefit from link bandwidth extended community 
weight based load sharing.

IPV6 flow label RFC 6437 stateless locally significant 5-tuple header hash 
generated 20 byte key input to hash function results in uniform 50/50 load 
balancing over EGP or IGP ECMP paths.

I think it maybe a good idea to reference the IPv4 polarization issue with flow 
based load balancing and that only with IPv6 flow label can true 50/50 uniform 
load balancing be achieved.

I noticed that the normative draft referenced was adopted but has not 
progressed.

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/

Has the draft been implemented by Cisco or any other vendors ?

Kind Regards

Gyan


On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi all,

On behalf of all the authors, we request a discussion of the draft 
https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and 
subsequent WG adoption.
This draft extends the usage of the DMZ link bandwidth to scenarios where the 
cumulative link bandwidth needs to be advertised to a BGP speaker.
Additionally, there is provision to send the link bandwidth extended community 
to EBGP speakers via configurable knobs. Please refer to section 3 and 4 for 
the use cases.

This feature has multiple-vendor implementations and has been deployed by 
several customers in their networks.

Best Regards,
--Satya
___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

[Gyan Mishra]

Hi Satya

I read the draft and have a few questions.

IPv4 does not support per flow per packet load balancing as all packets
belonging to the same flow must hash to the same path to prevent out of
order packets and thus is subject to polarization of flows as high
bandwidth flows may hash to the same path and low bandwidth flows as well
to the same path resulting in very uneven load balancing.  Do to this issue
it does not make either iBGP or eBGP can really benefit from link bandwidth
extended community weight based load sharing.

IPV6 flow label RFC 6437 stateless locally significant 5-tuple header hash
generated 20 byte key input to hash function results in uniform 50/50 load
balancing over EGP or IGP ECMP paths.

I think it maybe a good idea to reference the IPv4 polarization issue with
flow based load balancing and that only with IPv6 flow label can true 50/50
uniform load balancing be achieved.

I noticed that the normative draft referenced was adopted but has not
progressed.

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/

Has the draft been implemented by Cisco or any other vendors ?

Kind Regards

Gyan


On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh)  wrote:

> Hi all,
>
>
>
> On behalf of all the authors, we request a discussion of the draft
> https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03  and
> subsequent WG adoption.
>
> This draft extends the usage of the DMZ link bandwidth to scenarios where
> the cumulative link bandwidth needs to be advertised to a BGP speaker.
>
> Additionally, there is provision to send the link bandwidth extended
> community to EBGP speakers via configurable knobs. Please refer to section
> 3 and 4 for the use cases.
>
>
>
> This feature has multiple-vendor implementations and has been deployed by
> several customers in their networks.
>
>
>
> Best Regards,
>
> --Satya
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess