TLA request 'for multihoming' (was: pTLA request SSVL)
Christian Kuhtz
ck@arch.bellsouth.net
Mon, 22 Apr 2002 14:52:24 -0400
> From a technical point of view, there is no need for
> multihoming. An ISP
> (look at the thread I started previously) can maintain
> redundant uplinks
> to the Internet, multiple peering routers, multiple transit
> carriers,
> etcetc, without the need for the customer to have its
> prefix announced
> by more than one ISP.
pim, et al,
if i may interject here.. with all due respect, i find such notions
very much out of touch with reality.
there is very much a need for multi-homing, from a service provider as
well as end customer point of view. the non-existent support for such
a vital topology feature is probably one of the biggest, most glaring
holes in the current fabric of policy and technology that we have.
the 'these are not the droids you're looking for' speech doesn't work
to declare multi-homing obsolete, nor is there any recognizable motion
in the ietf or any other standards body or association that i'm aware
of to provide us with such functionality or functionality which serves
the same purpose.
the non-existance of multi-homing is an issue. any customer should
have the ability to create multi-homing for redundancy,
load-balancing, whatever as they see fit as there are well known and
well documented uses for it. one service provider is very much a
single point of failure and unacceptable for those wishing to avoid
such dependency. for us to stand there and declare to the customer
'dear customer, you need not to worry about redundancy or dependency
on us' will not work, will not allow us to pass the straight face
test, and will get us laughed out the door with all but those
customers who couldn't find a packet with both hands ever.
now, i'm not saying we should approve pTLAs for anyone interested in
multi-homing, but we do have a gaping hole here where there's no real
solution apparent and where standards bodies are of little help at
present. and to say 'there's no reason or no need' is simply false
from where i stand.
thanks,
chris