<chair hat off; speaking only as an individual member of the WG>
In looking at the description of the dyanmic proxy behavior, I was
reminded of a problem that the SFC working group wrestled with and never
resolved to our satisfaction. (In the SFC case, since we were not
specifying the behavior of the proxy, we could leave it to implementors.
This document seems to be more specific.)
As I understand the draft, the dyanicm proxy for a non-SR aware service
function can be handling packets subject ot multiple service policies.
That is desirable. These separate policies will have separate cache
entries. Also good.
But as far as I can tell, the re-attachment of the cached header to the
returned packet (from the non-SR aware SF) is done based on first come,
first cache.
What happens if, due to differences in internal processing, packets from
different service policies get swapped in time. So packets go in
Packet-1, Packet-2, but come out Packet-2, Packet-1. The text seems to
result in the proxy reattaching the SR information to the wrong packets?
Am I misreading the text?
Depending upon ones, reading, this may apply to a case where a single
device is service as multiple static proxies for a single non-SR aware
SF. It was not clear if that was intended to be allowed, but if so the
same issue would seem to apply.
Yours,
Joel
<chair hat returning to wherever it belongs.>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
