Subject: clarifications on FE Model

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 14 Jul 2004 19:34:55 -0700

Hi All,
 
I had some questions/clarifications on the FE Model....
 
Does the LFB Type, Instance Id essentially identify a single Table for
that LFB instance, which can be configured ? or Could a LFB Instance
have multiple Tables ? If there are multiple tables (I don't suspect
this), how is this information conveyed to the CE ?
 
For static LFB Topologies, how is the LFB topology represented or
defined, so that the CE can query this ? I found text around this but
did not find the precise definition.

I went through a few sections in the draft but did not find these
answers. Sorry if I missed it.
 
Thanks
Hormuzd

________________________________

From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Deleganes, Ellen M
Sent: Friday, July 09, 2004 8:04 AM
To: [email-masked]
Subject: [FORCES] draft-ietf-forces-model-03.doc - with changes turned
on

Attached is the word document with the changes shown. In addition to the
changes shown, sections 3.1, 3.2.1, 3.2.2 were significantly rewritten
and 3.2.4.1 was added.
 
Regards,
Ellen

---

From: Alistair Munro <[email-masked]>
Date: Thu, 15 Jul 2004 08:25:59 +0100

Hi Hormuzd,

> that LFB instance, which can be configured ? or Could a LFB Instance have
> multiple Tables ? If there are multiple tables (I don't suspect this),
> how is this information conveyed to the CE ?

We've found it convenient to have more than one table to manage multiple
namespaces, e.g. it may be convenient to have several blocks of meters in
an LFB meter instance that are indexed by rule ids that originate from
multiple rule sets. So the metadata includes TABLE_ID and RULE_ID to access
the specific meter. TABLE_ID is an optional (conditional?) external
metadatum because we don't expect it to be invoked very often.

However, isn't it the protocol's job to express this functionality between
the FE and CE? I'm not sure if the model need say how it happens and the
text of 03 seems adequate to me. Maybe more examples are needed but I guess
it's not necessary to put in too much tutorial stuff.

> defined, so that the CE can query this ? I found text around this but did
> not find the precise definition.

Again, isn't the representation part of the protocol? The model text seems
to say sufficient about the topology graph. The only thing I don't like
much is the use of "port" in combination with "LFB input" and "LFB output",
which could be confused with physical media interfaces, for which the term
"port" is also used.

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: Thu, 15 Jul 2004 09:15:34 -0400

> it's not necessary to put in too much tutorial stuff.

I think this is very LFB semantic specific. Perhaps what we need is to
have all LFBs define what an instance Id is.
To be precise: An LFB instance is an instantiation of the LFB.

I am not sure i agree with the meter example you gave Alistair. A table
ID representing a IPV4 LPM would be intuitive - probably because it is a
classifier. OTOH, a index into a meter table would make more sense.

I have seen text (was hoping to comment at some later time) which almost
seems to lump virtualization into instance Ids via table IDs for
example.  If the desire is to talk about VRs, shouldnt those be
addressed by the FE/CEID and not via some table ID?

> which could be confused with physical media interfaces, for which the term

I have issues with the ports/input as well but they may be more around
the concept than naming. Refer to thread.

cheers,
jamal

---

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

(I realize that there has been some discussion on this, but I think my
answer will be clearer if I keep it separate.  What follows is what
I expect, and has not been reviewed with the model design
team.)

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

At 07:34 PM 7/14/2004 -0700, Khosravi, Hormuzd M wrote:

Hi
All,

I had some
questions/clarifications on the FE Model....

Does the LFB Type, Instance Id
essentially identify a single Table for that LFB instance, which can be
configured ? or Could a LFB Instance have multiple Tables ? If there are
multiple tables (I don't suspect this), how is this information conveyed
to the CE ?

For static LFB Topologies, how
is the LFB topology represented or defined, so that the CE can query this
? I found text around this but did not find the precise
definition.

I went through a few sections
in the draft but did not find these answers. Sorry if I missed
it.

Thanks

Hormuzd

From: Forwarding and Control Element
Separation
[mailto:[email-masked]]
On Behalf Of Deleganes, Ellen M

Subject: [FORCES] draft-ietf-forces-model-03.doc - with changes
turned on

Attached is the word document with the changes
shown. In addition to the changes shown, sections 3.1, 3.2.1, 3.2.2 were
significantly rewritten and 3.2.4.1 was added.

Regards,

Ellen

---

From: Steven Blake <[email-masked]>
Date: Wed, 28 Jul 2004 15:08:45 -0400

> To be precise: An LFB instance is an instantiation of the LFB.

Right.

> addressed by the FE/CEID and not via some table ID?

There is a lot of variety in how people handle virtualization in their
datapaths, and I would not be happy seeing ForCES restricted to handling
virtualization strictly by means of "virtual FEs", or some type of
highly separated LFB topology for each virtualized entity.  I can think
of a lot of cases where I would choose to handle virtualization via
separate tables (indexed by interface of VR metadata) within LFBs.

Regards,

// Steve

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 29 Jul 2004 13:47:52 -0400

> > To be precise: An LFB instance is an instantiation of the LFB.

Ok, this is important to clarify since we need it to be clear at the
protocol level.

> separate tables (indexed by interface of VR metadata) within LFBs.

I think it would make a lot of sense for Forces to have virtualization
based on FEIDs. You could still have each FEID within the physical FE
control only a specific tableid. Pushing tableids is in my opinion
enforcing a specific mode for virtualization. OTOH, I think we can still
leave this upto a specific NEs setup for selection of how they want to
do it; could be part of FE capability exchange and negotiation.

cheers,
jamal