Subject: model draft comments

From: Jamal Hadi <[email-masked]>
Date: Wed, 1 Jan 2003 15:30:23 -0800

Folks,

I finally read or more like attempted to read but couldnt get myself to
really focus on completely digesting the draft. I see this draft as
attempts to be too many things at once without addressing clearly what i
see as the real issues.
I was tempted to write an alternative point of view, but realize we may
not be that much different in the perspective of looking at this. So heres
the way i see it:

- I believe there are two layers to the modelling and your draft doesnt
make a clear distinction between the two and hence the chaos.

1) A functional block layer:
A functional block provides a mechanism for packet massaging.
It must be told how to treat packets that traverse it.
Typical modelling of a functional block would involve a table of sorts.
The rows would represent states of _instances_ of the functional block.

2) A datapath layer:
This is a graph/serialization of _instances_ of functional blocks as
defined in a _policy_.

Figure 6 in the draft is a good represantation the two. There are several
instances of meters for example (representing layer 1 above) and a
policy is used to interconnect them. In my opinion, this is sufficient
representation.

To digress: the ForCES protocol tells the individual functional blocks
what to do (i.e it populates their tables with appropriate parameters).
The CE maintains the datapath layer and its synchronization and would
send a series of ForCEs messages (perhaps one to each functional block
or to a group of blocks in the instantiated datapath/policy) to create a
policy. What is being referenced in the draft is more akin to a CE point
of view than an FE one - although thats not how it is potrayed.

In order to help in laying out and managing the policy, the details that
help are:
a) capabilities:
"this FE can handle IPv4 and IPv6 forwarding"
b) Capacity
"This FE has 8192 IPv4 table forwarding rows per port"

These i believe are important elements of the model and maybe sufficient
to express it.
I am not sure if b) is that important for modeling really.

The last item which seems to be an obsession with the draft is:
datapath flow i.e how the fucntional blocks are laid out; in other words,
what i refer to as policy.
I think this adds a lot of complexity in the equation. If you factor it
out to a CE concern (as opposed to it being an FE concern as in the
draft)  then it may be useful. Whether you believe or like it or not,
implementors tend to use the model draft.
In my opinion there should be no restrictions on how functional blocks are
laid out. Lets leave that to the admin and whatever smarts the CE has
to dissalow certain graphs of functional blocks (this may be useful for
certain legacy devices).
In more flexible devices - allow the admin/operator to  shoot themselves
if they wanted to (example use a combination that may not make any sense).
This is the essence of good design/architectures (Look at how much the C
language or unix allows in terms of policies).

There are also a few implementation specific obscenities in the draft
but i wont go into details because we seem to differ in the basics and we
need to talk about that first.

cheers,
jamal

---

From: Alan DeKok <[email-masked]>
Date: Mon, 6 Jan 2003 14:04:18 -0500

> It must be told how to treat packets that traverse it.

  I agree.

> This is a graph/serialization of _instances_ of functional blocks as

  I agree.  Note that it's possible to define, address, and manage
functional blocks, completely independently of their interconnections
(graph topology.)  In addition, doing topology discover and
configuration is an *extremely* difficult task.

  Page 5 of the draft, near the bottom, has the text:

    "However, the CE cannot reconfigure the graph topology
     dynamically, such as adding another meter or queue onto
     the FE in Figure 6 on the fly."

  To me, this would indicate that it's probably not necessary for the CE
to know the topology.  That is, if your "configuration" and "control" of
something is limited to knowing it exists, then it you might as well
treat it as if it didn't exist.

> of view than an FE one - although thats not how it is potrayed.

  It's a conceptual view of how ForCES would fit into a larger
environment.  It needs details (or agreement on details) of the kind
"ForCES applies here, but not there."

  Topology should probably be out of scope of ForCES, at least for the
initial design and implementation.

> what i refer to as policy.

  .. and the draft refers to as "graph topology"

> implementors tend to use the model draft.

  I believe that those issues need to be discussed in the draft, if only
to show how functional blocks fit into a larger application.

