Re: Why this is broken [was Re: Extending a /64]

[Matthew Petach <[e-mail]>]

On Mon, Nov 16, 2020 at 3:17 PM Tony Whyman <[e-mail]>
wrote:

[...]


> 3. Forward the packet to the care-of address using normal internet routing.
>
> Here, the MNP is being used as a "name" and the mobility routing problem
> is solved by looking up the care-of address associated with the MNP
> (name). Once the packet gets to the aircraft then the destination
> address becomes a routeable address, etc.
>
> It's not as if this approach is that novel. In LISP, for example, a
> destination IP address (an EID) is used to lookup a corresponding RLOC
> IP address and the packet is then encapsulated and forwarded to the
> RLOC. Once there, the EID is routeable.
>

Please forgive me for asking what seems to be prima facie a completely dumb
question--
but why *not* use LISP for this, as it seems like a good fit for a
situation in which you
need to use different RLOCs to reach a given EID.  Simply include the 39
bits of
information identifying the aircraft in the mapping lookup, and you've
moved the
problem space out of the addressing arena into the 'updating your mapping
table'
arena, which decades of advancement has shown is far cheaper to scale than
internet routing hardware.

If you need a unique 39 bit identifier, great.  Just treat it as an
identifier, rather
than a locator, and separate out that requirement from the locator
requirement,
and the problem seems much easier to address, if you'll pardon the pun.

The only reason I see in this discussion for trying to cram it all into the
address
is this sentence:

>> In order to avoid a lookup table in the protocol gateway, etc. we need
>> to have an airline identifier in the MNP.

Why such an aversion to having a lookup table?  LISP has demonstrated
that lookup tables aren't that painful to use, as has DNS for decades
before
that.

There's a reason we currently do name-to-address lookups in hosts, rather
than routers;
it's much more cost effective to keep the flexible name-to-address lookup on
hosts that scale better than routers, and leave the routers to forward
packets
as quickly as they can.

I get it--you have a legacy protocol you're trying to carry forward into
the future.
We've all been there.  DECnet, SNA, Novell, Appletalk, Vines--the road
behind
us is littered with legacy protocols.  And what do we do when we want to
carry
them over the Internet?  We encapsulate them.  We don't try to bludgeon
them
directly into the IP framework itself.

Much of this discussion feels like trying to hammer a square peg into a
round
hole; the peg isn't going to be terribly happy about it, and that hole is
never
going to be the same ever again.

Matt