Re: [RRG] LISP-ALT (was: LISP-EMACS & LISP-ALT)

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

Hi Scott,

Thanks for your response.

I understand that LISP-ALT is not a physically separate network, but
 that it uses tunnels through the current network to create a
structurally independent network, with its own use of address space,
its own BGP system and its own new use of BPG's ASNs.

I understand that the connectivity between the LISP-ALT routers is
structured according to the address hierarchy:

> Did you understand that part?  If you are responsible for
> 192.0.2.0/24 you would say so to one or more parent nodes
> responsible for an including prefix, for example 192.0.0.0/18.

This makes me think that the connections are not structured
according to geography.  The Devil's Advocate perspective on this is
that the links between routers could be, on average, rather
geographically long compared to the links between ordinary BGP
routers.  This means lots of routers per tunnel, with consequent
increases in overall latency and risk of packet loss.


>> ETRs are the authoritative source of mapping information.  (I
>> don't understand how this would work, especially with respect
>> to redundancy and the fact that ETRs may be cut off from the
>> rest of the Net.)
> 
> Are you saying that an ETR might have a connection to the ALT 
> infrastructure but be cut off from ordinary Internet packet
> flows? The ALT flows are just Internet packet flows, so if you
> have one you have the other -- there's fate sharing.  I suppose
> there could be a situation where an ETR had a physical interface
> exclusively for ALT traffic, and all of its other core-facing
> interfaces were broken.

I was questioning the whole LISP approach of making ETRs the
authoritative source of mapping information.  I write more on this
in my next message on LISP-EMACS.


>> There is also something in 5.2 (3.) about LISP-ALT routers
>> acting as a "proxy-ITR to "support non-LISP sites".  I
>> understand this is to handle packets sent from networks without
>> any LISP upgrades - specifically, without an ITR.  As I have
>> written recently (mssg 529), I don't see how any such scheme
>> can work unless the prefixes in which EIDs are found are
>> advertised in ordinary BGP - which is at odds with the original
>> conception of LISP.
> 
> There are a number of possible "proxy ITR" plans.  I think in the
>  context you are talking about that yes, EIDs would be advertised
> in "ordinary" BGP, but they can be aggregated (reducing BGP
> state, possibly dramatically) and stable (reducing churn rate).
> In any case this is not specific to ALT.

I can't understand clearly what you are proposing - can you give a
concrete, detailed, example?  I write more about this in my next
message.


>> There are so many options within this proposal, and so few
>> examples, I can't clearly understand it.  However, I see there
>> is no mention of how to cope with MTU, PMTUD etc. problems and
>> that there is no discussion of why anyone would want to build
>> this network.
> 
> Business motivation is a significant issue for all of the RRG 
> scenarios.  My attitude towards this is that first we figure out
> a really good technical approach for the evolution of the
> Internet. Once we know where we want to go, then we think about
> whether it's feasible to motivate people to move that way, given
> that Internet operations is primarily based on profit.

I agree we need to be somewhat bold - but not completely unrealistic
- in these early days of designing a new architecture.  That is why
I boldly went for a simpler system based on the assumption that we
could achieve the challenging task of pushing mapping data out
around the Net within a few seconds.  This seems a lot easier to me
than than trying, as you do with LISP, to add complexity to a
pull-based system in order to achieve acceptable performance.


>> Since the number of separate micronets (see mssgs 533 & 535)
>> and therefore ETRs is likely to grow to vastly higher than the
>> ~240k prefixes of the current BGP system, it is not clear to me
>> why BGP is a good choice to cope with this larger number in the
>> LISP-ALT overlay network.  (I understand this new network has
>> some simplifications which might help.)
> 
> Mainline BGP carries announcements of prefixes with paths to get 
> there.  Routes are propagated following physical topology.  The
> ALT infrastructure carries announcements of prefixes with a
> promise that it can get you to a node that can give you an
> EID-RLOC mapping. Routes are not constrained to propagate
> following physical topology, so prefixes can be aggressively
> aggregated.  Even if the EID space fragments (and I think it will
> too), the announcements carried over the ALT infrastructure will
> still aggregate way down, to the same number at the top levels.
> For example, if I have 192.0.2.0/24, as above, that is connected
> to a parent node responsible for 192.0.0.0/18, and I split that
> /24 into two /25s, both of them will still connect through the
> same parent (or one below it), and the split will not be visible
> above that level.

Yes, I understand that the logical structure of the LISP-ALT network
will be tied directly to the tree-like splitting of the address
space into the micronets of each end-user network.  This is
conceptually simpler than the BGP prefixes being advertised in a
geographically scattered fashion, with the geographically-structured
BGP network trickling this information through itself until every
router has what it needs to make a good enough forwarding decision
for each prefix.

