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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 29 Jul 2004 11:03:40 -0700

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Steven Blake

> Hi Folks
>
> Sorry to trouble you again, but we (protocol team members) need
> another clarification on the FE Model...
>
> This is on a very basic issue, what does a LFB Instance signify ? Does
> it signify one or more Tables on the FE for a particular functionality
> ? or Does it signify an entry in a Table, such as an entry in a Meter
> table ?

What is unclear about the definitions on pp. 4-5 of model-03?
[HK] It is clear to me

> From my understanding of the Model and section 3 in the draft, I
> believe the former to be the answer (one or more Tables) but there is
> another view on this and a clarification from the Model team would be
> helpful.

An LFB may access one or more tables that are configured by the ForCES
protocols.  But the LFB is an abstraction of the packet processing
operation plus its associated tables.

[HK] This is my understanding as well. Thanks a lot for the prompt
clarification!
Jamal, others, any comments on this ?

Thanks
Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 29 Jul 2004 14:18:01 -0400

> What is unclear about the definitions on pp. 4-5 of model-03?

What is pp 4-5? Section 4.5 seems to be referencing soemthing else.

> Jamal, others, any comments on this ?

That is my understanding as well. I think we are discusing something
beyond that though:
The meaning of instanceid is per LFB semantic. What are the kinds of
semantics that we expect to see? In some cases it may make sense to have
the tableid to be the instanceid. Not in every case.
And as in the other thread - the one reason to maintain the multi-tables
is for virtualization. There is more than one way to do that.

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.

cheers,
jamal

---

From: Steven Blake <[email-masked]>
Date: Thu, 29 Jul 2004 15:29:39 -0400

> What is pp 4-5? Section 4.5 seems to be referencing soemthing else.

Sec. 1, pages 4 and 5.

> the tableid to be the instanceid. Not in every case.

I don't believe that it makes sense in any case.  You will have LFB
classes that are defined so that only one instance of a table is
permitted, and some that permit multiple instances.  You will have cases
of LFB instances that have one table instantiated, where more than one
are permitted by the class definition.  In any of these cases, I think
you want to differentiate between the LFB instance ID (which is used to
address the LFB and is needed to describe the LFB topology in the FE),
and the table IDs, which are unique and specific to each LFB instance.

> is for virtualization. There is more than one way to do that.

Sure.  You might also want multiple tables because you want one table
per-incoming interface, one table per-label depth in an MPLS label
stack, etc.

> do both the "instanceid is a tableid" and "instanceid is a table row"

If an LFB instance has only one table (permitted or instantiated), it
might be convenient to address the table using only the LFB instance ID.
But in cases where there are LFB instances with multiple tables, you
need to be able to address the LFB instance and its tables separately;
otherwise, every table instance shows up as an LFB instances and
seriously complicates the topology.  I'm afraid that if you ever allow
the two IDs to be conflated, you make interoperability harder.

Regards,

// Steve

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 29 Jul 2004 16:22:34 -0400

> per-incoming interface, one table per-label depth in an MPLS label

All good reasons to have multiple tables.

> the two IDs to be conflated, you make interoperability harder.

How about we formalize what i think you said:

Instanceid := tableid:rowindex

when only one table exists we have the instanceid being the rowindex.
i.e thats the only useful information. This fits my single meter table
where each entry is an instance.
When we have multiple tables, then both pieces are useful.

Of course i am assuming everything is table driven and i am not saying
how big the tableid and rowindex should be or where in the protocol
messages they should sit at. That we can resolve easily (we allocate a
16 bit for an instanceid at the moment).

cheers,
jamal

---

From: Steven Blake <[email-masked]>
Date: Thu, 29 Jul 2004 16:51:24 -0400

> 16 bit for an instanceid at the moment).

Were are not on the same page.  :)

Suppose I have a Meter LFB instance that sits somewhere in the FE
datapath where I want to police packets.  I have lots of different
Diffserv SLAs and consequently lots of different meter policies (e.g.,
rate, bucket size parameters).  I represent each meter policy as an
Meter LFB attribute (model terminology), and I organize these attributes
in a table associated with the Meter LFB instance I am refering to.
When I want to apply a metering policy to a packet, I use some metadata
item (e.g., CLASS_ID) associated with the packet as an index into the
attribute table to look up the appropriate policy (of course this is
just an abstraction for the CE; what actually happens in HW may be
different).

In this case there is only one table associated with the Meter LFB, but
potentially lots of attributes (e.g., "rowindexes") in that table.  LFB
instance ID and table rowindex aren't directly comparable since there is
a 1:N relationship.

Another example: I have a Classifier LFB instance in the FE datapath
where I perform 6-tuple classification.  I have lots of different
Diffserv SLAs and hence lots of different 6-tuple classification
filters.  I represent each filter as an Classifier LFB attribute.
In this example, I want to organize my filters into multiple tables, one
per-incoming interface, and I want to use incoming interface metadata to
select the appropriate table to search when I classify the packet.
Each Classifier LFB attribute is associated with a unique CLASS_ID
metadata which is associated with a packet when it matches that
attribute.  In this example I've got multiple tables, and multiple
entries per-table.  Again, there is no way to directly compare the LFB
instance ID of the Classifier LFB with any particular table ID or
attribute ID, since there is a 1:N:M relationship.

