Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR)

From: "Michel Py" <[email-masked]>
Date: Tue, 4 Sep 2001 19:39:41 -0700

Iljitsch,

Thanks for your comments.

Iljitsch van Beijnum wrote:
>>>> Until someone finds a mechanism that can do it.
>> Ok, you're right, other ways, such as on-demand created routes, are
>> possible, but I don't see it happening.

Me neither, that's why I designed MHTP.

>> I'm not as pessimistic as some others: I think the current
multihoming
>> practices could continue to work for the foreseeable future if BGP
>> implementations can be optimized.

So do I, and this is how I consider MHTP: an optimization of the
existing
model, a waiting solution, and something that would provide a working
base for two things that are likely to be used anyway:
- A prefix reserved for multihomed addresses.
- The concept of multiple addresses per host.

>> Still, if we can create a good host-based multihoming solution, this
will
>> drain away much of the growth of current multihoming practices,
giving us
>> all more breathing room. Also, it makes multihoming reachable for
>> everyone. With IPv6 we're in the unique position that the
implementations
>> are still very fluid, so we should take advantage of that.

Yes, but I still have to see that solution. Again, MHTP does not pretend
to be "THE" multihoming solution.

>> However, your proposal depends on changing the Internet core routing,

I do not agree with that. The core of the routing would still be
the existing, strongly summarized BGP4+ DFZ that we want to keep.
What I propose to change in not HOW the traffic is routed but WHAT is
being routed (because it has been translated).

>> The main advantage of your proposal is that you solve the
"alternative
>> address discovery" problem.

By using the same, proven mechanism that works today: a BGP routing
table.

>> Note that a network that is part of the DFZ does not have "an ISP".

An interesting semantics issue. To me, an ISP is who provides
connectivity
to the Internet. In the US, it is fairly common to buy a DS3 or bigger
pipe with full BGP feed from one or more ISP(s) (that would be for
companies
that have an ASN and a CIDR block).

>> you pay an ISP to route traffic to all destinations connected to the
Net

I don't think so. I pay my ISP to provide me a connection to the
backbone
without the hassle of getting into a colo where I do not want to move
and
without the hassle of being part of an exchange which is not my core
business.

>> in other words: you pay for a default.
No, I'm getting a full BGP feed.

>> In the default-free zone there are no defaults

Let's say there SHOULD be no defaults, related to the fact that
10.0.0.0/8 SHOULD NOT been advertised in the DFZ either....

>> (but the reverse is not always true: a network running without a
>> default is not necessarily part of the DFZ)

Agree. A network is part of the DFZ because it has its own block, the
same
animal that clogs the DFZ's routing table.

>> So using the DNS seemed like logical choice.

There are way too many people that consider a DNS-based solution an
absolute
no-no to attempt any DNS solution, IMHO.

>> Any consensus on BGP changes is a long way off

Definitely. I guess I have not made myself clear about the relation
between
MHTP and BGP. What should I change in 6.2.9 of
http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt ?

>> Maybe we should come up with some more specific requirements for
multiple
>> addresses / address rewriting solutions. Or we can just wait and see
who
>> is the first to produce code.  :-)

This might no be the fastest course of action. What if the people that
write
the code are waiting for us to decide something ;-)

Michel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Sep 2001 23:01:25 +0200 (CEST)

> connectivity to the Internet.

Can't argue with you there. Now let's define "default-free zone". I would
say: "the subset of routers that do not receive a full routing table from
a single peer or a default route".

> In the US, it is fairly common to buy a DS3 or bigger
> companies that have an ASN and a CIDR block).

Having an AS number and a PI or even PA block don't make a network part of
the DFZ: as long as it pays another network to carry packets to any
destination, the network in question may use a default to the other
network and if there is a default filtering is possible without hurting
connectivity. The problem with the DFZ is that defaults are not possible,
so filtering always hurts connectivity.

> I don't think so. I pay my ISP to provide me a connection to the

"backbone" is a word without meaning in interdomain routing.

> without the hassle of getting into a colo

Why would your location have anything to do with it?

> No, I'm getting a full BGP feed.

A full feed is pretty much a more verbose default.

> same animal that clogs the DFZ's routing table.

