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

On Tue, Nov 17, 2020 at 2:24 PM Matthew Petach <mpetach@netflight.com>
wrote:

>
>
> On Mon, Nov 16, 2020 at 3:17 PM Tony Whyman <
> tony.whyman@mccallumwhyman.com> 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.
>
>

I second Matt!

Behcet

> Matt
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>