Subject: Re: draft-savola-multi6-asn-pi-01.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 Feb 2004 15:48:31 +0100

On 31 jan 2004, at 8:35, Pekka Savola wrote:

> I've sent it to be published to the I-D secretariat, and in the
> meantime is available at:

> http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-asn-pi-01.txt

While limiting this to 15 bits worth of AS numbers solves some 
problems, it also immediately removes much of the potential use from 
this proposal, as this way there is still no solution for people who 
want/need to multihome in IPv6 but don't have an AS number today.

I think if we want to do _something_ like this, there are probably 
better ways to do it.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 20 Feb 2004 18:21:42 +0200 (EET)

> I think if we want to do _something_ like this, there are probably 

I've targeted this solution for the biggest corporations, for which 
(IMHO) multiple addresses are a non-starter.  Such corporations have 
AS numbers.  Such corporations don't crop up from nowhere.

But if folks feel we should just allow everyone, one could just as 
well allow full 16 bits or even 32 bits.  That would just lead to the 
exhaustion of AS numbers, though -- and folks would be worse off than 
before, as also small enterprises would get AS numbers for the "easy 
multihoming ticket".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 20 Feb 2004 17:57:38 +0100

> (IMHO) multiple addresses are a non-starter.

I also think that big institutions will be reluctant to use multiaddressing,
for the comments that i've heard on different lists.

>  Such corporations have AS numbers.  Such corporations don't crop up from
nowhere.

Yes, but many other who are not big sites also have AS numbers. I even know
people who have an AS number at their home network.

So, automatically giving all people who have a AS number today an PI address
block may not be appropriate.

I guess that first we should agree that really big sites won't use
multiaddressing and that they should obtain their own PI block.
Then we need to define the criteria to identify big sites
A finally then decide which addresses we should give them

IMHO, the first decision concerns the IETF
I am not so sure about the second and the third point, perhaps this should
concern the rirs, more than the ietf?

Regards, marcelo

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 22 Feb 2004 17:08:10 +0100

> concern the rirs, more than the ietf?

Agreed. We could make our lives very easy and just say that the current 
filtering policy is up to the RIRs to handle. By that giving them also 
one of the other keys to the multihoming problem - just break 
aggregation. IMHO this is where we are today. But as most sites 
actually do filter on allocation boundaries, we don't have an issue.

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 23 Feb 2004 11:29:36 +0100

>> I am not so sure about the second and the third point, perhaps this
>> should concern the rirs, more than the ietf?

> actually do filter on allocation boundaries, we don't have an issue.

I am profoundly unsatisfied with the way the RIRs operate in this 
regard. For instance, they set a policy and then don't stick to it (see 
my rant at http://www.ipv4.bgpexpert.com/archive2003q4.php never mind 
the "ipv4" in the URL, I'm on the road and for some reason contacting 
my site using a hostname that has an IPv6 address doesn't work too 
well). Also, since anyone can participate in the policy decision making 
process, they're pretty much a special interest group in this regard 
and if there is enough pressure to make something happen, it will 
happen, regardless of whether it's a good idea.

If we want to break aggregation in a way that doesn't break scalability 
then I think we need to put out an RFC that tells people how to do it, 
so that it's actually usable (no point in doing this if network 
operators filter) and scalable. I think it can be done but Pekka's 
draft isn't the way.

Iljitsch

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 23 Feb 2004 12:11:16 +0100

> regard. For instance, they set a policy and then don't stick to it 
> (see my rant at http://www.ipv4.bgpexpert.com/archive2003q4.php never 
> mind the "ipv4" in the URL, I'm on the road and for some reason 
> contacting my site using a hostname that has an IPv6 address doesn't 
> work too well). Also, since anyone can participate in the policy 
> decision making process, they're pretty much a special interest group 
> in this regard and if there is enough pressure to make something 
> happen, it will happen, regardless of whether it's a good idea.

Well, there are a lot of things you can say about the RIR policies, but 
let's take that to some other mailinglist :)

>
> If we want to break aggregation in a way that doesn't break 
> scalability then I think we need to put out an RFC that tells people 
> how to do it, so that it's actually usable (no point in doing this if 
> network operators filter) and scalable. I think it can be done but 
> Pekka's draft isn't the way.

I think that the issue of breaking aggregation will have to be part of 
the general architectural discussion. Just like any other proposal.

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 23 Feb 2004 18:16:11 +0100