No, that's my point: that has still nothing to do with it. Having your own
block means you are visible in the DFZ, being part of the DFZ means you
can't dump packets for which you don't have a route in someone else's lap.
In other words: the DFZ is the top of the tree. On all other levels, you
route the packet to a known destination or to the higher level. At the
top, there is no higher level so all destinations have to be known
destinations to be reachable.

> http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt ?

Nameserver problem, can't get at the document right now. Maybe you should
multihome...

Iljitsch

---

From: Michel Py <[email-masked]>
Date: Thu, 6 Sep 2001 15:26:35 -0700 (PDT)

From: Iljitsch van Beijnum 
>> a single peer or a default route".

Or: "The subset of routers that do not use a default
route, and peer
with two or more other ASNs."

>> so filtering always hurts connectivity.

I think I see your point here. My ISPs are major ones,
I have the assurance
that the routers that I peer with are part of the DFZ
and do not use a default route.

>> destinations to be reachable.

If I have two BGP feeds from two major ISPs, why
should I use a default route?
With a 200,000 route feed, if the route is unreachable
to me it is probably
unreachable to my ISPs as well and I'd rather dump the
traffic into the bit
bucket at my site instead of wasting bandwidth on the
link.

>>>> between MHTP and BGP. What should I change in
6.2.9 of
http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt

>> Nameserver problem, can't get at the document right
now. Maybe you should

This is my home^H^H^H^H serf setup. I use "The Public
DNS" for name resolution,
they have two different name servers connected to two
different networks, and I
regularly have DNS failures. Besides the fact that I
got what I paid for (none),
that makes my point about multihoming DNS servers I
guess.

Michel.

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 Sep 2001 10:01:30 +0200 (CEST)

On Thu, 6 Sep 2001, Michel Py wrote:

> >> "the subset of routers that do not receive a full routing table from

> route, and peer with two or more other ASNs."

I want to exclude the routers that run defaultless by choice, rather than
out of necessity. You want to include those.

> should I use a default route?

I can only tell you why I do it: the routers for "my" network don't have
enough memory to carry a full table. For two customers I have installed
filters to keep the routing table small(er) as well. They have Cisco 7500
routers with more than enough memory on the RSP, but only 32 MB on one of
the VIP cards. Those cards need a copy of the forwarding table and 32 MB
leaves to little room for error.

But if you can, it's better to take full routing from multiple
connections, because that way BGP can always find the shortest path.

> >>>> between MHTP and BGP. What should I change in 6.2.9 of

The problem is that it is hard to find specific information I'm looking
for. MHTP rendevous points keep the mapping between multihomed addresses
and single homed addresses, right? But is this a static mapping or a
dynamic one?

I guess I'm used to the "inverted pyramid" writing style, which makes it
easier to glance at something and get the most important facts right away.

Back to the problem at hand. If we are going to translate addresses, we
need to know to things: what are possible valid addresses to translate to,
and which of the possible addresses are actually valid/reachable. Unless
I'm reading the draft wrong, you try to solve both in one go. I think
that's not the best solution, since this way a continuous stream of
reachability information flows around the globe, whether this information
is of use at a certain point at a certain moment or not. The mapping
between MH and SH addresses could easily be quite static if we employ
separate means to validate the SH addresses.

Also, using MH addresses that are reachable without translation makes
sense. That way, there is instant compatibility with non-MH-capable hosts
and it saves some processing and address space.

> >> Nameserver problem, can't get at the document right now. Maybe you should

[...]
> that makes my point about multihoming DNS servers I guess.

Disagree: the DNS system has its own redundancy features, which are even
better than multihoming. But many people still don't get it and put
primary and secondary nameservers in places with shared fate. I remember
one time that the entire berkeley.edu domain vanished. They had four
nameservers, but all on campus. It seems they have learned from this,
though.

Iljitsch

---

From: Michel Py <[email-masked]>
Date: Fri, 7 Sep 2001 17:44:36 -0700 (PDT)

Iljitsch -

--- Iljitsch van Beijnum <[email-masked]> wrote:
>>>>>> "the subset of routers that do not receive a
>>>>>> full routing table from a single peer or a
>>>>>> default route".

>>>> Or: "The subset of routers that do not use a
>>>> default route, and peer with two or more other
ASNs."
 
>> I want to exclude the routers that run defaultless
>> by choice, rather than out of necessity. You want
>> to include those.

That is where I don't follow you. In defining the
semantics
of what is the DFZ, why would you exclude the routers
that
run defaultless by choice? I thought that the
definition
if the DFZ should match WHAT the routers actually do
and
not WHY.

