Subject: Re: A discussion of metadata in ForCES

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 20 Oct 2003 12:31:11 -0700

Alan --
When you discussed internal & external metadata and said the former is
out of scope of ForCES while the latter is within the scope, I suppose
you mean internal or external at the LFB level, right?

You said, "In contrast, as one of the goals of ForCES is to facilitate
inter-vendor communication, External metadata is within the scope of
   ForCES.  The group should create definitions of, and standards for,
   External metadata which permit different vendor implementations of
   devices to communicate metadata." I want to clarify what you meant by
"inter-vendor communication" and "standards" -- Do you mean we ought to
define metadata for LFB such that LFB A from vendor X can be
inter-operable with LFB B from vendor Y?

My understanding of ForCES's focus and mission is to ensure
interoperability at the FE and CE level, but not at the LFB level. We
define the concept of LFBs just so that we can describe and configure
the functions of FE meaningfully and modually, but not to make LFBs from
different vendors work seamlessly together. LFB interopeability is a
fine goal by itself, but it may be overly ambitious and out of scope for
ForCES.

Lily

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Thursday, October 16, 2003 12:24 PM
To: [email-masked]
Subject: Re: A discussion of metadata in ForCES

"Joel M. Halpern" wrote:
>
> There is a big difference between requiring that LFBs document their
> "preconditions" (and "postconditions") and trying to formally specify
such
> things.

  While my goal is to formally specify such things, I currently don't
know how to do so.  That's why the document was vague as to
implementation details.

> Even if one thinks that such a capability (computerize condition
checking)
> would be useful, I would think we would want to defer that work till
later
> and get the basics working first.

  Absolutely.  The intention of the document was to cut short the
circular discussions of metadata which I've seen in the past.  Once we
have a common vocabulary for communication, we can then later work on
defining computer representations of our intentions.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 21 Oct 2003 12:55:09 -0400

> you mean internal or external at the LFB level, right?

  Yes.  The vendor implementations of LFB's may have internal
information which is outside of the scope of the ForCES model.

> inter-operable with LFB B from vendor Y?

  I was intentionally vague as to the scope of that inter-operability.
Such issues are contentious, and I would like to agree on vocabulary &
goals, before discussing implementations and standards.

  I do believe that the metadata used in CE -> FE configuration MAY be
independent of that used in the LFB's, or in the actual FE.  e.g. A CE
may tell an FE "this packet goes out port 5", but there should be no
requirement that the metadata in the FE either exists, or is represented
by a sequence of N bits with value "5".

> fine goal by itself, but it may be overly ambitious and out of scope for

  We need to use common terminology when creating the model, and dealing
with LFB's.  I do not expect anyone to implement the LFB's as defined in
the model, so there should be no requirement that LFB implementations
are inter-operable.

  However, all LFB's exist within the model, so in the model, the LFB's
and any metadata they use MUST be "compatible".  If the metadata used in
the model is different from LFB to LFB, then those LFB's cannot be used
to build a self-consistent model.

  At a higher level, the *conceptions* of metadata must be compatible
between different vendor's engineers, during human discussions about
ForCES.  Acheiving consensus and compatibility in human discussions
about metadata was the main goal of the document.

  Alan DeKok.