Xref: utcsri comp.dcom.lans.ethernet:15914 comp.protocols.tcp-ip:39469
Newsgroups: comp.dcom.lans.ethernet,comp.protocols.tcp-ip
Path: utcsri!info.physics.utoronto.ca!utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: one ethernet address, two interfaces
Message-ID: <D5I2Cy.A2z@zoo.toronto.edu>
Date: Wed, 15 Mar 1995 21:00:30 GMT
References: <794696322snz@scotia.co.uk> <3jn9he$k80@zeus.ieee.org> <1995Mar9.191619.17479@nb.rockwell.com>
Organization: U of Toronto Zoology

In article <1995Mar9.191619.17479@nb.rockwell.com> manfredi@engr04.comsys.rockwell.com writes:
>>	...note that the
>>problem of "routing to the right interface" is one of routing, not
>>IP addressing.
>
>Not sure I see a great distinction. "Routing" is, by definition, a Layer 3
>proposition. "IP addressing" is also a Layer 3 thing. Hence, if IP
>addressing is done in an ambiguous manner, routing can and will be affected.

Forget the mystical level numbers and concentrate on *thinking* about what
is going on.  The necessary function of addresses is to give unique
numbers to computers, so you can address a packet to one particular
computer and no other.  What *network* the computer is on -- in other
words, in which direction you should throw the packet to get it to that 
computer -- is an entirely separate issue. 

Conceptually, you could have a gigantic table which maps each address to a
location.  For example, that is how 800 numbers are routed:  the phone
company's switching gear does a table lookup to decide which wires to
connect the call to.  The number is totally unrelated to the physical
location of the wires. 

In practice, table lookup is clumsy when the number space gets large.
The XNS approach was that the 48-bit host address was just a unique
number, but the packet also contained a network number which was a
routing hint.  The IP approach is to embed the network number in the
address.  Either way, though, you still have to consult some sort of
routing database to find out which direction that network lies in --
doing routing by network rather than by host just reduces the size of
the problem somewhat.

>To me, it seems that if we want to send a train from DC to LA, we have
>to say more than "go from DC to LA." If we want the train cars to stay
>hooked up to the same train, we have to define the point of arrival at
>LA, and perhaps the point of departure from DC, in specific enough terms
>so that each switch along the way will be switched to the same position
>for every car that goes by. All the way to the final train station.

Poor analogy.  Do you really *care* which platform in the LA station the
train ends up at?  It's not possible to buy a ticket to "LA station,
Platform 3".  The platform assignment is entirely at the convenience of
the railroad; their obligation is only to deliver you to the specified
station, and the ticket specifies only the station.  It's even possible,
in big stations serving multiple semi-distinct rail networks, that which
platform you arrive at will be a function of where you started from.
-- 
There is a difference between                      |       Henry Spencer
cynicism and skepticism.                           |   henry@zoo.toronto.edu