Subject: Re: Revised LFB input/output text

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

Jamal --
The key difference I see in your view and the view described in the model document is regarding the output branching -- everything else you said seem in sync with the model we have in mind.
In your description:
> 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)
I understand that the branching is driven by the "metadata". But we need to explicitly model that behavior somewhere in this graph. 
And the picture you drew shows that one output from LFB can branch into several different LFB for next step of processing. It is not clear to me where/how the "metadata driven branching" is modeled. 
That kind of branching is prohibited explicitly in our current model with a good reason:
"A single LFB output can be connected to only one LFB  input.  This  is
required  to  make  the  packet  flow   through   the   LFB   topology
unambiguous."

A simple way to model that behavior would be inserting a "redirector" LFB between the output branch and the multiple next step LFBs. The "redirector" LFB has one input and multiple output, and the only processing it does is to send packets to different output according to the metadata. 

So all in all, what you want is indeed provided by the current model -- as long as you explictly model them.

Another thing you said which I don't quite agree is that you don't see any difference in example a) and b). If the LFB to be modeled tend to process the packets and sort them into two different categories -- then we should model them explicitly within the LFB and the multiple outputs enable just that -- the semantic difference between the two outputs.

Granted, just because we provide all these mechanisms/alternatives, it doesn't mean every LFB designer has to use it for every LFB. I tend to think of what FE model provides as what C language provides. You can choose to use array, struct to make your program more readable, more elegant. But you can also choose ignore all that, just use simple scalar variables to do everything -- it is probably still doable, theoretically. But there are times when you realize it definetely makes big difference if you use the right constructs.

Lily
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Jamal Hadi Salim
> Sent: Tuesday, April 27, 2004 6:38 AM
> To: [email-masked]
> Subject: Re: Revised LFB input/output text
> 
> 
> 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
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 27 Apr 2004 22:12:57 -0400

On Tue, 2004-04-27 at 18:40, Yang, Lily L wrote:
> Jamal --
> The key difference I see in your view and the view described in the model
> document is regarding the output branching -- everything else you said seem
> in sync with the model we have in mind.

The input has several choices of which what i have in minds fits in one
of three posibilities.
So that part is fine.

> I understand that the branching is driven by the "metadata".

There are several "branchings"
a) to the "processing" within an LFB
b) to the output post processing.

#a maybe be influenced by metadata and existing state.
Seems like you refer to #b which is not driven by metadata.

>  But we need
> to explicitly model that behavior somewhere in this graph.
> And the picture you drew shows that one output from LFB can branch into
> several different LFB for next step of processing. It is not clear to me
> where/how the "metadata driven branching" is modeled.

I think you are refering to #b above - i dont see any metadata driven
branching either.

> required  to  make  the  packet  flow   through   the   LFB   topology

An output can only connect to one input. The diagram may have been
misleading. The text desription in #5 is very explicit.
I think we may have deviated a little because of that confusion; so dont
bother responding to above text. Let me redraw the representation to be:

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

> A simple way to model that behavior would be inserting a "redirector" LFB
> between the output branch and the multiple next step LFBs. The "redirector"
> LFB has one input and multiple output, and the only processing

> it does is to send packets to different output according to the metadata.

No, let me stop here since the assumption for everything you said is
based on a single output that may go to multiple LFBs.

>Another thing you said which I don't quite agree is that you don't see
>any difference in example a) and b). If the LFB to be modeled tend to
>process the packets and sort them into two different categories -- then
>we should model them explicitly within the LFB and the multiple
>outputs enable just that -- the semantic difference between the two
>outputs.
>
>Granted, just because we provide all these mechanisms/alternatives, it
>doesn't mean every LFB designer has to use it for every LFB. I tend to
>think of what FE model provides as what C language provides. You can
>choose to use array, struct to make your program more readable, more
>elegant. But you can also choose ignore all that, just use simple
>scalar variables to do everything -- it is probably still doable,
>theoretically. But there are times when you realize it definetely makes
>big difference if you use the right constructs.

My main problem is i see no need for output groups at all. Every edge of
"output group"  is infact a branch decision - by definition there could
be one or multiple branches. Of course you can give them labels and a
namespace to make them look pretty in a diagram; however, grouping them
has semantical connotations. To be precise, the outputs can be described
as in a simplistic C like description (since you brought that up;->):

a) can be described as:

result = process_packet();
send(output0);

b)
result = process_packet();
if (result = xxx)
   send(output0);
else /* default */
   send(EXCEPTIONOUT);

You can apply the same concept to c) and d). Theres no difference
between any of a), b), c) or d).

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 28 Apr 2004 09:51:41 -0400

It is true that output groups are not "necessary".
We could simply declare that an LFB simply has outputs numbered 1 to
n.  (Where for some LFBs n is fixed and for some LFBs n is variable.)

