On Wed, May 23, 2018 at 08:03:45AM -0700, Randy Bush wrote: > >>> me and Job Snijders have recently submitted > >>> draft-ss-grow-rpki-as-cones-00, which discusses AS-Cones, an > >>> attempt to bring as-sets into RPKI to facilitate route filtering. > >> > >> in irr, an as-set may reference an as-set. could you explain the > >> authority model you have for this when as-sets are signed? > > > My initial thinking for RPKI AS Cones, is that a given Cone in an > > ASN's namespace can only be defined by the owner of the ASN in who's > > namespace the Cone is defined. > > namespace?
In the IRR world we have the concept of hierarchical naming of AS-SETs: an example is "AS15562:AS-SNIJDERS" [1] - under the "AS15562" hierarchy only the owner (or delegated folks) can add/change/remove AS-SETS. I call this a namespace, should a different term be used? > isn't this the irr authorisation model? The IRR AS-SET feature is working pretty well (since it is better than nothing), but there are some downsides. For instance "AS15562:AS-SNIJDERS" can exist in multiple IRR databases, and we don't know which of those was actually created by the owner of AS15562. I hope this can be addressed in AS Cones. Another problem is that there no longer is a way (or perhaps there never was) to autodetect what AS-SET should be used by which organisation to generate a filter. RPSL is broken, fundamentally flawed. Perhaps this can be addressed - not by introducing a new language - but just having a handy naming convention. Think of it as "AS15562:AS-2914", so AS 2914 knows it should use AS15562:AS-2914 if it exists, and if it doesn't exist use AS15562:AS-DEFAULT. > and how did that work out for us? I consider it a feature that anyone can add anything to an AS-SET they created, this puts the workload on transit providers and doesn't require stub networks to do anything. The "member-of:" feature is barely used and seems to pose too much work. Clock is ticking... multiple RIRs are struggling with their IRRs (or lack thereof). If IETF does not pony up a solution that is good enough for operational purposes, we may end up with RIRs investing in legacy technology and a continuation of the duplication/discovery/ownership issue. There is an opportunity here and now, let's work on it? Kind regards, Job [1]: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=AS15562:AS-SNIJDERS#resultsSection _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
