[RRG] Re: Aggregation Implies Provider Dependence (LISP-ALT) & Ivip dependencies too

[Robin Whittle <rw@firstpr.com.au>]

Hi Christian,

I agree that with the strictly aggregated model of ALT (as best I
understand it) the end-user would need to connect their ETRs
(actually, the ETRs probably belong to the one, two or more ISPs the
end-user connects to the Net through) via a GRE tunnel to a
particular ALT router which is at the lowest level of the hierarchy.
 That ALT router is is presumably operated by whoever is responsible
for the address space of which the end-user's EID is a subset.

That router would be located somewhere, probably not anywhere near
the ISPs currently chosen by the end-user, since end-users are able
to use any ISP in the world.  This does imply a direct
"provider-dependence", in terms of physical LISP-ALT communications
via the GRE tunnels, which are essential to the system operating
correctly.

Alternatively, invoking ALT's potential for meshiness, the first ALT
router might be a local one, not owned by whoever provides the
address space.  That ALT router would be more likely to be operated
by the ISP which the end-user chose for Net connectivity.  End-users
are not bound to any particular ISP.

Every administrative arrangement I can think of for managing the new
type of address space of a map-encap scheme (EID for LISP) involves
some kind of dependence on the organisation who somehow provides the
larger block of address space from which the end-user's space is a
subset.

This assumes that the end-user gets their EID or micronet addresses
from some other organisation, implicitly a "provider", who also
provides such address space to many other end-users.  I use the term
"Mapped Address Block" (MAB) to denote each range of addresses,
advertised in BGP as a prefix, which is devoted to Ivip mapping.  A
"provider" is the organisation who has been assigned this address
space by an RIR (unless of course the provider is an RIR).

If an end-user already had their own PI space today, with its own
BGP advertised prefix, made that a part of LISP or Ivip, and then
mapped the whole thing as a single EID/micronet, then the end user
is acting as their own "provider".  There is no direct reduction in
the number of BGP advertised prefixes - so this is not how I think
LISP or Ivip should generally be used.

I wrote about provider dependencies for Ivip on 2007-11-14:

  Ivip end-users' dependencies
  http://psg.com/lists/rrg/2007/msg00536.html

The end-user does depend on the organisation which provides the
address space.  The most obvious dependency is that the organisation
accept the end-user's commands about changing the mapping of their
micronets and makes sure this is sent to all the ITRDs and QSDs in
the Net.

The end-user can't select some other organisation to be responsible
for this, since ultimately, one organisation has to
cryptographically sign the packets which are sent out to the ITRDs
and QSDs.

Theoretically, that "organisation" could be a consortium, somehow
operating a genuinely distributed system or contracting the work to
a separate organisation which handled the mapping changes.  Then,
the end-user could change from having a commercial relationship with
one member of this consortium to having it with any other member.
But as long as the end-user wants to retain this address, it is
dependent on the "organisation" which physically administers the
mapping information for the larger address block of which the
end-user's micronet is a part.


Number portability has been enforced on many cell-phone and wireline
POTS services around the world - despite their protests.  I am not
sure exactly how this is implemented, but I think it involves the
call first going to the telco which originally had the number, and
then to the telco which the end-user currently selects for their
service.  This is messy, but is feasible on the national scale of
these phone networks.  (The alternative is a database lookup -
perhaps locally cached - of a national numbering database for every
single call which is made.)

The end-user is still dependent on the telco which originally had
that block of numbers assigned to it, although they don't have a
business relationship with them.  I think we don't want such
"triangle routing" in the new map-encap architecture.


My idea with Ivip is that a bunch of mapping updates for a
particular MAB would be contained in one or more packets, as part of
 a larger stream of such updates for other MABs.  I intend that each
such packet be signed or be in some other way verifiable as having
been authorised by the organisation which is responsible for it.

It would probably be prohibitively messy to redesign the system so
that all the ITRs in the world could somehow get updates for each
individual micronet from some other organisation.  With the current
plan, the packet says what MAB it applies to, and contains one or
more mapping updates - with the whole thing verified in some way as
having come from the one organisation which is publicly known as
being responsible for this MAB.

Individual signatures for each update, and the verification and
security problems this would entail, sounds like more trouble than
it is worth.

Absolute, true, independence from any one "provider" whilst
retaining a given IP address is probably too much to ask from a
map-encap scheme.  End-users need to choose their IP address
provider with care.

But the scheme enables them to use any ISP, to split their address
space into as many micronets as they like, and to have each micronet
use any ETR at any ISP in the world - so its a pretty good deal.

  - Robin


--
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