There are two related motivations that have prompted us to create the
concept of output group.
Firstly, there are semantics associated with the way LFBs will use certain
output ports.  As such, it is helpful to identify the semantics.  This
means that in the description one can say that certain packets go to the
"error" port.  It also means that the CE can understand explicitly that it
is connecting following LFBs to the error output vs a normal output.  (In
particular, this makes it easier for a human being to follow what the CE
has done when she needs to diagnose what is going wrong.)  These means that
we want some named outputs.
Secondly, when ports have related semantics it is helpful to have the
ability to group them together.  So a branching classifier can have a table
which gives the index of the output to be used for a packet which matches a
specific table entry.  This leads to wanting ports with specific semantics
and indexing.

I hope that clarifies things a bit further.
Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 28 Apr 2004 23:36:23 -0400

On Wed, 2004-04-28 at 09:51, Joel M. Halpern wrote:
> has done when she needs to diagnose what is going wrong.)

The semantics from the way you describe them imply an embedded decision
process of some form to select 1 of n outputs.
Why is for example an error port so speacial?

> These means that we want some named outputs.

No problem with this. Tagging a certain port/branch as an error port is
fine.

> ability to group them together.

why? Explaining this may help me sync.

>   So a branching classifier can have a table

sure, but why would grouping help in any of this?

> I hope that clarifies things a bit further.

Knowing you, I am sure you are saying something clever that i am still
not getting. HEres my take:
1) there are 0..n-1 possible outputs. This part is fine to be modeled as
a group or array etc. It is also fine to associate names to those
branches.
The CE can decide at policy install time the decision making process
on selecting the output branching. At runtime when possible one can also
redefine the decision making process as well (adding or removing to from
those possible outputs)
2) A decision part selects from 0..n-1 outputs to use ( i was trying to
demonstrate that in pseudo code). Somehow this is encompassed in your
description but only implictly.

its #2 that iam running into issues with. In my looking at this picture
from perspective of #2 i see #1 as 0..n-1 branches and dont see the
motivation to have a group of branches.

Again

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 28 Apr 2004 23:42:07 -0400

BTW,
Just so we are on the same page, the box i drew is a representation of
an _instance_  of a LFB class.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 Apr 2004 10:24:39 -0400

Let me try to separate issues a little.

One aspect is how does an LFB class definition describe the decision
process (and parameters) used by an instance of that class to choose which
output to send a packet to.   The current approach envisioned (and probably
not well described) in the model is taht the processing logic of an LFB
Class is described informally.  We are not expecting to define a
pseudo-language for LFB processing logic.  Rather we expect to use english
descriptions.  This does imply that the writers of CEs will need to build
into the CE understanding of the relevant behavior of any LFB class it
needs to work with.  We are not providing any noticeable assistance for the
CE understanding teh semantics of an LFB class.
The textual description for an LFB class might say that the LFB validates
the IP header, and anything that fails the check is sent to the error
output singleton.  Anything that passes the check has its meta-data
examined and branches by examining a dispatch table indexed by the
"service-class" meta-data element and giving the output index in the
normal-output port group.
Another LFB class definition might indicate that the LFB examines only the
MAC protocol, and sends packets to the IS-IS, IPv4, IPv6, MPLS, and error
outputs.  (You might prefer a table driven LFB, but that is a different
debate.)  For this later class, the CE gives orders connecting the
different outputs to the kinds of processing specific to that packet
type.  There is much less of an issue with consistency between the logic of
the LFB instance, the connectivity created by the LFB, and the programming
provided by the human & policy machinery.

What we are trying to do is make it easier for the CE, FE, and human to
understand the semantics of the interfaces to the LFB class.  If we only
allowed one variable-count port group in an LFB class definition, then the
naming of Singleton ports and output groups could be looked at as simply an
aliasing for the 1..n outputs of the LFB class.  Such aliasing makes
understanding easier.
When we started down taht path, we noticed that in some circumstances more
than one semantic classes might have a variable number of outputs.  For
that case, named port groups is actually noticeably more flexible than just
aliasing the ports.  To elaborate, if I have OG1 which can have up to 10
outputs and OG2 which can have up to 10 outputs, but the LFB can have only
10 total outputs, there is no way to assign OG1 and OG2 as aliases against
ports 1-10 such that I can grow OG1 or OG2 as I need to as services are
added to the instance.  With the port groups I can easily describe what I
am doing.  I can achieve the same affect by just explicitly managing the
direct outputs, and keeping track of how I am using each 1 (a careful
examination of the configuration tables would probably allow a human to
determine which ports are being treated with semantic 1 and which ports are
being treated with semantic 2.)
Now, I will readily admit that most cases I can craft right now that use
two variable output groups can easily be done with two cascaded
branchers.  And may be better done that way.  But I am reluctant to declare
that there can only be one variable sized output group just because I have
insufficient foresight.

Yours,
Joel