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

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 5 May 2004 12:08:49 -0700

see below <LY>...</LY>

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

Hi Lily,

On Wed, 2004-05-05 at 12:41, Yang, Lily L wrote:

>
> I can live with them as well. I see logically not more than two groups
> if you insist on grouping. Otherwise we need to explain why we need
> more. There was something about XML connotations needing it.
> Again, to reitarate my position i dont see why you need groups.
>
> [Yang, Lily L] Let me try one more time:
> 1) We don't live or die for "group". In another word, with or without,
> we can still make it work.
> 2) But, IMHO, the concept of "group" allows better delineation of the
> semantics in input/output.

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>

> Take the example of one LFB with one
> "exception-output" and n "normal-output". Yes, you can represent that as
> output 0, 1, ... n (that is, just one group). But with this construct,
> you lose the semantic difference of output 0 from 1 to n. With the
> concept of grouping 1 to n together, you retain that semantic meaning in
> the construct itself.

I am not sure i agree theres any semantic loss, but i can live
with that because it doesnt make a difference for me.
So, ok -  two groups.

> 3) What do we lose without "group"? I've shown that in 2). Now what do
> we lose with "group"? Does "group" impose more complexity for LFB
> designers? Absolutely not. Yes, it means one more concept to wrestle
> with in the model document, but if it is useful, then it is worthwhile.
> Besides, we are wrestling with it already :-)

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>

> 4) No, the point about XML is misunderstood here. I think we all agree
> that we need to allow multiple outputs for some LFB so that they can
> fork. One argument is to allow it only for special LFBs like redirector.
> If we take that approach, it means the XML schema would not be the same
> for every LFB. That doesn't seem like a good design, and so the model
> team is more in favor of the generic schema that allows multiple output
> (including groups) for any LFB, as long as it makes sens.
> [/Yang, Lily L]
>

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>

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

> Both the above seem to me to be overzelous future-proofing design. Ok,
> there i said it.
>
> [Yang, Lily L] Depends on the price you pay for that future-proofing. If
> it is cheap, why not? I think that is the case here.
> [/Yang, Lily L]
>

Confusion is not cheap friend ;->
<LY> Shhh, isn't that our trick for job security for us engineers ;-)
</LY>

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 May 2004 15:42:33 -0400

> <LY> Well, it is similar for the output -- you can use it or ignore it.

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

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

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.

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

> 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