Re: [spring] Dynamic Proxy in SR service programming

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 26 July 2020 19:36 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B046F3A13E8 for <spring@ietfa.amsl.com>; Sun, 26 Jul 2020 12:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr6LRujfuUod for <spring@ietfa.amsl.com>; Sun, 26 Jul 2020 12:36:44 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090213A13E4 for <spring@ietf.org>; Sun, 26 Jul 2020 12:36:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BFCqb6TmLz6G9jW; Sun, 26 Jul 2020 12:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1595792203; bh=lty4WSQ3ntMYR5aqZKqSOYPhJJGBq03CJQ4/yva6olk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=fzB45N4GzhbAJcnjb/pK6HiiqWYslTQBPdIBFjh/UWrM5Rf32Xm30BVQbNOftJmNr z3nQJL1CzUUDDgKl31JxObt+95AaOuAHIDA97anSpJxuDcNK3pBM4JGWbhXD8I6EUl bOtqgpvwZxAaqvJRSUUKi2DgpSc2Er2cGF8kxNbo=
X-Quarantine-ID: <eXK-c9VPdQuw>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BFCqZ3Swrz6G7Mk; Sun, 26 Jul 2020 12:36:42 -0700 (PDT)
To: "Francois Clad (fclad)" <fclad@cisco.com>, Stefano Salsano <stefano.salsano@uniroma2.it>, "spring@ietf.org" <spring@ietf.org>
References: <9175c5f7-0f1a-38db-55e5-0a0255a43622@joelhalpern.com> <acffc87a-7918-5b06-8bc5-a36fc175ba76@uniroma2.it> <47f13681-caf9-64ed-8ca7-604f4d552983@joelhalpern.com> <421B04D6-14B1-4A46-A2B9-93B999A5424F@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <0c20cb09-d02a-0405-a631-469f782c578b@joelhalpern.com>
Date: Sun, 26 Jul 2020 15:36:41 -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: <421B04D6-14B1-4A46-A2B9-93B999A5424F@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ACR-27F-use2ZWWcwSTEcV4jxP8>
Subject: Re: [spring] Dynamic Proxy in SR service programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2020 19:36:46 -0000

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

Yours,
Joel

On 7/26/2020 3:32 PM, Francois Clad (fclad) wrote:
> 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" <spring-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:
> 
>      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:
>      > 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
>      >> spring@ietf.org
>      >> https://www.ietf.org/mailman/listinfo/spring
>      >
>      >
> 
>      _______________________________________________
>      spring mailing list
>      spring@ietf.org
>      https://www.ietf.org/mailman/listinfo/spring
>