Hi, I have been thinking some more. Could we not solve the problem of legacy assignments of /32s that have been split to /48 with no covering route out of a RIR block with a /32 minimum with relative ease. AS operators that choose to filter these RIR blocks on /48 minimum have no problems, ISPs that choose to filter on /32 minimum do as they loose visibility of these "island networks" aka no covering route.
If we were to extend peeringDB to add a field to indicate with there is a covering route or not, this could then be used to assign a peer to a peer-group with the associated filter as appropriate either permitting 48s or denying them. This enables the people that have deigned their networks in this fashion to indicate as such, and those who choose to use the information can accept their prefixes without having to accept any old 48. Peering DB could then also publish a RegExp string from their database of all the ASes that have indicated no covering route. This could then be used, if desired, by an AS operator to filter his BGP sessions which are not directly with the end AS, transit or peering, enabling the deployment of a route-map that would match the RegExp and prefix length of 48 and permit these, then match the Regexp with a prefix length <>48 and deny all of that (because there shouldn't be any), and then match what is left on a filter list that selected on RIR minimums. The island networks would be incentivised to register, those that choose to filter can, those that don't want to can accept all 48s. Filters can be used on RIR minimums and new assignments made out of the new non-contiguous address blocks with a 48 minimum size, and the legacy problem is handled. Everyone is happy. No technology needs to change and all that is needed is for someone such as peeringDB to keep a record of the ASes that indicate they don't have a covering route and this can be readily used when setting up direct peerings or used to construct a generic filter for all ASes in this category to be applied to other BGP sessions. Thoughts.... RIPE seems to be saying its upto the community to decide policy, ours is a /32 minimum and we strongly recommend you don't de-agregate but we are not going to tell you you can't. The legacy of island networks is the only thing that forces this issue to be dealt with one way or the other as it is not possible for them as they currently have things setup to announce the covering route. I think a BCP would be good that considered alternatives to the polarized debate of do or don't do minimum filters vs TE routes vs why should I carry your TE. I think something like the above could be simply implemented as an opt in system that could be used if operators choose to that would keep all three groups of AS operators happy. Ben -----Original Message----- From: Ben S. Butler Sent: 16 November 2012 00:54 To: 'Matthew Petach'; Ben S. Butler Cc: nanog@nanog.org Subject: RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
