Subject: Re: FE model open issues

From: "Deleganes, Ellen M" <[email-masked]>
Date: Wed, 5 Nov 2003 09:12:41 -0800

In the model draft it states: 
"LFB topology reconfiguration is considered an important aspect of the
FE model." It seems like one of the questions that has not been resolved
by the working group is how much dynamic reconfigurability is required.
A number of possibilities have been proposed in various drafts, ranging
from the ability to completely reconfigure an FE - changing the service
by adding/deleting LFBs to supporting only a limited amount of
reconfigurability. 

The ability for the CE to treat the FE as a blank sheet of paper and
download LFBs and their associated topology seems unnecessary. If the
goal is for ForCES to define a protocol to allow CEs and FEs from
different vendors to interoperate, this seems to be out of scope for the
ForCES WG. I assume that FEs would have capabilities built in that the
CEs could query, and customize the LFB behavior at runtime (the degree
is dependent on the capability of the FE), but not to add new
functionality by downloading LFB code.  

I'd also argue that dynamically reconfiguring LFB topology does not
require the ability to add or delete paths, assuming the approach of
using a combination of encoded state and a topological graph approach is
used to model the LFB topology. Functionality such as redirecting
traffic flows dynamically can be handled by changing the encoded state,
the topology graph itself is static.

Regards,
Ellen Deleganes
  
-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Yang, Lily L
Sent: Tuesday, October 28, 2003 11:02 AM
To: [email-masked]
Subject: FE model open issues

Hi, all --

I hope you've had a chance reviewing the latest FE model draft. Here is
the link, in case you have not done that. 
http://www.ietf.org/internet-drafts/draft-ietf-forces-model-01.txt

The FE model design team also identified a list of open issues that we
consider either not fully resolved or completely missing  in v01. Here
is the list:

#1 FE connectivity: Whether or not the FE connectivity information
should be part of the FE model? 
#2 metadata: How to define the metadata in LFB model? 
#3 XML schema for LFB class: We need to refine LFB model and turn it
into XML schema for Section 4.
#4 LFB class partition: How to partition common FE functions (starting
with IPv4 forwarding) into a list of LFB classes? When to use a base
class ? (Section 7)
#5 Satisfying requirements: We need to provide examples to demonstrate
that the FE model can address all the requirements in Section 8.
#6 FE capabilities and attributes: We need to define the FE level
capabilities and attributes in Section 6.
#7 LFB topology for Section 5.

We would like to continue working on these issues to move the FE model
forward. Your ideas, suggestions & contribution in these areas are most
welcome!

Lily

---

From: Alistair Munro <[email-masked]>
Date: Mon, 10 Nov 2003 11:32:22 -0000

Hi All,

I'm writing to express my opinion about the ForCES model draft in my role
as editor of the corresponding document in the Network Processing Forum.
There are only two points that I can tease out as separate from the ongoing
discussion threads.

First, the main gripe I have right now is about terminology. The
requirements and purpose of the NPF and IETF models overlap sufficiently
well that we can use the same names for things. Specifically, at present
NPF uses "resources" as a term where the IETF text refers to "attributes".
Neither is good enough right now - NPF probably doesn't qualify resources
enough, while the ITEF text has at least three categories of attribute. It
would be good to get this aligned.

My point: several of the IETF editors are also present and contributing in
the NPF, so it shouldn't be too hard.

Second, as a general comment, there are several parts of the draft that I
would find too constraining because they seem to imply [assumptions about]
implementation behaviour. For example, section 4.4.4: metadata pass through
limitations, metadata CONSUME/PROPAGATE mode selector. I think this comes
about because of the dynamic reconfiguration capability that the model is
apparently intended to support, which  requires a very specific operational
model and semantics if it is to be invoked at a fine grain by the CE.

My point: this capability isn't, as far as I can tell, a ForCES requirement
on the model. Or am I mistaken?

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: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Nov 2003 11:45:33 -0500

I think that there are two issues here.
We are discussing reconfigurability.  I would really like to retain that
(as most folks have gathered by now.)

Separately, there is the question of describing and using metadata.  If we
are going to allow the system to talk about metadata (which seems sensible)
then evenin a fexed topology the CE needs to understand how the metadata is
handled.  Whether the right way to do that is CONSUME / PROPAGATE or some
other model entirely is still very much up in the air.  We have not agreed
on how to talk about metadata at all.  I expect we will try to keep it in
the system, and therefore we will have to talk in some fashion about how it
moves / is used inside the FE, even for static topologies.

Yours,
Joel M. Halpern