RE: draft-kurtis-multihoming-longprefix comments

["Tony Hain" <alh-ietf@tndh.net>]

J. Noel Chiappa wrote:
>     > No, it is asking for the same address to work when 
> USPS, UPS, FedEx, the
>     > pizza guy ... service providers deliver the packets.
> 
> No, it's *not*, Tony - which is not to say your point above 
> (modulo the pizza guy, who's an application, not a service) 

I consider the packets delivered by the pizza guy to be a more valuable
service than what usually comes from the other delivery guys ...  ;)

> is not also true.
> 
> Why you are having such a hard time with this seemingly 
> simple concept is really starting to frustrate me (which I 
> concede tends to make me awfully cranky), but let's try it again.
> 
> When some host stops buying service from provider X and 
> starts buying it from provider Y, you wind up running a wire 

This is where the analogy breaks down ... I had though more about it
after sending the earlier note, and realized this would come up. The
copper/fiber doesn't change from the site perspective. More below:

> from that computer to *different place* on the network - to 
> the infrastructure of provider Y. **That host has, from the 
> point of view of the rest of the network, moved to a new 
> location on the network**.
> 

The street analogy would express this as the choice of direction at the
stop sign (end of the consistent copper/fiber loop). Using the different
attachment point as a different address model, I would have a different
service address when turning left, than turning right or going straight.
While I might give different instructions to those coming toward me from
each of those directions, the actual address doesn't change. 

> 
>     > 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.
> 
> It's precisely because the service provider *provides the 
> connectivity* that the address has to change. That's the 
> *service* they are providing - the connectivity.

In some cases, but in many the physical plant (street) comes from a
different provider. 

> 
>     > In 'the real world' the connectivity (street) is 
> separated from the
>     > service provider.
> 
> The *street* is the connectivity service - and moreover, it's 
> one that all "resellers" (UPS, UPS, FedEx) are allowed to use 
> *for free*. So your analogy breaks down here.

No, it is not *free*, they pay indirectly through fuel & business taxes.
In the case of the copper/fiber, service providers generally pay for
exclusive use. 

> 
> You have a slightly better case for this analogy in what's 
> happening on some cable TV systems, where you can sign up 
> with one of multiple providers, but you keep the same cable 
> TV hookup. Still, even in these cases, when you switch 
> providers, from the point of view of the rest of the network 
> you're moved somewhere else (in that you're "attached" to 
> provider Y, not provider X as before), which is why your 
> address has to change.

I know why we make people change today, but that does not make it a
requirement. If the cable system had a decent L2 and allowed
simultanious connection to X, Y, & Z, we would get back to the analogy
of a different address depending on the direction. The forced address
change approach simplifies routing by moving the complexity to the
endpoints.

> 
> We don't have any way to assign that cable TV network a 
> single address, *and* ensure that incoming traffic to host Q 
> goes over the network that host Q is paying money to.

Why do we care which path the packet takes? The simple answer is we
don't have the mechanisms necessary to deal with real-time accounting.
In a business model where the L2 provider collected from the endpoint
and paid L3's based on volume, the routing system wouldn't need to
ensure traffic followed a particular path. Which is easier, building a
routing system that scales to several billion entries, or silicon that
is good at counting? 

Another way to approach it would be, sender pays whoever the packets are
handed to. This idea that we can remotely align the senders handling of
the packet with the receivers policy (expressed through payment) is
seriously broken. In the physical package world, they figured this out
and charges are aligned with the holder of the package. We don't do this
in the virtual world because there is no simple scheme for the
originators to recover costs from the consumers of the content. 

Maybe we are solving the hard routing problem because it is more
interesting...

> 
> 
>     > The phone system allows this (for a price), so people 
> expect it to be
>     > possible from the 'more powerful' Internet.
> 
> The way the phone system did this is they jacked up the phone 
> system naming layers by one, and slid a new one in 
> underneath, one which is your real "physical" phone number (I 
> don't know the actual jargon terms the phone guys use here), 
> and the number you give everyone is now (effectively) a 
> "virtual" phone number.

I understand how they did it (my desk phone has a Bellevue & San Jose
number), the point was that is the type of service Joe Sixpack expects,
yet it doesn't scale in the routing system.

> 
> Then they maintain a big mapping database which converts from 
> virtual phone numbers to actual phone numbers.
> 
> To do the equivalent in the Internet, we'd have to allow 
> people to emit packets with a "virtual" address in them 
> (let's call them Effective Internet Demultiplexors, or EID's, 
> for short), and then some router would have to do the mapping 
> and stick on the actual address.
> 
> I have in the distant past proposed doing exactly that, but 
> people didn't like the idea.

In an abstract sense, 8+8 (maybe 16+16) does the same thing.

> 
> 
>     >> 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.
> 
> Look, the routing gurus *aren't* the people who designed a 
> new network architecture and put in only a single namespace. 
> If you're pissed off, go beat up the internetwork level architects.

I am not picking on anyone, just trying to point out that the average
network manager doesn't really have a clue how complex this is, and
wouldn't laugh at the concept of addresses that are consistent across
provider changes.

> 
>     > 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 simple things.
> 
> If you persist in thinking that a tree sloth is a fish, you 
> will of course be upset that it doesn't have scales and fins.

True, but when all you care is that whichever it is gets delivered to
the right street address as food, the only problem might be needing to
choose a different wine.

> 
> 
>     >> 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.
> 
> The model that everyone should give me a Ferrari is simple 
> and easy to understand. That doesn't mean it's either useful 
> or workable.
> 
>     > Where it breaks down is that the decision leading to 
> PA-only occurred at
>     > the same time as CIDR.
> 
> Yes, and gravity and mass have no connection either.
> 
>     > 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.
> 
> Yeah, and no doubt car owners want cars that run an infinite 
> distance on no gas, too. I sure wouldn't mind one.

Clearly it would have to be a Ferrari :)

The point is we did not solve the problem, we just moved it. 

> 
> 
>     >> *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.
> 
> Words fail me.

I understand, but don't give up. You are looking at this from the
perspective of exclusivity in the attachment point, so it makes sense
that differences in attachment might lead to differences in addressing.
If you remove the exclusivity restriction, it doesn't make as much sense
for the address to change depending on which delivery guy is coming down
the street. Sure it may be simpler to tell coorespondents to send to
FedEx customer 123, and led FedEx figure it out, but if the
coorespondent has a good deal from Joe's Delivery, Joe's will dump it at
the closest FedEx box. If the address were independent of delivery and
the remote routing mechanism only dealt with cities, Joe's would have to
bring it to Seattle to figure out what to do with it.

Tony


> 
> 	Noel
>