Subject: Re: [lisp] Some questions about ALT

From: [email-masked] (Noel Chiappa)
Date: Fri, 4 Dec 2009 22:43:17 -0500 (EST)

> From: Michael Menth <[email-masked]>

    > I have some questions about LISP+ALT since some pieces of that
    > architecture are not yet clear to me.

Hi, sorry this never got a reply - it was sent in during the big UDP checkum
list melt-down, and got overlooked in the midst of all of that.

Note that these answers are only my personal take on your questions; others
may have different thoughts.

Note also that LISP is 'sort of' set up to allow use of different mapping
systems, and indeed it might be that something other than ALT would be
swapped in to replace ALT, if it seems that some other alternative would be
better. ALT was put together to provide a distributed mapping system for LISP
which minimized the amount of new code that had to be written; i.e. it
re-used as many things as possible. Needless to say, that is not necessarily
the way to get the best possible design... 

    > 1) The question of control
    > Who has the control over ALT? Who decides what the aggregation points are?

I'm not sure there would be anyone in control, any more than there is anyone
in control of the DZF routing. It's a mesh of peers (in protocol terms, if
not in terms of the size of the namespace chunk each is responsible for), and
it is constructed from a set of peer agreements. Of course, if maximal
aggregation is to be achieved, the peering cannot be arbitary - more on this
below.

As to aggregation, BGP (which is run the ALT runs on) does not of course do
aggregation automatically; any aggregation done by BGP has be configured
manually. Moreover, for maximal aggregation, the peering cannot be arbitary;
if X.1 is being injected on one side of the ALT mesh, and X.2 on the other,
they cannot be aggregated.

So, ideally, peerings should be selected with some thought to how the
aggregation will work. I would imagine there would generally need to be a
commercial agreement, such that nodes which are 'higher' in the aggregation
hierarchy are compensated for their effort, although I do concede that I'm
a bit hazy on the details of how this might happen.

Note that a single Map-Server (a.k.a. ALT leaf node) might in fact have
connections to more than one 'higher-level' (in aggregation terms) node in
the ALT, to allow optimal aggregation. E.g. if a given Map-Server is
responsible for both A.1 and B.2, it might peer with one node which does A,
and advertize A.1 to that one, and with another one which does B, and
advertize B.2 to that one.

    > 2) Who's paying for the map-request traffic?
    > In LISP+ALT, map-requests are carried over the ALT. In contrast, data
    > traffic is carried over paths provided by "traditional BGP" for which
    > intermediate carriers are obliged by contracts to carry the traffic.
    > What are the incentives for providers to forward map-requests if they
    > have no relations to the source or destination of that traffic. This
    > situation seems possible or even likely to me for aggregation nodes.

Well, first, there should not be much map-request traffic (compared to user
data traffic).

Second, the ALT nodes are, to the network, just client nodes like any other.
I.e. if ALT node X is connected to ISP I (either directly, or by being at a
site S which has purchased connectivity from I), X looks like just another
normal node, as far as I is concerned. Just as any normal node might exchange
traffic with any other node on the Internet, without special arrangement with
the ISP, so too for x. Traffic it exchanges with other ALT nodes looks, as
far as the ISP is concerned, just like traffic any other host might exchange
with another site.

So this one doesn't worry me much (compared to the previous one).

    > 3) The structure of the ALT and data-probes
    > What are the guideline for designing the paths in the ALT? Business and
    > trust relationships dominate the paths in the normal BGP. Aggregation
    > should be the objective in the ALT, right? Can't that lead to extremely
    > long paths when EID-prefix-aggregators on different levels are located
    > in different areas?

This sounds a lot like what I discussed above, when I talked about the ALT
aggregation hierarchy? Yes, aggregation should be the goal, and I admit this
part isn't worked out yet; the thing that is most up in the air are the
commercial relationships, but I don't see that it is fundamentally insoluble:
DNS brings a similar set of challenges, and they seem to have been worked out
there.

