That was my thought. It's been quite a while since I've been on a WG
call but the last ones involved fixing suboptimal routing and adding
communities that provide hints on the location and connectivity of a
prefix might help supplement BGP's limited knowledge (which in itself is
just a hop count so a 10,000km 1Gbps path of AS path length 3 will win
over a 200km 400Gbps path with a AS path length of 4).
Action based communities are between you and your peer.
Mark.
On 3/4/2024 05:18, David Farmer wrote:
My thought was that the BGP communities would be
primarily advisory,
like what part of the globe the route originated from, etc... For
example, GREN:EEEE would mean the route originated in Europe, and
GREN:AAAA would mean the route originated in Asia. This would provide an
additional basis for local policies on which routes to prefer or accept
from which peers.
Action-based BGP communities would be based on the ASN of the network
where the action was to take place. For example, if you wanted Internet2
to prepend to other International peers, that would be 11537:XXXX
Thanks
On Tue, Apr 2, 2024 at 4:22 PM Dale W. Carder <dwcarder(a)es.net
<mailto: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
<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 <mailto: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(a)internet2.edu
<mailto:ssw@internet2.edu>> wrote:
> On 2 Apr 2024, at 10:33, Dale W. Carder wrote:
>
> > Thus spake Steven Wallace (ssw(a)internet2.edu
<mailto: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 <mailto:Email%3Afarmer@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
===============================================
--
===============================================
David Farmer Email:farmer@umn.edu <mailto:Email%3Afarmer@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
===============================================