an effect of ignoring BCP38

[oberman at es.net (Kevin Oberman)]

> Date: Thu, 11 Sep 2008 11:24:43 -0700
> From: "Kevin Oberman" <oberman at es.net>
> 
> > 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.

Ack! Fat fingered it!

Certainly not 212K entries. That was supposed to be 12K. Not nearly so
impressive. 
-- 
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/0f7b9d8c/attachment.bin>