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

Dino Farinacci <dino@cisco.com> Mon, 10 September 2007 20:08 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 1IUpYB-0005fV-VS; Mon, 10 Sep 2007 16:08:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpYA-0005fQ-QP for ram@iab.org; Mon, 10 Sep 2007 16:08:02 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUpY9-0002JH-Kk for ram@iab.org; Mon, 10 Sep 2007 16:08:02 -0400
X-IronPort-AV: E=Sophos;i="4.20,233,1186372800"; d="scan'208";a="70665692"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2007 16:07:59 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8AK81RA026836; Mon, 10 Sep 2007 16:08:01 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8AK7mC6029540; Mon, 10 Sep 2007 20:07:59 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 16:07:52 -0400
Received: from [10.225.24.82] ([10.82.218.139]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 16:07:52 -0400
In-Reply-To: <DB3E5D6F36600847BC70D451534EBCD5010B16F1@E03MVB2-UKBR.domain1.systemhost.net>
References: <DB3E5D6F36600847BC70D451534EBCD5010B16F1@E03MVB2-UKBR.domain1.systemhost.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <415D3A2C-8DBC-4F3B-847D-8032D37B2D1E@cisco.com>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <dino@cisco.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Mon, 10 Sep 2007 13:07:51 -0700
To: "<louise.burness@bt.com>" <louise.burness@bt.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 10 Sep 2007 20:07:52.0521 (UTC) FILETIME=[44C61B90:01C7F3E6]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1179; t=1189454881; x=1190318881; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20 |To:=20=22<louise.burness@bt.com>=22=20<louise.burness@bt.com>; bh=yMsUupxWEuM6sfa1ITCt/PFdlJ4/LvIRTM7nNQzq8S8=; b=HDS3fJ2TaeyPQKV+YApZMUid+/cppz1lpTkbDLpeSBOIpO+8j3xVZodHeoO9T7ncaynLvW1q Qn0+gfXPZvnuNxRf2AMavMi/2BOHUdsT1sqkWBwxo0zzKzBEtH3KtU4L;
Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: jnc@mercury.lcs.mit.edu, 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

>> From: Iljitsch van Beijnum <iljitsch@muada.com>
>
>> If nothing much is happening and caches are empty, and a host then
>> starts a session towards some remote destination, in a pull model,
> the
>> encapsulating device must first look up a mapping so it can
> perform the
>> required encapsulation. So the first packet must be dropped.
>
> Well, is that latter really necessary? I know it's more complex to  
> hold
> onto the packet until the mapping comes back, but if dropping that  
> first
> packet causes problems, we could write that code without changing
> anything else in the system; i.e. it's an optimization we can add  
> later,
> invisibly to the rest of the system, if it turns out we need it.

This is the reason why the data-triggered based Map-Reply in LISP  
takes a packet that does not have a mapping cached and copies the  
inner destination address to the outer header's destination address  
field.

And hence LISP 1.5 allows no drop of packets if an EID-prefix  
namespace is routed on another topology where you only route on IDs  
(where the Internet topology we know of today routes only on locator  
prefixes).

Dino


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