Subject: Re: [issue32] Packet Redirect

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 23 Jul 2005 14:33:49 -0700

My thinking would be the latter (below). We should strive to keep the
model, lfb library, etc relatively simple atleast for the first rev...we
can add more flexibility for the second rev as we learn more from
different usage scenarios and implementation experiences.

regards
Hormuzd

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

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

At 04:39 PM 7/23/2005, Khosravi, Hormuzd M wrote:
>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 22:05:28 -0400

I suppose as long as we define a configurable meta-data transcoder, I can 
live with making the meta-data IDs fixed by the LFB definition.

Just for completeness, I do have one other concern.  If we make the 
meta-data ID fixed, then the LFB designer has to figure out what id makes 
sense for any meta-data he generates, and what ids are assigned for 
meta-data he wants.  This means that the process of defining an LFB is now 
intertwined much more tightly with the definition of other existing or new 
LFB definitions.

Yours,
Joel