all the mails on Filtering

Hi,

  So what happens to multihoming assignments made by the ISP? That means
the multihoming assignment can't be used as a backup. If the customer's
connection to the ISP which made the multihoming assignment gets lost,
then it can't use its multihoming assignments (say a /24) to get traffic
from some other ISP?!

Thanks to all,
Harsha.

If you're multihomed you can generally obtain provider indepdent
space from your RIR.

  Most people who do this filtering do it on the RIR boundaries
for their minimum allocation.

  If you are annoucing your provider assigned space
as a /24, they tend to announce the (/14 - /rir-minimum)
so your packets will follow the aggregate. If they
are not announcing their aggregate then you will have
problems. Most people in that case would blame
the provider for not announcing their space.

  - Jared

Hi,
  But it appears that there are many cases where customers prefer to take
a prefix from the ISP rather than an RIR even if it is a /19 or a /20 -
for example from the /11 of a big ISP, there are 50 /19s and /20s which
are multihoming assignments.

  I was told that this saves the cost of RIR membership for the customer.

  Moreover, how do we know the RIR makes multihoming assignments from a
separate /8 - atleast in the case of RIPE it does not I think (in the case
of APNIC it does). If we are of sure of this - i.e. that a multihoming
assignment from an RIR comes from a separate section of the address space
- we can't filter.

Harsha.

Hi Harsha,
this occurs quite often as a topic for discussion here.. the answer is they do
it because they can and unless you have an RIR allocation theres no guarantees
and to be fair the RIRs do state that. and good/bad agree/disagree some ISPs
filter more than others and theres not a lot you can do!

providing you connect to the provider who gave you the prefix you wont have any
issues....

Steve

This has been rehashed time and time again on this list, and others.
The fact is, ISPs have to filter somewhere to keep routing table growth
in check. It makes more sense to filter out announcements longer than
the longest assignment within an RIR's space than to filter on any
arbitrary boundary. I think everyone will agree with that, even if they
do not agree that filtering is necessary or good.

As an example of why filtering is good, click on this link and visit the
CIDR Report AS Summary for an ISP here in Kentucky. They used to have
over 50 useless announcements within one /18, for which they had an
aggregate announced as well. They seem to have gone to some efforts to
reduce the route table pollution the emit, and I applaud their efforts,
however you can further reduce the amount of pollution you accept from
them, and other ISPs who mistakenly announce from their IGP or for any
other reason do not announce blocks as they are assigned by the RIR,
simply by filtering on the minimum assignment size.

http://bgp.potaroo.net/cgi-bin/as-report?as=11979&view=4637

I think there are very few networks who purposely announce longer
networks to control their inbound traffic flow, verses the number who
mistakenly do so. Again, everyone will agree. Except, perhaps, Ralph
Doncaster. And if you want to spend your FIB entries, and your money,
making your bits flow to him in the manner that's most cost-effective
for ISTOP, then more power to you. Most folks will agree that is up to
Ralph and Ralph's ISP(s) to work out, though.

[snip]

  But it appears that there are many cases where customers prefer
to take a prefix from the ISP rather than an RIR even if it is a
/19 or a /20 - for example from the /11 of a big ISP, there are 50
/19s and /20s which are multihoming assignments.

  I was told that this saves the cost of RIR membership for the
customer.

When shaving pennies, be sure you don't slice off your thumb. And
if you do, don't blame someone else.