Re: [lisp] LISP does not involve separate namespaces

jnc@mercury.lcs.mit.edu (Noel Chiappa) Thu, 30 July 2009 03:15 UTC

To: lisp@ietf.org
Message-Id: <20090730031536.1CB5E6BE58C@mercury.lcs.mit.edu>
Date: Wed, 29 Jul 2009 23:15:36 -0400
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] LISP does not involve separate namespaces
Precedence: list

    > From: Robin Whittle <rw@firstpr.com.au>

    > A namespace is a context within which a number or name is interpreted.

Exactly.

    > the remainder of the global unicast space cannot be used for routing
    > packets in the BGP core. 

Not necessarily.

LISP is a long process, and things that are true at one phase are not true at
another. Remember the big debate some months back about whether a LISP EID
was a 'true' EID or not? Well, now, with LISP Mobile, they are (i.e. the
LEIDs of mobile nodes contain absolutely no location information whatsoever).

So I expect that some day we may well see instances of the same 32-bit number
being the RLOC of one place, and the EID of a host somewhere else.

    > This includes any end-user network where a mobile device might have its
    > care-of address.

LISP Mobile does not have care-of addresses.

    > how can a LISP MN act as its own ETR without an RLOC address of its
    > own? 

It has an RLOC: whatever IPvN address it has been assigned by DHCP, etc, on
the network to which it is currently attached.

    > If the MN is in an end-user network, and that end-user network is using
    > EID addresses .. then its address can't be within an RLOC prefix.

If a LISP MN is behind an existing xTR (e.g. at a site boundary), then
packets to it from elsewhere in the network have to be
double-LISP-encapsulated when the arrive at the site's ETR (i.e. by the
encapsulating ITR). The site xTR strips the first layer, and then the xTR in
the LISP MN strips the second. I'm not sure if this is covered in the draft,
but it happens pretty naturally: the EID maps to an RLOC which happens to be
an EID (i.e. there's a valid mapping for it), and gets mapped and
encapsulated again.

(This is an instance of a circumstance where the two namespaces do in fact
overlap. There is some complex hair I won't go into where if 'core' RLOCs are
being allocated out of a namespace with another syntax, e.g. some new
variable-length locator-spare, the source ITR can tell when it can stop
looking up the RLOC, on the offchance it's also an 'EID', because RLOCs with
that syntax cannot be an EID, but that's a long way down the road so I'm
going to ignore it for now.)

	Noel

Re: [lisp] LISP does not involve separate namespa… Noel Chiappa
Re: [lisp] LISP does not involve separate namespa… Robin Whittle
Re: [lisp] LISP does not involve separate namespa… Dino Farinacci
Re: [lisp] LISP does not involve separate namespa… Noel Chiappa
Re: [lisp] LISP does not involve separate namespa… Scott Brim
Re: [lisp] LISP does not involve separate namespa… Noel Chiappa
Re: [lisp] LISP does not involve separate namespa… Dino Farinacci
Re: [lisp] LISP does not involve separate namespa… Robin Whittle