Subject: Re: A discussion of metadata in ForCES

From: "Cain, Gamil" <[email-masked]>
Date: Mon, 27 Oct 2003 11:09:53 -0800

> This means
> well-defined protocols, and metadata.  Defining the terms we use is
> therefore within the scope of ForCES.

Agreed.  Definition of terms (your original contribution) definitely.  I
guess what I'm more concerned about are the "well-defined protocols, and
metadata".  What will ForCES be defining in this regard?  You bring up a
good point that the FE is already "open" via the model doc.  And I don't
think I have much concern with defining metadata *concepts* as part of
looking inside the FE.  That makes sense.  In my view, however,
"well-defined protocols, and metadata" goes a step further then the
conceptual view and starts to get quite specific about what metadata
looks like.  Is it the intent of ForCES to go to this level or stay at
the conceptual level (question is slightly divergent from your original
contib. which seems to stay at the conceptual level).

Thanks,

Gamil Cain
Software Architect
Intel Research & Development
916.356.9153
mailto:[email-masked]

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Monday, October 27, 2003 10:41 AM
> To: [email-masked]
> Subject: Re: A discussion of metadata in ForCES
> 
> Gamil Cain wrote:
> >
> > My question is of a similar vein as Lily's.  It seems to me that by
> > defining external metadata (as the text above suggests) ForCES may
need
> to
> > crack open the FE (which I thought was viewed as a black box, from a
> ForCES
> > perspective).
> 
>   The model document already "opens" the FE, if only from a
> modelling/black-box point of view.
> 
> >  So is this really in scope for ForCES or should ForCES just
> > assume that there is a mechanism for transporting information across
> FEs?
> 
>   The FE's must communicate, so any information which is exchanged
> between FE's must be in a mutually understandable format.  This means
> well-defined protocols, and metadata.  Defining the terms we use is
> therefore within the scope of ForCES.
> 
> > Taking from your response to Lily's questions:
> >
> > "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."
> >
> > So what's the difference between being "interoperable" and
"compatible".
> 
>   Interoperable means that they communicate & interpret metadata
> programmatically.  The systems are "compatible" on both conceptual,
and
> on physical levels.
> 
>   Compatible means that the *concepts* of metadata are the same, but
the
> systems may not communicate that metadata directly.
> 
>   There is overlap between the two terms, but I'm not sure that
they're
> identical in meaning.  My response quoted above was meant to show that
> there may be things in the model which are not in the physical system.
> The physical system does not have to inter-operate using the concepts,
> but the concepts MUST be compatible from the perspective of fulfilling
> the conceptual goals.
> 
> >  And I'm still not sure how
> > you go about defining metadata (in ForCES) without opening up the FE
> "black-
> > box" and making some judgment on what's going on inside that FE.  Is
the
> FE
> > a black box or not?  I think if ForCES goes to the point of
specifying
> > metadata, the FE (to a certain extent) is no longer a black box.
> 
>   As I said, the model document already "opens" the FE black box.  My
> document adds no more requirements or restrictions on ForCES.
Instead,
> I'm simply trying to define the terms we use in ForCES, as there has
> historically been controversy and confusion surrounding the word
> "metadata".
> 
> > I have another concern that there could be overlap, and possibly
> > incompatability, between metadata definition work done within ForCES
and
> > work being done within NPF of a similar nature.
> 
>   Most companies involved in NPF are also involved in IETF.  In some
> cases, it's the same person in NPF & ForCES.  While I'm not involved
in
> NPF, I was involved historically, and I still follow it.  The person
at
> IDT who is involved sits near me, and we coordinate our efforts.
> 
>   Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 27 Oct 2003 16:40:01 -0500

"Cain, Gamil" wrote:
> metadata".  What will ForCES be defining in this regard?

  ForCES should define sufficient things to allow the system to be
implemented, and to inte-operate across multiple vendors.

  Yes, that's vague enough to be a cop-out.

  Another way of saying it is "I don't know, we need more experience
with the model & the protocol proposals."

>  You bring up a
> looks like.

  As Joel pointed out, the CE is going to have to tell the FE to do
*something* with packets.  That configuration MUST include metadata.

>  Is it the intent of ForCES to go to this level or stay at

  My contribution intentionally stays at the conceptual level, because
people have historically been unable to agree on the concepts.  And
without agreement on concepts, any implementation is contradictory and
useless.

  Alan DeKok.