Subject: Re: metadata

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 15 Mar 2004 19:36:28 -0800

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Monday, March 15, 2004 7:12 PM
To: [email-masked]
Subject: metadata

-Is the modelling assuming the metadata to be of a certain size?
Last time i suggested a type/tag:lenght:value model, not sure
i got a response or not.

<LY> In theory, metadata *value* type can be of any atomic data type, as
defined in the LFB schema. But typically we expect 32-bit value is good
for most. Of course, there are times when 32-bit is not sufficient, for
example, for MAC address or IPv6 Address.
</LY>

-I dont see a mention whether multiple types of metadatum could
be received by the same LFB or produced by an LFB.
<LY> Well, by "metadata type", I suppose you really just meant "metadata
tags", right? In another word, one LFB can produce multiple metadata. Of
course. 
</LY>

- I am not sure if the classifier is a good example of a variable
producer. Seems to me it produces only one type of metadata with a
tag of CLASS_ID. A good example would be the IPV4 LPM example i gave
earlier which may create a NHLFE_ID tag or NH_ID tag.

<LY> CLASS_ID could be the name for the produced metadata for a
classifier. IPv4 LPM could be regarded as another classifier, with the
metadata output as NH_ID. It doesn't matter which one, the problem is
that you got to fix the "tag" when you define the classifier. Sometimes
that creates trouble if that doesn't match what the consumer expects. So
variable tag comes in handy at such times.
</LY>

- I am still struggling to follow the redirector example in 3.2.4.3
which conditionaly uses a classid or protocoltype as its work selector.
Care to explain a little more?
<LY> I suspect the trouble you are having is thinking sth more
complicated than what it really is -- it is all about names, "tag"
names. So you have 
+-------------+     +----------------+
| NextHop LFB |---->| redirector LFB |--->
+-------------+     +----------------+

Now, nextHop LFB is defined by you, Jamal, while simultaneously, 
- On enumeration and binding; isnt all metadata always bound at some
point. I.e if theres a producer, there has to be a consumer.
And when it is bound, doesnt it have to be enumerated? (maybe not as
exhaustively as a simple meter).

- on explicit metadata: Why does it make a difference what the metadata
is used for? if the result is a table update, a packet creation,
shrinking, expansion etc - why is it important to distinguish how that
metadata is used?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Mar 2004 09:36:59 -0500

Hi Lily,

> example, for MAC address or IPv6 Address.

32 bit is the most common value i know being used (especially in
hardcoded ASICs). There are cases where it is insufficient. Since
the model is generic, i suggest we introduce the size/lenght portion.

> tags", right? In another word, one LFB can produce multiple metadata. Of

By Type i mean tag.
You responded to one side of that question. If an LFB can produce
multiple metadatum, is it true then it can consume multiple such
metadatum? Not a trick question, just the fact the text doesnt talk
about it.

> metadata output as NH_ID.
>  It doesn't matter which one,

Sure most LFBs will have some classifier built in (which classifies
based on pakect and/or metadatum).
The text I am referencing is talking about something along the lines of
a 5 tuple clasifier not LPM.

> the problem is

I dont follow this, but i will read on and see if it gets clarified.

> complicated than what it really is
>
> -- it is all about names, "tag" names. So you have
> somebody else (say Lily) is defining redirector LFB. Since we don't talk
> to each other or can't agree with each other even if we try to talk, so
> nextHop LFB is defined with output metadata tag called "nextHopID",
> while redirector LFB insists on an input metadata tag of "ClassID". You
> see the problem? Somehow when you put these two together, you need to
> configure them so that "nextHopID" becomes "ClassID". That is what the
> selector attribute is for.
>
> Now, you will say, if Lily and Jamal talk and agree, we shouldn't have
> this problem. Well, what about another LFB, say meter LFB defined by
> Joel,(with a metadata called "color") is followed by the same redirector
> LFB?
> It's just all about names. Alias.
> </LY>

Gotcha. Yes this is simpler than i thought ;-> Translation: the text description
in the draft really SUCKS ;-> Actually i just read it twice and i still
dont get the message above.
Let me repeat what i think you just said:
- "nextHopID" is just an alias to "ClassID" since two different people
created the two LFBs who cares what they call them.
- that consistency is still there with at least the ID output by NextHop LFB
that is consumed by the Redirector LFB. Else the CE would make theres
consistency.
Is this correct?

I will wait for Zsolts input on the other two items.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Mar 2004 09:49:20 -0500

If we take it one step further, I think we are there.  Given that there can
be multiple consumers, and multiple producers, the produced nextHopID can
be seen as an alias for ClassID at an LFB that utilizes ClassiD, and may be
an alias for Color at an LFB that utilizes Color.
So, we frequently need some form of aliasing.

Yours,
Joel

PS: Now, to try to figure out how to get the text so that a reader who has
not seen this conversation will get the right understanding.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 16 Mar 2004 10:12:12 -0500

> So, we frequently need some form of aliasing.

Almost sounds like a scoping problem: Is the scope/validity of a tag
only within the LFB class? Is the primary assumption that multiple LFB
authors need not agree on the tags before the LFBs are used to provide a
service?
I would think that scoping resolution happens at the CE whether
predefined or not. Is this correct? Still trying to put things together
before coming with text.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Mar 2004 10:55:50 -0500

We had assumed that some kinds of metadata would have well defined tags
that would be used consistently by the various LFBs that produce / consume
them.  We also assume that this is not true of all LFBs.
Clearly, it is the CEs job to construct the necessary consistency.  The
obvious way to do this is by setting the tags that are generated, and
setting the tags that are used.  Not all tags need to be adjustable.
We may have crafted too many alternatives, but we were trying not to
restrict the implementations.  My gut feeling is that once we have an LFB
library and some meta-data usage we can look again at how much
configurability / aliasing we need to allow.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 17 Mar 2004 07:51:06 -0500

On Tue, 2004-03-16 at 10:55, Joel M. Halpern wrote:
> setting the tags that are used.

Nod.

> Not all tags need to be adjustable.

I cant come up with good wording to rewrite that text because i may have
to get rid of the tag selector thingy (which seems almost implementation
detail). So i will leave it to the authors.

On Tue, 2004-03-16 at 11:54, Yang, Lily L wrote:

> <LY> This is indeed covered by the datatype in the LFB XML schema.
> It will become clear when you get to Section 4.
> </LY>

I will keep this in mind.

> <LY> Of course it can consume multiple metadatum. I don't see why not.
> </LY>

It is not in the text; that may indicate exclusion. English is an
ambigous language.

cheers,
jamal