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

Tony Li <> Tue, 07 September 2021 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EFEA3A03FF for <>; Tue, 7 Sep 2021 15:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cTwXjabcWogF for <>; Tue, 7 Sep 2021 15:58:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 736DC3A03FC for <>; Tue, 7 Sep 2021 15:58:42 -0700 (PDT)
Received: by with SMTP id k17so127723pls.0 for <>; Tue, 07 Sep 2021 15:58:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wA411jMLcQNe7WzOI/N1t8CmS7D+QNgkdMDadQCySYg=; b=dDC62l4Jbv8/maJkfgY8kCzWFZrxCkINNzBumBu50JseYAQE7gBuPBckqOFmZzXVB7 ym22yqK3opxdSkiDg63tkRKvfGlgCi16Hfha/SZZdkcHeXnpBLtUzgBEAZVykuy5gbrt 4T7y6MW4Qx3mpRxQgM3tM5mPw4eMbD90yNLpK2HdFO9tPlcmAKn0EsMDYbzoYNA6YBWY xQvMTSR32ES2cYDvEY71Xq76vecONAe6s51ki/YxQWvy8BGbCLM4UiN+HhI3DtOefDws nCE40sdO+jDFkmeOtUT115KBRC2ro3fDgcDmwiqW8cT2e8xxiLJN4ZH+inSJlbJfbPcU eZKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=wA411jMLcQNe7WzOI/N1t8CmS7D+QNgkdMDadQCySYg=; b=Pe+t/nvx7AqGfd1AZNxCm6gIUasVDGriKWD7iCJ8cfZI6q+yTqaQBdGbWMXWr6+e1j wJkvfoShuWZDlGb84FhAebV5EZjB+Qynmc+s/Z0aO+oo2z7JXk+7MhHU3YpO7qrmDMlD XwXndWK4tPSfr63uex1FJ5ec//zC6N8ntBnz+zVPdO7Oz4/upeJSkLAfBK6y7EFelccM iBDxRUCb62kDY+9jRfIdwkqsciY3FOkdtlzS8vmi6GofHi1sH7UM4sO+8yk6h/nGWdaN TJpjD3zM3MDdHEoLsFcKkD9WUnF4fjg1UYTPwnplDWoGH4fwh5fTrobRnIIayEOnboLe mrgw==
X-Gm-Message-State: AOAM532RH2f3t/KKXfWl5imh4nGrIKo9nXPQFXb0GXlov1H+1Kjwlych YSlfujfSzuCtLB3P2ztelBOLi4GvrBI=
X-Google-Smtp-Source: ABdhPJzBZGnOdV6dHMXHTSf4+BVLwpgrZHcCZvR7fgl2AiBRq+lddk3TZwD6nlxkHhic35UBPew7Vg==
X-Received: by 2002:a17:902:a5c2:b0:13a:31dc:8417 with SMTP id t2-20020a170902a5c200b0013a31dc8417mr373729plq.88.1631055521448; Tue, 07 Sep 2021 15:58:41 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 3sm130132pfp.112.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Sep 2021 15:58:40 -0700 (PDT)
Sender: Tony Li <>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Tony Li <>
In-Reply-To: <>
Date: Tue, 07 Sep 2021 15:58:40 -0700
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Joel M. Halpern" <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [spring] Conclusion from WG poll on dataplane solution for compressing segment routing over IPv6
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: Tue, 07 Sep 2021 22:58:49 -0000

Dear chairs & WG,

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

I’m very pleased that we’ve found the courage to say that we want to make a decision.

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

I concur that there is interest in CSID.  However, as we have not yet done a consensus check to select the specific proposal, I hope that this is not your assertion that CSID is the result. This is a major decision by the WG and it does deserve a formal and explicit check.

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

If the authors of the CSID proposal, or any proposal, would like to revise their proposals before we make a selection, this would seem to be an opportune time.