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 10:55 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 B2E083A0DEB; Tue, 26 May 2020 03:55:22 -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=ham 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 bP2_MAgia4gH; Tue, 26 May 2020 03:55:20 -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 3E91B3A0DE2; Tue, 26 May 2020 03:55:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 72BB44C; Tue, 26 May 2020 12:55:14 +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=1590490512; bh=9X74ct77zcN3yZ6YI+2 JLZh1ySUD7Li66aGo8CXYChc=; b=OxOgEBvyUMi1O17oRAsYFIo5E9NwkdfOqbV ybJ/F7amrBPgK7AAD3ZDauH15eG69y5xHYeA3vh+6nfmKBzIk05obOSWDiX2IWfZ IgAsIKzu0SD/Fh6w+cjQFoTjzhUMcMWql6nvcM4UFOwSquk2Fds5TfLMhY9qvryA 5Si0oazs=
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 orO7NNnNpJpq; Tue, 26 May 2020 12:55:12 +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 1ECCA3C; Tue, 26 May 2020 12:55:12 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <46D9BE97-FD71-4E52-A276-3ADCC13B6822@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_6814B5AF-6AE1-4FAD-9A77-5365D4B4D58B"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Date: Tue, 26 May 2020 12:55:10 +0200
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297B9C599@dggeml510-mbs.china.huawei.com>
Cc: "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: Mach Chen <mach.chen@huawei.com>
References: <641D69E6-39D6-4EFD-A04E-1E33D585BEAE@cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297B9C599@dggeml510-mbs.china.huawei.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hEqLkUk-sIndpEeI5AN0fHNixHM>
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 10:55:23 -0000

Hi,

> Take a step back, assume SRm6 is also adopted, there will be two solutions for the community to choose; there will be interop issues between the two solutions. The vendors will have to support both to make different customers happy, more money will be spent and will be finally payed by the SPs/customers.
> 
> Do we really want this?

Speaking as an operator: yes

Different (parts of) network use different IGPs, different architectures (leaf/spine, clos, core/edge/distribution/access, STP, MLAG, VXLAN, EVPN, VPLS, L2VPN Martini or Kompella) etc etc etc. There is no "one solution fits all", and there are many things besides the feature set that determine what an operator will use. And some technologies will become obsolete, and the networks move on. But as an operator I want to choose. I don't want my vendors or the IETF to choose for me.

Cheers,
Sander

v2.23.0 | Report a Bug | By Email