[address-policy-wg] 2006-05 New Policy Proposal (PI AssignmentSize)

> > Which is unfortunate. Because if scaling of the global routing
> > table is really as big of an issue as some people claim,
>
> It's just an issue which crops up again and again, and costs money to
> solve each time.  I've got a bunch of dual stacked sup720 pfc3b's.
> These no longer take a full v4 routing table in their default
> configuration, and shortly, I expect them not to be able to take a full
> v4 routing table using any soft configuration, except by filtering out
> routes.
>
> Yes, I can upgrade them.  But it's an issue.  It means downtime and lots
> of ¤¤¤.
>

> > And, don't forget that you even can do multihoming without PI address
> > space, by multihoming of PA assigment (if LIR permitted it).

> Some traffic flows on default gateway, even if you have BGP full view on
> the router... :)
> Normally, longest prefix has highest priority. If your
> multihomed prefix doesn't exist in some part of Internet, you may have
> troubles with connectivity with this part of Internet, don't looking PA
> or PI addresses you uses.

Sorry to say, but you're running an ISP on 6500's and propose a problem with
upgrading PFC-3B to PFC-3BXL at about 6.000 - 9.000 $ per engine ? Besides
that, you bought a 256k prefixes engine about 2 years ago (i think it was
released about sometime 2004) ?

There's not only an issue of routing / routing table scalibity but also an
issue of network scalability. The latter is in the sole responsibility of
the ISP / LIR.

Instead of table size/memory issues due to table growth we could also
discuss about CPU utilization issues due to BGP updates. Did you check the
CPU load of your sup720 loaded with a bunch of session ? The current number
of constant updates triggers about 10-20% (at least) load on 3BXL engines
when connected with decix peers and an upstream for example.

Maybe we should propose serious actions to be taken against flapping
systems, software- and standard-pc - based (zebra, quagga, etc.) networks,
too ... /-(
And in my opinion include bgp links across links of 2-4 mbit/s of bandwidth
to the list above - usually those are encountered to satisfy the
2-upstreams-rule.

As long as I see ASN >= 64512, prefixes down to /30, /16's with
sub-advertisements of 200 /24's with the same as path, packets with source
addresses out of RFC 1918 ranges even via large multinational ASN sessions,
I believe there're more important general operating problems than a bunch of
PI prefixes. IMHO the massive de-aggrations hurt much more (and yes, we're
doing some of that ourselves).

There're a lot of operational problems currently existing so why bother
about a few more PI prefixes and introduce additional administrative and
operational overhead ? Most time I spend with PI-related problems are
advertisements < /24 sent by customers (and therefore dropped) filing a
complaint later, LIR not responding to db object transfer request,
inaccurate or outdated db information etc.

But these won't solve by further constraining PI assignments. Remember, a PI
request has to be filed with RIPE by a LIR. You can refuse the customers
wishes - but that customer will find some LIR that will do just to take over
the customer from you.

Those arguments lead to the same discussion fought out in the IPv6 PI
discussion: if the internet's end users (customers) are denied their
requests by policies and their wishes are ignored, those areas will starve
in the long run.

regards,

Marcus

------------------------------------------
 Tropolys Rhein-Main GmbH
 Versatel Group

 Network Engineering and Administration
------------------------------------------
 ASN 8881 / 15837             MG3031-RIPE
------------------------------------------