Subject: Re: [issue32] Packet Redirect

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 23 Jul 2005 13:39:55 -0700

Joel,

I did some thinking on this and I couldn't see how having configurable
meta-data would make things simpler for the protocol or model. Having
unique meta-data IDs per LFB is a much more simpler approach IMHO. I
don't think this list will be very large and this way seems to be more
manageable to me...its in line with our common philosophy of keeping
things simple atleast for the 1st rev of the protocol/model.

My 2 cents
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Sunday, July 17, 2005 2:25 PM
To: [email-masked]
Subject: Re: [FORCES] [issue32] Packet Redirect

This was a topic of major discussion within the model team.
The cases which drive it get complex.

Firstly, there is the simple case of a meta-data classfiier.  This
accepts 
packets on its input, looks at their meta-data, and selects the output.
Clearly, such an LFB must have a selectable meta-data usage, so that you

can use if after the port-id, or after the DSCP selection, or ...

Then, we get into more complex situations.  SUppse that we want to have
the 
output port of an LFB selected by a piece of meta-data.  We could try to

assign globally unique IDs, and define the meta-data ID that this LFB
uses.
At the same time we have the LPM lfb which produces an extress
interface, 
possibly a port, and possibly some next hope identifying information.
We 
could try to define which of those correspond with the output port
Identifier.
And we could ensure it was different from the input port identifier.
But then someone defines a new LFB that sometimes wants to use next-hop
ID 
and sometimes wants to use port-ID (maybe to cope differently with
p-to-p 
interfaces).
And gradually we add more LFBs, and they want different meta-data values
to 
match, etc.
We would (and may eventually anyway) need to create a meta-data
rewireter 
that by configuration copies values from certain meta-data items to
certain 
other meta-data items.
That will work.

Or we take the approach that the identifier (not the semantics, just the

identifier) of the meta-data item used or produced by each LFB needs to
be 
configured.

This whole issue is finessed in the model.  My own feeling is that since

some items will necessarily require configurable meta-data handling, it 
seems much simpler to always se configurable meta-data selection.

Yours,
Joel

PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their

thinking never got into the document.  They probably have a better idea
of 
what is really needed and why.

At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote:
>Joel,
>
>I am not sure I understand why the Identifiers will be assigned by the
>CE?
>Isnt this just another Type that will be defined in the Model...e.g.
>Id=Port, metadata value=port_id
>
>Let me know what I am missing here,
>
>Thanks
>Hormuzd
>
>-----Original Message-----
>
>This looks good to me.
>My only quibble (minor difference) is with the description that the
>identifier portion of the meta-data ILV is assigned by the model.  We
>have
>not worked this out, but I think that the identifiers are probably
going
>to
>end up assigned by the CE.
>(The implication of this is that if one CE takes over for another, it
>may
>have to do some analysis to get the meanings for the meta-data
>identifiers.  But it should be simple to find the LFBs where the
>meta-data
>is created, and determine what ID is configured to be used for it.  And
>this needs to be described somewhere in either the model or the
protocol
>
>document.  I think it will go in the meta-data portion of the model
>draft.)
>
>Yours,
>Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 23 Jul 2005 17:16:48 -0400

It is certainly attractive to simply define for a given LFB what meta-data 
ID it uses / produces.
If we want to take that approach, then we are going to frequently need to 
make use of meta-data transcoders whose only function is to take meta-data 
of ID x and turn it into meta-data of ID y.
This comes up because one could easily have a classifier that uses "port" 
(say ID 12), but a tunnel processor that produces "tunnel-id" (say id 
34).  And the CE wants the classifier to use the tunnel ID as the port for 
its work.

If we believe that the significant majority of the time we can get the IDs 
right, then the LFB definition can include the meta-data ID.  I am doubtful.

Yours,
Joel