IETF Logo Mail Archive

Re: [RAM] The mapping problem: rendezvous points?

David Conrad <drc@virtualized.org> Wed, 09 May 2007 23:58 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlw3Y-0000M4-61; Wed, 09 May 2007 19:58:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlw3W-0000Ly-CQ for ram@iab.org; Wed, 09 May 2007 19:58:50 -0400
Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlw3U-0003IH-W4 for ram@iab.org; Wed, 09 May 2007 19:58:50 -0400
Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49NgkHT070849; Wed, 9 May 2007 16:42:47 -0700 (PDT) (envelope-from drc@virtualized.org)
In-Reply-To: <F3A8A33D-614D-4E6F-9741-61FFBB42E40C@nokia.com>
References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <F2F9AE97-7599-42BB-A542-A4B33AC3FD18@virtualized.org> <F3A8A33D-614D-4E6F-9741-61FFBB42E40C@nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org>
Content-Transfer-Encoding: 7bit
From: David Conrad <drc@virtualized.org>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Wed, 09 May 2007 16:58:33 -0700
To: Lars Eggert <lars.eggert@nokia.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Lars,

On May 9, 2007, at 3:30 PM, Lars Eggert wrote:
> I'm not saying that they will break - I am saying that there is a  
> danger of additional inefficiencies.

Yep.  This is part of adding a layer of indirection implicit in the  
locator/ID split.

>> I'll ask again:  how does this ARP thing work again?
> First off, all the ARP implementations I know of queue the packet  
> during the loopkup, i.e., no loss.

That's what I thought, but folks have been saying that routers don't  
queue anymore.

> Second, the duration of an ARP lookup vs. the end-to-end RTT is  
> typically miniscule. This is not so with LISP-like schemes.

Yes, but memory for queues (for edge device I/O queues) is much  
cheaper than it was...

Rgds,
-drc



_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram

v2.23.0 | Report a Bug | By Email