Subject: New draft "ForCES FE Functional Model Elements"

From: Steven Blake <[email-masked]>
Date: Tue, 1 Jul 2003 16:27:21 -0400

Zsolt Haraszti and I have put together a draft on the elements needed
for the ForCES FE functional model.  It is complimentary to
draft-yang-forces-model.  Since we missed the deadline for I-D
submissions, I have placed the draft at

http://www.petri-meat.com/slblake/networking/drafts/draft-haraszti-forces-model-00.txt

We hope that this contribution helps move the model definition effort
forward.  Any comments would be appreciated.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Jul 2003 17:12:35 -0400

An interesting and useful approach to describing this.

Allow me to use this document as a hook to raise a question that I think we
have all been skirting.  Our documents talk about supporting and using
meta-data.  Most of us assume that meta-data (support and usage) is
important for getting workable solutions.

However, I suspect that we have as many models of meta-data as we have
participants.  This document has one model in it (a collection of
name-value pairs).  I have seen many others (including arbitrary text
strings, arbitrary bit strings, a stack of name-value pairs,
etc.  Different models treat the consumption of metadata
differently.  (This one says you consume what you do not explicitly pass
on.  Others state that you pass on what you do not explicitly
consume.  Others take different views.)

1) It strikes me that we should be careful to be explicit whenever we
assume a model of metadata usage.
2) I would personally like to concentrate on getting the core work done,
leaving the meta-data unspecified at first.  I think this has the best hope
of our getting a usable result in a modest amount of time.
3) If we are going to work on meta-data, I would like to treat it as a
separate work item, and get moving on it.

Yours,
Joel M. Halpern

PS: This is not a criticism of the Haraszti / Blake document.  This
document is pretty good about explicitly describing its meta-data model,
particularly since this issue has not been raised in the group thus far.

---

From: Steven Blake <[email-masked]>
Date: Wed, 9 Jul 2003 16:42:55 -0400

> An interesting and useful approach to describing this.

Thanks Joel.

> consume.  Others take different views.)

What we are trying to say is that, for metadata a LFB receives and uses
internally, it either explicitly reads & propagates it, or consumes it.
For metadata that is not used internally, the model should indicate what
limits (if any) a LFB has on transparently propagating that metadata (or
metadata in general).

> assume a model of metadata usage.

Agreed.

> separate work item, and get moving on it.

I'm not sure I understand your point.  I'm not sure how to model a
forwarding path without specifying the metadata that is exchanged
between the LFBs.

Regards,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Jul 2003 17:21:53 -0400

My approach to skirting meta-data is based on an assumption / observation.
Given a decent set of blocks, there are a lot of capabilities that can be
controlled / delivered without any reference to metadata.  One can assemble
an IP forwarding engine, coupled to diffserve classifiers and queuers that
could handle a large range of cases.  While meta-data would expand the
range, the absence of meta-data does not make it useless.
Then, we could start getting that out while we see how we can best describe
meta-data and it uses / limits.

Yours,
Joel M. Halpern

---

From: Steven Blake <[email-masked]>
Date: Wed, 9 Jul 2003 17:31:24 -0400

> meta-data and it uses / limits.

Coming out of the Classifier, how does the Queuer figure out which queue
to put the packet in?  If you use a topological representation (e.g., a
distinct Classifier output per-entry) then this could work, as each
Classifier output would be directed to a unique Queuer input dedicated
to a single queue.  But then you have committed to solving the dynamic
LFB topology problem long-term (e.g., to support a variety of Diffserv
processing actions per-Classifier entry) rather than meta-data problem.

Regards,

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Jul 2003 13:15:22 -0400

Steven Blake <[email-masked]> wrote:
> to a single queue.

  See: draft-yang-forces-model-02.txt, sections 5.2.4 and 5.2.5

  The model includes a classifier which produces meta-data and has one
output, and a classifier which doesn't produce metadata, but has N
outputs.

>  But then you have committed to solving the dynamic

  In the short term, topology is easier to deal with than metadata.  As
the model draft says, the hope is that we may be able to agree on
representation and interpretation for the metadata.  That will allow us
to better describe the system, and to describe & control how the Queuer
interprets the results of classification.

  Alan DeKok.