Subject: Re: IETF multihoming powder: just add IPv6 and stir

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 2 May 2003 14:44:13 +0200

On vrijdag, mei 2, 2003, at 09:22 Europe/Amsterdam, Kurt Erik Lindqvist 
wrote:

[...]

> I think that this is a very good summary of the situation. And I think 
> that it is good that we from time to time remind ourself of this..:-)

Maybe we should remind the IPng wg as well...

>> So we should use Vienna to decide WHAT we want to do, the HOW is then 
>> only a question of engineering, which we're supposed to know how to 
>> do here in the IETF.

> I would also think that this is the main target of the Vienna meeting. 
> That said, it doesn't have to be the only thing we do.

I think that after the what question has been answered, the how will 
soon be raised.

>> It looks like the type of solution that most people like / the least 
>> people hate is a GSE++/8+8/6+2+10/16+16 type of solution. Such a 
>> solution is probably the least ambitious that can still be expected 
>> to work well in the long term and probably the most ambitious we can 
>> expect to be deployed before we run out of IPv6^H^H^H^HIPv4 address 
>> space. If we can't reach rough consensus on this as a general 
>> approach it is extremely unlikely we can reach it on something else.

>> Note that agreeing on this approach doesn't mean all other proposals 
>> should be off the table immediately: if they provide additional 
>> benefits (for instance, they can be deployed before the "official" 
>> solution is ready) they should be viable so individual authors can 
>> keep working on them as they see fit.

> I agree. Question is, with what you note above, how do we move that 
> forward? Leave that to Vienna to discuss or should me and Sean think 
> up away and present that?

It might be good to get the word out that multi6 wants to recharter and 
work on the identifier/locator thing aka GSE++ aka 6+10. Then we can 
see if the pro mob is larger than the anti mob at the meeting. It looks 
like this approach can't be too controversial (at least on this list) 
because nobody has taken the trouble of speaking out against it. (Just 
assuming they would if they were, for no particular reason.)

While making some other approaches official multi6 work items may be 
good for the proponent's egos, I don't think it will help those 
solutions much as there seems little interest in working on them as a 
group.

Alternatively, you can surprise us. It had better be a pleasant 
surprise, though.  :-)

Of course there are the little details of the two documents the wg has 
to deliver. I'm not going to mention the "R" word, but how about the 
"how is it done in v4" draft? I seem to remember some text about it, do 
we need to work on this and get it shipped by Vienna?

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 2 May 2003 09:22:03 +0200

Iljitsch,

> It seems to me the problem is that everyone brings different 
> assumptions and requirements to the table. For instance, the HIP 
> people are mainly interested in security and mobility, and solving 
> multihoming is secondary to those goals. Christian Huitema's proposals 
> are built around the idea that we can only make baby steps and should 
> work as much as possible with existing mechanisms. Michel Py doesn't 
> mind much that both ends must be changed in order to support MHAP; in 
> my geo stuff I don't worry about the fact that this will impose limits 
> on the network topology; and the GSE++ people aren't all that 
> concerned with the fact that GSE needs changes to not just one, but 
> many aspects of IP: routers, hosts, DNS.

> only a question of engineering, which we're supposed to know how to do 
> here in the IETF.

> solution is probably the least ambitious that can still be expected to 
> work well in the long term and probably the most ambitious we can 
> space. If we can't reach rough consensus on this as a general approach 
> it is extremely unlikely we can reach it on something else.
>

I agree. Question is, with what you note above, how do we move that 
forward? Leave that to Vienna to discuss or should me and Sean think up 
away and present that?

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 2 May 2003 14:59:17 +0200

>
> It might be good to get the word out that multi6 wants to recharter 
> and work on the identifier/locator thing aka GSE++ aka 6+10. Then we 
> can see if the pro mob is larger than the anti mob at the meeting. It 
> looks like this approach can't be too controversial (at least on this 
> list) because nobody has taken the trouble of speaking out against it. 
> (Just assuming they would if they were, for no particular reason.)

I am not sure I want to say that we recharter to the GSE++ model. I 
think we need to recharter mainly to update the milestones and also to 
perhaps change the charter somewhat. I am discussing this with Sean. 
Question is if this is worth doing before meeting in Vienna so that we 
can discuss this then, or if we should wait until after to reflect what 
has been discussed.

> solutions much as there seems little interest in working on them as a 

Well, that is certainly true. But I think that if they want to present 
and make their case for their solution and against a GSE based 
approach, they should be allowed to do that in Vienna.

> Alternatively, you can surprise us. It had better be a pleasant 

I am not buying the beer..:-) I will discuss with Sean and see what we 
think is the best way forward.

> "how is it done in v4" draft? I seem to remember some text about it, 
> do we need to work on this and get it shipped by Vienna?

We will last call the "Requirements" doc shortly. As for the 
"IPv4-HOWTO", does it actually bring us something new that will help us 
move forward at this point? Or is this a nice to have that gets some 
issues of the table?

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 2 May 2003 15:09:14 +0200

On vrijdag, mei 2, 2003, at 14:59 Europe/Amsterdam, Kurt Erik Lindqvist 
wrote:

> perhaps change the charter somewhat.

Ok, the charter isn't the most important thing, what we want to 
accomplish is.

> approach, they should be allowed to do that in Vienna.

