Re: [RRG] On "jack-down" models

[Scott Brim <swb@employees.org>]

On 3/17/08 4:13 AM, Tony Li allegedly wrote:
> |None of the map-encap schemes involve a truly new namespace for the
> |ETR addresses - ETRs are located on some subset of the address space
> |which is not itself subject to mapping by ITRs.
>
> Well, I'd claim that they are indeed a new namespace, or at least could be
> if the proposals were generalized.  To see that this is possible, consider a
> case where we used some other new network layer for doing the encap.
> Imagine, for example, that LISP used v6 to encap v4.  As far as I can tell,
> logically, the entire proposal still works.  [Yes, I'm sure there would be
> bugs, that's not what I'm after...]

Right.  Or we could run the jackup with DECnet IV.  Or we could run IPv6
in the core and connect islands of XNS over it, or some completely new
protocol.  Adding a jackup layer gives you tremendous freedom, and
potential for Internet evolution (incremental, too).

However, where we're running IP over the same version of IP :-), I think
we're still uncertain about whether we want complete decoupling.  Having
non-overlapping namespaces in map-n-encap means: (1) Devices at the edge
can directly address some special well-known core devices.  This could
solve some so-far-unthought-of bootstrapping problems.  (2) You can put
the mapping points anywhere you want, you can even put multiple ones in
series, and still have only one encapsulation take place.  So for
example if my ISP has decided to "help" me by putting an ITR in my town,
I can still run my own ITR and control my packets.  This works only if
the ISP's ITR recognizes RLOCs as RLOCs in the headers I put on my
packets.  So there are potential benefits either way.

Scott



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg