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

Sander Steffann <sander@steffann.nl> Fri, 29 May 2020 13:15 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 AE8073A084E; Fri, 29 May 2020 06:15:31 -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 bH65dwtbhINf; Fri, 29 May 2020 06:15:28 -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 7CA323A0847; Fri, 29 May 2020 06:15:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 681F64B; Fri, 29 May 2020 15:15:24 +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=1590758122; bh=HU1pl0M6EJ3ePVtRrzU I8R0dx0trIHEKtYiTXR/u5A4=; b=Twkg08PGYcyPwsrgMikl27acd50D019xEkl CdZGOv4VQ3KKaAsIAF8MZ3AJXfy8E0NSem8uALP3DPI2wpOlnuNGB6glHMWRVmEX k0zccFlvdaERQubeEdmaN5m0l8xotCk/IA5vgGc6g2adH3v7TuMb7TG9SMBeMJFO Qf+FNKsE=
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 kK8y78tJM5Dy; Fri, 29 May 2020 15:15:22 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:d565:a455:92fd:c189] (unknown [IPv6:2a02:a213:a300:ce80:d565:a455:92fd:c189]) (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 D98163C; Fri, 29 May 2020 15:15:21 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <C749DB48-6CAA-4986-B586-EE6204685150@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_6FB63A70-1CFA-4D6F-A453-50029633176A"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Date: Fri, 29 May 2020 15:15:20 +0200
In-Reply-To: <FC665D06-F0D0-4822-9FF3-5013FE58D38F@nokia.com>
Cc: Robert Raszuk <robert@raszuk.net>, "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>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
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> <FC665D06-F0D0-4822-9FF3-5013FE58D38F@nokia.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jcNYfLmk6Ku3mxFUYMVHUmAB4S4>
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: Fri, 29 May 2020 13:15:32 -0000

Hi Wim,

> Sander, can you describe your use case. So far the only thing that people has asked CRH to do is steering and as mentioned we have solutions for those. If there are others, please share them..

Well, a routing header is obviously for steering, but not only encapsulated payloads need steering. A use case would be to steer control plane packets along a path. And because CRH works well together with existing headers it would be possible to provide a DO header for the named nodes along the path.

I can imagine using it for debugging as well, and I'm sure you can come up with more examples yourself.

Cheers,
Sander