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

Ole Troan <otroan@employees.org> Mon, 25 May 2020 16:22 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 86ADD3A0D8D; Mon, 25 May 2020 09:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mA3T5ENiFDk6; Mon, 25 May 2020 09:22:34 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::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 52AEC3A0D8A; Mon, 25 May 2020 09:22:34 -0700 (PDT)
Received: from [IPv6:2a01:79d:53aa:d30:848:12b6:f3b4:f8c4] (unknown [IPv6:2a01:79d:53aa:d30:848:12b6:f3b4:f8c4]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 3A2D74E11B63; Mon, 25 May 2020 16:22:33 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
Date: Mon, 25 May 2020 18:22:29 +0200
Message-Id: <936AF2E6-7D66-451D-A79D-7C9155D7535F@employees.org>
References: <DM6PR05MB63482E49DEB39E7692DD3F7FAEB30@DM6PR05MB6348.namprd05.prod.outlook.com>
Cc: Sander Steffann <sander@steffann.nl>, Robert Raszuk <robert@raszuk.net>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
In-Reply-To: <DM6PR05MB63482E49DEB39E7692DD3F7FAEB30@DM6PR05MB6348.namprd05.prod.outlook.com>
To: Ron Bonica <rbonica@juniper.net>
X-Mailer: iPhone Mail (17F75)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/la6Vy9BA2DhPEvp0uwj58akn8jg>
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 16:22:39 -0000


> On 25 May 2020, at 17:49, Ron Bonica <rbonica@juniper.net> wrote:
> 
> Ole,
> 
> When commenting on list, could you indicate whether hats are on or off?

And that is important to you for this particular message because?

> Juniper Business Use Only

Ole

> -----Original Message-----
> From: otroan@employees.org <otroan@employees.org> 
> Sent: Monday, May 25, 2020 6:31 AM
> To: Sander Steffann <sander@steffann.nl>
> Cc: Robert Raszuk <robert@raszuk.net>; Ron Bonica <rbonica@juniper.net>; spring@ietf.org; 6man <6man@ietf.org>; rtg-ads@ietf.org; Ketan Talaulikar (ketant) <ketant@cisco.com>
> Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
> 
> [External Email. Be cautious of content]
> 
> 
> 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