Subject: Re: [lisp] lisp Digest, Vol 13, Issue 11

From: Charrie Sun <[email-masked]>
Date: Sat, 5 Dec 2009 17:30:49 +0800

>
> From: [email-masked] (Noel Chiappa)
> To: [email-masked]
> Date: Fri, 4 Dec 2009 22:43:17 -0500 (EST)
> Subject: Re: [lisp] Some questions about ALT
>    > 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.
>

Yes, i agree.. Also i thought that the construction should be done in a
organisational way, e.g. from top to down.

>
> 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).
>
> I do think that ALT can be another interest group. They can charge for
their mapping services. Maybe we can borrow ideas from the DNS.

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

Here i thought that if ITR buffers packets when it has no mapping
information for them, the mapping request delay is a critical thing. Because
the high-speed flow would soon overflow the waiting buffer of that ITR.
In fact, i made another suggestion. It's based on the idea that
map-resolvers (leaf nodes) contain mapping information which ETRs report to
them. These map resolvers reply to ITRs directly. Based on this, ITR caches
not only actual mapping information but also indexing of EID mapping, i.e.
the location of map-resolvers who have recently (or often) gave it mapping
replies. Since that map resolver may store mapping information for a larger
EID blocks than what a single ETR is responsible for, and that desination
addresses have strong local nature, this indexing information could be very
helpful to reduce the response delay, and also the burden of upper-layer ALT
nodes. I raised this suggestion in the attachment in Section 7. Warm welcome
for comments. :)

>
> 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.
>
>
Redundancy has another merit as to robustness.

> 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?
>
>
LISP perhaps doesn't recommend so. But some argues that buffering the
unsolved packet may be unrealistic to ITR in the high-speed network, and
dropping the packets is just what we don't want to see.

>
>    > 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.
>
> Yes, and if one ETR in a site is down, other ETRs within the site can
inform the information to ALT.

>
>    > 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
>
> Yours,
Letong