However, based on my limited understanding of LISP-ALT, I still
think your new LISP-ALT routers are going to be scattered
geographically all over the Net, and that a logical link from the
LISP-ALT router in you example network 192.0.2.0/24 is probably not
going to be anywhere physically near the LISP-ALT router for
192.0.0.0/18.  So while logically, LISP-ALT would look like a
compact network, the physical distances of the links between routers
could be, on average, very long.  If you can give some more concrete
examples, this might correct the likely deficiencies in how I
imagine LISP-ALT would work.


>> Overall, I think the LISP proposals (not so much NERD) are hard
>> to understand, with terse, conceptual descriptions with many
>> options and not enough examples.
> 
> And your feedback will help make future versions clearer.  Thank
> you.

OK.  I would be glad of similar attention to the Ivip ID.

If you believe it is fundamentally undesirable or impractical to
push mapping data out globally, aiming for a few seconds delay, to
ITRDs and QSDs all over the world, then I suppose you might think
Ivip is not worth considering.

However, Ivip doesn't enforce every ITR to be an ITRD.  There is
great flexibility - with local decisions about where to place
caching ITRCs, Query Servers (caching QSC and full database QSDs the
ITRCs need, and full database ITRDs.  So if the cost and
difficulties of pushing the data is high, Ivip can be deployed with
fewer, more centralised, ITRDs and QSDs.  I think this is more
locally flexible and more elegant than having to make a global
overlay network as you are proposing with LISP-ALT and LISP-EMACS.


>> This is different from having a variety of principles which can
>> be combined in various combinations, as in LISP, to create 
>> fundamentally different architectures.
> 
> Actually I'll disagree here.  All of the scenarios proposed
> consist of multiple functional components.  For example, it is
> admirable that we (all) have been able to separate data plane and
> control plane so that we can mix and match.  This kind of
> flexibility is important.  You say you can produce different
> "architectures" by combining them differently.  That's true, and
> that's why names and packaging are  not as important as the
> functional components themselves.  It is good that we can mix and
> match -- that gives us power and freedom in creating the future
> Internet.

OK - I can imagine that one could deploy a pure LISP-NERD system, a
pure LISP-CONS system etc. or some combination of the two.

Its just that if you can do LISP-NERD to some places, why can't you
also push the data (actually, each LISP-NERD requests the mapping
data files) to some Query Servers which are geographically close to
LISP-CONS' all caching ITRs?  Then, you don't need LISP-ALT or
LISP-EMACS.

eFIT-APT says "Push (slowly) all the mapping info to a Default
Mapper in every upgraded network".

Ivip says "Push (very quickly) the mapping info to ITRD and QSDs
which can be located as deep in ISP networks, or outside them, as
you like.  Then deploy as many ITRCs and ITFHs (in hosts) with
caching QSCs as makes sense in order to achieve the best trade-off
between cost of ITRs etc. query and push traffic, and more optimal
paths for the traffic packets.

LISP-CONS says "All ITRs are caching, so we need a global CAR-CDR
network to handle (and perhaps cache) mapping queries".

LISP-ALT says "All ITRs are caching, so we build a GRE overlay
network to handle mapping queries, and also (like eFIT-APT's Default
Mappers) send unmapped packets to something which will both tunnel
it to the correct ETR and send mapping information to the ITR".

LISP-NERD says "Caching ITRs have difficulties finding which ETR to
tunnel novel packets to, so it is better for all ITRs to get a full
(rather slow) feed of mapping data.

The 3 mechanisms:

  CONS - Global CAR-CDR network.

  ALT - Global GRE network with its own BGP system.

  NERD - ITRs downloading all mapping data periodically.

are not the sort of thing you would mix and match.

If it was practical to do NERD, then it would be easier to have
local Query Servers to handle those LISP ITRs which only cache -
rather than build a CONS or ALT global network.

I don't think you wouldn't build both the CONS and the ALT network.

Ivip is a single, flexible, architecture which could be deployed
with various mixes of full database and caching ITRs and Query
Servers.  There is not one part of Ivip which isn't globally needed
if another part is built.


>> I am surprised that Ivip remains the only proposal which aims
>> for fast distribution of mapping data to query servers and
>> ITRDs all over the world.  Bandwidth, RAM and CPU power are
>> cheap and getting cheaper.  So I don't think the future
>> architecture of the Net should be constrained by over-complex
>> architectures which have only modest aims regarding mobility
>> and rapid delivery of packets - as if the designers are scared
>> by the apparent impossibility of doing what Ivip aims to
>> achieve.
> 
> I suspect you are wrong that you are the only one distributing
> mapping data to query servers.  To start with, NERD does, and
> CONS does via caching.

My understanding of LISP-NERD is that all ITRs have a full copy of
the database, and that they all download (AKA "push") the mapping
updates themselves.  Full database Query Servers are only needed for
handling queries from caching ITRs, and from any caching Query Servers.

When I wrote: "fast distribution of mapping data to query servers
and ITRDs all over the world." I meant: "Fast pushing of the
complete mapping updates to all ITRDs and QSDs all over the world."

"Distribution" is more general, and perhaps could include the query
and cache system of LISP-CONS and LISP-ALT, but that is not what I
was trying to convey.

> There are tradeoffs with pushing your mapping information. How do
> you deal with policy differentiation?  How do you get one site to
> use one RLOC set, and a different site to use a different one, 
> without revealing your policies to the world?  One of the things
> I like about ALT is that it supports policy differentiation while
> still keeping mapping information tied to operational reality.

Ivip does not attempt to enable the end-user to specify one ETR for
some ITRs and another ETR for other ITRs.  If you want to load
balance a network 22.33.44.0/24 over four ITRs in four ISPs, Ivip
only enables you to do this by having some mix of this address space
mapped to each such ITR.  Ivip has arbitrary lengths of address
space for micronets, so you can specify a different ETR for every IP
address if you like, or have micronets such as:

  22.33.44.0    ETR1   Micronet length 1
  22.33.44.1    ETR2 } Micronet length 2
  22.33.44.2    ETR2 }
  22.33.44.3    ETR3   Micronet length 1
  22.33.44.4    ETR4 } Micronet length 5
  22.33.44.5    ETR4 }
  22.33.44.6    ETR4 }
  22.33.44.7    ETR4 }
  22.33.44.8    ETR4 }

