IETF Logo Mail Archive

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Sander Steffann <sander@steffann.nl> Thu, 28 May 2020 15:02 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 94EB53A0E80; Thu, 28 May 2020 08:02:59 -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 ZXGodbdiTowq; Thu, 28 May 2020 08:02:58 -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 C7E753A0E7A; Thu, 28 May 2020 08:02:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 285CE49; Thu, 28 May 2020 17:02:52 +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=1590678170; bh=2tsZLOJwuSnBr/qTB4r 6tt0wH7hJ5s6a+f3/zQiNKwA=; b=ddZR2zeAR04eKqbHfhVRcD+jscZ8v+lsP5x ZAYP5ERW0LwOnV/3kU0AN6D4QvVplJ5r8YA+VaEIWeXuHRpACZ2/9gP/j0+Hm5Co /TIX+0eXsx/vXP+pt2xnkL5xyFL6sEoaOwwbl+CeRVQ0k0vXOE1P0iT4Nvm9TtzT UKXc7Wwk=
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 ezZ9s51kH4Y1; Thu, 28 May 2020 17:02:50 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:8095:8735:6dd9:e6de] (unknown [IPv6:2a02:a213:a300:ce80:8095:8735:6dd9:e6de]) (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 B18293C; Thu, 28 May 2020 17:02:49 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <66F3150A-FF45-4890-A864-E870475D4CA9@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_4DE9ED2D-55A8-4639-BC63-39E64D717CF0"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 28 May 2020 17:02:48 +0200
In-Reply-To: <FC7E2896-CFBB-4CD7-B110-F87ECB4FFE6A@steffann.nl>
Cc: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "Zafar Ali (zali)" <zali@cisco.com>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
To: Robert Raszuk <robert@raszuk.net>
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <DM6PR05MB6348D86E8BE339067C5238E4AEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <30C37AC0-B03A-45B1-BE0F-7E185361BBBC@liquidtelecom.com> <64e6b98b01c64ec8b699c065bc7ee9e0@boeing.com> <94DF5577-4DCC-4491-A12B-21EAC214172F@cisco.com> <aa7edfd5c56b4e2883e2e91649fc6061@boeing.com> <7A3F2E3E-687F-4C53-B1F9-1BF593356384@cisco.com> <45de95803b734d73a0288a09332c445f@boeing.com> <CAOj+MMH-1RbicwqHVueeokRq-FNm2QWkyCQXuyZdR2xFvdh13g@mail.gmail.com> <FC7E2896-CFBB-4CD7-B110-F87ECB4FFE6A@steffann.nl>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/i-_3p55wTrJJ6_vjJDMRsM6l8sQ>
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: 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: Thu, 28 May 2020 15:03:00 -0000

> And this is an important difference: some of us don't want encapsulation/tunneling, we want something that can be part of a non-encapsulated packet. There are use-cases where CRH used with encapsulating is the best solution, and there are cases where the packet itself can be steered without encapsulation. CRH allows both, and therefore covers more possible use-cases than RFC8663. This makes CRH a building block that some of us desire.

PS: any IPv6 extension header can be replaced with one or more encapsulations. Even SRv6 can be implemented by encapsulating the packet separately for every segment, like the TOR network does. I don't buy the "you can already do this with encapsulation" argument. If that would become a valid argument then IPv6 innovation is dead.

Cheers,
Sander

v2.23.0 | Report a Bug | By Email