Subject: [forces] re-charter topics

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 27 Feb 2013 08:58:53 -0500

Folks,

While it was hard to leave out some of the popular polled items
like OF and virtualization from being explicitly mentioned, the
following 5 work items are the tasks that are of relevance to a
possible re-charter. The decision was purely based on "What is the
minimal we could do and must do to complete the work based on deployment
experiences and requirements". Veterans like Joel Halpern helped in
narrowing down this list. Essentially it boils down to people committed
to doing the work and to deploying it.

Having said that virtualization (being the most popular work item) is on
the list implicitly from an infrastructure perspective.
You could still disagree with this task-list in the mailing list
or/and at the meeting, but from a personal level i would like it if we
reduced the uncertainty we have around the WG on what we should work on.
This seems to turn off some people from more deployments.

There are a few drafts out there already on some of these topics and
there have been presentations made in the past on all these topics
(drafts to come where missing).

The list is as follows:
o Model Extensions and protocol:
This work is to address a set of extensions to the base model and protocol
resulting in updates to RFCs 5810 and 5812.

The model extensions will:
1. Allow complex metadata.
2. Allow optional default values for datatypes
3. Allow optional access-type for datatypes inside complex components
4. Define new base type: Bitmap

The protocol extension will:
1. Table range query.
2. Table append
3. Additional return codes to reduce ambiguity

o Inter-FE Connectivity:
It has been found that ForCES processing often needs to be spread across
multiple FEs.  The original framework identified this as the Fi interface.
Protocol and LFB mechanisms to carry metadata across this Fi interface are
now needed.  This effort will produce a standards track doument defining the
protocol on the wire to address this need, and the LFBs used to represent the
interfaces for sending and receiving such information.

o Paralellization:
While in theory an FE can implement an LFB chain with paralellization, the
current mechanism has no means to represent when synchronization is needed,
or to allow the CE to specify where it believes such paralllism is useful.
This work item will produce a single standards track document to improve the
handling of this case.

o Subsidiary Management:
Deployment experience has demonstrated usefulness of expressing the FEM
with the same semantics as any other LFB and thus be controlled by the CE.
This work item assumes the presence of an initially booted FE whose
configuration could then be updated at runtime via an FEM LFB for runtime
config purposes (eg adding a new CE and its associated IP address).
This work item can also be useful in addressing control of virtual FEs
where individual FEM Managers can be addressed to control the creation,
configuration, and resource assignment of such virtual FEs within a physical FE.
This work would result in a standards track LFB FEM library RFC.

cheers,
jamal