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

[jnc at mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Iljitsch van Beijnum <iljitsch at 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 at iab.org
https://www1.ietf.org/mailman/listinfo/ram