> let's take that to some other mailinglist :)

Too many mailinglists, too little time... Also, the fact that the RIRs 
don't stick to the policy they themselves (+ IANA) published is a very 
bad thing. I think the IETF has to set stricter boundaries on what the 
RIRs can and can't do in their policies. But it's no use discussing 
this in general, we'll talk about it when it gets more concrete.

> the general architectural discussion. Just like any other proposal.

Sure, no problem. But this draft isn't the right way to go about it. I 
think the solution is to be found in the area of shooting holes in 
provider aggregates. But we need to get away from the ad-hoc way this 
is done today which couples a relatively low level of redundancy with a 
high number of additional entries in the global routing table. The fact 
that we have more or less fixed ISP aggregate and end-user assignment 
sizes allows us to filter more aggressively so if we couple this part 
with a set of "if you're going to allow your customers to multihome, 
this is what you need to do" rules that should do the trick. I'll be 
happy to write something down either before Seoul or after.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Feb 2004 09:35:32 +0100

> AS numbers.  Such corporations don't crop up from nowhere.

The trouble with large corporations is that they typically have many 
offices. Now either all of those connect to the net individually, and 
then having a single AS and a single block of address space is of 
little use, or those offices are connected through a private network 
that also carries internet traffic, in which case they are their own 
ISP and they should qualify for an AS and address space like regular 
ISPs. (The 200 customers within 2 years requirement might be slightly 
problematic but there is push to lower this a bit anyway.)

> before, as also small enterprises would get AS numbers for the "easy

I agree that would be a bad idea.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Feb 2004 10:43:14 +0200 (EET)

On Wed, 25 Feb 2004, Iljitsch van Beijnum wrote:
> little use, 

Well, it could be of a lot of use.  But as noted before by Craig 
Huegen (at least), if using a single netblock, these corporations 
would have traffic engineering requirements.  If more specific routes 
aren't allowed for traffic engineering purposes, or advertising just a 
regional subset of address space, this is not enough for a solution.

An alternative mechanism, which I have stated earlier, is to 
"divide-and-conquer" even the larger enterprises: every branch which 
connects to ISPs has different addresses.  This will be pure hell for 
network admins if they have offices in e.g. 100 or 200 countries, but 
such is life, I guess... :)

Of course, almost all solutions have ignored these traffic engineering
considerations.

> or those offices are connected through a private network 

IMHO, the RIR allocation policies do not allow an /32 for this 
specific case of "Enterprise network having its customers within the 
enterprise".

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Feb 2004 10:25:47 +0100

> Well, it could be of a lot of use.

It could be, but I'm not convinced it is most of the time.

> But as noted before by Craig
> would have traffic engineering requirements.

Everyone who multihomes and doesn't have huge piles of money to burn 
has traffic engineering requirements. I agree this is problematic, and 
we need to revisit this at some point.

> If more specific routes

Guess what, it is allowed, but most people filter these routes out.

> such is life, I guess... :)

One man's "pure hell" is another man's job security.  :-)

Why should BigCorp Inc. be allowed to announce 200 /40s for 200 
offices, when a collection of 200 small corportations isn't allowed to 
do the same thing collectively?

It's very simple: either you announce your entire block everywhere and 
carry traffic from location A that needs to be in location B over your 
own network, or be like anyone else and get PA space (which you can 
then use for multiaddress multihoming).

>> ISPs.

> specific case of "Enterprise network having its customers within the

Yes, the current "200 customers in 2 years" requirement is problematic 
(although I'm sure a fortune 500 company can meet it, just give your 
employees /48s or some such) but so far nobody has been able to come up 
with something better.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Feb 2004 09:07:44 +0200 (EET)

> employees /48s or some such) but so far nobody has been able to come up 

I've been contacted about this off-list, so let me clarify.

The current policy is more than just "200 /48's".  To be more 
specific, you have to make the allocations to *other organizations*.

From RIPE policy, which is identical to the "global policy proposal" 
in this aspect:
----
5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an 
organisation must:

    a) be an LIR;

    b) not be an End Site;

    c) plan to provide IPv6 connectivity to organisations to which it 
will assign /48s by advertising that connectivity through its single 
aggregated address allocation; and

    d) have a plan for making at least 200 /48 assignments to other 
organisations within two years.
----