Re: [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Jorge Rabadan (Nokia)]

Hi everyone,

As part of the same review, I wanted to take advantage of Jeff’s email to throw 
a couple of comments if I may:


  *   While initially 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb defined a 
new extended community because the IDR link-bw extended community was 
non-transitive, the definition of the new community evolved and it defined a 
new “value-units” field which indicates what the weight is (bw or a generalized 
weight). Also the BW is expressed in Mbps.



  *   There are implementations and deployments of the above draft



  *   Now draft-ietf-bess-ebgp-dmz-02 also mentions that the link bandwidth 
extended community can be used not only with IPv4 (and I guess IPv6) families, 
but also VPN-IP and EVPN families. For EVPN the question would be – what’s the 
proposed interaction between the link BW extended community and the EVPN link 
BW extended community, if both are received on the same EVPN route? That should 
be clarified..

Thanks!
Jorge


From: BESS  on behalf of Jeff Tantsura 

Date: Monday, June 26, 2023 at 5:21 PM
To: Alvaro Retana 
Cc: idr-cha...@ietf.org , bess@ietf.org , 
Matthew Bocci (Nokia) , i...@ietf.org 
Subject: Re: [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



It is the second draft - 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb

The authors have also defined a new community with the change transitivity as 
the motivation:

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.

> On Jun 26, 2023, at 2:44 PM, Alvaro Retana  wrote:
>
> On June 26, 2023 at 5:27:39 PM, Jeff Tantsura wrote:
>
> Jeff:
>
>> Over the last couple of years I have reached out to the authors of the
>> original draft at least twice with a request to refresh the draft and bring
>> the necessary changes in, without much success though.
>>
> ...
>> Note that there’s also an EVPN specific draft (standard track).
>
> That made me go look -- I found two related documents!  Are these what
> you're referring to?
>
>https://datatracker.ietf.org/doc/html/draft-ietf-bess-weighted-hrw
>https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb
>
>
>> I’d be happy to volunteer to help managing the mess ;-)
>
> I know the idr/bess-chairs are listening. ;-)
>
>
> Alvaro.

___
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 for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Jeff Tantsura]

It is the second draft - 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb

The authors have also defined a new community with the change transitivity as 
the motivation:

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.

> On Jun 26, 2023, at 2:44 PM, Alvaro Retana  wrote:
> 
> On June 26, 2023 at 5:27:39 PM, Jeff Tantsura wrote:
> 
> Jeff:
> 
>> Over the last couple of years I have reached out to the authors of the
>> original draft at least twice with a request to refresh the draft and bring
>> the necessary changes in, without much success though.
>> 
> ...
>> Note that there’s also an EVPN specific draft (standard track).
> 
> That made me go look -- I found two related documents!  Are these what
> you're referring to?
> 
>https://datatracker.ietf.org/doc/html/draft-ietf-bess-weighted-hrw
>https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb
> 
> 
>> I’d be happy to volunteer to help managing the mess ;-)
> 
> I know the idr/bess-chairs are listening. ;-)
> 
> 
> Alvaro.

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

Re: [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Alvaro Retana]

On June 26, 2023 at 5:27:39 PM, Jeff Tantsura wrote:

Jeff:

> Over the last couple of years I have reached out to the authors of the
> original draft at least twice with a request to refresh the draft and bring
> the necessary changes in, without much success though.
>
...
> Note that there’s also an EVPN specific draft (standard track).

That made me go look -- I found two related documents!  Are these what
you're referring to?

   https://datatracker.ietf.org/doc/html/draft-ietf-bess-weighted-hrw
   https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb


> I’d be happy to volunteer to help managing the mess ;-)

I know the idr/bess-chairs are listening. ;-)


Alvaro.

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

Re: [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Jeff Tantsura]