This is not the most elaborate form of load balancing - so other
ITR-ETR schemes may be superior in this respect.  However it is nice
and simple.

I would think that an end-user network of the sort which would have
LISP-EID space or Ivip-mapped address space wouldn't be too fussed
about which other ISPs networks their packets arrived by en-route to
each ETR.  They will be vitally interested in which ETR the packets
go to, but I would have thought "policy" was something the ISPs were
interested in, and that they would continue to use current BGP
arrangements to achieve this.

Can you give an example of when it would be desirable for an
end-user to give out one ETR or set of ETRs for some ITRs to use and
another set for other ITRs?  How would you do this with LISP-CONS,
LISP-ALT or LISP-NERD?  I don't recall mention of this in the LISP IDs.


>> I think it will be practical to create a fresh architecture and
>> a fancy, fast, mapping data distribution system
> 
> Please propose something.

I have.  The overall architecture is described here:

  http://tools.ietf.org/html/draft-whittle-ivip-arch-00#section-7
  http://tools.ietf.org/html/draft-whittle-ivip-arch-00#section-8

I am working on a more secure and robust system than the simple UDP
packet approach I have in the ID.


>> I think a lot of the options and complications of LISP are
>> attempts to fix problems which are inherent in its conception,
>> including:
>> 
>> 1 - An overly ambitious goal of removing BPG advertisements,
>> when I think it would be fine to keep a lid on the current
>> number, or accept a somewhat higher number, provided we can
>> serve the needs of many more end-user networks.
> 
> All of the scenarios keep BGP around, but just reduce the
> rate*state it suffers.  There is no goal of removing BGP
> advertisements completely.

OK - I got the impression from Dino that he wanted, ideally,
initially at least, to have the main BGP system have no
advertisements for any prefixes which contain EID space.


>> 2 - An overly cautious approach to the problem of distributing 
>> mapping information around the world - either with CONS, which
>> does not attempt it, or NERD which does it very slowly. (TRRP
>> generally does not attempt it and eFIT-APT intends to do it
>> very slowly indeed, over the current BPG network - which is not
>> necessarily a consenting partner . . . )
> 
> Please run a simulation, or at least provide an analysis with
> numbers. I hope others will too.

It is early days yet.

I figure that we can build a robust, fast, reliable, Replicator
system more easily than trying to get a global CAR-CDR or LISP-ALT
network running with acceptable reliably and speed.


>> 3 - Therefore, LISP mapping distribution is too slow to allow 
>> mapping database changes to be the means of implementing 
>> multihoming service restoration.  This leads to the requirement
>>  for more complex mapping information, ITRs having to make
>> their own decisions about which of various ETRs is the best one
>> to tunnel packets to etc.
> 
> Multihoming service restoration?  To me this means either (1) 
> continuity of higher layer sessions, for example RTP, or (2)
> switching from one ETR to a different one.  Session continuity
> happens at a higher layer.  The IP layer service is constant and
> doesn't need to be restored (that's why you're multihomed).  ETR
> switching is handled in LISP using information in headers and
> Map-Replies.

I mean (2).

LISP and eFIT-APT (I am not sure about TRRP) involve a complex body
of mapping data, giving the ITR multiple ETRs to choose between -
with each ITR having to do its own detective work to figure out
which ETR is both reachable and has connectivity to the destination
host.

Ivip mapping data is a single ETR, which is changed by some external
system, of the end-user's choice, which decides how best to
multihome the end-user's network, and sends the appropriate mapping
updates (perhaps through some intermediary) to the RUAS (Root Update
Authorisation Server) where it gets Replicated out to the world's
ITRDs and QSDs within a few seconds.  QSDs can push the changes to
ITRCs and caching Query Servers which recently queried the mapping
for any address affected by the update.


 - 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