Subject: LFB link and aliases

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 16 Sep 2005 16:32:49 -0400

Joel,

I promised i was going to send something on events but here's something
that popped off some brain cells right now (and has been bothering me
for some time now):

While thinking of the "port" aka "network device" LFB connectivity, i
found an interesting issue.

Two schemes are possible to represent/model the ports or any other LFB.

1) Group all of a FE's "netdevices" into one instance (for ease of
implementation). A single table in that instance which houses all the
netdevice description. A path to the table.index gets details.
This is what i showed in my slides at the last meeting. It is my
favorite and we have infact implemented this.

2) Create an instance per "netdevice". No table - all the descriptions
for a single "netdevice" are in that instance. A little abuse of the
instance ID space, memory and CPU - but valid nonetheless.

While "netdevice" is a bad example for the use of #2, there are/maybe
other LFBs where this will make more sense.
 
However, looking at the FEobject and LFBTopology and in particular to
the LFBLink one notices that links are mapped to LFBselectors. This
means that only #2 will fit in well. 
This struck me as i was looking at "netdevices" links to a parent or
children netdevices and corelatting with how we have done things. It is
clear that packets may flow from a child netdevice to a parent netdevice
(or vice versa) as i showed in the meeting. And so while #1 is valid, it
makes it hard to fit it into the LFBTopology.

So where am i going with this?
I would like to suggest a change to the LFBLink to optionaly have a path
in addition to an LFBSelector. Then we can easily fit model #1 in the
topology. Which actually interestingly enough means that an alias
construct as we have defined it now is infact an LFBlink (if we redifine
it) - which makes sense.

Thoughts?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Sep 2005 21:14:33 -0400

I don't think the change you have described works.
I believe that the LFB Link (the topology) really needs to avoid getting 
entangled in the inside semantics of the LFBs.

yes, LFBs can be defined to have one "instance" or to have a table of 
instances.
For LFBs which have a table of instances, there has to be some way that 
incoming packets are associated with entries in the table.  In general, 
that is up to the LFB designer.  There are two common ways.
Some LFBs will select table entries based on the incoming port.  This can 
be supported.  It does not simplify the topology much.
Some LFBs will select table entries based on meta-data associated with the 
packets.  This clearly compresses the topology.  And such mapping does not 
belong in the LFB Link table.

Personally, I would recommend that one not use an LFB with a table of 
information if the selector is the incoming port index.  Given that one can 
merge the outgoing links from several such LFB instances, it is probably 
simpler to model them separately.

On the other hand, if it is meta-data driven one must use a table 
structure.  For example, the example LFB uses meta-data for demuxing 
traffic aimed at different circuits and laser channels.

Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 17 Sep 2005 08:10:54 -0400

> yes, LFBs can be defined to have one "instance" or to have a table of 

Actually come to think of it - we have had this discussion a few
times ;-> and for some reason, whenever i try to derive from first
principles i always come to this hump - so bear with me.

I think our main differences is you looked at it from the datapath
perspective and i kept thinking of it from a protocol/control
perspective.

Lets take the second example of LFB of netdevices as i described...
i.e there is a table which groups netdevices within one LFB class for
that FE. If it is modelled as a table of netdevices, it follows that an
instance (as in that part of the LFB selector) implies a derivation of
the class that has this table. So only one such instance is needed for
the class on the FE.
In other words:
- To configure any of the netdevices (protocol level) i need to specify
the path to LFBclass.instance.table.index address.

Would you agree?

Yes, from a datapath and packet traversal, the functional blocks that
processes the packets  would be "sown" together using either of the 
schemes that you specified (metadata etc). And as you indicate: it is
upto whoever put together that FE to define it. i.e it doesnt matter
from a protocol perspective.

Are we still in agreement upto this point?

So this leads next to the FE objects Topology map - If i was to show a
link to/from a netdevice (as modelled the way i described it) to another
LFB instance (or another instance of the same netdevice LFB), what would
i show the LFBLink part to be? Is it not the
LFBclass.instance.table.index, which is really the address the protocol
uses to configure the netdevice? There are other LFB instances whose
address is sufficiently described as LFBclass.instance. 
I currently use aliases to have netdevices point to their children or
parent - however, I made the posting because i realized that this is not
only related to the LFB i am currently worried but rather all LFBs that
will be similarly modeled. 

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 17 Sep 2005 10:32:15 -0400

All of the statements you make to confirm the starting point are accurate 
and agreed, but I think the difference is in a subtlety of semantics.
Given an LFB class with a table of net-devices and an LFB instance of that 
class, when you want to configure a single net-device, you send a SET 
Request whose LFB instance target is that LFB instance.  The path within 
the SET request will select the table of net-devices and the net-device 
table entry, and the fields of that netdevice entry you want to manipulate.
The LFB Link topology information in the FE will only tell you which LFB 
instances are interconnected by that link.  It will not tell you which 
table entry within the LFB instance is using that link.

Clearly, when the table entry is selected by meta-data, the LFB Link 
topology information can not refer to it, since it is not topological.
We could augment the topology information for the case where the selection 
is on the basis of incoming port.  But...
a) I consider that a complication that doesn't add anything, since that 
knowledge has to be in the LFB instance anyway.
b) I would recommend that such mapping be represented by defining the LFB 
Class to hold a single instance  While this will result in more LFB 
instances, it will result in both clearer LFB behavior and clearer topology.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 18 Sep 2005 09:40:21 -0400

> table entry within the LFB instance is using that link.

It is true that from a puristic/literal approach, the topology is
basically assuming a model that has LFBSelectors as links. 
My brain block (and again because i brought this same issue before,
please bear with me) comes from the desire to be able to stare at the
LFB Topology and be able to tell at least the details of the functional
processing blocks. Isnt this why we have that Topological detail?
The way i read it now is almost like there is an enforcement for a
purely detailed topological modelling - which i thought we said was not
practical.

What would be nice to see is:
"the packet coming in via physical port 0 will be sent to L2 LFB
instance 1 which may then send it to one of {PPPOE, SIT} netdevices
which leads to the L3 LFB instance 1 followed by {PPPOE, SIT} egress
processing that then may branch to any of physical ports 5, 6, 7".

which is better eye candy than describing it as:

"the packet coming in instance 1 of netdevice LFB will be sent to L2 LFB
instance 1 then to netdevice instance 1 which leads to the L3 LFB which
then leads to netdevice instance 1"

The L2/3 details are sufficient for me to get the details. The netdevice
aspect though is too vague in the second description. 

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Sep 2005 18:42:30 -0400

The LFB Topology is necessary so that the FE can pass the packets from one 
LFB to another.
When topology based multiplexing is used it also tells you what the 
functional path is.  When meta-data based muxing is used the topology does 
not tell you much about the functional path.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 19 Sep 2005 08:24:32 -0400

> not tell you much about the functional path.

Ok - fine; in any case, the details of the LFB topology are optional.

My suggestion:
I know that if you take the literal transalation of "LFB Topology" it
means just that. But in the case where purely topological model is taken
for all the LFBs then it reduces to a functional topology. Can we have
some text in the model draft to say that the two may not mean the same
thing?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Sep 2005 10:08:29 -0400

This sounds like a good clarification.
Could you open an issue so that when I get the source I can make sure I do 
this?
Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 19 Sep 2005 11:39:27 -0400

> Could you open an issue so that when I get the source I can make sure I do 

Issue #60 opened.

cheers,
jamal