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.li...@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.but...@c2internet.net<mailto:ben.but...@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.li...@gmail.com<mailto:ops.li...@gmail.com>)

Reply via email to