Re: section 3.2.1/2 LFB outputs/inputs

On Wed, 2006-08-11 at 13:23 -0500, Joel M. Halpern wrote:
> I believe we need to have the redirector LFB.  Whether we have one 
> class that can do both meta-data based redirection and content based 
> redirection, or two (or three) classes is not a concern.  But we need 
> to have that ability.  I realize that using such an LFB means that 
> someone reading the graph can't tell where the packets will go 
> without the table in the redirector.  But there are way too many 
> cases where we need it.  (The simplest example is where one places a 
> DSCP on a packet early in the processing, but branches to different 
> queues much later in the processing.)

We need to have some redirection information modelling representation. 
I am uncertain that it needs to be an LFB. Regardless, my worry (based
on experience) is that this document will be used as religious scripture
(as it should be) where the danger is people making literal
translation. 
Somewhere it needs to be spelt out, strongly, that the redirection
activity could reside in the src LFB, a special LFB (of which a
redirector as described in this doc is one _example_) or in the
destination LFB. 

> I am happy to add brief descriptions of other ways of doing the 
> interconnection, although I had thought that the two extreme examples 
> covered things pretty well already.

The redirector doesnt cover the Hubnspokes approach i spoke of early.
In-fact it is a speacial case of the hub.

> As a separate matter, if we need to strengthen the wording elsewhere 
> about the fact that LFBs are abstractions and not implementations, I 
> am happy to do so.  Suggestions on how to strengthen the existing 
> wording would be appreciated.  This is a very important point, and I 
> think some folks have already missed it.

Perhaps section 3.2 right at the begining (and combined with 
http://www.mip4.org/issues/tracker/forces/issue98 )?


cheers,
jamal