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

[Dino Farinacci <[e-mail]>]

> Hi Dino,
> 
> I'm not sure I understand. OOO packets most often happen when packets for the same flow take two different paths through the network at the same time so that packets sent later beat earlier ones to the destination. W.r.t. to the cache, the window for OOO delivery is when cache is entry is

Right.

> instantiated, but there are already packets inflight that presumably are taking non-cached scenic route. Once the non-cached packets have been received, all the packets for the flow go through the cache taking the same path so there is no more OOO. It's a small window. Also, if multiple connectionr.s

For the same destination yes.

> are simultaneously suffer OOO from this I doubt this would have a material impact-- congestion window collapse is unlikely without packet loss. Of course, a stateful firewall in the path might not be so tolerant of OOO packets…

In ILA there is likely a one-to-one association between locator and ID. So the out of order situation can happen to each new specific flow. In LISP, the locator can be a prefix used for many EIDs so the out of order or drop situation on the ITR only happens for one destination and not to all the others that start a flow for the same prefix.

> > > 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
> >
> > But the ILA router in the network needs to have the mapping. And if it does not, what happens then?
> >
> > The ILA router is considered authoritative for its shard. If it doesn't have a mapping then the packet is silently dropped as having an unreachable destination.
> 
> Does the ILA router for the shard only route to destinations inside of the shard? 
> 
> Yes.
>  
> And if so, it is kept small so you can push the mappings and make it scale at that level?
> 
> Small is relative. The ILA router first needs to being able to forward the load, so provisioning would need to consider the worse case where no entries hit the cache. Redirects would likely be rate limited (probably capped by throughput). In a network, design I would probably target a cache hit rate of at least 95%.

In any loc/ID design push can be used and scale. But is it practical (and necessary) for 1B entries?

> > > still be viable but sub-optimal; that characteristic establishes a bound for the worst case DOS attack.
> > >
> > > Any thoughs on this approach?
> >
> > You’ll really need to put signatures in the Redirect messages if you want robust authentication.
> >
> > The redirects are sent over an established TCP connection to an ILA-N so that deters message spoofing. For stronger security, TCP authentication option or TLS can be used.
> 
> Is it worth the state to hold millions of TCP connections only the occasion redirect message?
> 
> It might be millions of TCP connections spread across a large network, but for ILA-Ns it's at most a couple of hundred connections and for a mapping resolution ILA-R it's probably no more than 50K. Assuming 2K memory per TCP connection ctx (and TLS if in use) that's a 100M on the ILA-Rs. In addition to security, the other reasons to use TCP is it's reliable transport and provides congestion control and avoidance. There's also the option of using TFO if the amount of state were to become an issue.

Okay. Agree its not a memory-issue proble I was referring to. It was how to manage the connections. And how much is exposed to a network admin engineer to debug. Managing 100s of BGP connections have been a challenged with the customers I have worked with in the past.

Dino