Subject: Re: FW: Another clarification on the FE Model

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 Jul 2004 22:48:17 -0400

This depends upon the LFB class defintion.
That is, if the LFB Class defines the LFB as containing a table of meters,
with the specific meter selected by meta-data on the packet, then the LFB
Instance is collection of processing logic and tables with multiple meter
values and meta-data based selection.
If the LFB Definition says that the LFB has one meter value and applies
that to all data that arrives at the LFB instance, then the LFB instances
corresponds to what in the other case would be a table entry.

The protocol needs to allow for both cases.

Separately, we can work out what LFB Class definitions we want to have.

Yours,
Joel

At 02:36 PM 7/29/2004 -0400, Jamal Hadi Salim wrote:
>On Thu, 2004-07-29 at 14:29, Khosravi, Hormuzd M wrote:
> > -----Original Message-----
> > From: Jamal Hadi Salim [mailto:[email-masked]]
>
>[..]
>
> > Its important for the protocol to be laid out such that it can
> > do both the "instanceid is a tableid" and "instanceid is a table row"
> > view.
> >
> > [HK] The "instanceid is a table row", is what is causing the current
> > confusion.
> > Jamal, could you elaborate a bit on your thoughts on this? For example,
> > in case of a Meter with 100 entries in a Meter table on the FE, do you
> > view this as a single Meter LFB instance containing a table or 100 Meter
> > LFB instances ?
>
> >From a policy perspective i would view each of the 100 entries as an
>instance with an instanceid. Instanceid in this case would be a table
>row index which only holds parameters for the LFB instantiation.
>Note, such represantiation may not be very suitable for some forms of
>classifiers such as IPV4 LPM or when you wish to virtualize by having
>multi-tables. In such a case, the protocol instance could be a tableid
>with something within LFB data specifics index the table row.
>
>cheers,
>jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 30 Jul 2004 09:03:50 -0400

> corresponds to what in the other case would be a table entry.

This is what i was hoping to hear. i.e what instanceid means is specific
to the defined semantics of the LFB.

[Off topic: Why do you have to insist on meta-data selection of the
tables (eg meter tables above); in my case, the topology is bound for
the flow at policy installation time. Conceptually the overall result is
the same i am only worried about using language that implies metadata
approach is the way to go. We can take this to another thread]

> The protocol needs to allow for both cases.

At the moment we define the instanceid on the protocol level to be 16
bits which is insufficient to cover the second case.

> Separately, we can work out what LFB Class definitions we want to have.

Agreed.
The challenge is that need to know possible scenarios for an instanceid
for the protocol in order to define it better. I believe, the model
draft needs to come up with text on this in order to provide guidance.

cheers,
jamal

---

From: Alistair Munro <[email-masked]>
Date: Fri, 30 Jul 2004 16:50:48 +0100

Hi All,

>> That is, if the LFB Class defines the LFB as containing a table of
>> meters, with the specific meter selected by meta-data on the packet,
>> then the LFB Instance is collection of processing logic and tables with
>> multiple meter values and meta-data based selection.

It's the *opposite* of what I expected, and I think Steve was making a
clearer distinction of the semantics (and I agree with him).

As far as I'm concerned, a FE datapath is a collection of objects that are
addressable by instance identifiers. Tables within them are like public
data-structures in an object and are addressed by table identifiers, or
meter identifiers within tables, according to the semantics of the LFB
class definition (I think we are agreeing about this). All these
identifiers are like memory addresses, i.e. instance identifiers.

This would seem to me to make the protocol simpler, but inevitably PDUs
would be larger than they would be with the optimised model that Jamal
seems to be using as his framework.

> approach is the way to go. We can take this to another thread]

I think the insistence on using a metadata tag to select a meter from a
table arises from the model itself (there are examples in the text that
seem to imply this). The metadata approach is *not* the only way to go. The
datapath can branch (e.g. using the output group model to select an index
on the output of the LFB [instance]).

>> The protocol needs to allow for both cases.

The protocol needs to provide mechanisms to address object and
datastructure instances in the FE. I suspect the same protocol could be
used to suit both models (as described by Joel) but if different
implementers have different semantics, then we have a problem.

> bits which is insufficient to cover the second case.

I agree with this. But my model is not the same as yours (AFAIU).

> draft needs to come up with text on this in order to provide guidance.

I don't think a *model* for a FE needs to provide guidance of this kind. I
think an instance identifier is something than an FE can publicise
(opaquely - we don't care how it got it). When it gets it back, it should
know what to do with it. Maybe the model needs to say this - it is a bit
vague on instance ids. How big it is is another matter. Why not use 128
bits and thus a sub-space in the IPv6 address space? Probably better
long-term.

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: Fri, 30 Jul 2004 13:47:32 -0400

> clearer distinction of the semantics (and I agree with him).

It may be implementation semantics actually being the reason why we are
not reaching a common ground.

> addressable by instance identifiers.

agreed.
'To go one step further: the LFB topology is a policy in which such
addressable instances of such objects are interconnected.

> Tables within them are like public
> class definition (I think we are agreeing about this).

Yes we are in agreement; however, above you said "It's the *opposite* of
what I expected" to my statement of "what instanceid means is specific
to the defined semantics of the LFB".

> All these identifiers are like memory addresses, i.e. instance identifiers.

Agreement again.
Caveat: How these "instances" are actually accessed after the policy/LFB
topology is defined seems to be a contentious issue at the moment but
not a show stopper. I use metadata only when i have to.

> seems to be using as his framework.

I think we are agreeing on one thing in general:
a (service?) policy is described by a LFB topology which typically
describes how a packet gets massaged. How the packet walks the topology
is the contentious issue but as i said earlier not a show stopper. The
model oughta not be restrictive with any.

The challenge is how to address that entity you refered to as
"these identifiers are like memory addresses, i.e. instance identifiers"
from the protocol. How do i send a query or config such that i address
that instance.
Its important to at least resolve what the protocol should be putting in
the generic headers. The pieces which are  LFB specific could be left
upto the LFB specific messaging.
Again, this is in terms of management of those instances more than
how a packet gets to the instance (for that you can go ahead and use your
metadata and i will just optimize mine). Unless you see a strong corelation
between the two.

> on the output of the LFB [instance]).

I will defer this discussion to later.

> implementers have different semantics, then we have a problem.

I think we have a problem.

> I agree with this. But my model is not the same as yours (AFAIU).

We need to find a common ground for my model as well as yours at least
from a protocol perspective.

> I don't think a *model* for a FE needs to provide guidance of this kind.

Well, the model is a lot more adventorous in its current form to
overlook this. As an example the littering of metadata aproach to the
packet walk. I actually have no problem with that as long as its not
exclusive.

> I

rowindexes in a table are probably the safest thing to do; a 128 bit
address would be fine - the semantics could be entirely left to the
LFB.

Perhaps a better approach is to totaly remove the instanceid from the
main headers and have each LFB handle its own.

cheers,
jamal

---

From: Steven Blake <[email-masked]>
Date: Fri, 30 Jul 2004 17:15:57 -0400

> Separately, we can work out what LFB Class definitions we want to have.

We can support the "one meter per-Meter LFB" approach using the same LFB
class definition needed to support the "multiple meters per-Meter LFB"
approach.  A "OMPML" LFB would be instantiated with a single-entry in
its single table.  We talk about the capability to configure what (if
any) metadata item an LFB instance looks at in Sec. 3.2.4.5 of model-03,
but I'm not sure if all of the necessary mechanisms exist in the schema
now to express this capability.

Regards,

// Steve