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

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

Return-Path: <sander@steffann.nl>
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 662383A0F90; Tue, 26 May 2020 07:31:05 -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 1ATaaCt_vfYD; Tue, 26 May 2020 07:30:50 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::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 C5B7C3A1018; Tue, 26 May 2020 07:30:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 4E05E4C; Tue, 26 May 2020 16:30:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1590503443; bh=J0d3RzURx7MulM3QDHh 4kU2qZUteKDGu1DHn6q0bDuc=; b=P/5xU//hPpzVOHmq7ojKCJFnGlT99Op9V59 NY37e+nhl/YRCdA6DeHv+lIGbiS2D7y7vQnBbYVmVVCEcdKlD2Ki2RY7rKkMGw4V FttY293G0kdoCckFXvuYBqi4/pvxvF5G7RS9DWsNt+EfeC29N9ykR/HCTp9R2aM2 b1eZ18vY=
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 g6BbCVp5oFYo; Tue, 26 May 2020 16:30:43 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:19f6:dcc2:c2ab:45c4] (unknown [IPv6:2a02:a213:a300:ce80:19f6:dcc2:c2ab:45c4]) (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 A441B49; Tue, 26 May 2020 16:30:42 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <EDB1EA57-406E-46C8-B4B3-CCCF178D1AE8@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_4E614B1E-3EE9-40D3-AAED-E8496B445C30"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 26 May 2020 16:30:41 +0200
In-Reply-To: <C70B4EA4-5B92-498F-8D94-ABA3E70AFCA4@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>
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
References: <C70B4EA4-5B92-498F-8D94-ABA3E70AFCA4@nokia.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/W5n-tz7MqwfeplqPwa6oFftKluc>
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
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: Tue, 26 May 2020 14:31:11 -0000

Hi Wim,

> I agree that if you look into the details RFC8663 from a data-plane operation is very similar to CRH. It uses a tag and derives a destination ipv6 address from it.
> On top it if you look at the requirements, the following is possible with RFC8663
> 
> 	• It can steer the packet through a specific path. Implementations exists which do well beyond 8
> 	• No new VPN encapsulation is required
> 	• No new service chaining needed and various options possible.
> 	• Compliant to SPRING
> 	• Uses MPLS but it is used here as a lookup tag, not any different than the CRH proposal. In essence if you look at the details you can implement this with a complete v6 infrastructure and use the tag as a steering function. And uses 32 bit.
> 
> As such I don’t see why we need another encap to achieve something we already can do and is available in various implementations and is as efficient on the wire (looking at 32 bit, which is what people agree upon)

RFC8663 doesn't work between domains that are not directly connected. I want a solution where the connectivity between the domains is plain IPv6 (e.g. the internet). I have tried this with Andrew using CRH and that works fine. Part of the SR domain was in Kenya, part of it was in The Netherlands, and we could use CRH without any problems. That isn't possible using MPLS.

Cheers,
Sander