IETF Logo Mail Archive

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> Thu, 28 May 2020 14:58 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 1C3C33A0F49; Thu, 28 May 2020 07:58:30 -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 RXe1oOzivESg; Thu, 28 May 2020 07:58: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 39C853A0F4D; Thu, 28 May 2020 07:58:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id BC3C549; Thu, 28 May 2020 16:58:20 +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=1590677898; bh=1SH4rONn6HwVHNOvOJB J6KDTQeJuwTMC8tsVV2rUHbA=; b=e6xpCtjjvQ/lXdV1C8BfO5Yl2OVe8ekxn4q N6N7rtl5LE2nTf6EO60WMMz8V2hJZUHSeMIBLxmiCObcNW9X02hFBeLfJ56DrqDt rcPAncPEh/cvzd7EdNYIGpuJphfKhjBwYt7O902pfyHlomVKmKTrXiFKFwqOW/gr l0GEs6X0=
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 IMnsvPCmYiAs; Thu, 28 May 2020 16:58:18 +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 EEE613C; Thu, 28 May 2020 16:58:17 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <FC7E2896-CFBB-4CD7-B110-F87ECB4FFE6A@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_A2C41498-9241-4AE0-A1E2-9930BF03ABC6"; 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: Thu, 28 May 2020 16:58:16 +0200
In-Reply-To: <CAOj+MMH-1RbicwqHVueeokRq-FNm2QWkyCQXuyZdR2xFvdh13g@mail.gmail.com>
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>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-0kW826OYnZaOl59dq1En6uugHw>
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: Thu, 28 May 2020 14:58:30 -0000

Hi Robert,

> There can be a lot of acronymous or names invented but under the hood it 16, 32 or 20 bit opaque bit string in both CRH and SR-MPLS which is mapped to a rewrite string. No more no less.

So far so good

> And rfc8663 precisely automated such rewrite to UDP encapsulation.

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.

Cheers,
Sander

v2.23.0 | Report a Bug | By Email