Re: [Ila] [5gangip] Scaling mapping systems (was Re: BOF Description)

[Tom Herbert <[e-mail]>]

On Sun, Feb 4, 2018 at 3:55 PM, Dino Farinacci <[e-mail]> wrote:

> > One question about the packet flow sequence in section 4.1 of RFC6830.
> > On a cache miss, what does an ITR do with the packet? Is it dropped,
> > queued for pending resolution, forwarded to a node that would have the
> > mapping, or other?
>
> From an architectural point of view we wanted it to behave like ARP (and
> many ND implementations as well). That is drop the packet. There are
> implementations that queue the first packet that invokes the Map-Request or
> the last packet that was received while waiting for the Map-Reply.
>
> We were told by financial apps that dropping is better than queuing and
> sending older data.
>
> As time has gone on with experience in deployment, forwarding to another
> node that has a large shared cache, like an RTR, seems to deal with the
> issue in a compromised way.
>

In ILAMP (https://tools.ietf.org/html/draft-herbert-ila-ilamp-00) secure
redirects are defined to be the primary means of populating a cache. On a
cache miss, a packet is forwarded into the network and routing should
forward the packet to an ILA router that contains the complete set of
mappings for the associated shard. The router performs the transformation
and can send a redirect back to the caching node. The redirect can be
cached so that subsequent packets take a direct route and avoid the
trianglular routing. Redirects must be secure so that they cannot be
spoofed, so for that reason (and some others) the protocol is over TCP. The
mapping cache is only an optimization and packets are never dropped or
queued for pending cache resolution. If the cache weren't present,
communications would still be viable but sub-optimal; that characteristic
establishes a bound for the worst case DOS attack.

Any thoughs on this approach?

Tom