Re: [spring] Dynamic Proxy in SR service programming

"Joel M. Halpern" <> Sun, 26 July 2020 00:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD9543A0475 for <>; Sat, 25 Jul 2020 17:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nNOAukE4pcHK for <>; Sat, 25 Jul 2020 17:56:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCF4C3A045B for <>; Sat, 25 Jul 2020 17:56:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BDkzJ4wBlz6G932; Sat, 25 Jul 2020 17:56:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1595725004; bh=ONzoiuQkTtzRSlnXD+0xBkkM0Si3S0/TWi36Wu8xoKI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=qc4Jw6XPc/biq+EoPm2EuNXNZOydphCrqtY67vqlRNliMBUUAH+ZSZClVg2mXk0jT b+Si5yG9woxgJLShJzpku+vOjliQnLEXuoYQXpZ6TvCLN4wJ8JjdKyhWlF8oQvLCZJ Rxi3YrZEOl54X99Iy77lMbNAb1LVwMVUpObhL5/Q=
X-Quarantine-ID: <SkIMNVDDBqC2>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4BDkzJ0F9bz6G7Mk; Sat, 25 Jul 2020 17:56:43 -0700 (PDT)
To: Stefano Salsano <>,
References: <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Sat, 25 Jul 2020 20:56:42 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [spring] Dynamic Proxy in SR service programming
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Jul 2020 00:56:48 -0000

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


On 7/25/2020 8:31 PM, Stefano Salsano wrote:
> Il 2020-07-25 19:49, Joel M. Halpern ha scritto:
>> <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.
> 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
>> 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