[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
Yes, but a multi-homing customer would have PI space from an appropriately filtered block allowing /24 PI v4 or /48 PI v6. An ISP would have their own RIR PA allocation /22 to /19 v4 or /29, /32 v6 block that are from blocks that follow along the lines of minimum assignment size for that block. This is not a problem created by the registries or by the filters. The problem comes with ASes that don?t have a backbone interconnecting all of their POPs / islands and are therefore unable to add a covering route and do not provide a route via any transit provide for the whole ip block at the RIR minimum boundary. In some ways whether people should:
1> Have a network of none interconnected islands that take IP space from the same IP block below RIR minimum?
2> Should we filter these networks?
3> Should the /32 be visible in the route table somewhere if the intention that component /48s are going to be visible on the Internet.
I don?t like the IRR answer particularly as it requires a level of third party trust that I am not entirely comfortable with, nor configuring separate filters for each BGP peering session.
From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com]
Sent: 14 November 2012 13:25
To: Ben S. Butler
Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler <Ben.Butler at c2internet.net<mailto:Ben.Butler at c2internet.net>> wrote:
3> Don't use filters, generate it from an IRR?
Given there is no "right" answer what is considered to be the best fit one?
This sounds like your best bet. Assuming you can find an IRR with comprehensive enough coverage.
The other option is of course "don't filter based solely on RIR minimum assignments" ..
I know at least some ISPs (like swisscom) do this for v4 too, but that simply means people who try to multihome with anything less than a /19 in level3 land aren't going to succeed.
ip prefix-list martians seq 8000 permit 188.8.131.52/7<http://184.108.40.206/7> le 19
Not so much of a problem in v4 but as you saw for yourself, you risk not seeing prefixes at all if you try this.
Suresh Ramasubramanian (ops.lists at gmail.com<mailto:ops.lists at gmail.com>)