Subject: Re: [lisp] Fwd: Re: Re: A mapping system design-- specification of LISP+ALT

From: [email-masked] (Noel Chiappa)
Date: Wed, 2 Dec 2009 13:36:23 -0500 (EST)

On Wed, Dec 02, 2009 at 12:06:13PM -0500, Margaret Wasserman wrote:

    > My use case for this type of configuration was a company that has a
    > large HQ and various small satellite offices, perhaps connected by
    > leased lines or other private links, and all directly connected to the 
    > Internet. They would like Internet traffic for the satellite offices to
    > go directly to/from those offices, but to fall back to going through
    > the HQ if one of the satellite offices does not have direct Internet
    > connectivity. However, they would not like traffic to/from HQ to flow
    > through the satellite offices if/when HQ has Internet connectivity
    > problems.

The problem here, fundamentally, is that we are trying to equate apples and
oranges: specifically, we are trying to take a _naming_ aggregate (the
company, and its block of EIDs) and equate (aka 'map') it to a _topology_
'molecule' (i.e. the mapping, which is a somewhat indivisible set of
topological 'atoms').

Needless to say, when we do that, if the naming aggregate is _not_ a single
set of topological 'atoms', things don't work! :-) You can only do such a 1:1
mapping when the former is a single set of topological 'atoms', and in
Margaret's example, it's not.

To put it another way, we're trying to introduce an efficiency (having a
single block of EIDs, which is covered by a single mapping), but you can't do
that if you want to i) chop out a piece of the block and have it go to a
different mapping, and ii) do so _without_ indicating that the block (and its
associated mapping) is not _complete_ (i.e. covers the entire block), but
only _part_ of that block.

For example, the way to do Margaret's thing is to have one main mapping, for
the company, which maps to just the RLOCs of the main location's ingress
routers, and secondary mappings - one for each branch office which has
independent Internet connectivity - which list their ingress router(s) RLOCs
as high-priority RLOCs, and the main location's ingress routers as low
priority RLOCs.

The problem is that if the branch office EIDs are sub-blocks of the companys
main EID block, they can be 'hidden' by the main block's mapping. Yes, the
company could divide its EID block into two, and use half for the main
company, and advertise that in one mapping, and split the other half up into
smaller chunks, each of which is advertized separately (i.e. has a separate
mapping). However, once again we are basically having to allocate EIDs on
topological basis.... and if machines move, they will have to get a new EID.

So there are a couple of ways to fix this - and there is no shortcut, it's a
fundamental problem (see above).

First, you could circulate a partial block's mapping together with
information about what sub-pieces of it are not in fact covered by it. That
way, someone looking at the mapping can know when it does, and does not,
apply, and can go get the other mapping if the destination they are looking
for is in a sub-block which is not actually covered by this partial block.

Second, in a variant of this, you never circulate the mapping for a partial
block _without_ circulating all the mappings for smaller pieces of the block,
in tandem.

Another solution is to understand that what we're trying to make 'efficient'
or 'simple' is the _configuration_, so that e.g. company X can get a block of
EIDs, and then allocate them freely to various bits of the company,
regardless of the location. However, it's perfectly plausible to have a tool
that is placed between the configuration description, and what goes into the
mapping database, which converts that first simple description ('we have been
allocted this block, of which this piece is allocated over here, and it's
using these routers') and spits out the more complex set of mapping table
entries which implement that.

E.g. if a company gets a /16, and wants to split off an /19 for an office, it
just puts two lines in its config file: the /16, and the /19. The tool then
automatically generates 4 mapping entries: a /17, an /18, and two /19s; the
first two, and the first of the /19s _all_ map to the same thing (for the
main office), and the second /19 maps to the office info.

Yes, this can lead to a inefficiencies in mapping lookups, since if a distant
site is trying to talk to multiple machines in the company, which happen to
fall into diffferent blocks, it could take multiple map-request/reply cycles
instead of one. However, that's almost an inevitable result of the simpler
_mechanism_ than the first option(s), which can describe more complex chunks
of the address space in a single mapping - 'you pays your money, and you
takes your choice' - you get more complex mechanism, or more mapping entries.

Something like this is inevitable if i) naming blocks are not necessarily
topological blocks, and ii) we want to have the efficiency of being able to
apply a single mapping to a block of the identity naming space.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 2 Dec 2009 14:16:22 -0500 (EST)

> From: "Joel M. Halpern" <[email-masked]>

    > Given that LISP names sites, not machines

There's nothing in the protocol that mandates that. The protocol can be used
either way.

    > The fact that if a machine moves from a remote site to the home site it
    > has to change EIDs is a consequence of the LISP design

No, it would be a consequence of how it is _used_.

Only if people want the efficiencies of having a _block_ of namespace covered
by a single (identity->location) mapping does one suffer the consequence that
all things in that identity block have to be at that same location.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Dec 2009 14:19:28 -0500 (EST)

> From: "Darrel Lewis (darlewis)" <[email-masked]>

    > It dosen't follow that the Proxy-ETR needs to participate into the ALT.
    > An ITR can locally choose to point to an [P]ETR for non-LISP sites.

Oh, good point. A PETR would probably not want to be open to traffic from
anyone, anyway, only those ITRs with whom it has a contractual relationship,
so no need to advertize.

Anyway, good to know there are multiple arrows in the quiver... :-)

The interesting thing about your point is that if this is always true, it
gets rid of a strong argument at to why overlapping mappings need to exist.
Are there any others (other than configuration convenience)?

	Noel