Re: section 3.2.1/2 LFB outputs/inputs

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.)

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.

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.

Yours,
Joel

At 01:06 PM 11/8/2006, Jamal Hadi Salim wrote:

>I am not adding this to the tracker yet. Will do when we discuss and
>reach some consensus.
>
>I havent looked at this text for a while - but last i looked at it i had
>some strong reservations with its use. It still left the same after
>taste in my mouth this time as well.
>
>I am making the strong assumption that this text will be used by many an
>implementer to provide the information model or spec[1]. It has been
>argued in the past that the information model is merely meant as a
>guideline - so was RFC2401 and to this date i am met with many
>arguements of "but thats what the RFC said". So that arguement is not
>strong.
>Enough of that rant, heres where i am coming from:
>
>Inputs and outputs are good to have because they provide for a
>consistent way to info-model the graphing - so no argument there. The
>text however, still has some strong subliminal implementation
>suggestions of the existence of a redirector LFB (suggested on page 15
>and other places) whose purpose merely is to bridge different LFBs. This
>is where i have argued in the past, it borders on implementation
>details. As an example, I could interconnect
>LFBs in a star topology with a specialized LFB doing the routing.
>I have seen many a ASIC with this approach. I am certain there are other
>ways which i havent come across.
>
>If:
>  a) i) we got rid of the redirector LFB as a necessary component
>   or
>    ii) add the other ways of doing it such as the hubnspoke scheme i
>just described above and perhaps others.
>  b) we add some strong language to mean all this is not necessarily the
>way to implement.
>
>Then my concern will go down.
>
>Thoughts?
>
>cheers,
>jamal
>
>[1] Infact section 4 para 2 states: ".. the model will serve as an
>       important reference for the design and development of the CEs
>       (software) and FEs (mostly the software part).  It will also serve
>       as a design input when specifying the ForCES protocol elements for
>       CE-FE communication."