Subject: Re: Revised LFB input/output text

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 2 May 2004 14:20:49 -0400

On Thu, 2004-04-29 at 10:24, Joel M. Halpern wrote:
> 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.

Yes, but to have sensible english or any other natural language, you
need to remove ambiguities or be all encompassing. I used the pseudo-C
to make such a point. I also happen to know that many people follow
model documents in their implementations almost as if they were design
documents ready to be whipped into code.

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

The example i gave shows the result of the processing making the call on
the path taken. I indicated that consulting "arriving" metadata is part
of the processing phase. You seem to be indicating the metadata,
probably encoded in a previous LFB instance, is used to make
post-processing path decision. I think we are saying the same thing from
a mile view, the granularity may be different. To me its like you have
two LFBs in one.
I still dont see why you need a "port output group" with this example.
Its almost like i view your port group as something which is a next
stage LFB (relative to one being described). And even then probably the
last LFB in a chain. Its main task being that faced with multiple output
choices, of probably physical interfaces or channels, it has to make a
decision which one of those to send to based on metadata it received on
input (not output). I would call such a thing a output
selector/muxer/demuxer/redirector LFB. While making sense in the context
of an LFB topology doesnt always when enforced within a LFB instance.

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

One of those outputs only, correct?
This is a better example for a group definition, but i feel still
stretching it.
you mention the error output a few times now; and thats the only other
branch that seems to be standing out in the generic case, everything
else fits in one group;
in other words, I think that all LFBs will have an error/exception
output, but semantic sugar for what that path means applies only to that
class of LFB. i.e I see it as default path - which makes sense for what
that specific LFB does.
Same sample space: Its no different in my opinion than having a routes
with a default gateway; or firewall policies with a default accept/drop
rule.

Are you saying the exception path is so common that you needed to define
it?

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

i think the above was a good example, but still falls short on
justification.

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

How many groups of these outputs do you see? I only see one + the
default path which i am willing to say is a separate group. You seem to
be saying theres more.

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

the naming part i agree with absolutely; the grouping is something i am
tagging along with just to settle this. The main challenge was whether
the decision to select a path was somehow assumed in your english
description. Now i am finding myself even questioning the grouping.

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

I may be halfway to understanding you then. In which case, the draft may
be a little lean on describing things. Like i said earlier, in my
analysis i dont see much more than one group and within a group infact a
default branch if the LFB semantic needed such a branch. Like you i am
not gonna claim sufficient foresight to say this will cover everything.
I am also finding myself now struggling to justify the port groups.

cheers,
jamal

---

From: Alan DeKok <[email-masked]>
Date: Mon, 3 May 2004 14:35:40 -0400

> a mile view, the granularity may be different. To me its like you have

   Almost.  The issue is one which has been debated within the ForCES
model group.  If we have permit only the "redirector" LFB to redirect an
input to one or more of N outputs, then many, many, other LFB's will
almost always be followed by a redirector.  Further, the XML
descriptions of the LFB's become more complex, as the redirector now has
properties (multiple outputs) which no other LFB shares.

   By placing some redirection ability within each LFB, the schema
becomes more consistent, and many models of implementations become more
obvious to the implementors.  So in this case, an "IP validation LFB"
can have two outputs: good packets, and bad packets.

   The benefit of having two outputs here is that the "metadata" which
chooses between the two outputs is internal to the LFB.  If we were to
require a redirector to make this decision, that metadata MUST be
external to the LFB, which means that the ForCES model needs to describe
it.  By keeping it in the LFB, it becomes "implementation defined".  So
long as the external behavior is consistent across implementations, it
doesn't matter how that metadata is represented.

   These concepts should be clarified in the model draft.

> of an LFB topology doesnt always when enforced within a LFB instance.

   I understand, and I generally agree with you.  It may make sense for
the model document to describe these issues, and to explain via diagrams
and examples how the current choice is imperfect, but solves some
problems that would otherwise be awkward.

> I am also finding myself now struggling to justify the port groups.

   They hide implementation choices which would otherwise have to be
included explicitly in the model.  By hiding them in the LFB's, we can
simplify both the model, and the implementation.

   Alan DeKok.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 3 May 2004 22:39:39 -0400

On Mon, 2004-05-03 at 14:35, Alan DeKok wrote:
> > To me its like you have
> almost always be followed by a redirector.

