Subject: Re: clarifications on FE Model

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 15 Jul 2004 13:40:43 -0700

Hi Joel,
 
Thanks for your response, I think it helps.
It seems like some of these issues are still open in the Model, but you
have some idea of how they should be resolved, which is fine.
 
If you could throw some light on the LFB Topology question that I asked
in my previous email, that would be helpful. Also, I assume that if
there are multiple Tables in an LFB, the Table Ids will be reported as
part of the LFB Capabilities ?
 
Thanks
Hormuzd

________________________________

From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern

An LFB class definition can include multiple attributes.  Some of these
attributes may be tables (arrays).  Some of these arrays may even be
multi-dimensional arrays.  There are many reasons for this.

In the definition of the LFB class, we (the working group) will have to
agree on what is inside the LFB, and what is outside.  For example, we
may decide that a "meter" LFB should have only a single meter, and if
you want multiple meters you should instantiate multiple LFBs.  We may
also decide that a "multi-meter" LFB has multiple meters, and that
traffic is associated with a specific meter based on meta-data that
arrives with the packet (probably from a classifier.)  Such an LFB class
will presumably have a (read only / capability) attribute that indicates
how many meter entries the table can have.

As a practical matter, it is clearly desirable for some LFB classes to
support such meta-data driven behavioral indexing.  Equally clearly, an
implemenation can claim to support such a multi-meter, and set the
capability to indicate that the maximum number of meters is 1.  (Which
is why we probably will not decide to support both a single meter and a
multi-meter.)

Hence, each LFB class definition will have to clearly define the scope
of its capabilities, and the way it uses meta-data, including whether it
supports meta-data indexing to select its basic function.  I hope that
after we define a few more LFBs, and the working group is comfortable
with the definitions, that we will be able to develop guidelines about
when to use such approaches.  But it would be difficult to write such
guidelines at this moment.

I hope that this answers your question rather than muddying the water
further.

Yours,
Joel

---

From: Steven Blake <[email-masked]>
Date: Tue, 27 Jul 2004 19:52:22 -0400

On Thu, 2004-07-15 at 16:40, Khosravi, Hormuzd M wrote:

> If you could throw some light on the LFB Topology question that I
> asked in my previous email, that would be helpful.

Sec. 5.2.2.3 covers LFB Topology, and you suggested that this wasn't
enough.  What more do you want to see?

> Also, I assume that if there are multiple Tables in an LFB, the Table
> Ids will be reported as part of the LFB Capabilities ?

Right.  The number of tables supported by an LFB instance will be a
capability of that instance that the CE can query.  The valid table IDs
might simply be the indexes 0 - N-1.

Regards,

// Steve