Subject: Re: [issue32] Packet Redirect

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 16 Jul 2005 22:54:38 -0700

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: Sun, 17 Jul 2005 17:25:01 -0400

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.