Ok, you'll probably want to plan this part as the last item on the 
agenda because I'm pretty sure that after a few rounds of "geo is good" 
"no it's bad" people aren't in the mood to reach consensus on much of 
anything.  :-)

> As for the "IPv4-HOWTO", does it actually bring us something new that 
> will help us move forward at this point? Or is this a nice to have 
> that gets some issues of the table?

There are quite a few limitations for people that want to multihome in 
v4. Not everyone may be aware of those and subsequently underestimate 
the latent need for multihoming. So it might be good to document this 
after all.

---

From: Joe Abley <[email-masked]>
Date: Fri, 2 May 2003 14:15:16 -0400

On Friday, May 2, 2003, at 09:09 Canada/Eastern, Iljitsch van Beijnum 

> the latent need for multihoming. So it might be good to document this 

I am still very happy to collate ideas and edit that document, if 
people are happy for me to do so.

The main reason it stalled last time was that I wasn't happy being the 
only one writing down a description of current practices, since many 
different people are doing many different things for many different 
reasons, and there weren't many contributors to the doc at the time. It 
got as far as "rip all the v4 stuff out of the requirements doc into a 
separate doc", and that was about it.

Joe

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 2 May 2003 23:56:08 +0200

On fredag, maj 2, 2003, at 20:15 Europe/Stockholm, Joe Abley wrote:

>> There are quite a few limitations for people that want to multihome 
>> in v4. Not everyone may be aware of those and subsequently 
>> underestimate the latent need for multihoming. So it might be good to 
>> document this after all.
>
> reasons, and there weren't many contributors to the doc at the time. 
> It got as far as "rip all the v4 stuff out of the requirements doc 
> into a separate doc", and that was about it.
>

If we think that this will actually help us move forward - by all 
means, I think we should do it. If it is as Iljitsch say, that there 
are valid and tricky cases that should be documented, maybe we should 
do that. But I think you have a point in that  we then need to get more 
peole providing feedback.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 3 May 2003 13:43:34 +0200

> people are happy for me to do so.

Ok, here is some text:

The preferred way to multihome in IPv4 is to announce an independent 
block of address space over two or more ISPs using BGP. Until the 
mid-1990s this was relatively easy to accomplish, as the maximum 
generally accepted prefix length in the global routing table was a /24, 
and little justification was needed to receive a /24. However, in 1995 
the growth of the global routing table became a problem once again, and 
as a result Sprint decided to start filtering prefixes it accepted from 
peers based on prefix length. This broke the expectation that a 
multihomed network announcing a /24, regardless of where in the IPv4 
address space this /24 was taken from, would be globally reachable.

Over the course of the next several years, filtering on Regional 
Internet Registry allocation boundaries became accepted, if not 
widespread, practice. As of the late 1990s the RIRs allocate address 
space to those requesting it from them directly (mostly ISPs) in blocks 
of at least a /20. The address space in 192.0.0.0/8 and part of 
193.0.0.0/8 was allocated before CIDR was developed so it still 
contains a large number of much smaller blocks. This part of the IPv4 
address space is often called "the swamp". The networks that filter on 
prefix length typically accept much larger prefixes from swamp space.

In the mean time, RIR address distribution policies became increasingly 
more restrictive. The result of these two developments is that it is 
nearly impossible for an non-ISP organization to obtain a large enough 
block of address space to be sure its BGP announcement isn't filtered. 
Multihomers are often forced to work around this by taking regular 
provider aggregatable (PA) rather than the traditional 
provider-independent (PI) address space from one of their ISPs and 
announce this prefix to two ISPs. In theory, announcing this prefix to 
the secondary ISP would be enough as reachability over the primary ISP 
is assured by the aggregate this ISP announces. However, due to the 
"longest match first" rule, traffic would exclusively flow over the 
path with the longer prefix. So in practice the multihomer announces 
the longer prefix both over the ISP that announces the aggregate and 
over one or more secondary ISPs.

This practice has two advantages and one disadvantage for the 
multihomed network. The first advantage is that they can obtain a much 
smaller block of address space from an ISP than from a RIR. (Would-be 
multihomers still often optimize their networks for qualifying for at 
least a /24 by adopting accepted but relatively wasteful address 
deployment strategies.) The second advantage is that even if their 
announcement is filtered, they are still reachable over the primary ISP 
by virtue of the aggregate announced by this ISP. Even when the circuit 
to the primary ISP is down, this often works because the primary ISP 
will generally accept the announcement over the secondary ISP, so 
traffic flows from the filtering network to the primary ISP and then to 
the secondary ISP in order to arrive at the multihomed network.

The disadvantage is that the multihomed network must depend on the 
primary ISP for the aggregate. If the primary ISP goes down, this will 
impact reachability to networks that filter. And when the multihomed 
network leaves the primary ISP, they are generally expected to return 
the address space because otherwise this ISP would have to route 
traffic for a non-customer. Most ISPs will cooperate with this 
"shooting holes in an aggregate" solution to multihoming, but some are 
reluctant.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 May 2003 00:13:12 +0300 (EEST)

> separate doc", and that was about it.

As stated previously, I think the v4 document would be worthwhile.

I'm willing to work on it, and I think I've some stuff in my thesis for
extracting that would fit the bill quite nicely.

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