Regards,

// Steve

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 29 Jul 2004 17:25:09 -0400

> Were are not on the same page.  :)

No reason we cant get to the same page ;->

> Meter LFB attribute (model terminology), and I organize these attributes

We may be differing on the term policy. To me policy is infact the
lfb topology which interconects LFB instantiation. LFB instantiation
requires parametrization of an LFB which is what you are describing
above.

> in a table associated with the Meter LFB instance I am refering to.

So in other words in this specific example you create a table row.
With the table columns belong the attributes you just parametrized.

> just an abstraction for the CE; what actually happens in HW may be

We may have subtle differences but the end goal seems to be the same.

In my case when i apply a policy, it may go in two steps:
1) i create those row entries (instantiate).
2) I then connect instances of such entries together to create a
topology/policy. In this case i actually create a bound path
which doesnt need to use metadata; you could use metadata - from an
abstraction level you see a LFB instance topology.

> instance ID and table rowindex aren't directly comparable since there is

What you call attributes above i call instances; an instance may have
many attributes. Could this be the major difference or is that a typo?
in other words attributes are colums for me.

> select the appropriate table to search when I classify the packet.

the main conflict seems to be what the attributes mean and how you do
things; actually the later is a lesser issue since the end goal is the
same- i bind paths and you use metadata to do path selection.
Theres also the question of whether the table belongs to the system or
to the device. I would rather have it belong to the device.

> attribute ID, since there is a 1:N:M relationship.

Ok, brings up two views:
1) You could have
interface ->classifierboundtothisdevice-->multiple entries
In which case that specific classifier is bound to the interface and
getting entries to it via the protocol should include the interface name
or ifindex.

2) You could have:
interfaces --> system wide classifer#X --> multiple entries
In which case you need some metadata to select classifier#X.
And possibly in your case classifier#x could be shared by multiple
interfaces.

I was coming more from model #1 and you are from #2. Does this make
sense?
We need to support both schemes.

cheers,
jamal

---

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

> requires parametrization of an LFB which is what you are describing

That is one sense of "policy", but I was very careful to specify what I
meant by "meter policy" == (rate, burst) parameter set.

> With the table columns belong the attributes you just parametrized.

To be precise, in the model schema, for the Meter LFB example I gave,
the table itself would be an attribute of the LFB class which would be
defined as a variable-length array of structs, where each struct
corresponds to a (rate, burst size) parameter set.
> abstraction level you see a LFB instance topology.

How do you bind "things" between LFBs without metadata (unless the LFB
only has one "thing").  It seems that what you are advocating is the
topological approach to modeling the datapath (pg. 29 of model-03).  If
I understand you correctly, then note that the model schema supports the
topological approach as a well as the encoded state approach.

> in other words attributes are colums for me.

I spoke carelessly in my previous note: while all variables associated
with an LFB class definition can be referred to as attributes, the
things that are defined with the <attribute>...</attribute> syntax are
the top-level container objects.  I have used the term "instance" to
refer only to LFB instances in a particular FE datapath.

> to the device. I would rather have it belong to the device.

I can't parse this paragraph, except by assuming that you are assuming a
topological encoding approach.  I also don't understand what you mean
by "system" and "device" in this context.  As far as the model stands
now, tables are defined in LFB class definitions and exist within LFB
instances within a particular FE, although draft-blake-forces-attrib-00
makes some arguments as to why we may need more flexibility here.

> We need to support both schemes.

Agreed.

Regards,

// Steve

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 30 Jul 2004 20:59:15 -0400

> On Thu, 2004-07-29 at 17:25, Jamal Hadi Salim wrote:

[..]
> the table itself would be an attribute of the LFB class

nod.

> which would be

Could be modelled as a fixed size array of capacity X. Infact i expect
the upperbound capacity would be defined.
The struct you refer to (which stores the rate, burst, size) could be
looked as the table row.
To get to the struct i have to get to the LFB then table then find the
struct. One way to uniquely find the struct is to give it an Id.

> only has one "thing").

Imp specifics: memory address of the LFB specific parametrization(the
struct) is one way. Binding is having such "pointers" in a topology of
some form; possibly stored in SRAM. You could go to the extreme and
claim the SRAM memory addresses are infact metadata.

> It seems that what you are advocating is the

Its a hybrid model (both encoded state and topological). The LFB
instances maintain state and the decision on branching within a LFB
instance topology.
I think you have the same thoughts as well; the difference seems on how
to walk the LFB topology path.

We are probably not gonna make progress here (i think theres also a
strong relation in this to the input and output port differences)- lets
talk in SD.

cheers,
jamal