Re: section 3.2.1/2 LFB outputs/inputs

"Joel M. Halpern" <[email protected]> Wed, 8 Nov 2006 15:52:11 -0500
Newsgroups gmane.ietf.forces
Message-ID <[email protected]>
If you can give me a bit more explanation of the hub-and-spoke case, 
I'll try to work it in.
And 3.2, with the better description of what LFBs are, is a good 
place to re-iterate that they are a descriptive construct, not an 
implementation construct.

Yours,
Joel

At 03:34 PM 11/8/2006, Jamal Hadi Salim wrote:
>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