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: 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 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\))
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/spring/eFI0zCBF0rU1OPJQQ_dokG0zrzI>
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 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
- [spring] CRH is not needed - Re: How CRH support … Zafar Ali (zali)
- Re: [spring] CRH is not needed - Re: How CRH supp… Mach Chen
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Andrew Alston
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… James Guichard
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Robert Raszuk
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… Tom Herbert
- Re: [spring] CRH is not needed - Re: How CRH supp… John Scudder
- Re: [spring] CRH is not needed - Re: How CRH supp… Andrew Alston
- Re: [spring] CRH is not needed - Re: How CRH supp… Robert Raszuk
- Re: [spring] CRH is not needed - Re: How CRH supp… John Scudder
- Re: [spring] CRH is not needed - Re: How CRH supp… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [spring] CRH is not needed - Re: How CRH supp… Sander Steffann
- Re: [spring] CRH is not needed - Re: How CRH supp… 刘毅松