As to the path lengths, I'm not sure how much of a problem that will be. For
one thing, if the requestor is on one side of the network, and the
authoritative mapping source is on the other, even with optimal placement of
aggregation nodes, nothing can reduce the path between them to next to
nothing. So, optimal placement of aggregation nodes can only approach an
asymptote on the stretch, not reduce the path length to nothing.

It is possible to add caching in the Map-Resolvers, in addition to that at
the ITRs, which would substantially reduce the number of queries which have
to go all the way to the authoritative mapping source, so even in that worst
case (above), you can still make things better.

For another thing, it's perfectly feasible to have multiple aggregators (we
are after all using BGP, not EGP :-). This does not reduce the path length to
zero, but can prevent gross path stretch (i.e. travelling from a requestor to
the far side of the network to get to X, and then all the way back to get to
X.1, which happens to be topologically close to the requestor). E.g. there
could be two nodes which both aggregate for X, and which are on far sides of
the network; X.1 registers with both X nodes, and then requests for anything
in X.1 will go first to whichever X node is closest to the requestor, and
then on to the X.1 node.

The whole issue of how to minimize path delays through the ALT is a complex
one, and if the ALT comes into widespread use, I'm sure reducing path lengths
is something that will get worked on down the line.

    > What was actually the reason to renounce on data-probes in the current
    > version of LISP?

Sorry, please refresh my memory - what's a data-probe? Do you mean a user
data packet sent through the ALT? If so, I don't recall exactly why they are
not used; perhaps someone else can answer this?

    > 4) Resilience
    > LISP+ALT uses ETRs as authoritative sources of the mappings and
    > map-requests are delivered to them over the ALT. Multihomed networks
    > have several ETRs which improve their availability. Which mechanism
    > makes sure that map-requests are deviated to another ETR if the primary
    > ETR fails?

Good question. There are a couple of existing mechanisms which will detect
down ETRs (from the point of view of a Map-Server). Of course, these may not
provide acceptable performance, but if so, it's not a difficult thing to do
(discovering dead ETRs more quickly), just some straight-forward engineering,
so I don't forsee a major problem handling that circumstance.

Anyway, to list the existing mechanisms, there are TTLs in Map-Register
messages, so eventually they will time out. Also, if another ETR decides that
a neighbour ETR is down, it will mark that ETR down with the the R-bit in the
locator record for the down ETR in _its_ Map-Register message, which
over-writes the existing record for that EID-block in the Map-Server. The
Map-Server will then ignore the down ETR, because of the R-bit.

    > 5) Security
    > Are there plans yet to add security in LISP+ALT?

Well, the topic of security in the binding system is a complex one. I should
start by saying that the current system doesn't have 'industrial-strength'
security, merely not-so-bad security with the most obvious vulnerabilities
dealt with. Depending on where we go in the future with mapping (whether the
ALT is retained, or some other system replaces it), probably more security
will be added. I personally would like to see individual bindings be signed,
but that would require a fair amount of infra-structure.

Anyway, about the ALT specifically: there are a number of aspects to security
in the binding system. There is the ITR->Map_Resolver link, the path through
the ALT, and then the Map_Server-ETR link. Round-trip, spoofing can be
prevented by the nonce. The Map_Server-ETR link is protected by a key pair.

The ALT is more of an issue, since the underlying technology (BGP) is
relatively open to attack by a rogue member of the mesh, unless constrained
by configuration. Just as anyone connected to the DFZ can, within limits of
configuration settings, claim to be a route to anywhere, anyone connected to
the ALT can claim to be on a path the authoritative mapping for any part of
the namespace. It would be nice to be better than what BGP does for basic
packet routing, but at the same time, it's not clear that being a lot better
than what BGP does for basic packet routing would do much good.

	Noel

---

From: Michael Menth <[email-masked]>
Date: Sat, 05 Dec 2009 23:30:21 +0100

Hi Noel,

thanks for the reply.