It is true there will be one of n outputs that an LFB instance will end
up going to. Why you need a redirector for each case, i dont fully see.
Ok, maybe the root issue is this "redirector" thing. I see the task of a
redirector to be infact a stealer of packets. It takes a packet and
redirects it to some hole - be it a port/channel/software device etc.
Essentially, the topology of LFBs terminates once it hits a redirector
at least in the local scope of its execution path.
If you were to look at it the way i just described it, then a redirector
is not needed for each LFB. It does seem like the model draft also
defines a redirector as something that interconnets LFB instances. A
better name for something like this is a "brancher". No pun intended.

>  Further, the XML

The XML thing is new - is having a output port group useful to the XML
definition or makes it easier to describe?

> can have two outputs: good packets, and bad packets.

Again i have no problem with the two outputs or n outputs for that
matter.

> doesn't matter how that metadata is represented.

In my view i see the folowing as the internal path:
- packet comes into LFB instance
- process packet by probably consulting metadata if need to.
- select output based on processing result.

you seem to say (and i have heard Joe say this as well i think):
- packet comes into LFB instance
- process packet
- consult metadata to select output.

Could this be another of deviating view points?

[..]

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 4 May 2004 07:47:48 -0400

In my view, both of those are internal operations of the LFB.  If an LFB is
going to select an output based on its input meta-data (or select an output
and attach an associated meta-data, or attach meta-data and send the
p[acket to the associated output, or any order you like) that is internal
processing of the LFB and needs to be described clearly in the LFB
description.

If, and only if, the situation is modelled as two LFBs, (one which
generates the meta-data and passes the packet with the meta-data to a
second LFB which uses the meta-data to select the output) then you have
different processing.

That is why Alan (I think), and I, view that second as more complex.

Yours,
Joel M. Halpern

---

From: Alan DeKok <[email-masked]>
Date: Tue, 4 May 2004 15:35:14 -0400

> up going to. Why you need a redirector for each case, i dont fully see.

   It depends on the conceptual model you use.  If you split the LFB's
by function, then an LFB which decides "IP packet good/bad" can

   a) mark the packet good/bad, and let a later LFB redirect the bad packets
   b) do the redirection itself.

> redirects it to some hole - be it a port/channel/software device etc.

   Exactly.

> at least in the local scope of its execution path.

   I'm not sure why.  The topology of an IP network includes bridges and
switches.  A redirector is just another name for a bridge/switch, but in
the context of LFB's.

> definition or makes it easier to describe?

   Someone else would have to answer that.

> - select output based on processing result.

   I understand.  But other models are possible.

> Could this be another of deviating view points?

   It's terminology.

   In the first example, you say "select output based on processing
result".  That processing result *is* metadata.  There is a physical
wire, or bit on a wire, which holds that result.  That "result" data is
separate from the packet data, and independent of it.  Therefore, that
"result" data is metadata.

   So to re-phrase your examples:

   - packet comes into LFB instance
   - process packet, and come to conclusion X
   - use X to select output

   That "X" is metadata.

   Alan DeKok.

---

From: Robert Haas <[email-masked]>
Date: Wed, 5 May 2004 15:39:44 +0200

Alan,
I assume the notion of "duplicator" is included in the model. Correct me 
if I am wrong: can there be more than one simultaneous outputs as a 
result of an LFB processing ? Take for example a non-intrusive 
packet-capturing application that wants to redirect copies of packets 
for analysis at the CE, while leaving the stream of packets untouched.

Regards,
-Robert

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 May 2004 10:32:22 -0400

Although we have not defined such an LFB class yet, it is certainly 
permissible (and necessary for certain cases) to do so.
Any one packet can only go one place, but an LFB can create as many packets 
as it needs to in order to do its job.

Yours,
Joel

At 03:39 PM 5/5/2004 +0200, Robert Haas wrote:
>if I am wrong: can there be more than one simultaneous outputs as a result 
>of an LFB processing ? Take for example a non-intrusive packet-capturing 
>application that wants to redirect copies of packets for analysis at the 
>CE, while leaving the stream of packets untouched.
>
>Regards,
>-Robert
>
>Alan DeKok wrote:
>
>>Jamal Hadi Salim wrote:
>>
>>>

---

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

>    b) do the redirection itself.

