Hi, 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. Ben From: Suresh Ramasubramanian [mailto:ops.lists@gmail.com] Sent: 14 November 2012 13:25 To: Ben S. Butler Cc: NANOG 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@c2internet.net<mailto:Ben.Butler@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. http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf ip prefix-list martians seq 8000 permit 8.0.0.0/7<http://8.0.0.0/7> le 19 [etc] 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@gmail.com<mailto:ops.lists@gmail.com>)