Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

otroan@employees.org Mon, 25 May 2020 10:31 UTC

Return-Path: <otroan@employees.org>
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 BC6133A0B64; Mon, 25 May 2020 03:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 N6wnR0cjIIiK; Mon, 25 May 2020 03:31:05 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EA63A0B74; Mon, 25 May 2020 03:31:02 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [173.38.220.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 0B2B94E11B86; Mon, 25 May 2020 10:31:02 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B228B34D8847; Mon, 25 May 2020 12:30:58 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
From: otroan@employees.org
In-Reply-To: <43FE1AA8-D2B8-4EBD-8775-69C53D663D25@steffann.nl>
Date: Mon, 25 May 2020 12:30:58 +0200
Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD04A44D-4F9F-404C-8F20-79D9E875AACD@employees.org>
References: <9CF68CCE-B584-4648-84DA-F2DBEA94622D@cisco.com> <C7C2E1C43D652C4E9E49FE7517C236CB02A2C1AE@dggeml529-mbx.china.huawei.com> <DM6PR05MB6348A22A123AFA7E7345087BAEB70@DM6PR05MB6348.namprd05.prod.outlook.com> <MW3PR11MB457041A967A6BBDA1C7EF0FDC1B70@MW3PR11MB4570.namprd11.prod.outlook.com> <93a31c7f-a102-da59-d9a8-2585cd8e3c65@gmail.com> <MW3PR11MB4570B197EE00C5385DAEE138C1B40@MW3PR11MB4570.namprd11.prod.outlook.com> <5F062FA6-9E2D-46BB-A3D6-257D374D8F92@gmail.com> <MW3PR11MB4570485EEDBADEF3B193BB82C1B40@MW3PR11MB4570.namprd11.prod.outlook.com> <ec63e90e-19fa-cd6c-eacb-4dee44815c99@joelhalpern.com> <MW3PR11MB4570FB2397D4B28A42626802C1B40@MW3PR11MB4570.namprd11.prod.outlook.com> <3bbb28c8-0106-ad63-abf9-c9dc4e428e0c@joelhalpern.com> <MW3PR11MB4570FD37ED32519C677F5E59C1B20@MW3PR11MB4570.namprd11.prod.outlook.com> <DM6PR05MB63486B842CD9DF5BE57FC1A5AEB30@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMFT-JVWOhRoJ3UBsvmYrYvt96N7vkL3_v9Sq4PXzNtzAw@mail.gmail.com> <43FE1AA8-D2B8-4EBD-8775-69C53D663D25@steffann.nl>
To: Sander Steffann <sander@steffann.nl>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yM5UJc-jzQDYSzY90-bV7lQ8zjA>
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: Mon, 25 May 2020 10:31:14 -0000

Sander,

>> Your below list looks like custom made set of RFP requirements to eliminate any other vendor or any other solution to solve the problem at hand rather then rational list of requirements.
> 
> My main customer (an ISP in NL) would fit exactly in the list that Ron sent. They want a simple solution that they can understand and manage, that works over IPv6. Whether the path will include many nodes (>8) is not known at this point, but they want something that can support it in the future.
> 
> So the list of requirements isn't that strange.

That CRH is simple is a bit like claiming that MPLS is simple just because the header has few fields.
I think you would be hard pressed to substantiate that any solution here is particularly simpler than any other. But you are welcome to try.

Everyone claims to want a simple solution, funnily enough the end result is usually the opposite. The words "simple" and "source routing" are oxymorons.
Let's leave the marketing out of this.

Ole