Alvaro,Over the last couple of years I have reached out to the authors of the original draft at least twice with a request to refresh the draft and bring the necessary changes in, without much success though.There’s a plethora of implementations, some allowing to change the transitivity through configuration, some setting it as transitive, some as non.Cumulative behavior is a mandatory feature for DC (RFC7938 alike deployments) and is widely deployed in the largest networks.Note that there’s also an EVPN specific draft (standard track).I’d be happy to volunteer to help managing the mess  ;-)Cheers,JeffOn Jun 22, 2023, at 10:20, Alvaro Retana  wrote:Hi!I took a look at this document.  I agree that the use case presented should be addressed, but I don't think the document is ready for WGLC, or even necessary (see below).  In fact, I'm having a hard time understanding how it can progress if it depends on an expired draft, the proposed changes are not specific, etc. The meat of the document (beyond the explanation of the use case) is (from §1):   The new use-case mandates that the router calculates the aggregated    link-bandwidth, regenerate the DMZ link bandwidth extended community,    and advertise it to EBGP peers.I-D.ietf-idr-link-bandwidth expired in 2018.  I have seen no indication from the authors that it will be refreshed.  I know that implementations exist, but that is orthogonal to the need to reference this document as Normative.The rest of the document is mostly dedicated to describing the use case, but the description of the actions is loose (at best); for example, there is no specification about how "the router calculates the aggregated link-bandwidth".  Yes, we can all guess/assume what it means, but that needs to be documented.Assuming that I-D.ietf-idr-link-bandwidth is revived, the use case from this document could be covered there.  In fact, there is already a hint to the ability to regenerate the community based on received information (from §3):   Alternatively CEs of the site, when advertising IP routes to PE1    and PE2, could add the link bandwith community to these    advertisements, in which case PE1 and PE2, when originating VPN-IP   routes, would use the bandwidth value from the IP routes they   received from the CEs to construct the link bandwidth community   carried by these VPN-IP routes.In summary, given that this document depends on I-D.ietf-idr-link-bandwidth, I believe that the aggregate behavior can be "merged" into it.Alvaro.On May 25, 2023 at 5:43:55 AM, Matthew Bocci (Nokia) (matthew.bo...@nokia.com) wrote: 







Hi IDR WG
 
The BESS chairs would like to request review of 
draft-ietf-bess-ebgp-dmz-02 (draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and load-balancing), for which
 we are considering starting a working group last call.
 
Please could you review the draft and post any comment to the BESS mailing list (bess@ietf.org) by 25th June 2023.
 
Thanks
 
Matthew and Stephane



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
 
___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 for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Robert Raszuk]

Hi,

> I agree that the use case presented should be addressed, but I don't
think the document is ready for WGLC,

Indeed.

In fact it is clear by now that
https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07
needs to be rewritten to accommodate both 4 octet ASNs (instead of
proposing use of AS_TRANS) as well as define support for transitive
community use.

On the last one inspection of the IANA registry reveleas subtype 0x04 as
"Juniper Transitive Link Bandwidth" and the date 25th April 2023.

[image: image.png]

Interesting especially that I do not recall any discussions in IDR about
this this year ...

Cheers,
R.


On Thu, Jun 22, 2023 at 7:20 PM Alvaro Retana 
wrote:

> Hi!
>
> I took a look at this document.
>
> I agree that the use case presented should be addressed, but I don't think
> the document is ready for WGLC, or even necessary (see below).  In fact,
> I'm having a hard time understanding how it can progress if it depends on
> an expired draft, the proposed changes are not specific, etc.
>
>
> The meat of the document (beyond the explanation of the use case) is (from
> §1):
>
>The new use-case mandates that the router calculates the aggregated
>link-bandwidth, regenerate the DMZ link bandwidth extended community,
>and advertise it to EBGP peers.
>
>
> I-D.ietf-idr-link-bandwidth expired in 2018.  I have seen no indication
> from the authors that it will be refreshed.  I know that implementations
> exist, but that is orthogonal to the need to reference this document as
> Normative.
>
>
> The rest of the document is mostly dedicated to describing the use case,
> but the description of the actions is loose (at best); for example, there
> is no specification about how "the router calculates the aggregated
> link-bandwidth".  Yes, we can all guess/assume what it means, but that
> needs to be documented.
>
> Assuming that I-D.ietf-idr-link-bandwidth is revived, the use case from
> this document could be covered there.  In fact, there is already a hint to
> the ability to regenerate the community based on received information (from
> §3):
>
>Alternatively CEs of the site, when advertising IP routes to PE1
>and PE2, could add the link bandwith community to these
>advertisements, in which case PE1 and PE2, when originating VPN-IP
>routes, would use the bandwidth value from the IP routes they
>received from the CEs to construct the link bandwidth community
>carried by these VPN-IP routes.
>
>
> In summary, given that this document depends on
> I-D.ietf-idr-link-bandwidth, I believe that the aggregate behavior can be
> "merged" into it.
>
>
> Alvaro.
>
> On May 25, 2023 at 5:43:55 AM, Matthew Bocci (Nokia) (
> matthew.bo...@nokia.com) wrote:
>
> Hi IDR WG
>
>
>
> The BESS chairs would like to request review of draft-ietf-bess-ebgp-dmz-02
> (draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and
> load-balancing
> ), for which
> we are considering starting a working group last call.
>
>
>
> Please could you review the draft and post any comment to the BESS mailing
> list (bess@ietf.org) by 25th June 2023.
>
>
>
> Thanks
>
>
>
> Matthew and Stephane
> ___
> 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 for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Alvaro Retana]

