Re: [spring] General Proxy behavior in SR Service Programming

Joel Halpern Direct <jmh.direct@joelhalpern.com> Sun, 26 July 2020 19:41 UTC

Return-Path: <jmh.direct@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 E12933A13F0 for <spring@ietfa.amsl.com>; Sun, 26 Jul 2020 12:41:40 -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 P6vj3CtXZGrr for <spring@ietfa.amsl.com>; Sun, 26 Jul 2020 12:41:39 -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 758CD3A13EF for <spring@ietf.org>; Sun, 26 Jul 2020 12:41:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BFCxH2JPYz6G8tJ; Sun, 26 Jul 2020 12:41:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1595792499; bh=2tNkCV8BKkltMGk2sBx77MgZVezFwM03O3BxRIKB/ns=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DFSxuFsP8y9PJIdWV3ai5fx/ZsofbZu5RBwXOokEp4XV06AuHnTXMtRCXatlWLzMf lUC+YlvSnZPfxrei18FWcO3pHQArtLosy+MiE8QOkPD1YooFL27MzfHIMTMYAkJOnX c3jF61VNU56SUFvd2V0aE5fDBrd62a3Pv6yo8FU8=
X-Quarantine-ID: <lQG19dlZL1W8>
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 4BFCxG5vY4z6G7Kw; Sun, 26 Jul 2020 12:41:37 -0700 (PDT)
To: "Francois Clad (fclad)" <fclad@cisco.com>, "spring@ietf.org" <spring@ietf.org>
References: <3c542370-c7dd-9ec2-8120-186f24b993b2@joelhalpern.com> <AD76C305-5108-4C7C-9946-D9B001E86071@cisco.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <b61a023a-f3dc-158a-d16d-0d85d41ac67c@joelhalpern.com>
Date: Sun, 26 Jul 2020 15:41:36 -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: <AD76C305-5108-4C7C-9946-D9B001E86071@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/GviA4Ys4NN4d-Ypgxr94vtvV3qs>
Subject: Re: [spring] General Proxy behavior 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:41:41 -0000

In the shared memory case, indeed, it is very reasonable to look at the 
proxy as an arm of the function.
In SFC, we do look at it (the proxy as an arm of the SF) that way more 
generally.  We can do that because the SFC architecture calls that out.

Given that the other cases do involve network transfer of packets, and 
thus are visible, and given that neither the SR architecture, the MPLS 
architecture, nor the SR architecture call out such things, it seems 
that we need to be explicit.  To be clear, I think it is a very 
reasonable approach.   Much mroe reasonable, for example, than NAT in 
its various incarnations.  All I am asking is that we state explicitly 
that we understand that as an architectural component this violates 
existing rules, and does so over a limited scope so as to preserve the 
desired / needed behavior over the larger scope.  The one thing we may 
need to be clear about is the degree of proximity required between the 
SF and its serving proxy.  If we treat this as legitimate arbitrary 
networking, it gets out of hand.

Yours,
Joel

On 7/26/2020 3:33 PM, Francois Clad (fclad) wrote:
> Hi Joel,
> 
> Thank you for your email.
> 
> A proxy and its associated SF can be seen from the network as a single entity: a packet enters this entity from the network, gets processed by the SF, and exits towards the network. The packet modifications that occur between the entry and exit of this entity are compliant with existing standards.
> 
> Whatever happens between the proxy and SF is internal processing and invisible to the network. However, a network operator or controller needs some information about the proxy’s internal behavior to determine an appropriate SID-list through the SF and possibly configure the proxy.
> 
> Cheers,
> Francois
> 
> 
> On 25/07/2020 20:23, "spring on behalf of Joel M. Halpern" <spring-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:
> 
>      <chair hat off for now;  This issue may, depending upon resolution,
>      become a chair issue, in which case, I will look at it through a
>      different lens.  Heck, I may even disagree with myself.>
> 
>      Let me start by saying that I understand and support what the draft is
>      trying to do.  While I like SFC, I am under no illusions that it is or
>      should be the only answer to service chaining / service programming.
> 
>      Further, I understand what the proxies are for.  They seem necessary.
>      To deploy this stuff, we have to be able to work with older equipment.
>      Proxies seem the best way to do so.
> 
>      The document is even clear that  proxy is a new kind of thing.  Good.
> 
>      In order to do its job, and as I read this document, the SR proxies (of
>      various kinds) violate the rules for MPLS processing, SRH processing,
>      and IPv6 processing at various points.  They have to.
> 
>      It seems to me that we need to accept this requirement, and state it
>      clearly.  Most likely, this would suggest that we will want some form of
>      signoff from the MPLS and 6man working groups that these violations, for
>      these specific reasons, are acceptable to the community.  Personally, I
>      would rather have the discussion soon, rather than pretending it is a
>      non-issue and having the discussion during IETF last call.
> 
>      Maybe I am misreading, and things are less conflicted.  That would be great.
> 
>      Yours,
>      Joel
> 
>      <chair hat returning to wherever it belongs.>
> 
>      _______________________________________________
>      spring mailing list
>      spring@ietf.org
>      https://www.ietf.org/mailman/listinfo/spring
>