Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
https://docs.google.com/document/d/1hKCo75qrC_21TdlQULCTgA5ApFCgBTSPo7tecgD-...
On 1/4/2024 20:40, Steven Wallace wrote:
Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
I would suggest that you develop a mutual set of communities to indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful.
Mark.
Mark,
That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from.
Steve
On 1 Apr 2024, at 9:58, Mark Prior wrote:
On 1/4/2024 20:40, Steven Wallace wrote:
Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
I would suggest that you develop a mutual set of communities to indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful.
Mark.
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
The document should recommend consistency in what NRENs announce to each other and peer NRENs and other policy goals we have in common. I have seen it several times where an NREN doesn't announce a prefix to one peer but does to another peer, causing traffic to go the wrong way around the globe. Actually, documenting the prefixes and the relationships will go a long way to resolving many of these issues. Nevertheless, we should recognize and document our common policy goals in addition to the mechanisms used to achieve the goals.
Thanks
On Mon, Apr 1, 2024 at 9:10 AM Steven Wallace ssw@internet2.edu wrote:
Mark,
That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from.
Steve
On 1 Apr 2024, at 9:58, Mark Prior wrote:
On 1/4/2024 20:40, Steven Wallace wrote:
Based on the feedback from this list, I’ve put together a rough draft
of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
I would suggest that you develop a mutual set of communities to indicate
if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful.
Mark.
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu _______________________________________________ Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
Steve,
In rereading it, in your example for Internet2, do you anticipate AS11537:AS-NREN-PEERS to be made up of the customer cones of the NRENs Internet2 will provide transit too?
For example, AS11537:AS-NREN-PEERS = AS7575:AS-CUSTOMER, AS6509:AS-CANARIE, AS-CERNEXT, ...
I ask because there are limits to the depth of how many references to references to references can be made for most RPSL tooling.
So you should probably cover that issue in the discussion.
Thanks
On Mon, Apr 1, 2024 at 9:23 AM David Farmer farmer@umn.edu wrote:
The document should recommend consistency in what NRENs announce to each other and peer NRENs and other policy goals we have in common. I have seen it several times where an NREN doesn't announce a prefix to one peer but does to another peer, causing traffic to go the wrong way around the globe. Actually, documenting the prefixes and the relationships will go a long way to resolving many of these issues. Nevertheless, we should recognize and document our common policy goals in addition to the mechanisms used to achieve the goals.
Thanks
On Mon, Apr 1, 2024 at 9:10 AM Steven Wallace ssw@internet2.edu wrote:
Mark,
That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from.
Steve
On 1 Apr 2024, at 9:58, Mark Prior wrote:
On 1/4/2024 20:40, Steven Wallace wrote:
Based on the feedback from this list, I’ve put together a rough draft
of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
I would suggest that you develop a mutual set of communities to
indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful.
Mark.
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu _______________________________________________ Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
--
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 ===============================================
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.
Steve
On 1 Apr 2024, at 11:40, David Farmer wrote:
Steve,
In rereading it, in your example for Internet2, do you anticipate AS11537:AS-NREN-PEERS to be made up of the customer cones of the NRENs Internet2 will provide transit too?
For example, AS11537:AS-NREN-PEERS = AS7575:AS-CUSTOMER, AS6509:AS-CANARIE, AS-CERNEXT, ...
I ask because there are limits to the depth of how many references to references to references can be made for most RPSL tooling.
So you should probably cover that issue in the discussion.
Thanks
On Mon, Apr 1, 2024 at 9:23 AM David Farmer farmer@umn.edu wrote:
The document should recommend consistency in what NRENs announce to each other and peer NRENs and other policy goals we have in common. I have seen it several times where an NREN doesn't announce a prefix to one peer but does to another peer, causing traffic to go the wrong way around the globe. Actually, documenting the prefixes and the relationships will go a long way to resolving many of these issues. Nevertheless, we should recognize and document our common policy goals in addition to the mechanisms used to achieve the goals.
Thanks
On Mon, Apr 1, 2024 at 9:10 AM Steven Wallace ssw@internet2.edu wrote:
Mark,
That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from.
Steve
On 1 Apr 2024, at 9:58, Mark Prior wrote:
On 1/4/2024 20:40, Steven Wallace wrote:
Based on the feedback from this list, I’ve put together a rough draft
of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
I would suggest that you develop a mutual set of communities to
indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful.
Mark.
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu _______________________________________________ Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
--
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 ===============================================
--
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 ===============================================
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
I'm not sure how that is helpful.
If Internet2 indicates that it is providing transit to Géant then as far as building filters is concerned that is different to Internet2 indicating who its customers are as the customer set should include all prefixes and as-paths I might see but the as-nren-peers set will not. If you are building filters via a RPSL tool then these export policies are different.
Mark.
On 1/4/2024 22:49, Steven Wallace wrote:
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.
Steve
On 1 Apr 2024, at 11:40, David Farmer wrote:
Steve, In rereading it, in your example for Internet2, do you anticipate AS11537:AS-NREN-PEERS to be made up of the customer cones of the NRENs Internet2 will provide transit too? For example, AS11537:AS-NREN-PEERS = AS7575:AS-CUSTOMER, AS6509:AS-CANARIE, AS-CERNEXT, ... I ask because there are limits to the depth of how many references to references to references can be made for most RPSL tooling. So you should probably cover that issue in the discussion. Thanks On Mon, Apr 1, 2024 at 9:23 AM David Farmer <farmer@umn.edu <mailto:farmer@umn.edu>> wrote: The document should recommend consistency in what NRENs announce to each other and peer NRENs and other policy goals we have in common. I have seen it several times where an NREN doesn't announce a prefix to one peer but does to another peer, causing traffic to go the wrong way around the globe. Actually, documenting the prefixes and the relationships will go a long way to resolving many of these issues. Nevertheless, we should recognize and document our common policy goals in addition to the mechanisms used to achieve the goals. Thanks On Mon, Apr 1, 2024 at 9:10 AM Steven Wallace <ssw@internet2.edu <mailto:ssw@internet2.edu>> wrote: Mark, That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from. Steve On 1 Apr 2024, at 9:58, Mark Prior wrote: > On 1/4/2024 20:40, Steven Wallace wrote: >> Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors. >> > > I would suggest that you develop a mutual set of communities to indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful. > > Mark. Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu <mailto:ssw@internet2.edu> _______________________________________________ Routing-wg mailing list -- routing-wg@lists.gna-g.net <mailto:routing-wg@lists.gna-g.net> To unsubscribe send an email to routing-wg-leave@lists.gna-g.net <mailto:routing-wg-leave@lists.gna-g.net> -- =============================================== 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 ===============================================Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
Thus spake Mark Prior (mrp@mrp.net) on Tue, Apr 02, 2024 at 04:29:54PM +1030:
I'm not sure how that is helpful.
If Internet2 indicates that it is providing transit to Géant then as far as building filters is concerned that is different to Internet2 indicating who its customers are as the customer set should include all prefixes and as-paths I might see but the as-nren-peers set will not. If you are building filters via a RPSL tool then these export policies are different.
This was the same path I was going down. If the goal is to build filters via RPSL, you would need to stitch together the IRR objects representing the customer cone of each peer.
Dale
On 1/4/2024 22:49, Steven Wallace wrote:
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.
Steve
On 1 Apr 2024, at 11:40, David Farmer wrote:
Steve, In rereading it, in your example for Internet2, do you anticipate AS11537:AS-NREN-PEERS to be made up of the customer cones of the NRENs Internet2 will provide transit too? For example, AS11537:AS-NREN-PEERS = AS7575:AS-CUSTOMER, AS6509:AS-CANARIE, AS-CERNEXT, ... I ask because there are limits to the depth of how many references to references to references can be made for most RPSL tooling. So you should probably cover that issue in the discussion. Thanks On Mon, Apr 1, 2024 at 9:23 AM David Farmer <farmer@umn.edu <mailto:farmer@umn.edu>> wrote: The document should recommend consistency in what NRENs announce to each other and peer NRENs and other policy goals we have in common. I have seen it several times where an NREN doesn't announce a prefix to one peer but does to another peer, causing traffic to go the wrong way around the globe. Actually, documenting the prefixes and the relationships will go a long way to resolving many of these issues. Nevertheless, we should recognize and document our common policy goals in addition to the mechanisms used to achieve the goals. Thanks On Mon, Apr 1, 2024 at 9:10 AM Steven Wallace <ssw@internet2.edu <mailto:ssw@internet2.edu>> wrote: Mark, That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from. Steve On 1 Apr 2024, at 9:58, Mark Prior wrote: > On 1/4/2024 20:40, Steven Wallace wrote: >> Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors. >> > > I would suggest that you develop a mutual set of communities to indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful. > > Mark. Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu <mailto:ssw@internet2.edu> _______________________________________________ Routing-wg mailing list -- routing-wg@lists.gna-g.net <mailto:routing-wg@lists.gna-g.net> To unsubscribe send an email to routing-wg-leave@lists.gna-g.net <mailto:routing-wg-leave@lists.gna-g.net> -- =============================================== 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 ===============================================Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
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
On 1 Apr 2024, at 11:40, David Farmer wrote:
Steve,
In rereading it, in your example for Internet2, do you anticipate AS11537:AS-NREN-PEERS to be made up of the customer cones of the NRENs Internet2 will provide transit too?
For example, AS11537:AS-NREN-PEERS = AS7575:AS-CUSTOMER, AS6509:AS-CANARIE, AS-CERNEXT, ...
I ask because there are limits to the depth of how many references to references to references can be made for most RPSL tooling.
So you should probably cover that issue in the discussion.
Thanks
On Mon, Apr 1, 2024 at 9:23 AM David Farmer farmer@umn.edu wrote:
The document should recommend consistency in what NRENs announce to each other and peer NRENs and other policy goals we have in common. I have seen it several times where an NREN doesn't announce a prefix to one peer but does to another peer, causing traffic to go the wrong way around the globe. Actually, documenting the prefixes and the relationships will go a long way to resolving many of these issues. Nevertheless, we should recognize and document our common policy goals in addition to the mechanisms used to achieve the goals.
Thanks
On Mon, Apr 1, 2024 at 9:10 AM Steven Wallace ssw@internet2.edu wrote:
Mark,
That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from.
Steve
On 1 Apr 2024, at 9:58, Mark Prior wrote:
On 1/4/2024 20:40, Steven Wallace wrote:
Based on the feedback from this list, I’ve put together a rough draft
of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
I would suggest that you develop a mutual set of communities to
indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful.
Mark.
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu _______________________________________________ Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
--
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 ===============================================
--
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 ===============================================
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
Routing-wg mailing list -- routing-wg@lists.gna-g.net To unsubscribe send an email to routing-wg-leave@lists.gna-g.net
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?
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?
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 ===============================================
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
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 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 ===============================================
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 ===============================================
On 2/4/2024 21:38, Steven Wallace 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?
The way I read your statement is that an Internet2 peer should expect to see Internet2's NREN peers as well as its customers from a peering but not the customers of those NREN peers.
Mark.
On 3 Apr 2024, at 9:33, Mark Prior wrote:
On 2/4/2024 21:38, Steven Wallace 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?
The way I read your statement is that an Internet2 peer should expect to see Internet2's NREN peers as well as its customers from a peering but not the customers of those NREN peers.
Mark.
Hi Mark,
I agree. It would make more sense for AS11537:AS-NREN-PEERS to contain the as-cones of I2’s peer. For example, AS11537:AS-NREN-PEERS would include AS-GEANTNRN and AS-GEANTNRENPEERS to accommodate I2 transiting routes from GEANT and its customers.
Is that more consistent with your thinking?
Thanks,
Steve
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
On 2 Apr 2024, at 9:38, Steven Wallace 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?
Steve,
If AS11537:AS-NREN-PEERS only contains the AS numbers of Internet2’s NREN BGP neighbors, then the AS-SET isn’t easily usable by others to create a complete prefix list. For each ASN in the AS-SET you would then need to determine the correct AS-SET to use for that ASN. As you’ve discovered, that can be a challenge.
If a BGP neighbor of AS11537 finds ASxyz in AS11537:AS-NREN-PEERS, there is still the challenge of determining which of ASxyz’s AS-SETs should be used. Even if we got 100% participation in the AS-SET naming you are proposing, one would still not know if ASxyz:AS-CUSTOMERS or ASxyz:AS-NREN-PEERS should be used.
If AS11537 is already using an AS-SET to filter routes from ASxyz, rather than just adding ASxyz to AS11537:AS-NREN-PEERS, wouldn’t it be more helpful to add the AS-SET instead of just adding ASxyz?
Jeff
Hi Steve,
Well AARNet still lists their communities (someone like Warrick would need to confirm if they still use them or not) but it doesn't scale to collect together someone else's communities and try to use them.
As a community you need to identify a collection of networks that makes sense as a collective of ASes where a similar routing decision might be helpful and then assign that a community and get all those ASN tagged with that community so that another network can make a routing decision based on it. The aim here is to help cut out unnecessary trans oceanic transits that might happen because BGP is just doing an AS hop count and that is a poor indicator of high performance connectivity and latency.
For example, NORDUNet might see SINET via Géant and Internet2. If SINET is tagged with an "east Asia" community then NORDUNet might have a routing policy that says that Géant is the best way to reach east Asia irrespective of BGP as-path length as the path across Eurasia is "better" than going across the Atlantic, continental US and the Pacific. Hopefully SINET would have a similar rule.
Mark.
On 1/4/2024 21:10, Steven Wallace wrote:
Mark,
That’s a great suggestion. I believe Internet2 used to publish a set of community tags that attempted to provide this capability. I’m looking through old records to see if there is anything worth reusing or learning from.
Steve
On 1 Apr 2024, at 9:58, Mark Prior wrote:
On 1/4/2024 20:40, Steven Wallace wrote:
Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors.
I would suggest that you develop a mutual set of communities to indicate if a prefix is a customer or a transit receiving peer, and which continent the prefix lives on so that some sensible pruning could be attempted. As an example it would probably be helpful for Géant to know if Internet2 is sending prefixes from South America or Africa as they possibly have a better path to those locations and would want to depreference an Internet2 version even if the AS path was shorter. If there are regions with limited connectivity options than enumerating them might be helpful.
Mark.
Steven Wallace Director - Routing Integrity Internet2 ssw@internet2.edu
-
Dale W. Carder -
David Farmer -
Eli Dart -
Jeff Bartig -
Mark Prior -
Steven Wallace