[spring] Conclusion from WG poll on dataplane solution for compressing segment routing over IPv6

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 06 September 2021 17:26 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 EAC673A1759 for <spring@ietfa.amsl.com>; Mon, 6 Sep 2021 10:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 2GaEhHJ0clyR for <spring@ietfa.amsl.com>; Mon, 6 Sep 2021 10:26:53 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.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 293F93A1758 for <spring@ietf.org>; Mon, 6 Sep 2021 10:26:53 -0700 (PDT)
Received: from localhost (localhost []) by mailb2.tigertech.net (Postfix) with ESMTP id 4H3Fgw5PWPz1ns3d for <spring@ietf.org>; Mon, 6 Sep 2021 10:26:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1630949212; bh=k3UR3uiTBYQJKpCSDTvwWg5FtjCQzsIqc34/tGBkhyI=; h=To:From:Subject:Date:From; b=fPGBsa8piOyLamHnbCZgB2iuQqGaeRQK0Xke7hvNvOouvkUxtwqB8Ss+KdsO0ThRq 2Mkoe3TJ6aFcr0Bgl8ichMC5M/ayrAv/GLEbDWNMXsMRe5kFYzLQQHzGQBE/aBzRy6 OUGnQ+4Lv3uDPfuo0t12NYQCgLqQl4M/vPUywhYc=
X-Quarantine-ID: <utcILnmV4-GJ>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [] (50-233-136-230-static.hfc.comcastbusiness.net []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4H3Fgw2Kp9z1nryr for <spring@ietf.org>; Mon, 6 Sep 2021 10:26:52 -0700 (PDT)
To: "spring@ietf.org" <spring@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <d060f258-4e7d-51a8-2ced-69cfe2daa31f@joelhalpern.com>
Date: Mon, 06 Sep 2021 13:26:50 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.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/eggaG-ygj88hruJ3AnMzjwYOqtk>
Subject: [spring] Conclusion from WG poll on dataplane solution for compressing segment routing over IPv6
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: Mon, 06 Sep 2021 17:26:58 -0000

Our thanks to the working group members for speaking up clearly.  There 
is a rough (quite clear) consensus for standardizing one dataplane 
solution to compressing segment routing over IPv6.

As chairs, there are some related observations we need to make.
There appears to be significant interest in using the framework in the 
CSID draft for addressing the above.

However, before we issue a call for adoption on that, the chairs would 
like to understand how the working group wants to solve a technical 
problem.  The CSID draft contains two dataplane solutions.  The above 
rough consensus is for one dataplane solution.  Does the working group 
want to choose one?  Do the authors want to suggest that one of the two 
is the one we should standardize, and get working group agreement?
Should we adopt the document, with a note indicating the problem, and 
solve the problem afterwards?  (That itself does not solve the problem, 
it merely kicks it down the road.) Do folks see another means to avoid 
putting the WG in conflict with itself?

As a loosely related side node, the chairs will also observe that we do 
not see an obstacle to informational or experimental publication of 
other solutions, as long as there is sufficient energy in the working 
group to deal with those.  Also, only documents for which there is at 
least one implementation will be progressed this way.

Thank you,
Bruno, Jim, and Joel