The way around it is to stop growing the DFZ routing table by the size
of the Prefixes. If customers could have PI addreses and the DFZ
routing table was based, instead, on ASNs in such a way that customers
could use their upstream's ASNs and not need their own, then, provider
switch would
--On October 24, 2005 10:44:31 AM +0100 [EMAIL PROTECTED] wrote:
One way to do this is for two ISPs to band together
in order that each ISP can sell half of a joint
multihoming service. Each ISP would set aside a
subset of their IP address space to be used by many
such multihomed customers.
One way to do this is for two ISPs to band together
in order that each ISP can sell half of a joint
multihoming service. Each ISP would set aside a
subset of their IP address space to be used by many
such multihomed customers. Each ISP would announce
the subset from their neighbor's space
On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said:
In fact, this is technically feasible right now with IPv4. Does anyone know
of a pair of ISPs doing this?
technically feasible and business case reasonable are two different things.
Under what conditions does this sort of cooperation with a
[EMAIL PROTECTED] wrote:
On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said:
In fact, this is technically feasible right now with IPv4. Does anyone know
of a pair of ISPs doing this?
technically feasible and business case reasonable are two different things.
Under what conditions does
On 24-Oct-2005, at 11:21, [EMAIL PROTECTED] wrote:
On Mon, 24 Oct 2005 12:53:12 CDT, John Dupuy said:
In fact, this is technically feasible right now with IPv4. Does
anyone know
of a pair of ISPs doing this?
technically feasible and business case reasonable are two
different things.
the internet model is to expect and route around failure.
You cannot stop the last mile backhoes.
no, but if your facility is critical, you have redundant physical
and layer one exits from it. and you have parallel sites.
randy
ISPs who wish to connect customers who have allocations from the
multihoming space must
a) announce the whole space aggregated
b) peer with other providers who host other customers
As mentioned, this huge aggregate attracts unwanted traffic.
It would make more sense if this so-called
On Thu, 2005-10-20 at 07:49 -0400, Joe Maimon wrote:
SNIP
C)
- end node performs locator lookup
- end node encaps
- destnode decaps
This could be as easy as performing IPinIP with srv records and DDNS.
There is an 'example possible alternate use' in the following document:
(apologies to Owen for CC'ng list, his points are valid concerns that I
hadnt addressed or considered properly)
Owen DeLong wrote:
c) Carry a much larger table on a vastly more expensive set of routers
in order to play.
ISPs who dont wish to connect these customers should feel
Considering that most people who are in favor of multihoming
for ipv6 believe that there is customer demand for it, the
market forces would decide this one.
We have nobody but ourselves to blame for this. If we all ran
networks that worked as well as our customers demand and didn't have
our
We have nobody but ourselves to blame for this. If we all ran
networks that worked as well as our customers demand and didn't have
our petty peering squables every full moon, the market wouldn't
feel the need to have to dual home.
that's the telco brittle network model, make it so it fails
that's the telco brittle network model, make it so it fails
infrequently. this has met with varied success.
One way to look at it:
the internet model is to expect and route around failure.
this has also met with varied success. :-)
Neil J. McRae wrote:
Considering that most people who are in favor of multihoming
for ipv6 believe that there is customer demand for it, the
market forces would decide this one.
We have nobody but ourselves to blame for this. If we all ran
networks that worked as well as our customers demand
On Fri, 21 Oct 2005, Randy Bush wrote:
the internet model is to expect and route around failure.
randy
That precludes agreement on a definition of failure. In recent
weeks we have once again learned that a large fuzzy fringe around
any sort of 100% consensus makes life interesting.
the internet model is to expect and route around failure.
You cannot stop the last mile backhoes.
Tony
There is not only the multihoming issue but also the PI address issue.
Even if any ISP would run his network very competently and there
were no outages we would face the ISP switching issue. Again we
would end up with either PI addresses announced by the ISP or BGP
by the customer. With
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yo Neil!
On Fri, 21 Oct 2005, Neil J. McRae wrote:
If we all ran networks that worked as well as our customers demand...
Some demand low price and some demand high availability. No way to
please everyone.
RGDS
GARY
-
A customer with a prefix assigned from this chunk has to connect with an
ISP who has
* a Very Large Multihoming (to handle scaling concerns) router somewhere
in its network that peers to other ISP Very Large Multihoming routers.
ISP operating a VLMrouter to offer multihoming service to
Owen DeLong wrote:
A customer with a prefix assigned from this chunk has to connect with an
ISP who has
* a Very Large Multihoming (to handle scaling concerns) router somewhere
in its network that peers to other ISP Very Large Multihoming routers.
ISP operating a VLMrouter to offer
20 matches
Mail list logo
