Subject: Re: FE model open issues

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Nov 2003 12:27:57 -0500

There will certainly be FEs whose internal LFB topoloogy is static or
nearly static.  There will be FEs whose only "adjustability" is in the
metadata.  There will also be FEs where LFBs can be selected to be used in
different data paths, and services created in a more dynamic fashion.  The
most capable FEs will have an extremely flexible topology where most any
LFB can occur anywhere.

One could argue that for the first release we should support only static
topology.  Based on experience, I feel that is too limiting.  Hence, I
would like to see the protocol include  mechanisms for "creating" LFBs and
connecting them to other LFBs in the FE.   This is not primarily to support
the blank sheet model (although that will happen to be supportable) but to
support the large range of FEs with some adjustability in the LFB topology.

The consequence of course is that the CE must be prepared to have its
attempt to adjust the topology fail, since most FEs will have limits on
their adjustability.  This is largely inevitable.  If a CE is trying to
install a service, the FE might not be able to deliver it  (the
capabilities information is about helping the CE have information to judge
whether and how to configure the service on a given FE.)  Related to this,
as we say in the documents, some of the mapping requires human intelligence
and will not work without a person in the loop.

Joel

At 09:12 AM 11/5/2003 -0800, you wrote:
>Subject: Re: FE model open issues
>To: [email-masked]
>
>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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 Nov 2003 12:55:48 -0500

> support the large range of FEs with some adjustability in the LFB topology.

I am in agreement with you. And infact have proof of concept existing
already.
Have we talked about "creating" LFBs before?
My presentation (last in the agenda) talks about an implementation
that is capable of doing what is being refered to as "dynamic".
In that model, downloading LFB modules and inserting them in the FE is
what i would term as "creating". I think this is more out of scope for
Forces.
Creating policies that use the downloaded LFBs is more "instatiating" a
LFB instance. This is within scope and you may have meant to say this.
In other words, FE capabilities may change and be rediscovered at any
point in time by Forces requiring adjustements (example lost
capabilities).
Moral of the point here, is this is not a blank sheet to the FE; it is
there today (and yes that code is known to work with static LFB FEs like
ASICs and some NPs).
Nobody cares how the dynamic LFBs get there, just that you can use
Forces to configure them when you need to.

> and will not work without a person in the loop.

Indeed.

cheers,
jamal