David Conrad <[EMAIL PROTECTED]> wrote:
|On Saturday, February 1, 2003, at 09:35 AM, Dan Lanciani wrote:
|> I was actually referring to the practice of inserting 48-bit (or even
|> 64-bit)
|> hardware identifiers into the address in the name of easy
|> configuration.
|
|One allocation mechanism is pretty much as good as any other. Doesn't
|matter how those 48 or 64 bit numbers are allocated, the EUI registry
|would be fine.
That isn't clear. There are certainly cases where we will want to number
an interface for which we do not already have an EUI from the hardware. If
the entire identifier space is already taken up with EUIs then there is no room
for someone to get a block of identifiers for non-EUI applications. I admit
I haven't looked into this; what does it take to get an EUI-64 allocation?
I assume that to get any EUI-48 space you still have to buy an OUI at a fairly
high price (or else buy old Ethernet cards to hold as tokens).
|> I would not want to depend on the edge router's having that kind of
|> knowledge
|> of the locator routing system just to make multi-homing work for other
|> sites.
|
|Hmmm. Multiple ways to solve this, of course. E.g.: the source edge
|router does a lookup, gets back a bunch of locators. A naive
|implementation could simply pick one and forward to the core via
|default. Getting back a network unreachable could trigger the naive
|implementation to pick a different locator. The more elaborate the
|edge router gets in terms of routing system knowledge, the more
|effective the multi-homing would be.
Again, I'm not thrilled with making the effectiveness of multi-homing depend
on the participation of other sites' routers in the low-level routing (locator)
system. I would prefer to add more at the identifier level, but this is really
a minor quibble.
|> I'm not sure what you meant by forwarding.
|
|The old destination edge router gets a packet for an end point
|identifier that has left the network the old edge router is responsible
|for. The old edge router does a lookup of the destination identifier,
|gets the new locator (if it doesn't already have it), and forwards to
|the new edge router. It would need to do this for the TTL of the old
|locator.
Yes, definitely not what I meant by short-circuiting. :)
|It would. The reason I favor the edge router approach is that I wanted
|something that would work with IPv4 as a transition aide...
I'm still not sure I see why it wouldn't work.
|> Whether we really want to help perpetuate
|> the current archaic routing system by building a layer like this is
|> still open
|> to debate. Clearly adding a layer is better than doing nothing;
|> however, I'd
|> like to think that we can ascertain a pure routing solution that is
|> isomorphic
|> to the split solution.
|
|Baby steps...
Perhaps, but this is really what got us into the mess we are in today. What
was meant as a crutch to keep memory-address-bit-deficient hardware viable
for a few extra months/years has become a serious dependency problem. By
turning addresses into almost-routes aggregation has allowed routing protocols
that were obsolete years ago to remain in use, but end users pay the terrible
price of having their addresses tied to topology. Like any addiction, this
problem will only get worse as we continue to feed it.
So, yes, I'm all for a translation layer if it is the best that we can do and
if we can do it at all. But since we almost certainly can't do it all in the
face of current politics, I might as well dream about fixing routing...
Dan Lanciani
ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
