an effect of ignoring BCP38

[oberman at es.net (Kevin Oberman)]

> Date: Thu, 11 Sep 2008 20:59:39 +0300 (EEST)
> From: Pekka Savola <pekkas at netcore.fi>
> 
> On Thu, 11 Sep 2008, Jo Rhett wrote:
> > On Sep 11, 2008, at 10:10 AM, Valdis.Kletnieks at vt.edu wrote:
> >> By the time you walk our list of upstreams to any of the '5 biggest 
> >> anything', you've gotten to places where our multihomed status 
> >> means you can't filter our source address very easily (or more 
> >> properly, where you can't filter multihomed sources in general).
> >
> > I don't agree with this statement.  I hear this a lot, and it's not really 
> > true.  Being multihomed doesn't mean that your source addresses are likely to 
> > be random.  (or would be valid if they were)
> >
> > A significant portion of our customers, and *all* of the biggest paying ones, 
> > are multihomed.  And they might have a lot of different ranges, but we know 
> > what the ranges are and filter on those.
> 
> If you can manage ACLs for these customers, that's fine.  But maybe 
> your multihomed customers and '5 biggest anything' customers are 
> different.  Maybe your multihomed customer has 5 prefixes.  The big 
> ones could have 5000.  That's a pretty big ACL to manage.

It's big, but not un-workable. Just looking at our lists, the longest is
over 212K entries and we have 5 over 5K and 20 over 1K. We would have
even bigger ones if the IRR had more complete information.

I'll admit that doing this for a tier-1 would probably not work, though
I have never been able to try as the requisite information is not
publicly available.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080911/81e3a36b/attachment.bin>