Subject: RE: Draft: PI addressing derived from AS numbers

From: "J. Noel Chiappa" <[email-masked]>
Date: Sat, 1 Feb 2003 12:51:07 -0500

> From: Pekka Savola <[email-masked]>

    > But what they mainly want, as far as I can see is independence

If people wanted a namespace that was independent of topology, they should
have put one into the architecture when it was first designed.

Routing-names in a global-scale network will *always* depend on network
location.

The only namespace IPv6 has (other than DNS names) are addresses, which are
routing-names.

If an architecture without a namespace which is independent of topology in
unacceptable, then people have to either i) radically modify IPv6, or ii)
junk it.

Is a namespace with independence really absolutely required? If so, saying
tbat is equivalent to saying you have to either radically modify IPv6 (so
it supports that), or junk it (since it doesn't).

"We are a lighthouse. Your call."

	Noel

---

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Feb 2003 22:24:25 +0200 (EET)

> it supports that), or junk it (since it doesn't).

In the long term, i'm rather convinced that an architectural change will 
be required.  I can't see other scalable alternatives.  

But it's not all-or-nothing.  Current common practises require
independence already -- at "largish ISP" level.  This is deemed
acceptable, in contrast to late aggregatable global unicast addressing
(RFC2374) with hard limits.  So, independence is OK to some degree.. but
we must not get that degree get too far unless we have measures to provide
for it.

-- 
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: Randy Bush <[email-masked]>
Date: Sat, 01 Feb 2003 15:59:22 -0800

> be required.  I can't see other scalable alternatives.  

this is also what i see, though i am anxiously awaiting enlightenment.

randy

---

From: Pekka Savola <[email-masked]>
Date: Sun, 2 Feb 2003 09:38:16 +0200 (EET)

> this is also what i see, though i am anxiously awaiting enlightenment.

Well, speaking of enlightenment, I've had a few ideas lately.  I'm pretty 
sure someone has thought along the same lines at some point, but here goes 
anyway.

The current multihoming practises seem to have an impact on the global
routing table on two different axels:

 1) the absolute number of routes
 2) the number of changes in the routing tables due to the large number of 
routes, required processing and update propagation etc.

For example, consider (in future) 10,000 routes coming behind a
next-to-the-origin-AS ISP.   If something bad happens to the ISP, all 
10,000 routes will be withdrawn, and a secondary path will be selected 
(perhaps 3,000 will go to ISP X, 3,000 will go to ISP Y, and 4,000 go 
nowhere, simplifying).

The absolute numbers _might_ be manageable if changes were manageable: I'm
fairly certain of that at least to the degree of O(10^6) -- memory is
cheap.

A way to make changes manageable could be to change how BGP works with
regard to nested routes from multiple sources.  Or really, devise another
protocol.  Here's a raw thought:

When BGP is used for multihoming, all the paths are advertised throughout,
not only the current best paths.  There has to be a marking on which ones
aren't the best paths of course.  When a transit AS becomes unreachable,
instead of withdrawing the routes and waiting for updates, the only thing
that is signalled is "ASX went down, switch to alternative path(s) if
any".  So, changes would not be processed per prefix, but mainly per
(transit) AS, in an "aggregated" fashion. In that way, convergence could
be near-instantaneuous and the amount of processing for BGP updates (at
the cost of about N extra routes in RIB) needed when multihoming minimal.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 2 Feb 2003 13:31:15 +0100 (CET)

> fairly certain of that at least to the degree of O(10^6) -- memory is

I assume you mean 10^6 number of routes? Cisco's CEF seems to take
something like 300 bytes for a single route. That makes for 300 MB
worth of fowarding tables, which wouldn't stress current technology too
much.

BGP and routing table entries also seem to be something like 300 bytes
each, so for the main route processor the amount of memory could be
somewhat more problematic. But 4 copies of each route in the BGP table +
1 in the routing table would make for 1500 MB, also still doable.

> the cost of about N extra routes in RIB) needed when multihoming minimal.

We can do better than that. A new interdomain routing protocol should
separate the topology information from the NLRI. The AS <-> prefix
mapping can then be nearly static. Note that this would also be very
helpful in addressing the security concerns that currently exist about
BGP.

