Mailing List Archive

Joel_M_Snyder@Opus1.COM writes
> GIVEN that there exists some set of organizations who want to purchase
> multiple T1s from multiple independent suppliers for purposes of
> reliability and load sharing yet have need for less than 255 unique IP
> addresses, and GIVEN that certain extremely popular software products (such
> as Netscape Navigator) which are important to these organizations were
> developed by programmers who seem to have no knowledge of either efficiency
> or the way that the Internet works, and GIVEN that I have sufficient
> knowledge about routing as is necessary to fully understand every technical
> issue involved, and GIVEN that I have a rudimentary and imperfect
> understanding of the political and economic issues regarding IP numbering
> and the propagation of routes thereunto, HOW do I resolve the conflict
> between justifiable corporate service requirements and the expressed
> statements on these mailing lists the past few weeks which seem to imply
> that anyone who does not consume at least a /18 worth of address space is
> not worthy of being globally routed?
>
> I am asking, I suspect, not for a technical answer (there being none other
> than Chiappa's "it's gonna cost"), but the most politically correct answer
> to give the organization (which is not Netscape).

You present a hard edge case that isn't particularly well met by the current
infrastructure and it can't necessarily be done well or even done at all.
(Sean's tricky chocolate-consulting hack excluded). Probably the best
thing that be currently supported is getting two diverse connections to
a single provider that can globally aggregate your network. The connections
should go to different POPs and should follow seperate physical paths.
This should provide you the desired reliability and load sharing.

-scott

Scott,

>You present a hard edge case that isn't particularly well met by the current
>infrastructure and it can't necessarily be done well or even done at all.
>(Sean's tricky chocolate-consulting hack excluded). Probably the best
>thing that be currently supported is getting two diverse connections to
>a single provider that can globally aggregate your network. The connections
>should go to different POPs and should follow seperate physical paths.
>This should provide you the desired reliability and load sharing.

Thank you, thank you, thank you. This is exactly the kind of pragmatic
advice I was looking for. Saying "don't do it" or "multihoming costs" is
not helpful -- this sort of answer is.

Regards,

Mathew

Scott,

] You present a hard edge case that isn't particularly well met by the current
] infrastructure and it can't necessarily be done well or even done at all.
] (Sean's tricky chocolate-consulting hack excluded).

Why is it excluded?

It's too easy for people to make up reasons why they shouldn't
have to think, or heaven forbid, renumber. I'd wager a pound of
reese's pieces that Sean threw those paragraphs out of his mind,
with less than an hour's thought. The tricky thing about Sean is
realizing that he thinks about problem solutions, not excuses as
to why the problems can't be solved.

As for the reordering crisis, order the book from the Phonics people, it
might help -> D-H-C-P. What? Your software doesn't support it?
Erm, call your sales rep. Make threats; threaten to go to
Microsoft who does.

These things can be done, and the current state of the net can be
much eased by providers enforcing prefix aggregation impetus. It
could also be done by being "good net.citizens" and all that
ruckus, but the masses don't move unless forced to.

Somone needs to force them.

Thank you, Sprint, for slowing the acceleration with your /19
policy. Now, let's see if we can't decrease the problem with
historical prefix aggregation rules, or retirement so as to achieve
the same effect.

-alan

From: Scott Huddle <huddle@mci.net>

Probably the best thing that be currently supported is getting two diverse
connections to a single provider that can globally aggregate your network.
The connections should go to different POPs and should follow seperate
physical paths. This should provide you the desired reliability and load
sharing.

This solution has been pointed out before.

Also, Dorian Kim sent in a good message to the Big-Internet list talking about
reliability (the stated goal of most multi-homing), and the 7 places you could
do redundancy, and what was really important in achieving reliability, which
contained a lot of good insight. Here's his message (appended).

Noel

--------

Date: Fri, 1 Sep 1995 03:57:16 -0400 (EDT)
From: Dorian Rysling Kim <dorian@cic.net>
To: ... big-internet@munnari.oz.au
Subject: Re: Multihoming

....

There are many places where redundancy can be achieved with multiple
connections.

0) Equipment spares on site
1) Diverse local access of the two links
2) Diverse routing of the physical links into COs
3) Diverse routing to different local providers
4) Diverse routing to different regional providers
5) Diverse routing to different large transit providers (MCI, Sprint, ANS,
Alternet, Eunet etc)
6) #5 + connection to the NAPs.

