[address-policy-wg] Re: Re: a consensus, about what?

Hi @all,

first: thanks @Carlos for your response.

I've read a lot of statements and position herein, some making sense to me,
some hinting a way to go on and some simply sounding like 'ground-keeping'.

I'd like to try to sum up the problems (real, possible future, self-made)
and add a few thoughts myself.

Currently there're ~35.000 AS'es handed out with ~180.000 prefixes carried
in the v4 table. The v6 table houlds about 500-600 prefixes now.

According RIPE-353 about 1/4 to 1/3 of the ASN handed out aren't seen in the
forwarding paths.

This leads to the first (and I think most urgent problem) taking a look at
the rate ASN's a assigned nowadays. In rough numbers there're about 10.000
ASN not being visible in the routing table. And like someone else already
mentioned in the 'multi-homing v6' discussion, how many of the newly handed
out ASN are really required for multihoming ? I don't want to open a
discussion about 'proper' way to multihome (again), but how many of the
'corporate' ASN handed out are really going to connect to more than one
upstream provider ? (I know of LIR's operating their network with dual
uplinks for the same upstream and a 'fake' secondary. Before someone starts
shouting how to know: one of our aligned companies had been on of these.)
During my years in ISP networking bussiness I've more than once come upon a
network with fake entries and customers/potential customers multihoming to
one upstream and asking for an ASN request with a second upstream being
1/50th to 1/10th of the primary bandwidth to satisfy requirements. These
setups I'm almost sure don't need an ASN. And how about the non-visible ASN
? They may be hoarded, used for confed's after mergers & takeovers, a few
for test networks (if reasonable argumented I agree here) or simply not
returned to the pool after removal due to laziness.

So first point to consider when talking 'needless' resources is:
how to possibly limit the number of multihoming-ASN handed out to the ones
really needed and how to move people to hand them back when no longer needed
?

In case of PI space this is a bit more complicated. Adresses hasn't to be
visible in the global routing tables to satisfy a need for globally unique
adresses. Although in v4 world, RFC1918 & NAT are a fine thing to conserve
address space, but forcing their use would be dictating others how to
operate their network. This gets me to the assumption not every PI address
space will get through to the routing tables. Surely PI space mostly not
being aggregatable is filling up the tables with prefixes. But don't the
de-aggregated PA's also do ? And what about invalid announcements (take a
look to your table and search for ASN >=65512 !) ? What about the (IMHO)
pollution of the table with nonsene of entries longer - let's say - /24 ?
Did you ever take a look about your table in regard to prefix sizes ?
There's a lot of /28 - /30 flowing around. At least for the /30 I think
there're guys messing up their redist and BGP filters. Before we - the LIR
admins - aren't able to agree on senseful filters and what's mess not to be
announced (prefix length) and behave ourselves (de-aggregates) where's the
right to discussing other peoples needs ? (just a comment: I've read someone
here stating something like: do what you want, but not in my table.
Hopefully there's no flaw to find in YOUR announcements ....)
I've written in my previous (messy) post, but again: are we the ones
entitled to decide how a customer has to run it's network and what he needs
and what not ? Let me ask a simple question: how many of you do work
directly in first line on your customers (in means of consulting your sales
guys) ? Customers (especially corporate) nowadays are striving for redundant
/ multihomed connectivity and - the Level3/Cogent de-peer a few months ago
showed this - how can you be 100% sure connectivity even by multiple links
to one ISP won't take you offline ? There could be a serious network issue,
a de-peer, the network could be blown by one of those nasty bot-nets etc.
Many companies are moving ever more bussiness towards their internet access
and therefore they reasonably ask for best connectivity possible (at
reasonable cost). You can shake your head as furiously you like, but the
primary target won't change: customer's demand. Did you always try to tell
your boss that you wouldn't submit a PI or ASN request for a potential
customer ? I bet you wouldn't do that often - maybe more than once, but
you'd soon be looking for a job. Often a solution can be worked out together
with the customer but not always. The customer will simply move on to
another ISP willing to - at least try to - fulfil his wishes. PI space in v6
in demanded by customers the same way it is for v4. Either there'll be a way
to satisfy this need or a solution to the multihoming dilemma with globally
unique adresses SHORTLY or IPv6 can be dropped RIGHT NOW.

This get's the second and third thing to consider:
how do we get people to hand back no longer needed PI space and how will we
handle IPv6 PI ?

On side of the ISP's there're worries about size of the routing tables and
the costs to replace your routers. But did you take a look at the growth
rate of utilized bandwidth ? All these 'high-bandwidth' consumer links like
DSL and such are driving bandwidth requirements up and up steadily. How long
do you think your routers can keep with the traffic volume ? With number and
bandwidth of consumer internet access increasing also the risk of floods and
the basic 'trash' flowing around increases. On customers side there're
worries about stablility and cost also, but maybe taken in another
perspective. Corporate customers are willing (at least most of them) to pay
more for a stable setup lowering (or at least pinning) their TCO. This
includes not having to renumber regularly and/or being dependent on one ISP.
But even if they are willing to pay more for true multihoming I'd like to
hear how you sell them becoming a LIR themselves although they will never
provide internet services to others but would have to care for a lot rules
and administrative work in addition.
PI as it's administrative nature is now is exactly what the want and need.

So regardless where you put your eyes upon, it always comes back to money.

So why not take (try) a simple approach.

- get IPv6 (corporate-)ready by handing out PI space
    out of a well-known address space in chunks of  /40 to /48

- limit the routing table size by agreeing on 'best practice' filters for
prefix-length

- limit the routing table size by bashing de-aggregators --- just kidding
... ---

- limit routing table size and assigned resources by creating a motivation
to hand
    resourced back.

The last item is IMHO the crucial.

RIPE-330 charging scheme states:

Note: For AS Numbers and PI IPv4 allocations, only the allocations from the
past 12 months dating back from the 30 September 2004 are taken into account
as these resources are allocated or assigned on behalf of third parties.

WHY ???

Let non-LIR's pay for their resources as well, but without requiring them to
become a LIR.

I'd propose something like:

Add a new member category 'corporate' for those who don't provide internet
services to others but are in need of resources and assign a charging scheme
without any time variable.

One-time:                500 EUR
yearly:                     250 EUR
per ASN:                250 EUR (per year)
per PI assignment:   150 EUR (per year)

With at least 650 EUR a year people would think twice about their needs.

In addition remove the ASN's for ISP's from this charging scheme and also
charged fixed 250 EUR per ASN/year. This would hopefully push at least some
people to hand back no longer used ASN or 'official' ASN used for confed's.

regards,

Marcus

----------------------------------------------------------
            Tropolys Rhein-Main GmbH

      Network Engineering and Administration

 Fon: +49-(0)6131/129343 | Fax: +49-(0)6131/129321
      Mombacher Str. 40, 55122 Mainz, Germany
----------------------------------------------------------
 AS15837 | AS8638 | MG3031-RIPE
----------------------------------------------------------