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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 10 September 2007 02:16 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 1IUYp6-0001n9-GT; Sun, 09 Sep 2007 22:16:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYp5-0001n4-JG for ram@iab.org; Sun, 09 Sep 2007 22:16:23 -0400
Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUYp4-0005Xb-E6 for ram@iab.org; Sun, 09 Sep 2007 22:16:23 -0400
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id E482D87322; Sun, 9 Sep 2007 22:16:21 -0400 (EDT)
To: ram@iab.org
Subject: Re: [RAM] The mapping problem: rendezvous points?
Message-Id: <20070910021621.E482D87322@mercury.lcs.mit.edu>
Date: Sun, 09 Sep 2007 22:16:21 -0400
From: jnc@mercury.lcs.mit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: jnc@mercury.lcs.mit.edu
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.


    > If there is some place packets for destinations that aren't mapped yet
    > can be sent to so they arrive anyway, even if this path is slower, this
    > takes a lot of pressure off of the encapsulation devices,

Interesting idea. Let me ponder that...

    > The issue of determining rendezvous locations .. is simple enough: have
    > each rendezvous point handle a very long prefix, such as 96/6.

How about piggybacking the user's data packet on the request for the
EID->RLOC binding? When the request gets to whereever that binding is
available, it's sent on to the ETR, while the mapping is sent back to the
requestor? That avoids all the extra mechanism/configuration of rendezvous
points.

	Noel

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