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@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@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@internet2.edu <mailto:ssw@internet2.edu>> wrote: > > > On 2 Apr 2024, at 10:33, Dale W. Carder wrote: > > > > > Thus spake Steven Wallace (ssw@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 ===============================================