Hi all,

There are, of course, differences between different uses of BGP policy knobs.

Route filters to prevent or reduce the impact of mistakes is different from external control of routing for specific prefixes.

Something to remember is that it is often really valuable from a performance perspective to localpref prefixes learned from R&E peers higher than commodity....but that works better in conjunction with prefix filters that prevent mistakes. 

ESnet does this today.

I consider this to be both best practice and critical for supporting data-intensive science. If we are going to issue BGP best practice guidance to the community at large, I recommend we include this.

Eli


Eli Dart, Network Engineer                          NOC: (510) 486-7600
ESnet Science Engagement Group                           (800) 333-7638
Lawrence Berkeley National Laboratory 


On Tue, Apr 2, 2024 at 2:22 PM Dale W. Carder <dwcarder@es.net> wrote:

At first blush it's not a bad idea.  We defined something slightly
similar in LHCONE for informational communities, but they were not
routinely implemented:
https://twiki.cern.ch/twiki/bin/view/LHCONE/LhcOneVRF#BGP_communities

Of course we should be aware that use of communities in completely
unauthenticated, so the set of actions exposed by any given network
should be rather limited.

Dale



Thus spake David Farmer (farmer@umn.edu) on Tue, Apr 02, 2024 at 03:24:37PM -0500:
> I had a thought.
>
> Does GREN or GNA-G have an ASN?
> If not we/it could probably get one.
>
> My suggestion would be to use that ASN for a set of globally agreed to
> communities and to create an as-set that represents the entirety of the
> Global NREN community.
>
> Thanks
>
> On Tue, Apr 2, 2024 at 9:38 AM Steven Wallace <ssw@internet2.edu> wrote:
>
> > On 2 Apr 2024, at 10:33, Dale W. Carder wrote:
> >
> > > Thus spake Steven Wallace (ssw@internet2.edu) on Mon, Apr 01, 2024 at
> > 11:49:09AM -0400:
> > >> Dave,
> > >>
> > >> I’ll update the document to be clearer. I’m suggesting that
> > >> AS11537:AS-NREN-PEERS contains the ASNs of Internet2’s NREN peers, not
> > their
> > >> customer cones. For example, AS11537:AS-NREN-PEERS would contain AS20965
> > >> (GEANT), among others. It wouldn’t contain AS20965:AS-CUSTOMERS or
> > >> AS20965:AS-NREN-PEERS.
> > >
> > > What would be the use case for documenting that particularly in RPSL?
> > >
> > > Dale
> > >
> > [Not an RPSL expert] For example, if an NREN that peers with Internet2
> > wishes to use the as-cone of Internet2 AND the as-cones of the NRENs
> > Internet2 provides transit as a basis for a prefix filter. Am I thinking
> > about this incorrectly?
> >
> >
>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
_______________________________________________
Routing-wg mailing list -- routing-wg@lists.gna-g.net
To unsubscribe send an email to routing-wg-leave@lists.gna-g.net