1:40 p.m.
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…
1:58 p.m.
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.
2:10 p.m.
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:
Steven Wallace
Director - Routing Integrity
Internet2
ssw(a)internet2.edu
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. 
2:23 p.m.
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(a)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:
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.
--
===============================================
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
===============================================
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.
Mark.
Steven Wallace
Director - Routing Integrity
Internet2
ssw(a)internet2.edu
_______________________________________________
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
3:40 p.m.
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(a)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(a)internet2.edu> wrote:
--
===============================================
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
===============================================
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:
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.
--
===============================================
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
===============================================
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.
Mark.
Steven Wallace
Director - Routing Integrity
Internet2
ssw(a)internet2.edu
_______________________________________________
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
3:49 p.m.
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(a)umn.edu> wrote:
Steven Wallace
Director - Routing Integrity
Internet2
ssw(a)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(a)internet2.edu>
wrote:
--
===============================================
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
=============================================== 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:
--
===============================================
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
===============================================
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(a)internet2.edu
_______________________________________________
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
5:59 a.m.
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(a)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(a)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:
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.
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.
Mark.
Steven Wallace
Director - Routing Integrity
Internet2
ssw(a)internet2.edu <mailto:ssw@internet2.edu>
_______________________________________________
Routing-wg mailing list -- routing-wg(a)lists.gna-g.net
<mailto:routing-wg@lists.gna-g.net>
To unsubscribe send an email to
routing-wg-leave(a)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(a)internet2.edu
2:37 p.m.
Thus spake Mark Prior (mrp(a)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(a)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(a)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(a)internet2.edu <mailto:ssw@internet2.edu>
> > _______________________________________________
> > Routing-wg mailing list -- routing-wg(a)lists.gna-g.net
> > <mailto:routing-wg@lists.gna-g.net>
> > To unsubscribe send an email to
> > routing-wg-leave(a)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(a)internet2.edu
> >
> _______________________________________________
> 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
2:33 p.m.
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
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(a)umn.edu> wrote:
Steven Wallace
Director - Routing Integrity
Internet2
ssw(a)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(a)internet2.edu>
wrote:
--
===============================================
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
=============================================== 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(a)internet2.edu
_______________________________________________
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
--
===============================================
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(a)lists.gna-g.net
To unsubscribe send an email to routing-wg-leave(a)lists.gna-g.net
2:38 p.m.
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:
[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?
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
8:24 p.m.
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:
[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
===============================================
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
9:22 p.m.
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:
> 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
> ===============================================
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
===============================================
10:18 p.m.
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> 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:
--
===============================================
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
===============================================
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
===============================================
1:47 p.m.
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:
--
===============================================
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
===============================================
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
===============================================
1:33 p.m.
On 2/4/2024 21:38, Steven Wallace wrote:
On 2 Apr 2024, at 10:33, Dale W. Carder wrote:
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.
Thus spake Steven Wallace (ssw(a)internet2.edu) on
Mon, Apr 01, 2024 at 11:49:09AM -0400:
[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? 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
1:51 p.m.
On 3 Apr 2024, at 9:33, Mark Prior wrote:
On 2/4/2024 21:38, Steven Wallace wrote:
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(a)internet2.edu
On 2 Apr 2024, at 10:33, Dale W. Carder wrote:
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. Thus spake Steven Wallace (ssw(a)internet2.edu) on
Mon, Apr 01, 2024 at 11:49:09AM -0400:
[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? 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
1:49 p.m.
On 2 Apr 2024, at 9:38, Steven Wallace wrote:
On 2 Apr 2024, at 10:33, Dale W. Carder wrote:
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
--
Jeff Bartig
Interconnection Architect
Internet2 AS11164 / AS11537
+1-608-616-9908
jbartig(a)internet2.edu
Thus spake Steven Wallace (ssw(a)internet2.edu) on
Mon, Apr 01, 2024 at 11:49:09AM -0400:
[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? 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
6:32 a.m.
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:
Steven Wallace
Director - Routing Integrity
Internet2
ssw(a)internet2.edu 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.
34
days inactive
36
days old
18 comments
6 participants
participants (6)
-
Dale W. Carder -
David Farmer -
Eli Dart -
Jeff Bartig -
Mark Prior -
Steven Wallace