Subject: Re: metadata

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 16 Mar 2004 08:54:32 -0800

See below <LY>...</LY>
> -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>

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.

<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 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>

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.

<LY> Of course it can consume multiple metadatum. I don't see why not. 
</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, 

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
> 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 dont follow this, but i will read on and see if it gets clarified.

<LY> Again, it is just the naming problem, as I explained below.
</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,
> 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