4: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