section 3.2.1/2 LFB outputs/inputs

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