I dont have a problem with the multiple branches out of an LFB instance.
Of course you can be as granular as you want and have it with two LFBs
for the above.

> > redirects it to some hole - be it a port/channel/software device etc.

So lets settle this, since it is one of two issues i raised. Lets see
where a redirector is typically used in common literature:
- port redirector on Servers/firewalls --> used to imply a packet
destined to a TCP/UDP/SCTP port X gets sent to another port instead. The
redirection is the termination of that transaction on the local scope at
least.
- Port redirection on a lot of ethernet switches --> A packet coming on
physical port X gets redirected to physical port Y based on some match.

This may sound picky, but certainly redirectors you have in mind dont
fit the above. So to settle this maybe you shoulc change the name to
something like "selector" or "Muxer" or even "demuxer". Call an LFB a
redirector if it terminates the topology.

> switches.  A redirector is just another name for a bridge/switch, but in

Sure -- if you think of the LFB topology as spanning across multiple
FEs. In that scenario, you can draw the whole network as a connection of
LFBs. You could go as far as seeing a router/swicth etc as an LFB (how
granualar do you wanna be?). Note, i would have zero problem with that
approach; however, I think we did say we only wanna focus at the local
scope of a single FE.

>    Someone else would have to answer that.

I am curious and willing to consider if i can see the justification for
it as reasonable.

>    I understand.  But other models are possible.

Absolutely. I dont wanna have one view though being the only one
represented by the model.

>    - process packet, and come to conclusion X

Ok, it is probably just semantics, let me clarify my view:
* the result of internal processing is NOT metadata. Metadata MAY be
produced as a side-effect of processing. The result of processing is a
decision. Metadata is what gets carried around with the packet. Such
metadata may be used/consulted/consumed in processing the packet;
however, the processing is NOT dependent on receiving any metadata. In
other words, using metadata in processing is LFB specific. Some LFBs
will process just based on metadata others will never look at it even if
it existed.
The processing itself MAY create metadata which gets carried on the
packet (or stashed in some shared memory) to be used by the next LFB or
by the third LFB instance down the topology.
The decision to go out which branch is NOT dependent on such created
metadata rather it is dependent on the result/decision of the
processing.

Now, to my second contention point:
Do you see more than two groups of outputs? To use the grouping scheme
i only see two groups:
- the general path (upto n outputs)
- the exception path

I know you are trying to be generic and say if i can have two groups
then i can have X more. On the other extreme i see the two as one group
really, i dont see why you need to have the exception/error as separate.

Thoughts?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 May 2004 10:51:11 -0400

> as it needs to in order to do its job.

Actually, the mirror/duplicator LFB is an interesting contrast to the
redirector LFB; using what i know of common literature usage, one steals
packets(redirector) the other (nirror) just takes a copy of the packet
possibly to a different topology and lets it go on its merry way.
So how does the modelled topology look in your case for the two
contrasts?  I think it is a fundamental piece of the model.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 May 2004 11:07:29 -0400

From a topological point of view, the two are the same.
They are each an LFB instance of an LFB class (two different classes).
They each have one input, with meta-data tagging, and two outputs.
One class is defined to use the meta-data to decide which of the two
outputs to send the packet to.
The other is defined to always send the packet on output 1, and sometimtes
(depending upon the metadata) to make a copy of the packet, modify the
meta-data and send the copy on output two.

I would expect the outputs to have very different names in the two LFB
class definitions.  The first one might have outputs named IPv4 and IPv6,
while the second might have outputs named normal and LEA.

Connecting those outputs up properly is the job of the CE>

Yours,
Joel

---

From: Alan DeKok <[email-masked]>
Date: Wed, 5 May 2004 11:22:41 -0400

Jamal Hadi Salim wrote:

> fit the above.

   I believe that they do.  The one nit-pick is that you're group
re-direction with session termination.  Routers re-direct packets, and
also update TTL/checksum, but no one pretends that updating TTL/checksum
is related at all to redirection.

> So to settle this maybe you shoulc change the name to

   The topology of the LFB's stops at an FE boundary.  Within that
context, redirectors are still useful.

   That is, an FE may be doing multiple things to packets.  The ForCES
model MUST include those multiple kinds of packet handling.

   e.g. A MAC bridge FE handles unicast and broadcast packets.  Portions
