Subject: [spring] Dynamic Proxy in SR service programming

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jul 2020 13:49:10 -0400

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

---

From: Stefano Salsano <[email-masked]>
Date: Sun, 26 Jul 2020 02:31:38 +0200

> returned packet (from the non-SR aware SF) is done based on first come, 

Hi Joel,

I'm speaking as an author of draft-ietf-spring-sr-service-programming-02 
(but I do not know if my opinion is agreed by all the authors)

my understanding of the dynamic proxy scenario is that a given "non-SR 
aware service function" (aka "legacy VNF") can be associated with a 
single Service Chain at a given time

so you can dynamically change the Service Chain by sending a Packet-2 
with a different SR policy with respect to Packet-1, but this is meant 
to change the Service Chain for the following packets of the flow, 
rather than to operate on a packet-by-packet basis

you are right that operating on a packet-by-packet basis leads to 
inconsistent behavior!

In draft-ietf-spring-sr-service-programming-02, the following limitation 
is associated to the static SR proxy, but it also applies to the dynamic 
proxy:

    However, a static SR proxy
    segment can be used in only one service policy at a time.  As opposed
    to most other segment types, a static SR proxy segment is bound to a
    unique list of segments, which represents a directed SR service
    policy.  This is due to the cached SR information being defined in
    the segment configuration.  This limitation only prevents multiple
    segment lists from using the same static SR proxy segment at the same
    time, but a single segment list can be shared by any number of
    traffic flows.

This is he description of the dynamic proxy:

    The dynamic proxy is an improvement over the static proxy that
    dynamically learns the SR information before removing it from the
    incoming traffic.

Maybe it would be better to explicitly clarify that the same limitation 
of the static SR proxy is applicable: "only one service policy at a 
time"... the difference is that you can change this association 
dynamically, e.g. in the order of few seconds but NOT on a 
packet-by-packet basis

hope that it clarifies...

ciao
Stefano

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Jul 2020 20:56:42 -0400

Thank you.  That does clarify, and it would probably be good to be 
explicit in the document.  (The restriction makes sense, we just need to 
be clear.)

Yours,
Joel

On 7/25/2020 8:31 PM, Stefano Salsano wrote:
>> 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.
> 
> Hi Joel,
> 
>> 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?
>>
>> SF.  It was not clear if that was intended to be allowed, but if so 
>> the same issue would seem to apply.
>>
>> Yours,
>> Joel

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Sun, 26 Jul 2020 19:32:40 +0000

Hi Joel,

Thank you for your email.

At high-level, the dynamic proxy combines a caching mechanism with a mapping scheme that associates cache entries to packets or flows.

There are many possible mapping schemes, each has pros and cons that make it more suitable in some environments and less in others. This I-D describes a simple one, which is interface-based (or VLAN-based), and implies that a dynamic proxy SID is used in a single SID-list at a time. This makes it particularly suitable for container-based environments, where VNFs are spawned on a per-SFC basis.

In different environments, other mapping techniques could be used, such as those described in draft-song-sfc-legacy-sf-mapping.

Cheers,
Francois

On 26/07/2020 02:57, "spring on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 26 Jul 2020 15:36:41 -0400

Thank you.  I think it would help if this were spelled out more clearly 
in the draft.

Yours,
Joel