Subject: Re: Revised LFB input/output text

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 20 Apr 2004 16:16:35 -0700

Hi, Jamal --

I promised that I will get back to you on the confusion over input/output group concept. If you have not done so, I would encourage you read over the new text Zsotl sent out. I hope that address the issues for you. If not, please let us know.

Thanks for your earlier comments. That really help the model team to dig deeper into the subject and come up with this new (and better, in my opinion) text. 

Lily

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Putzolu, David
> Sent: Tuesday, April 20, 2004 3:54 PM
> To: [email-masked]
> Subject: Re: Revised LFB input/output text
> 
> 
> Hi Zsolt.
> 
> This looks much better and makes sense to me now.
> 
> Minor nit: Should be ragged-right justification when
> it is actually added to the model draft.
> 
> Cheers,
> David
>  
> 
> > -----Original Message-----
> > From: Forwarding and Control Element Separation 
> > [mailto:[email-masked]] On Behalf Of Zsolt Haraszti
> > Sent: Wednesday, April 14, 2004 3:16 PM
> > To: [email-masked]
> > Subject: [FORCES] Revised LFB input/output text
> > 
> > After the dissemination of the last model draft in February
> > (draft-ietf-forces-model-02.txt), we got many very useful
> > comments.  Thanks.  One topic that generated lots of questions
> > was the concept of LFB inputs and outputs.  It became obvious
> > to us that in 02 we did not do a good job explaining the proposed
> > LFB input/output model.
> > 
> > Attached is a fully revised version of the relevant subsections
> > of 02 (3.2.1 and 3.2.2).  Hopefully this text conveys the design
> > intent much better.
> > 
> > Comments are welcome!
> > 
> > --
> > Zsolt Haraszti, Ph.D.                              Tel: +1 
> > 919 472 9949
> > Ericsson IP Infrastructure                         Fax: +1 
> > 919 472 9999
> > Raleigh NC USA                       Email: 
> > [email-masked]
> > 
> > 
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 27 Apr 2004 09:37:33 -0400

Lily, Zsolt,

On Tue, 2004-04-20 at 19:16, Yang, Lily L wrote:
> Hi, Jamal --
>
> I promised that I will get back to you on the confusion over
> input/output group concept. If you have not done so, I would
> encourage you read over the new text Zsotl sent out. I hope
> that address the issues for you. If not, please let us know.
>

Where is the text on the metadata? ;->
I finaly got to reading this. To be honest, i wouldnt say i am thrilled
although i would say there is an improvement. As an example, the input
grouping(section 3.2.2. LFB Inputs) with the three alternatives offered
is a good approach because it doesnt lean on one thing only and rather
points the alternative. The danger with model drafts is that people
with weak minds (who may take the shape of customers) will end up taking
them literally in 3 years after publication.
Iam trying hard to make it fit my mental view of things. Maybe i should
explain my view of the world then lets see if theres a middle ground
view which doesnt leave it out.
So in my world (as the expedia commercial starts) there are no input or
output groups.
Let me throw in a diagram to clarify.

      +--------------+       +------------------+
      | LFB X        +---+   |                  |      +--------------+
      +--------------+   |   |                  |  +-->| LFB A        |
                         |   |                  |  |   +--------------+
      .... ... . ... .. .|                      |  |
                         +-->|input     LFB     |  |
      . ..   .  ... ... .^   |                  +->+----->
Default/exception
                         |   |                  |  |
      +--------------+   |   |                  |  .
      | LFB Z        |---+   |                  |  .
      +--------------+       +------------------+  +----------> LFB D

1) There is only one input. This is at least taken care of by the
section 3.2.2 example (a) so i am not gonna whine about it.
2) There may be multiple edges (emanating from other LFBs or nodes)
that may lead to this input
3) There may be several branches of execution within an LFB
4) Input data or metadata decides on the processing within
an LFB path taken.
5) There may be multiple output paths from an LFB
6) Processing results which may consult state decide on the output
edge/branch to take.
7) metadata may be encoded as a result of #6 above in order to
influence nexthop LFB processing (as described in #4 above)

On the nature of the output branching:
There is no restriction on where those branches go. They may loop back
to self.

Now lets take the four examples listed.o
   +---------------+               +-----------------+
   |               |               |                 |
   |               |               |             OUT +-->
  ...          OUT +-->           ...                |
   |               |               |    EXCEPTIONOUT +-->
   |               |               |                 |
   +---------------+               +-----------------+

     a. One output               b. Two distinct outputs

I see no difference between the two. One has two branches and the otehr
has one.

   +---------------+               +-----------------+
   |               |               |    EXCEPTIONOUT +-->
   |         OUT:1 +-->            |                 |
  ...        OUT:2 +-->           ...          OUT:1 +-->
   |         ...   +...            |           OUT:2 +-->
   |         OUT:n +-->            |           ...   +...
   +---------------+               |           OUT:n +-->
                                   +-----------------+

  c. One output group       d. One output and one output group

Again i see no difference of these from the general model above.
The contendig issue seems to be that in c. and d. you can keep adding
these
output branches to the LFB instance. Sure, depending on the capability
of the LFB thats just fine; you should be able to edit its
runtime properties and add more branches.

I have to run to work, hopefully that gets my concerns across.

cheers,
jamal