It would be logical to make such an idr protocol a link state protocol,
but I'm not sure if it is possible to make a link state routing protocol
that can function even if the full state of the network isn't always
completely known. Essentially, you'd want to know the state of what's
going on close to your AS in great detail, but more and more information
should be aggegated away as the distance increases.

Of course this aggregation should be based on geography for multihomers.  :-)

---

From: Pekka Savola <[email-masked]>
Date: Sun, 2 Feb 2003 19:19:47 +0200 (EET)

> this is also what i see, though i am anxiously awaiting enlightenment.

Perhaps it was not clear what I meant with an "architectural change", and 
I should try to clarify.

I didn't mean we need IPv7; rather, that the model of solving a problem of
locator/identifier problem and dumb end-hosts with a global routing
solution.

For example, I consider models where multihomed hosts make a much more
active role in the current "multihoming routing" problem an architectural
change, as well as separating identifiers and locators as in LIN6 (or even
more so, HIP), etc. as architectural changes.

Certainly, there are ways to do multihoming with IPv6 today.  And there
will be ways.  But one point many, myself included, have tried to make is
that doing it the way most have done it with IPv4 -- that is using BGP
with "PI addresses" -- is not scalable.  That is likely the only solution
for a long time to satisfy all those requirements.  

For example, I personally have great faith in "multiple addresses from
multiple providers" -approach (though there are some small ways it will
have to be improved): it should give a sufficient amount of multihoming to
most sites.  Also, multiple connections to a single ISP are also a way to
get redundancy.

The major things I see missing are:
 - ways to get upstream _independence_
 - scalable ways to protect against your upstream ISP failures (if 
multiple addresses per node approach is not sufficient)

.. but I'm not sure whether solutions for these are really even required:  
people just want them because they've always had them.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Feb 2003 16:47:41 +0100

OK, maybe we need IPv6++ (although as Christian's message points 
out, the changes mainly wouldn't be in IPv6 itself).

But that is R&D, and it will be some years before it ships in product. 
Over here, can we get on with something shorter term? What is an I6SP 
supposed to say to a customer who asks for IPv6 multihoming next week?

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Feb 2003 17:57:06 +0200 (EET)

> supposed to say to a customer who asks for IPv6 multihoming next week?

Ask the customer what he really wants.  Really.

If the customer wants redundancy, use multiconnecting to connect him to 
two of the ISP's PoP's.  Problem (99%) solved.

If the customer wants independence, advise them to use multiple addresses.
(This needs a bit tuning yet.)  RFC3178 will also help you there, if you 
want a more complicated setup.

If the customer wants both short-lived redundancy and independence, do
both of the above.  Note that you really don't want to try to solve
short-lived redundancy problems with multiple addresses, it's just way too
painful.

That should cope with most customers' needs.

With some roadmap like this, we could actually get some solutions out of
the door, I think.

---

From: Randy Bush <[email-masked]>
Date: Mon, 03 Feb 2003 13:24:36 -0500

> supposed to say to a customer who asks for IPv6 multihoming next week?

ipv4 style

---

From: Randy Bush <[email-masked]>
Date: Mon, 03 Feb 2003 13:28:32 -0500

ipv4 style

---

From: "Mario Goebbels" <[email-masked]>
Date: Mon, 3 Feb 2003 19:30:58 +0100

I have some general ideas about how someone could able routing -from/to PI
networks over the regular IPv6 network, using some additional logical data
structure (I tagged it Locator Cache in my idea), some extension header and
requires exchange of PI network information over some routing protocol to
fill that Locator Cache on routers. Clients are also supposed to make use of
that locator cache too in my idea. Due the fact I'm no expert the idea might
be pretty general, but maybe some aspects in it are worth a dime. If you
don't mind, I could write it down in some human readable form and post it
onto this mailing list.

-mg

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Feb 2003 20:50:13 +0200 (EET)

> > supposed to say to a customer who asks for IPv6 multihoming next week?

did you mean:

ipv4

?

Seems like a good suggestion to me !

</swallowing the hook, the line, the fisherman and the boat>