Hi!

I took a look at this document.

I agree that the use case presented should be addressed, but I don't think
the document is ready for WGLC, or even necessary (see below).  In fact,
I'm having a hard time understanding how it can progress if it depends on
an expired draft, the proposed changes are not specific, etc.


The meat of the document (beyond the explanation of the use case) is (from
§1):

   The new use-case mandates that the router calculates the aggregated
   link-bandwidth, regenerate the DMZ link bandwidth extended community,
   and advertise it to EBGP peers.


I-D.ietf-idr-link-bandwidth expired in 2018.  I have seen no indication
from the authors that it will be refreshed.  I know that implementations
exist, but that is orthogonal to the need to reference this document as
Normative.


The rest of the document is mostly dedicated to describing the use case,
but the description of the actions is loose (at best); for example, there
is no specification about how "the router calculates the aggregated
link-bandwidth".  Yes, we can all guess/assume what it means, but that
needs to be documented.

Assuming that I-D.ietf-idr-link-bandwidth is revived, the use case from
this document could be covered there.  In fact, there is already a hint to
the ability to regenerate the community based on received information (from
§3):

   Alternatively CEs of the site, when advertising IP routes to PE1
   and PE2, could add the link bandwith community to these
   advertisements, in which case PE1 and PE2, when originating VPN-IP
   routes, would use the bandwidth value from the IP routes they
   received from the CEs to construct the link bandwidth community
   carried by these VPN-IP routes.


In summary, given that this document depends on
I-D.ietf-idr-link-bandwidth, I believe that the aggregate behavior can be
"merged" into it.


Alvaro.

On May 25, 2023 at 5:43:55 AM, Matthew Bocci (Nokia) (
matthew.bo...@nokia.com) wrote:

Hi IDR WG



The BESS chairs would like to request review of draft-ietf-bess-ebgp-dmz-02
(draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and
load-balancing ),
for which we are considering starting a working group last call.



Please could you review the draft and post any comment to the BESS mailing
list (bess@ietf.org) by 25th June 2023.



Thanks



Matthew and Stephane
___
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 for IDR WG review of draft-ietf-bess-ebgp-dmz-02

[Satya Mohanty (satyamoh)]

Hello all,

Gentle reminder for any review /comments as solicited by the BESS chairs.
This has already been deployed in networks for some time now and supported by 
many vendors.

Thanks,
--Satya

From: BESS  on behalf of Matthew Bocci (Nokia) 

Date: Thursday, May 25, 2023 at 3:44 AM
To: i...@ietf.org 
Cc: bess@ietf.org , idr-cha...@ietf.org 
Subject: [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02
Hi IDR WG

The BESS chairs would like to request review of draft-ietf-bess-ebgp-dmz-02 
(draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and 
load-balancing), 
for which we are considering starting a working group last call.

Please could you review the draft and post any comment to the BESS mailing list 
(bess@ietf.org) by 25th June 2023.

Thanks

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