One more question: BGP populates routing tables, but the ALT is a 
virtual topology, right? That means, BGP's information is just input for 
ALT nodes that they know where the next hop in the ALT is. In 
particular, this means that packets are sent hop-to-hop in the ALT, 
right? This means that packet processing in LISP+ALT is significantly 
more complex than just forwarding a packet in the data path, right? I'm 
just asking because I initially thought that LISP+ALT used BGP to 
forward requests very efficiently on the IP data paths, but that doesn't 
work in a virtual topology (maybe in a testbed where ALT nodes are 
chosen to be adjacent in the IP layer). I just want to have 
clarification on this.

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 5 Dec 2009 14:49:32 -0800

> virtual topology, right? That means, BGP's information is just input  
> for ALT nodes that they know where the next hop in the ALT is. In  
> right? This means that packet processing in LISP+ALT is  
> significantly more complex than just forwarding a packet in the data  
> path, right? I'm just asking because I initially thought that LISP 
> +ALT used BGP to forward requests very efficiently on the IP data  
> paths, but that doesn't work in a virtual topology (maybe in a  
> testbed where ALT nodes are chosen to be adjacent in the IP layer).  
> I just want to have clarification on this.

Packet forwarding on the ALT is trivial. This is how it is done *by  
any commercial router* right now that does not know anything about LISP:

(1) An IP packet is received on a GRE tunnel (this is a Map-Request).
(2) The GRE tunnel can either be configured in the default VRF or a  
non-default VRF (this later is necessary when full routes are accepted  
in the default VRF).
(3) An IP destination address lookup is performed in the VRF routing  
table associated with the VRF of the input GRE tunnel interface.
(4) A next-hop address and GRE tunnel interface is produced from a  
typical routing table lookup.

Done. This is done in hardware on many shipping commercial routers.

Dino

---

From: Michael Menth <[email-masked]>
Date: Sun, 06 Dec 2009 00:01:40 +0100

Hi Dino,

thanks for the answer. Now I can bring again the pieces together: with 
GRE tunnels you provide virtual links between the routers of the ALT so 
that ALT routers can carry map-requests very efficiently to the next hop 
in the ALT by just looking at their destination address and without 
changing headers.

Regards,

    Michael

Dino Farinacci schrieb:
>> more complex than just forwarding a packet in the data path, right? 
>> I'm just asking because I initially thought that LISP+ALT used BGP to 
>> forward requests very efficiently on the IP data paths, but that 
>> doesn't work in a virtual topology (maybe in a testbed where ALT 
>> nodes are chosen to be adjacent in the IP layer). I just want to have 
>> clarification on this.
>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 5 Dec 2009 15:10:20 -0800

> Hi Dino,
>
> thanks for the answer. Now I can bring again the pieces together:  
> with GRE tunnels you provide virtual links between the routers of  
> the ALT so that ALT routers can carry map-requests very efficiently  
> to the next hop in the ALT by just looking at their destination  
> address and without changing headers.

Right, and right now we use eBGP as a distance vector routing  
protocol. Each router hop resides in a different AS.

BTW, the header does change since the TTL is decrement and the IP  
header checksum is adjusted. But you probably realize that.

Dino

>>> virtual topology, right? That means, BGP's information is just  
>>> input for ALT nodes that they know where the next hop in the ALT  
>>> is. In particular, this means that packets are sent hop-to-hop in  
>>> the ALT, right? This means that packet processing in LISP+ALT is  
>>> significantly more complex than just forwarding a packet in the  
>>> data path, right? I'm just asking because I initially thought that  
>>> LISP+ALT used BGP to forward requests very efficiently on the IP  
>>> data paths, but that doesn't work in a virtual topology (maybe in  
>>> a testbed where ALT nodes are chosen to be adjacent in the IP  
>>> layer). I just want to have clarification on this.
>>
>> non-default VRF (this later is necessary when full routes are  
>> accepted in the default VRF).
>> (3) An IP destination address lookup is performed in the VRF  
>> routing table associated with the VRF of the input GRE tunnel  
>> interface.