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

["Templin (US), Fred L" <[e-mail]>]

Matthew, LISP has been proposed as one of the aviation mobility solution candidates
but so have AERO/OMNI and IMHO provide a better alternative:

https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/
https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/

Fred

From: ipv6 [mailto:[e-mail]] On Behalf Of Matthew Petach
Sent: Tuesday, November 17, 2020 12:24 PM
To: Tony Whyman <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: Why this is broken [was Re: Extending a /64]


This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.






On Mon, Nov 16, 2020 at 3:17 PM Tony Whyman <[e-mail]<mailto:[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