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

From: [email-masked] (Noel Chiappa)
Date: Sun, 9 Sep 2007 22:16:21 -0400 (EDT)

> From: Iljitsch van Beijnum <[email-masked]>

    > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: <[email-masked]>
Date: Mon, 10 Sep 2007 08:44:17 +0100

-----Original Message-----
From: Noel Chiappa [mailto:[email-masked]] 
Sent: 10 September 2007 03:16
To: [email-masked]
Cc: [email-masked]
Subject: Re: [RAM] The mapping problem: rendezvous points?

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

[alb] If the pull takes a while, someone could send lots of packets to
dud destinations, and if you hold all those packets waiting to find the
mapping you have DoS potential?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Sep 2007 15:14:11 +0200

> Well, is that latter really necessary?

"Routers are not in the storage business."

But if they were, there would be a limit to what they can store, and  
I think it's likely this limit is smaller than the maximum number of  
packets that the router can receive in the maximum time it can take  
until the mapping process completes.

So I'd say that drops will happen, even if some storage is added as  
an optimization.

> EID->RLOC binding?

Wouldn't that be a specific implementation of the general idea of  
sending packets for which there is no mapping to a location that  
knows how to deliver them?

> When the request gets to whereever that binding is

It's a tradeoff between the complexity of having an additional system  
or the complexity of having multiple functions in one system. I'd say  
that it would be good to design things such that it's possible to do  
it in separate rendezvous points and then let the implementers figure  
out whether they want to do it that way or not.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Sep 2007 13:07:51 -0700

> 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