of the packet handling are the same, and other portions are different.
So the "unicast packet handling" topology over-laps with the "broadcast
packet handling" topology.  However, both topologies are present in the
same FE, and both are therefore represented in the LFB model.

   In this context, the re-director *is* used to terminate the "common
packet handling" topology, and sends packets to the "uni/broad-cast
packet handling" topology.  So I understand your point.  But since the
topologies over-lap, the redirector is very useful.

> decision. Metadata is what gets carried around with the packet.

   This is the confusion I was trying to address in my "metadata
vocabulary" draft.  I'm updating the text, and will be adding it to the
model document.

   The result of a decision IS meta-data.  The result has physical
presence somewhere in the LFB, or in the device implementing the LFB.
In this context, the metadata is:

   a) internal to the LFB/device
   b) explicitly represented as some "result" of a decision process

   When the packet is sent out of the "IP validator" device, the device
can do it in one of two ways:

   1) Have one output, and attach the good/bad decision as metadata
      In this context, the metadata is:
       a) external to the device
       b) explicitly represented as bits on the wire, associated with
the
          packet

   2) have two outputs, for good/bad packets
      In this context, the metadata is:
        a) external to the device
        b) implicitly represented in the fact that bad packets are on the
           "bad" wire, and good packets are on the "good" wire.

> by the third LFB instance down the topology.

   In which case it's external to the LFB, and explicitly represented.

> metadata rather it is dependent on the result/decision of the

   And that decision is metadata.  Look at it as the LFB adding metadata
to the packet internally, and then internally consuming that metadata
when the branching decision is made.

   In all cases, the concept of the metadata is identical.  The only
difference is the scale at which you examine the metadata.

   e.g. Metadata which is explicitly represented in paths between LFB's
or devices on an FE often never makes it out of the FE.  Yet when you
look at the router in which that FE sits, you can't realistically claim
that the metadata doesn't exist.  It does, just not at the current scale.

> really, i dont see why you need to have the exception/error as separate.

   It's a good point.  I'm not sure I have a clear answer for you there.

   Alan DeKok.

---

From: Alistair Munro <[email-masked]>
Date: Wed, 5 May 2004 16:22:57 +0100

Dear All,

On the redirector and metadata/processing issues (Alan de Kok, Jamal's
exchange), I think Alan's model is more general and precise and thus more
acceptable to me at least.

I didn't want to have a model that ruled out redirector/demux LFBs or
aggregator/mux LFBs (selection based on metadata, no processing) and
allowed only the mux/demux embedded in LFBs of greater functionality
(selection based on internal processing results). The previous model
appeared to allow only the latter, and this is not compatible with silicon
that exists today. The current model text is better bar maybe some examples
and text optimisations.

Note: I take "processing" to mean a function that includes internal data or
state supplied independently of the packet flow together with metadata. So
just adding two metadatums (?) together isn't processing.

Speaking as editor of the NPF FE model, where support of legacy silicon is
essential, I believe this view is the consensus of the NPF members active
in this area. But I'll have to let them speak for themselves.

We might also be losing sight of the original issue (IMO), which was
groups. No, I don't really understand them either, but I can live with
them. The rules for using them seem clear enough to allow interoperability.

>> Although we have not defined such an LFB class [duplicator] yet, it is
certainly
>> Any one packet can only go one place, but an LFB can create as many
>> packets as it needs to in order to do its job.
>
> redirector LFB;

I think it is an unrelated function, not a contrast. Interesting
nevertheless.

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eagroup.com

---

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

Let me jump to this email because it puts us back on track - then i will
revisit the other emails including this because they still have
interesting discussion points.

> them. The rules for using them seem clear enough to allow interoperability.

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.

The other contention point is the naming around "redirector".

Both the above seem to me to be overzelous future-proofing design. Ok,
there i said it.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 May 2004 13:52:37 -0400

> Connecting those outputs up properly is the job of the CE>

Yes, the above should work.

I think we have _different_ views of how things should work - which is
almost implementation detailed. What worries me is that the definition
of LFB classes, when the time comes, is going to be very contentious (at
least with me).
You seem to have a lot of dependicies on metadata - which may explain a
lot of our disagreements.
I can live with the above, just dont impose the usage of metadata on me.

