[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] LISP etc architecture

To: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [RRG] LISP etc architecture
From: Christian Vogt <christian.vogt@nomadiclab.com>
Date: Mon, 17 Dec 2007 20:23:14 +0200
Cc: Routing Research Group list <rrg@psg.com>
In-reply-to: <9CF61F0E-12AE-40AC-8D80-0499FC42C680@muada.com>
References: <9CF61F0E-12AE-40AC-8D80-0499FC42C680@muada.com>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

Iljitsch -

This means that it's important that mapping systems are designed suchthat they can be deployed in each of the A/B/C scenarios. I'm not surethis is the case right now.


I don't think either that this is the case since the mode of deployment
is, IIUC, exactly what distinguishes APT from LISP:  APT aims for
deployment in ISP networks -- first locally within ISP borders, later
across ISP borders --, and LISP aims for deployment in edge networks.

Alternative deployment is not always possible:  While I don't see a
reason why APT could not be deployed also in edge networks, LISP is IMO
tailored to deployment in edge networks because it uses the edge
network's interior gateway protocol to synchronize status information
between ingress tunnel routers.

- Christian







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

References:
- [RRG] LISP etc architecture
  - From: Iljitsch van Beijnum <iljitsch@muada.com>

Prev by Date: [RRG] Re: Address/prefix bunches
Next by Date: RE: [RRG] LISP-NERD reachability and MTU detection
Previous by thread: [RRG] LISP etc architecture
Next by thread: Re: [RRG] LISP etc architecture
Index(es):
- Date
- Thread