[spring] General Proxy behavior in SR Service Programming

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 25 July 2020 18:23 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0D10C3A081C for <spring@ietfa.amsl.com>; Sat, 25 Jul 2020 11:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tjsQHnJPP4Is for <spring@ietfa.amsl.com>; Sat, 25 Jul 2020 11:23:14 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net []) (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 19EF43A081B for <spring@ietf.org>; Sat, 25 Jul 2020 11:23:14 -0700 (PDT)
Received: from localhost (localhost []) by maila2.tigertech.net (Postfix) with ESMTP id 4BDZFF6dx6z6G8pq for <spring@ietf.org>; Sat, 25 Jul 2020 11:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1595701393; bh=X7SXzefR//3Qfh97egwSy0mqGzZDNyWTC3REJOanrx8=; h=To:From:Subject:Date:From; b=aB+6vlcG0hwDza8HHJ6BY9W84H5XliH9ZHFD3jSDIZahzPwq9ULwDT9PnDswgVW25 +G7vPkwbDl48S13uKSWWh9SvbxDW2WoOBmoUMVA6VbfoE8oOCBt5QfGXzATPVRbY0K VDiguYZe5sDgyuRHftp1mSEA84bSCAnxFIEDkeW0=
X-Quarantine-ID: <zvxSwKlVsiha>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [] (209-255-163-147.ip.mcleodusa.net []) (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 4BDZFF3hW9z6G7LF for <spring@ietf.org>; Sat, 25 Jul 2020 11:23:12 -0700 (PDT)
To: "spring@ietf.org" <spring@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <3c542370-c7dd-9ec2-8120-186f24b993b2@joelhalpern.com>
Date: Sat, 25 Jul 2020 14:23:09 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/NVJhrii4FkUXOAG0yQRrPv_WE9o>
Subject: [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: Sat, 25 Jul 2020 18:23:15 -0000

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


<chair hat returning to wherever it belongs.>