my view, to summarize:
All LFBs can be looked at as reentrant clones of the LFB class. You can
instantiate an LFB but it is useless unless bound to a packet
path/topology. Once the CE creates the LFB topology (connects inputs to
outputs), then theres no dependency on metadata to decide where to go
next. The path decision is based on processing which is driven by state
primarily. State could actually be static internal data like "always
drop".

Maybe i should present again over a concall to the design team what i
presented at Mineapolis. or maybe i should output a draft.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 May 2004 14:28:38 -0400

[..]
> topologies over-lap, the redirector is very useful.

There are two extremes:
1) 10 mile view level: How big is the LFB topology and if it spans
multiple devices?
I think we draw a line at saying a single FE is the 10 mile view. Not to
say the concept of redirecting on the egress of each device doesnt apply
- we are just drawing a line.
Once you say that, the redirection is mostly applicable at the egress of
the FE. Nothing is saying you cant based on state at the middle of the
topology decide to redirect and terminate the topology.

2) The microscopic view:
Is an LFB itself a micromodel of the LFB? talking fractal modeling
here ;-> I just think that such an approach, while generic and makes
sense is complicating things.

> presence somewhere in the LFB, or in the device implementing the LFB.

Interesting idea.

>    b) explicitly represented as some "result" of a decision process

yikes ;->
Ok, i see where you are coming from. Its a little over the edge but not
wrong.

>        b) explicitly represented as bits on the wire, associated with

Sure, b) is within the FE (or could be a shared mem location that is
updated.

>            "bad" wire, and good packets are on the "good" wire.

The only need for the metadata was to select one of two patbs. It doesnt
seem to have much use outside the LFB.

Let me clarify:
In your definition _anything_ associated with a packets processing,
including any decision, as long as it is not packet content is metadata.
I think i agree with above definition i am just having a hard time
swallowing it for a microscopic view of the LFB. In other words i see
internal metadata as useful only within the bounds of the LFB. Once it
goes out, it is external metadata - and since i am ignoring internal
metadata, then theres only one type of metadata which you refer to as
external.

> difference is the scale at which you examine the metadata.

Yes, i understand you now - not sure if i like it.

> that the metadata doesn't exist.  It does, just not at the current scale.

Sure; like i said you can look at the FE as one fat LFB. You just gotta
draw a line somewhere.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 May 2004 14:39:25 -0400

On Wed, 2004-05-05 at 11:22, Alistair Munro wrote:
> that exists today.

Actually the only reason i am continuing this thread is because my
thought is that the model i have in mind is left out ;->

>  The current model text is better bar maybe some examples
> and text optimisations.

Valid examples would help.

> just adding two metadatums (?) together isn't processing.

Processing is what you do to come to a decision of "what next?".
Actually now that i understand Alan's view, i am even more adamant to
define it this way for simplicity's sake.

> in this area. But I'll have to let them speak for themselves.

My approach may be slightly different. Come up with general and fit in
the legacy devices. No need to restrict how much you can innovate
because of legacy devices. I actually have a few legacy chips i modeled
against.

> I think it is an unrelated function, not a contrast. Interesting

Not from what Joel describes - and i can accept that point of view. I
still think theres a contrast between something that takes a packet and
another that introduces an extra one in the system.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 May 2004 14:44:27 -0400

I agree that the two (director and replicator) are very different LFBs.
However, topological the placement and connections may well be identical.
Yours,
Joel M. Halpern

PS: I have tried to use the phrase topology (specifically LFB topology)
consistently.  To me the full set of LFB instances and their connectivity
within an FE.  I would hate to get into the complexity of trying to
describe multiple topologies within an FE.

---

From: Alistair Munro <[email-masked]>
Date: Thu, 6 May 2004 11:21:13 +0100

Hi Jamal,

>> Speaking as editor of the NPF FE model, where support of legacy silicon
>> is  essential,...
>
> because of legacy devices.

We had at least one good example where the model apparently excluded use of
one specific approach, i.e. it was not general enough. So I agree with you,
I think. But I wouldn't want to say that legacy constrains innovation.

Regards,

Alistair

---

From: Alan DeKok <[email-masked]>
Date: Wed, 5 May 2004 16:19:49 -0400

Jamal Hadi Salim wrote:
> I think we draw a line at saying a single FE is the 10 mile view.

   I agree.  I think the rest of the authors of the model document
agree, too.

> sense is complicating things.

   I agree here, too.

   As a benefit, however, it may be possible to occasionally use LFB
terminology to describe events happening *inside* of an LFB.  This is
not to say that those events are part of the LFB model, but that we're
simply using a pre-existing terminology for a related system.

> including any decision, as long as it is not packet content is metadata.

   But... that *is* the definition of metadata: "Data which is
associated with the packet data, but which is not part of the packet data"

> metadata, then theres only one type of metadata which you refer to as

   I agree.  But I prefer to be able to use the word "metadata" when I
refer to events happening inside of an LFB.  The qualifier of "internal"
metadata is still important.

> Yes, i understand you now - not sure if i like it.

   After working on/with this model for a number of years, it's the
conclusion I've ended up with.  The benefit is that the same terms can
be used to describe events at different scales.  So the vocabulary
becomes simpler, the model becomes simpler, and it's easier for me to
remember what I'm talking about.

> Sure; like i said you can look at the FE as one fat LFB. You just gotta

   Exactly.  In this context, we do not want to talk about LFB's outside
of the scope (or scale) of an FE.

   Alan DeKok.

---

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

> > sense is complicating things.

BTW, i apologize i missed out a little important detail. I meant to say
the LFB being a micromodel of the LFB topology is where the fractal
model comes in (in other words you microtopologies within a topology).
This i find as unneeded complexity.

> simply using a pre-existing terminology for a related system.

Like i said it makes sense technically. I am probably just blocking my
mind from accepting it a) because its new approach - preference to play
it safe comes first. I would rather not experiment and b) i get this
nudging that it may be missing something.
Call me a luddite if you want.

