Subject: [forces] On generic KEYS

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 2 Feb 2014 06:06:15 -0500

Folks,

We are in the process of implementing a control app and have run into
a "bottleneck".

To illustrate the challenge at stake, lets consider a switch/bridge fdb table.
In the simple case, such a table will have 3 columns {MAC, VLANid, port}
where port is the egress point to forward a packet with a matching
MAC + VLANid.
Such a table on the datapath is looked up by MAC + optional VLANid.
The LFB fdb table reference is therefore specified to have a key of
{MAC, VLANid}.
ForCES allows me to reference table rows by table index, range or key.
The table index or range of indices is meaningful for north-south
(control-datapath) transactions and the key selection is meaningful in
both east-west (datapath) and north-south.

Consider the scenario where i have multiple bridges/switches on an FE.
One i am interested in ("br0") has 100K active fdb entries. Say about 20%
(thats 20K) point to a port "eth0" - and I want to delete all of those specific
entries.
I would need a large amount of data on the wire to request for those 20K
entries to be deleted.
I could go and specify an extra key that is meaningful only from north-south
for this specific LFB but that in itself does not solve the general problem.

In our implementation, we are considering using a generic "key" that is
meaningful in the north-south direction. This key will have arbitrary
fields representing columns present on the specified table. From my example
above, the key contents could have one or more of {MAC, VLANid, port}
components.
My problem above is resolved by expressing a {port} with value of "eth0".
In order not to introduce any new constructs, I would like to propose
that we allow for KEY with id of 0 to represent such content.
IOW, the keyid of 0 becomes reserved for such a purpose.

Such a change is small and timely because we are still in the process of
pushing protocol and model extensions.

Thoughts?

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Sun, 02 Feb 2014 09:02:14 -0500

While that is a small change from a protocol perspective, and very 
effective from the controller perspective, it places significant 
requirements on the FE.  It has to be prepared to search the tables for 
any field combination.  This is exactly the opposite of the intended 
distribution of intelligence.

This is not an operation that has to take place quickly, since simply 
disabling eth0 will take care of the problem in this simple case.  In 
more complex cases, I admit there may be challenges.

I would note that rotuers do not expect their line cards to be able to 
perform these kinds of matches.

Yours,
Joel

On 2/2/14, 6:06 AM, Jamal Hadi Salim wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 2 Feb 2014 09:33:06 -0500

I  worried about the message getting lost via the one sample;->
So assume the "complex case" you alluded to as a generic reason.
Assume also we discover what the capability of a specific FE is and from
a control plane view we get to choose what gets sent to the FE in terms
of the request.

On Sun, Feb 2, 2014 at 9:02 AM, Joel <[email-masked]> wrote:
> While that is a small change from a protocol perspective, and very effective
> from the controller perspective, it places significant requirements on the
> FE.  It has to be prepared to search the tables for any field combination.
> This is exactly the opposite of the intended distribution of intelligence.
>

I am not expecting every FE to be able to handle this and we have ways
to do with capabilities of FEs. But for those FEs that are capable, i would
hope we can enable  them. Example:
one could make the query to the Linux kernel with extra filters on a variety of
LFBs. ForCES should be  able to take advantage of that (instead
of sending many queries and doing more filtering computation on the CE).

> This is not an operation that has to take place quickly,

No Joel - thats absolutely not the case for what i am trying to do
but i worry i am going to digress.
I dont want eth0 to go down and i want this done quickly.
Just ignore this example and focus on the generic case.

> since simply
> disabling eth0 will take care of the problem in this simple case.  In more
> complex cases, I admit there may be challenges.

I am more interested in the complex cases. I dont want to go on the distraction
of the example anymore.

> perform these kinds of matches.

And i dont expect classical/legacy devices to be able to do this.

Side/tangent note:
I should point out that even within software FEs these sort of lessons seem to
come as an after-thought. As example, in Linux theres a lot of filtering
that occurs in user space after the kernel has provided information.
Over the years hacks are being added (eg in some case you can download
a little bpf program to the kernel to filter out certain types of
responses because
the interfaces were wrong to begin with and the API is already in the wild).