Subject: Re: A discussion of metadata in ForCES

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 21 Oct 2003 10:16:03 -0700

Thanks, Alan, for the clarification. So it sounds that we agree and we are on the same page --
1) LFB are only logical concepts used by FE model to describe FE and may not exist as physical entity at all. So there is no such thing as LFB interoperability.
2) Logical definition of LFB-external metadata is necessary so that LFBs can be linked together to form a logically consistent model for FE.

Lily

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Alan DeKok
> Sent: Tuesday, October 21, 2003 9:55 AM
> To: [email-masked]
> Subject: Re: A discussion of metadata in ForCES
> 
> 
> "Yang, Lily L" wrote:
> >
> > 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?
> 
>   Yes.  The vendor implementations of LFB's may have internal
> information which is outside of the scope of the ForCES model.
> 
> > 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?
> 
>   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".
> 
> > 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.
> 
>   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.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Oct 2003 14:18:30 -0500

One aspect that gets complicated is that even though the meta-data passed
between LFBs is internal to the FE and not visible to the CE, the CE must
be able to understand the semantics and capabilities of the meta-data so
that he can set up data paths that will actually work and do the
job.  (Obviously, some information that the CE thinks is meta-data may
actually be buried in LFB topology, and some information that the CE thinks
is topology may actually be carried as meta-data.  But there needs to be a
reasonable level to talk about this in the CE-FE protocol.)

Yours,
Joel

At 11:09 AM 10/27/2003 -0800, you wrote:
> > 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]
>
>
> > [mailto:[email-masked]] On Behalf Of Alan DeKok
> > Sent: Monday, October 27, 2003 10:41 AM
> > 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
> > 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: "Cain, Gamil" <[email-masked]>
Date: Mon, 27 Oct 2003 13:45:03 -0800

All good points.  I will stay tuned in.

Thanks,

Gamil Cain
Software Architect

> Sent: Monday, October 27, 2003 1:40 PM
> "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.