> associated with the packet data, but which is not part of the packet data"

Grrr - You are right, but i still dont like it ;-> I think we should
restrict usage of that term on the inside-LFB aspect and be a little
more specific. At the end of it all you want people to understand what
the heck you are saying - it is always safe to start with commonly
understood terms. You have just lumped a DMA descriptor, function return
code, saved stack state and everything that happens within microcontext
of an LFB execution path into one.

> metadata is still important.

Ok, some serious text is needed to clarify some of these points.
I posted question on the metadata a while back but my last email wasnt
responded to. You should probably provide an alias for internal
metadata.

cheers,
jamal

---

From: Alan DeKok <[email-masked]>
Date: Mon, 10 May 2004 13:10:29 -0400

> This i find as unneeded complexity.

   Perhaps I wasn't clear.  I *don't* see the "micromodel" as part of
the ForCES LFB model.  However, in common conversation about ForCES,
it's useful to use similar terminology, where possible.

> it safe comes first.

   "Play it safe", how?  Calling something a MUX is describing what it
does, independent of where it exists in the network.

> more specific.

   Which is why my metadata draft was using vocabulary like "internal
metadata".  It's clearly not outside of the LFB, but *something*
logically exists, and we need a name for it.  Calling it "metadata"
outside of the LFB, and "a decision" inside of the LFB is awkward.

   Even when an LFB produces metadata externally, there *must* be some
internal representation of it, before it's produced.  Why not call it
"metadata" ?

> At the end of it all you want people to understand what

   "... into one common vocabulary", yes.  A CPU is a CPU is a CPU, no
matter if it's x86 or PPC.  The generic term applies to them all, and
the specific terms describe an implementation.

> Ok, some serious text is needed to clarify some of these points.

   I will be adding text about this to the draft.

> responded to. You should probably provide an alias for internal

   Could you post your question again?  I think I lost it...

   Alan DeKok.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 14 May 2004 10:15:49 -0400

> does, independent of where it exists in the network.

The problem is people are used to certain terminology. Playing it safe
is sticking to such terminology. To change it (even when it makes sense
such as in some of the cases in the LFB) requires indoctrination. None
of that indoctrination has happened - otherwise we wouldnt be
debating ;->

> outside of the LFB, and "a decision" inside of the LFB is awkward.

Metadata is such a generic term that it may end being confusing. People
are used to describing things in a certain way. Refer to my comments
about indoctrination requirements above to make the concept a success.

> internal representation of it, before it's produced.  Why not call it

I am not against the idea. I just think its too revolutionary. Humans
like evolutions better.

>    Could you post your question again?  I think I lost it...

I think the thread starts here:
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0403&L=forces&T=0&F=&S=&P=2267

I will read it again and see if it is indeed the right one.

cheers,
jamal