RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?

[Gert Doering]

Hi,

On Thu, Jul 12, 2012 at 12:42:27PM +0200, Chris Welti wrote:
> > If you do not want to carry everything there is, you could just put
> > up an arbitrary limit of your own choosing, and add a default route
> > to your upstreams.  (Which is what we do for prefixes coming from
> > other regions, as it doesn't make a huge difference for us where we
> > send traffic for a random american /24 to - all our upstreams will
> > do a reasonable job in delivering the packets.  If they don't, we find
> > new upstreams that do)
> 
> Yeah, but that strategy doesn't help the routing table size in the DFZ.
> You're just moving the problem up one tier (your upstreams).
> Someone will have to carry all those prefixes.

The routing table size isn't helped by filtering by prefix size for
certain ranges.  What does it help if I can all of a sudden announce
lots of /24s "unfiltered", just because someone else happened to receive
an official /24 from the same /8?

And indeed, you can expect to see /24s from *all* /8 before long - so what
you proposed "tell us which /8s have opened up!" is just buying you a few
months before they all show up on the list.


What would *really* help the DFZ is "all upstreams accept only those
routes from their customers that are properly registered in a proper
IRR DB", potentially improved by "and work to educate customers whether 
or not deaggregates (for TE, geographic diversity, or other reasons) 
need to be visible world-wide".  This is where the energy needs to go.


> As long as only the "valid" assignments/allocations end up in the DFZ that isn't
> a problem, but if people begin to de-aggregate their larger allocations for
> traffic engineering or just because they are too lazy to only announce aggregates,
> that leads to a really unnecessairy and uncontrollable bloating of the global
> routing table (DFZ).

True, and this is the largest group of routes in the IPv4 tables today, 
and a significant chunk of the IPv6 tables as well.

"Just filtering them out by size" isn't going to solve all possible use 
case - and isn't going to help you much if, for example, DTAG decides
to announce 2003::/19 as individual /32s...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20120712/0783fc86/attachment.sig>