IETF Logo Mail Archive

Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Sander Steffann <sander@steffann.nl> Tue, 26 May 2020 19:17 UTC

Return-Path: <sander@steffann.nl>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF943A0F09; Tue, 26 May 2020 12:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
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 Y1B_Fw6UHLHH; Tue, 26 May 2020 12:17:23 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 6C9AD3A0F0B; Tue, 26 May 2020 12:17:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 3E9924D; Tue, 26 May 2020 21:17:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:in-reply-to:references:message-id:date:date:subject :subject:mime-version:from:from:content-transfer-encoding :content-type:content-type:received:received; s=mail; t= 1590520636; bh=AbYAt133UeGH7DhCECHDVuI8PEfH7IZ7XKiYlkC4+Q0=; b=C znZ1KlWpju5e9dl3yDaH2HtD9lv2WxevYeD2soYWuRq9t/eUCwIwvjO1KSDv5OJm ZRCDtDiPx7ctiB2Bdc193tzhiyqKYINnuyRwzkohKAry1XsWFYZvHb6QdnLy59g8 dmX/WCuY5mjNkdRmsNCPh/gH1fWcipNXRVH2E7+Jp8=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gvxRkmBffgNd; Tue, 26 May 2020 21:17:16 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:4047:9a1c:3280:98fe] (unknown [IPv6:2a02:a213:a300:ce80:4047:9a1c:3280:98fe]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 02B6B4C; Tue, 26 May 2020 21:17:15 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Mime-Version: 1.0 (1.0)
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Date: Tue, 26 May 2020 21:17:14 +0200
Message-Id: <51B3FE50-DF61-49B3-9A28-B8B70E5DF6ED@steffann.nl>
References: <A87CBF94-3E2C-4AA9-9034-57248832D372@nokia.com>
Cc: Mach Chen <mach.chen@huawei.com>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "Chengli (Cheng Li)" <c.l@huawei.com>, 6man <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
In-Reply-To: <A87CBF94-3E2C-4AA9-9034-57248832D372@nokia.com>
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
X-Mailer: iPhone Mail (17E262)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/LWva8MWmxHsGoOY6x93ZHWjmrj4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2020 19:17:27 -0000

Hi Wim,

> WH> We are either all encapsulating or not, but in essence the point is that the difference is you put the sids in the extension header versus next header. Lets leave it like this. All in all what I am saying is RFC8663 allows you to do what you intend with CRH.

No, I can't. You're not reading what i wrote. I want packet steering without encapsulation: a plain IPv6 pakket with a RH and plain UDP, TCP etc in the payload.

Please stop telling me that RFC8663 is the answer, because it's not.

Sander

v2.23.0 | Report a Bug | By Email