[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-kurtis-multihoming-longprefix comments
J. Noel Chiappa wrote:
> > From: Kurt Erik Lindqvist <firstname.lastname@example.org>
> >> I believe that a significant portion of multihomers do
> it because they
> >> want to obtain operator independence. They usually
> don't have PI
> >> addresses, but what I'd call "PA sold off as PI" or
> "PA advertised as
> >> PI".
> First, once again, about "provider-independent addresses",
> AKA "connectivity- independent addresses".
> This is pretty much like asking for a street address that
> stays the same even when you move.
No, it is asking for the same address to work when USPS, UPS, FedEx, the
pizza guy ... service providers deliver the packets. Mixing the concept
of service provider and connectivity is what makes it so hard for the
average network manager to understand why his address has to change when
he changes providers. In 'the real world' the connectivity (street) is
separated from the service provider.
> Needless to say, try that one in the real world and see how
> far you get with it.
The phone system allows this (for a price), so people expect it to be
possible from the 'more powerful' Internet.
> In any rational discussion of addressing, the phrase
> "provider-independent addresses" ought to receive the same
> reception as "location-independent street address" - i.e.
> something between concern (that the person needs to be
> institutionalized) and racous laughter (at the ludicrousness of it).
Only by routing gurus. The average network manager looks at 'the real
world' where a large number of services are available using a common
street address, and the anomaly of portable numbers in the phone system,
and can't figure out why the Internet is not even capable of those
> Look, if you want some sort of identifier for machines, one
> that stays the same even when a machine moves somewhere else,
> the IPv4 architecture simply does not provide it. Frankly, it
> wasn't even guessed at as a requirement, back when the
> Internet had 18 total nets in it.
> IPv6 adopted the IPv4 architecture lock, stock, and barrel,
> changing only the length of the address. This is touted as
> its great strength - in fact, it's its greatest weakness, and
> we see an example here.
The strength is that it is a model that people understand. Where it
breaks down is that the decision leading to PA-only occurred at the same
time as CIDR. The zeal to clean up & prevent a new swamp resulted in a
system where the multi-homing issues were pushed to the host (ie: out of
the DFZ routing space). Now that end site network managers are getting a
voice, they are pushing back and stating they don't want it in the host.
> If you don't like the fact that IPv6 does not have
> identifiers for machines, ones that stays the same even when
> a machine moves, either i) complain to the IPv6 architect(s),
> or ii) work with people like Ran who are trying to add one.
> *Don't* come ask for "location-indepedent street addresses".
People aren't asking for location-independent addresses, in fact they
are asking for the architectural equivalent of a street address.
> > Well, what I am looking for is a) Any idea of why
> people are doing
> > this. We are again back to the problem that we should
> first understand
> > what we are trying to solve before we start posting solutions.
> Oh, I think it's reasonably easy to understand why people
> want identifiers for their machines that stay the same even
> if they change providers. They want to make it easy (or at
> least easier) to change providers, and prevent lock-in.
> The only possible solution *in the architecture as it stands*
> is to use DNS names, if people need a location-independent
> host identifier.
> Another option, again, is to work with people like Ran who
> are trying to add such a namespace.
There are also as set of us who are trying to define an intermediate
approach that scales within the constraints of the current routing
technology while we wait for the longer term additional namespace.
> Too bad IPv6 didn't have one from the start.