Subject: Re: LFB topology reconfguration

From: "Putzolu, David" <[email-masked]>
Date: Fri, 7 Nov 2003 17:12:45 -0800

[chair hat still off]
Jamal Hadi Salim wrote>
> A simple rearrangement of such as a service could be to temporarily
> add a mirroring LFB instance for debug or other reasons and then
> removing it later. This does not require bringing down anything.

Hi Jamal.

I agree that adding a new LFB instance is one way of doing this.
That is not the only way to do this however.  Since you mention 
software kernel modules, let's use Linux as an example: as far as
I know,  the Linux kernel has a very specific, fixed set of places
where one can mirror packets (using the QUEUE target I believe) - 
here's a simplified drawing I found of it:
http://iptables-tutorial.frozentux.net/images/tables_traverse.jpg

The ability to mirror packets is always latently present
at those specific places in the Linux kernel's packet processing
code.  One could imagine an FE based on Linux would contain a LFB 
graph very much like what that image shows (although there would
be a lot more LFBs since a lot more packet processing is done in
the Linux kernel).

In order to turn on mirroring, one would add the appropriate rule
with a QUEUE target to the appropriate chain (i.e. add the 
appropriate entry to some table in an LFB).  This doesn't require
instantiating new LFBs or reconnecting them - this is merely adding 
a rule to LFBs that already appear in the graph pictured.

Under the covers, the Linux kernel might actually load (or
unload) a kernel module based on what rules are in force at
a particular time.  However, what happens under the covers
seems to me like it should not be the ken of forces, because
FEs are likely to vary widely.

Apologies to those less familiar with Linux - hopefully the
combination of the picture and the text here is enough to
make the point clear.

> I think theres a mental block which results from a COPS mindset
> that is affecting how people are thinking about this.
> For simplicty sake assume that the LFBs already exist ...

I am not a COPS person myself, having never worked on that
specification or implementations of it.  You are probably 
thinking of another David :)

Cheers,
David

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 7 Nov 2003 21:03:44 -0800

> http://iptables-tutorial.frozentux.net/images/tables_traverse.jpg

Actually thats a bad example to relate to Forces.
A better one maybe (no diagrams) is:
http://www.cyberus.ca/~hadi/patches/action/README

jump to " cut here" to see a sample policy that adds new
LFB instances.
That documentation is slightly dated

[..]

> a rule to LFBs that already appear in the graph pictured.

So the sample i pointed to for example could have a s/add/replace
to get a new Mirroring LFB instance in its path. " replace"  could be
considered an atomic del/add.

> FEs are likely to vary widely.

Theoretically you could compile a kernel that does LFB mirroring
somewhere, download it to the FE; have the FE announce a new capability to
the CE and use a replace policy from the CE to instantiate a instance of
it in an existing topology. This (downloading) is outside the
scope of forces though.
The dynamic loading you describe would happen if the CE is already
knowledgeable about LFB capability.
And btw to the skeptics, this is doable on NPs, FPGAs etc.
Just pay me enough $ and i can show you how;->

Maybe i should tune my presentation to explain this stuff but i only
have 15 minutes.

> thinking of another David :)

Apologies, yes i did ;-> I guess i saw too many " nextlfb"  emails
and you happened to show at the right^Wwrong time.

cheers,
jamal