Subject: Re: output port groups WAS(Re: Revised LFB input/output text

From: "Deleganes, Ellen M" <[email-masked]>
Date: Thu, 6 May 2004 08:47:13 -0700

My comments are embedded.

Regards,
Ellen Deleganes

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Wednesday, May 05, 2004 12:43 PM
To: [email-masked]
Subject: Re: output port groups WAS(Re: Revised LFB input/output text

On Wed, 2004-05-05 at 15:08, Yang, Lily L wrote:

> As i said earlier, the input text is allowing me to ignor or lave with
> grouping so i am fine with it. The only challeneg is in the output.
>
> <LY> Well, it is similar for the output -- you can use it or ignore
it.
> </LY>

'fraid not. You have three sample alternatives for input. You only have
one alternative for output.

<EMD> An output group can be decomposed into multiple singleton outputs
in an implementation. The output groups are a convenient modeling
concept to group logically similar outputs from a single LFB together.
An implementation could either describe the outputs using a group
notation or as individual outputs if it desires, I don't see why the FE
model disallows the multiple singleton output method.
</EMD>

> for one it is confusing. Ive asked for a sample of a legit example
with
> more than one group + exception and noone is responding on that
point;->
>
> <LY> Going from 2 to n isn't a quantum jump here, so constraining to a
> hard magic number like 2 instead of n just does not make much sense to
>  me. So I would argue if we allow 2, we should allow n.
> </LY>

<EMD> I can't think of a specific example offhand either, but someone
might. Setting an artificial limit when it doesn't simplify anything
doesn't make sense either if there is a possibility where someone might
need more than two groups.
</EMD>

Yeah, but it doesnt make sense to have more than two. Conclusion by
induction doesnt apply in all cases.
Ok, lets take a step back, i am claiming it doesnt even make sense to
have two ;-> Actualy even one step back further, I am claiming one you
dont need a group at all.
All, i am asking for is justification.

<EMD> Like I stated before, groups are a convenience, not a necessity. I
personally think that it is easier to see how a group (or groups) could
be broken up into the individual singletons, than combined into a group.
It becomes more difficult to tell what outputs make sense to group than
if it is spelled out by the model to begin with.
</EMD>

> I think too much genericity may be dangerous. Because LFB class Y and
> class X need it doesnt equate class Z need it.
> Refer to my email to Alan; this is probably solvable by defining the
> granularity levels.
>
> <LY> But remember we are defining a "general" FE model here that has
> enough flexibity built in to allow for future innovation.
> IF LFB class X and Y need something, then the model should *allow* it.
> By that, nobody is saying every LFB has to use it. It is up to the LFB
> designers to choose the right tool for the right job. But it is FE
> model's responsibility to provide a powerful enough tool kit for them.
>  If someone sees everything as a nail just because he's got a hammer
in
> his hand, that is his own problem, not the hammer provider's fault.
> </LY>
>

What worries me is not the hammer ;-> Its someone down the road asking
me how come i dont have a hammer when thats what the doc says;->
I have been bitten by loose syntax before.

<EMD> The model document is intended to allow flexibility in
implementations - this was one of the explicit requirements on the model
document. It is possible that no implementation will support all of the
flexibility and extensibility spelled out by the model document.
</EMD>

> >
> > The other contention point is the naming around "redirector".
> > [Yang, Lily L] Don't seem too contentious to me. I don't mind if you
> > have better name. I can live with demux if that makes you happier.
> > [/Yang, Lily L]
>
>
> Anything but redirector.
> <LY> I am sure you don't really mean it :-).
> Ok, I admit I've said something just like that in other occasions.
> Now you just make me realize this "election" mindset might be
dangerous
> all by itself :-)
> </LY>

I am actually quiet serious. Redirector in literature out there has very
specific semantics on network equipment.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 7 May 2004 09:40:58 -0400

> model disallows the multiple singleton output method.

[..]

> need more than two groups.

Ok, heres what you need to do so we can move on (I have about a million
other comments on the model draft. I am also eagerly awaiting a response
on the metadata from moons ago to be responded to).

1)I honestly dont think "redirector" is the right noun. If you insist
on using it, please explain the current common usage of the term and the
generalization of it. Probably something with the word "mux" in it would
be useful. I think another term that needs to be scrubbed/defined
is the "port" into/outof the LFB

2)If you insist on using "output groups" and "ports" (both of which i
dont like) then you need to strengthen your text in a big way.
I apologize for bringing this up again: As an example since you are
struggling to find an example for more than two port groups, you clearly
have no need for more than two - i would like to point out (again!) that
you dont need more than one, and that if you dont need more than one,
then you dont need the term "group". I should add, however, i am willing
to live with for a middle ground good text explaining these details.
Sorry, cant come up with non-biased text; so i will leave that to you
hoping you understand my view.

> flexibility and extensibility spelled out by the model document.

Its clearly not flexible enough if i am trying hard to fit myself within
it;-> I think the model is fine to capture all sorts of ideas, but the
basics must be right. The outputs and inputs are basic.[1]

cheers,
jamal

[1]Theres a lot of stuff i am throwing out or ignoring because the model
is trying to cover everything under the sun.
Example i wouldnt give a rats ass about inheritance of LFBs. I am sure
someone with a product or trying to get a phd thesis would disagree. I
am just being practical.