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

2023-06-22 Thread 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

2023-06-22 Thread 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

[bess] I-D Action: draft-ietf-bess-secure-evpn-00.txt

2023-06-22 Thread internet-drafts 


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the BGP Enabled ServiceS
(BESS) WG of the IETF.

   Title   : Secure EVPN
   Authors : Ali Sajassi
 Ayan Banerjee
 Sameer Thoria
 David Carrel
 Brian Weis
 John Drake
   Filename: draft-ietf-bess-secure-evpn-00.txt
   Pages   : 37
   Date: 2023-06-20

Abstract:
   The applications of EVPN-based solutions (BGP MPLS-based Ethernet VPN
   and Network Virtualization Overlay Solution using EVPN) have become
   pervasive in Data Center, Service Provider, and Enterprise segments.
   It is being used for fabric overlays and inter-site connectivity in
   the Data Center market segment, for Layer-2, Layer-3, and IRB VPN
   services in the Service Provider market segment, and for fabric
   overlay and WAN connectivity in Enterprise networks.  For Data Center
   and Enterprise applications, there is a need to provide inter-site
   and WAN connectivity over public Internet in a secured manner with
   same level of privacy, integrity, and authentication for tenant's
   traffic as IPsec tunneling using IKEv2.  This document presents a
   solution where BGP point-to-multipoint signaling is leveraged for key
   and policy exchange among PE devices to create private pair-wise
   IPsec Security Associations without IKEv2 point-to-point signaling or
   any other direct peer-to-peer session establishment messages.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-secure-evpn/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-secure-evpn-00

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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