Subject: [lisp] Some questions about ALT

From: Michael Menth <[email-masked]>
Date: Tue, 04 Aug 2009 11:46:28 +0200

Dear colleagues,

I have some questions about LISP+ALT since some pieces of that 
architecture are not yet clear to me. Either I have overlooked that 
information in the drafts or they are not yet publicly available.

1) The question of control

Who has the control over ALT? Who decides what the aggregation points are?

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.

a) Does the ALT topology follow contract relationships like the normal 
BGP which possibly makes aggregation difficult?

b) Will there be extra contracts to carry map-request traffic on the ALT`?

c) Or will that work with mutual agreements since the overall rate of 
the map-request traffic is hopefully small enough to be carried without 
financial backing?

Or is there another option?

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 adds to delay which is especially unfortunate 
for data-probes which are currently not considered in ALT. What was 
actually the reason to renounce on data-probes in the current version of 
LISP?

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?

5) Security

Are there plans yet to add security in LISP+ALT?

Kind 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: Sam Hartman <[email-masked]>
Date: Tue, 04 Aug 2009 09:10:59 -0400

This sort of discussion is well within examining to what extent LISP
is an operable/managable protocol.  We try to avoid business process
discussions within the IETF, but at least to the extent that they
focus on whether something can be deployable, they definitely are in
scope.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 4 Aug 2009 15:18:46 +0200

+1

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sam Hartman
> Sent: Tuesday, August 04, 2009 4:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lisp] Some questions about ALT
> 
> This sort of discussion is well within examining to what 
> extent LISP is an operable/managable protocol.  We try to 
> avoid business process discussions within the IETF, but at 
> least to the extent that they focus on whether something can 
> be deployable, they definitely are in scope.
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>