Subject: Re: FE model open issues

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 5 Nov 2003 12:25:10 -0800

Thanks for the clarification. My comments below...

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, November 05, 2003 11:55 AM
To: [email-masked]
Subject: Re: [FORCES] FE model open issues

If I have read this right, there are LFBs that will work this
way.  However, I am not sure.  Let me rephrase.

1) At any time (ncluding startup) an FE has an LFB topology that is
actually instantiated.  For some FEs this will be initially empty, for
others it will be initially populated and always the same.  This is not
capability information, this the actual LFB topology.

[HK] I believe that during the capability discovery phase of the ForCES
protocol (post-association), the FE will report the LFB graph of all
possible LFBs and all possible connections. This will basically
represent
any constraints on the connections between LFBs.

2) Some FEs (particularly software / NPU based FEs, but also some
hardware
ones) have deployable components.  That is, data paths may be adjusted
to
cause different elements to receive different packets.  (Some folks will
think of this as the configured equivalent of meta-data based steering.)
2') For FEs with deployable components, there should be capability
infromation indicating what LFBs the FE supports, and something about
how
they can be interconnected.

[HK] Agree, same as my point above.

What you describe is a static LFB topology with service based steering
among the paths (either by metadata or by classification.  This will
commonly happen (After all, not all packets receive the same service.)

But there are other things that happen.  During operation, the service
owner decides to start offering a new service.  If the FE supports
conbfigurable LFBs, this may involve creating / instantiating / enabling
new LFBs, and connecting such LFBs to existing LFBs.  The owner may also
decide to stop offering a service, and may cancel use of certain
LFBs.  Both of these might involve only changing classifiers (in static
FEs) or instructing the FE to create a whole new LFB, or ...

[HK] I guess my question is what do you mean by creating or
instantiating
LFBs ? If you mean downloading code onto FEs for new LFBs then this is
out of the current scope of ForCES is my understanding. If you mean 
activating certain paths between LFBs that we not used during the
previous
operational state, then you could do that at runtime using the NextLFBID
metadata. This in turn is conceptually changing the Operational LFB
topology,
so I agree in that sense it is a topology change.
However, it is not changing the Topology (constraint) graph which was 
reported during capability discovery.

Yours,
Joel M. Halpern

---

From: Zsolt Haraszti <[email-masked]>
Date: Wed, 5 Nov 2003 18:14:07 -0500

Hormuzd,

See my comments below. (I see that Joel has answered in
the meantime, but I decided to send this anyway.)

> any constraints on the connections between LFBs.

I don't think this is feasible for the generic case.  If the FE
is very rigid, the above approach may work to describe the
"maximum" configuration.  But, in a very programmable FE
(where a large set of LFBs classes can be instantiated and
configured in almost arbitrary topologies) the above approach
does not work.  We need to come up with a scheme that can
provide for both of these extremes.  We have to keep in mind,
that the capability description does not have to be perfect;
we can leave some details to the try-and-fail feedback.

> metadata.
> This in turn is conceptually changing the Operational LFB
> topology,

Since when does the topology graph represent *constraint* rather
than the actual current topology?  Maybe I missed some
conversation?

--
Zsolt Haraszti                                     Tel: +1 919 472 9949
Ericsson IP Infrastructure                         Fax: +1 919 472 9999
Raleigh NC USA                       Email: [email-masked]

---

From: Avri Doria <[email-masked]>
Date: Mon, 10 Nov 2003 10:16:16 -0600

On onsdag, nov 5, 2003, at 14:25 US/Central, Khosravi, Hormuzd M wrote:

> If you mean downloading code onto FEs for new LFBs then this is
> out of the current scope of ForCES is my understanding.

I have seen this statement several times, but other then the assertion,
don't understand why it is out of scope.  There is nothing in the
charter that prohibits as far as I can tell.  I also don't see the
architecture are precluding it.

It seems to me an important capability to include even if current HW
designs cannot, currently, take advantage of a full dynamic capability.

It concerns me that at ever step of the decision process we seem t
limit the capability and the dynamicity of the architecture and of the
models.

a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 10 Nov 2003 08:32:44 -0800

I think making such a feature part of the protocol may be
unnecessary. LFBs can be downloaded via other mechanisms
(http(s), ssh, ftp, tftp etc).
CEM-FEM communication in the preassociation or even at runtime
phase can say which are trusted places to download such LFBs (and what
transport to use etc).
That interface may also be used to download such code (and "create or
installing the LFB" to use what Robert/Joel terms) .
Note you already trust the CE, so you can use the CE to store such
LFBs.
I think we may have bigger problems to resolve first (although i am
indifferent to this). So lets not get too excited about this (peripheral
issue).

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Nov 2003 11:54:12 -0500

My only concern is that defining the protocol envelop for carrying code
fragments gets rather "interesting".  I certainly would hope / expect that
the architecture would not preclude supporting this in the future.

Partially, I am trying to find a reasonable balance point on what we
include in the initial support.  I was trying to suggest that
reconfigurable topology but not reconfigurable LFB types was a reasonable
and useful point for the initial protocol.

We should always be watching both sides of the tension, to provide enough
capability to be useful but not so much that we can not complete the task.

Yours,
Joel M. Halpern

---

From: Alan DeKok <[email-masked]>
Date: Sun, 9 Nov 2003 18:19:09 -0500

> the architecture would not preclude supporting this in the future.

  Security considerations make this capability very problematic.  Email
systems sending viruses are on thing, but re-programming an FE on the
fly has a whole other set of issues.

  Alan DeKok.

---

From: Avri Doria <[email-masked]>
Date: Mon, 10 Nov 2003 13:31:51 -0600

> fly has a whole other set of issues.

While security concerns would definitely need to be dealt with, I don't 
see them as being of such a nature that they would preclude the 
possibility.

a.