>> but only 32 MB on one of the VIP cards. Those cards
need
>> a copy of the forwarding table and 32 MB

Selling the customer Cisco 12416s would solve the
problem ;-)
Then you can scrounge the 7500 for your CCIE lab :-)

>>>> What should I change in 6.2.9 of
>>>>
>> The problem is that it is hard to find specific
>> information I'm looking for. MHTP rendevous points
>> keep the mapping between multihomed addresses
>> and single homed addresses, right? But is this a
>> static mapping or a dynamic one?

The MHTP routing table is a standard BGP routing
table,
dynamic naturally. However, the rendezvous point is
used
in the bootstrap phase only, then the client and the
endpoint

>> Back to the problem at hand. If we are going to
>> translate addresses, we need to know two things:
>> what are possible valid addresses to translate to,
>> and which of the possible addresses are actually
>> valid/reachable. Unless I'm reading the draft
wrong,
>> you try to solve both in one go.

Correct.

>> I think that's not the best solution, since this
way a
>> continuous stream of reachability information flows
>> around the globe, whether this information is of
use
>> at a certain point at a certain moment or not.

I am unsure of what you are refering to here. If you
are
talking about the MHTP routing table, The way I
understand
BGP is that routes are not exchanged if they do not
change
so there is no reachability information floating
around the
globe unless a change occurs.
If you are referring to MHTP keepalives, these are
sent only
when there is active traffic between an MHTP client
and an MHTP
prefix, the the reachability information that flows
flows only
from/to there is current traffic and times out
quickly.

>> The mapping between MH and SH addresses could
easily be
>> quite static if we employ separate means to
validate
>> the SH addresses.

The mapping between MH and DH addresses is actually
static
(router's configuration if you prefer) in MHTP
endpoints.
In MHTP rendezvous points, it will change only if a
link
goes down or that kind of event.

>> Also, using MH addresses that are reachable without
>> translation makes sense. That way, there is instant
>> compatibility with non-MH-capable hosts

That way the implementation can be gradual, and there
are tools (control of proxying rate) that could help
enforce the migration, if desired or required.

>> Disagree: the DNS system has its own redundancy
>> features, which are even better than multihoming.
>> But many people still don't get it and put
>> primary and secondary nameservers in places with

We are actually saying the same thing: The design of
DNS redundancy is better than multihoming. How do we
get people to actually use it?

Michel.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 8 Sep 2001 16:02:15 +0200 (CEST)

> That is where I don't follow you. In defining the semantics
> of what is the DFZ, why would you exclude the routers that
> run defaultless by choice? I thought that the definition
> if the DFZ should match WHAT the routers actually do and not WHY.

The "tier 1" networks need to run defaultless, even if this becomes very
expensive. People who do it by choice can always stop if it becomes too
expensive for them. So if it's only the latter who complain, I don't see
why we should listen.

> >> but only 32 MB on one of the VIP cards. Those cards need

> Selling the customer Cisco 12416s would solve the problem ;-)

Ah, should have thought of that...

> >> I think that's not the best solution, since this way a
> >> around the globe, whether this information is of use

> I am unsure of what you are refering to here. If you are
> talking about the MHTP routing table, The way I understand
> BGP is that routes are not exchanged if they do not change
> so there is no reachability information floating around the

Of course. But with 100k+ multihomers that means many changes per minute
(even if we assume just a few flaps a month on average), and if
multihoming becomes easier the number will grow rapidly.

I think any solution where many systems around the world must be kept up
to date on the status of the connections of all multihomers world wide
won't scale: both the amount of information and the number of changes
increase with the number of multihomers, creating a growth curve in
processing requirements of O(x^2) or maybe O(x log x) with a good
implementation. What we want is at least O(x), but preferably O(log x).

And it's not necessary: as soon as you start communicating, it's not too
hard to find out which addresses are valid and which aren't. Finding out
all available potentially usable addresses is harder.

> enforce the migration, if desired or required.

So you agree that using separate MH addresses that aren't reachable
through existing SH means, is not the best solution?

> get people to actually use it?

Why should we? If they misconfigure their DNS they have to live with the
consequences. If we can make everything work when both sides of the
session have their stuff in working order and there is a possible path,
that should be enough. Userfriendliness is good for implementations, but
not so much for protocols, IMO.