<div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 10, 2020 at 3:22 PM Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 9 Feb 2020 at 23:09, Rod Beck <<a href="mailto:rod.beck@unitedcablecompany.com" target="_blank">rod.beck@unitedcablecompany.com</a>> wrote:<br>
<br>
> I am curious about the distinction about the flow versus non-flow architecture for data centers and I am also fascinated by the separate issue of WAN architecture for these<br>
<br>
Based on the context of the OP's question, he is talking about<br>
architecture where some components, potentially network devices, are<br>
flow-aware, instead of doing LPM lookup per packet, they are doing LPM<br>
lookup per flow.<br></blockquote><div><br></div><div>This was exactly my question. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This comes up every few years in various formats, because with<br>
flow-lookup you have one expensive LPM lookup per flow and multiple<br>
cheap LEM lookups. However the LEM table size is unbounded and easily<br>
abusable leading to a set of very complex problems.<br>
<br>
There are of course a lot of variation what OP might mean. Network<br>
might be for example entirely LEM lookup with extremely small table,<br>
by using stack of MPLS labels, zero LPM lookups. This architecture<br>
could be made so that when server needs to send something say video to<br>
a client, it asks orchestration for permission, telling I need to send<br>
x GB to DADDR K with rate at least Z and no more than Y, orchestration<br>
could then tell the server to start sending at time T0 and impose MPLS<br>
label stack of [l1, l2, l3, l4, l5]<br>
<br>
Orchestration would know exactly which links traffic traverses, how<br>
long will it be utilised and how much free capacity there is. Network<br>
would be extremely dumb, no IP lookups ever, only thousands of MPLS<br>
labels in FIB, so entirely on-chip lookups of trivial cost.<br></blockquote><div><br></div><div>My question was rather simple. </div><div><br></div><div>Many cloud operators use Open Vswitch (OVS) based dataplanes wherein each packet results in a new flow in the system. The first packet does a lookup in the slow path which causes the fast path (either OVS-DPDK or a smartNIC or VPP-like paradigm or something entirely different) to be programmed. All subsequent packets hit the fast path and reach the VM (which is hosting the VNF). The advantage of this scheme is that the operator knows the exact flows existing in their data center and can run some sort of analytics on that. This obviously becomes harder once you start aggregating the flows or with mega flows, but you hopefully get the drift.</div><div><br></div><div>The other architecture is based on LPM and LEM lookups.</div><div><br></div><div>BTW, when i spoke about the Telco Cloud i had meant pure software based routing. NO hardware. No baremetals and physical network functions. I had pure VNFs in my mind,</div><div><br></div><div>I see that Mellanox (smartNIC) is also programmed using flows. Hence is it fair to say that most of the current telco cloud architectures are built around OVS style flow based network devices?</div><div><br></div><div>Glen</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
  ++ytti<br>
</blockquote></div></div>