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