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

[Scott Brim <swb@employees.org>]

You discuss ALT and EMACS in one message.  I'm going to split them up
and deal with EMACS in a separate reply.

Excerpts from Robin Whittle on Fri, Nov 16, 2007 11:40:48PM +1100:
> I understand that LISP-ALT (AKA LAT = LISP Alternate Topology):
> 
>   http://tools.ietf.org/html/draft-fuller-lisp-alt-01
> 
> is a short-term (for deployment, or just for research) alternative
> to LISP-CONS and LISP-NERD.

LISP-ALT can be a first step to something else but it may be all we
ever need.

> A new set of "LISP-ALT routers" is created, forming an overlay
> network using GRE.  These LISP-ALT routers form a network using the
> same IPv4 address space, but this is a different, separate network
> from the global Internet.  This network runs its own BGP system with

It is not a separate network, just tunneled traffic.  The
GRE-encapsulated packets are carried over global Internet, just like
any other IP packets.  What you have is a "virtual topology", a set of
tunnel relationships between cooperating nodes.  Similarly, this mail
message is being "routed" by a "network" of SMTP "routers", connected
over the Internet.

> a separate ASN number space, completely unrelated to the current BGP
> and ASN numbering systems.  The connectivity patterns of these
> LISP-ALT routers is somehow determined by address structure, rather
> than physical proximity as it is in the current Internet.

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.

> 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?
SThe 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.  

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

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

> As with the other LISP proposals (unless they adopt an "anycast ITRs
> in the core" approach, as perhaps they might - see message 529) it
> is not obvious how packets from non-upgraded networks can get to a
> "proxy-ITR" so they can be tunneled to the correct ETR.

BGP.  See above.

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

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

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

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

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

Please propose something.

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

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

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

Scott

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