10:01 p.m.
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(a)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(a)umn.edu) on Tue, Apr 02, 2024 at
03:24:37PM -0500:
_______________________________________________
Routing-wg mailing list -- routing-wg(a)lists.gna-g.net
To unsubscribe send an email to routing-wg-leave(a)lists.gna-g.net
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(a)internet2.edu> wrote:
> On 2 Apr 2024, at 10:33, Dale W. Carder wrote:
>
> > Thus spake Steven Wallace (ssw(a)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
===============================================