> to dissalow certain graphs of functional blocks (this may be useful for

  I agree.

  Alan DeKok.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 8 Jan 2003 12:50:53 -0500

We have a basic choice about where on the spectrum of CE / FE
controllability we wish to be.
We could declare that the component graph is strictly under the control of
the FE, and the CE has no say in it.  If we say that, we will still need a
way for the CE to understand the graph, but we we will be restricted in the
services a CE can enable by the graph that actually exists on the FE.
We could declare that the CE must be able to change the component graph in
any way it wants to.  This would allow any service in principle.  In
practice, this would be impossible, as no FE will allow every possible
configuration of any possible number of graph elements.

Thus, it seems (and has seemed) to me that we need to allow the CE to
discover and manipulate the graph.  There are limitations on that graph
manipulation (and on the element manipulations) which can readily be
communicated (in capabilities for example) so that the CE will generally
know what it can and cannot do.  There will be limitations on the graph and
element manipulations which will not be captured in the capabilities, and
will result in the CE receiving errors when it attempts some service
establishments.

As far as I can tell, while we can adjust where in this middle ground we
are (and we should try for a good balance between power and simplicity in
the point we select), we must operate in this middle ground.

Yours,
Joel M. Halpern

---

From: Alan DeKok <[email-masked]>
Date: Wed, 8 Jan 2003 13:36:59 -0500

> controllability we wish to be.

  My opinion is that we can avoid much of this discussion by agreeing on
elements which are common across the spectrum, or models.

  e.g. Addressing a particular component of the graph is independent of
how the graph is represented, and who represents it.  The CE could
simply be told "here's a collection of handles to components", and can
often manage those components without knowing their relationships.

> way for the CE to understand the graph,

  I agree it would be useful for the CE to understand the graph, but I'm
not sure it's required.  I would like to have diagrams and examples of
the various scenarios to put the discussion on a concrete setting.
Until then, the discussion is too vague to enable us to move forwards.

> but we we will be restricted in the

  And the connections between the graph elements are often static, and
defined by physical traces on a board.

> will result in the CE receiving errors when it attempts some service

  I agree.  We now have some interesting questions.

1. How do we represent the graph?
2. Where is that graph representation stored at boot time?
3. How is that information communicated to the elements which need it?

  e.g. Systems with PCI busses can do PCI queries, and have a
well-defined way of discovering any graph topology at boot time.
Application-layer changes aren't required.

  Do we want systems supporting ForCES to have a similar discovery
protocol?  How do we address the graph components?  How do we
communicate component capabilities?

  Graph topology is a difficult area to work with.  I'd like to see
those issues seperated from the component configuration and control,
which is where I see ForCES being applied.

  Alan DeKok.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 8 Jan 2003 17:52:22 -0500

> services a CE can enable by the graph that actually exists on the FE.

The FE should really only own the component/node/element and its config. It
should be able to refuse a config for a node - but thats as far as it should
go if it should stay simple. Policy control should not be under the FEs
domain (rather owned by the CE).

> configuration of any possible number of graph elements.

The graph layouts aka policy being owned by the CE is a very good start i.e
the CE sees the big picture. You can embed the intelligence in the CE to
decide what the possible configuration of the graph elements are. You can
also embed the intelligence of what possible per-element configs are in the
CE (either after youve discovered them or by virtue of them being well
known). The graph element should be able to reject specific configs (in which
case the graph instance is incomplete).

> know what it can and cannot do.

Discovery of element manipulations is a well known science.
Discovery of the possibilities of graph configurations adds a second
dimension to the challenge and is a hard problem .. This is what Alan was
saying and i agree with him. protocols like COPS tried to resolve this but in
my opinion are insufficient and very limiting (that is why it is so hard to
add new extensions to COPS). Forgeting "legacy" devices for a sec - i think a
free hand in policy description is the way to go. Give someone a gun and let
them shoot themsleves. If you wanna put restrictions put them in the CE in
the form of ACLs - make it part of the configuration.

> There will be limitations on the graph and

yes, thats a fallback - but i only see that for element config. For graph
config, packets going to never land is your fault.

> the point we select), we must operate in this middle ground.

My opinion of the role of the two dimensions (element vs graph manipulation)
is pretty clear. what do you conmsider a middle ground?

cheers,
jamal

> > > or to a group of blocks in the instantiated datapath/policy) to create
> > > a policy. What is being referenced in the draft is more akin to a CE
> > > point of view than an FE one - although thats not how it is potrayed.
> >
> > > datapath flow i.e how the fucntional blocks are laid out; in other
> > > words, what i refer to as policy.
> >
> > > In my opinion there should be no restrictions on how functional blocks
> > > are laid out. Lets leave that to the admin and whatever smarts the CE
> > > has to dissalow certain graphs of functional blocks (this may be useful
> > > for certain legacy devices).
> >
> >   I agree.
> >
> >   Alan DeKok.