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

From: Robin Whittle <[email-masked]>
Date: Mon, 04 Feb 2008 16:05:01 +1100

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 [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Feb 2008 13:55:42 +1300

On 2008-02-04 18:05, Robin Whittle wrote:
...
> single call which is made.)

However, user expectations are of a noticeable delay between dialling
a phone number and hearing the ringing tone. So e2e lookup solutions
to both number portability and roaming are tolerable. If we're
prepared to tolerate such a delay in initial identifier-to-locator
lookup, why are we having this conversation? (And note that
Mobile IP effectively *does* use such a solution.)

    Brian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 08 Feb 2008 21:02:44 +0200

Robin -

> address space. [...]

Any ALT deployment has to effect a trade-off between aggregation and
provider-independence.  If ALT is to aggregate EIDs, then an edge
network E's entry to the ALT infrastructure will have to be at a
particular ALT router, R1, that is defined by E's EID space.  And this
implies a dependence on R1's operator.  Otherwise, if you want to avoid
this dependence, you cannot aggregate.

You need to make the same trade-off even if, as you describe, E's direct
provider sets up an ALT router R2 to which E may connect.  Then again:

- You either prioritize aggregatability, in which case R2 must relay to
   R1.  E then remains technically dependent on R1's operator, even
   though business relationships may be transitive from E to E's direct
   provider to R1's operator.

- Or you prioritize independence from R1's operator, in which case R2
   must connect to the ALT infrastructure directly.  In this case you
   lose aggregatability.

> map-encap scheme.  End-users need to choose their IP address

My opinion is that, if we were going to change the Internet routing
system for the purpose of scalable provider-independence, we better
ensure that the new system reaches this goal fully, not half-heartedly.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Fri, 8 Feb 2008 16:31:00 -0500

>   must connect to the ALT infrastructure directly.  In this case you

You do not need to lose independence or aggregatability.

There can/should be multiple ALT nodes responsible for a prefix.  This
is not really a hierarchy.  So, you could have

              R3  R4    routes to mappings for 192.0.0.0/8
	     /|\  /|\  
	    / | \/ | \
	 ...  | /\ |  ...
	      |/  \|
	      R1  R2    routes to mappings for 192.68.0.0/16
	      |\  /|  
	      | \/ |
	      | /\ |
	      |/  \|
	      ETR ETR   responsible for site 192.68.1.0/24

You do not lose independence or aggregatability.  The redundancy at a
particular level is abstracted out at the next level.  This is true no
matter how many ALT nodes you have within a level.