All of the above give you redundancy at various single points of
failures. In my experince, #0 - #2 should be considered as important in
providing true redundancy as 4-6. In fact, in most cases, the most common
case of outtages come from equipment failures, and circuits themselves,
and sites who are looking for multihoming for the reason of redundancy
should look at the cost of having 0-2, and think long and hard about
whether multihoming is what they really need.

-dorian

<There's an interesting point in the middle of this, about how multihoming
presents technically rooted problems no matter *how* we do the addressing,
even if we solve the conflict he mentions, and that these problems have
an impact on what policies it is useful to discuss...>


From: "Joel M Snyder, writing fool" <Joel_M_Snyder@opus1.com>

GIVEN that I have sufficient knowledge about routing as is necessary to
fully understand every technical issue involved

Sorry, I guess I just assumed the wrong interpretation of what your question
was about. (Also, to be honest, if we've got to the point that most everyone
understands these issues, I guess it's time for the champagne... :-)

GIVEN that I have a rudimentary and imperfect understanding of the
political and economic issues regarding IP numbering and the propagation
of routes thereunto

I'm not sure anyone has a truly "global" view of this, although if one listens
on this and other lists hard, one can start to get a view which integrates the
large and small ISP's, equipment suppliers, etc, etc...


GIVEN that there exists some set of organizations who want to purchase
multiple T1s from multiple independent suppliers ... HOW do I resolve the
conflict between justifiable corporate service requirements and the
expressed statements ... that anyone who does not consume at least a /18
worth of address space is not worthy of being globally routed?

To start with, this is another case where setting the size-based filter for
routing updates is having deleritous effects. Again, all we're doing is
creating a demand for address space, and as long as there is no well-modulated
back-pressure on address space (such as charging for it), I'm not sure I
see any easy way of dealing with it.

Second, whether it's a /18 or a /24 is of no interest to the routing. Let's
assuming we can separate the addressing issues out, to focus just on the
routing cost, which is going to be the same *regardless* of how you resolve
the address space issues. This is important:

*** No matter how you do the addresses, you *still* have the problem that if
*** a significant percentage of customers want to be multihomed, and we still
*** don't have any mechanism or tools for reducing the scopes of those
*** advertisements from global (such as I mentioned in my original message on
*** this thread), we will find it technically impossible to provide this
*** multihoming capability to a large number of users: we will be rerunning the
*** very routing table growth (tracking local sites individually) that caused
*** us to go to CIDR in the first place.

I don't know about you, but I could do without a re-run of that particular
learning experience! :-)

Ideally, in solving this, I would take a monetary approach, which is to say
"what are the true costs of this multihoming, and given that, is it important
enough to the client for them to pay for it", but of course we don't have a
charging mechanism for routes that would help to answer this, and maybe never
will. So, I can't use that copout.

Maybe a better question is to ask "what goal are they really after with
multi-homing", because if the answer is "reliability", then perhaps they get
more bang for their <insert-local-currency> with things like multiple access
lines, etc.

I am asking, I suspect, not for a technical answer (there being none other
than Chiappa's "it's gonna cost"), but the most politically correct answer
to give the organization

I understand that you have a very "bottom-line" concern, which is "what do we
tell the customer", but I hope that this time I have made clear to everyone
that there is no solution to the technical question of "can we provide
multihoming on a large scale", *at least in the system as it stands today*.
(I.e. if this is an important goal we need to get cracking on technical
solutions...)

Any policy discussion must take place in an environment which is aware of this
technical constraint. Thus, your question about the policy conflict you
pointed out is interesting and true, but ultimately not a critical one...

Noel