Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

"Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com> Tue, 26 May 2020 16:20 UTC

Return-Path: <wim.henderickx@nokia.com>
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 5C0C83A07BC; Tue, 26 May 2020 09:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=nokia.onmicrosoft.com
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 TKbcubaU4yE8; Tue, 26 May 2020 09:20:18 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80131.outbound.protection.outlook.com [40.107.8.131]) (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 6DAA73A07E5; Tue, 26 May 2020 09:20:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DE8VKDumBIWeVhWcrbteyheFMF1Vpmd9vy8qpYxVKRnfM8NuikbfMyvMM/wyAJhM9BagTgnsIkkwIsheVce4DwUA2fh/FaFl2ufMwI6HRSm6W12s7yFTet4Xav/X9glaF0PvMqKFbE+GR537zF7/N7Vywn8BWBA8Ca2qsCwK1+q4Mz3G2yPEt2ZzhsxkqYcBtMicurlPVHDONwRovLDsEEQIis14SKo45uWYrzDPpl7u7DiP277ECSg4ttGseCktnaqoVXeCFH+WExq3SjW7ra69WaSGoOg/KrfUdOYxMaOKF7JHk4cR2AlKXNrxZm9AHCZERidFKx8qBMtwdm4sRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nhynso/P485VZwYYuLFk+hNODq1lNJNKkN0VN0aBxGs=; b=J5IdBxnGdU2cA15qNLSm1sFBMXCUM/5CfmHgkcj/UOyOof/jtTswLu3SrI8wbo107pR0Hxr2fCIM9qOx3LQkag4C24xRUkTU4oTofLM35ItpzcY8xUqtKg3B8zbBgzyZnXjO6zfqZGQc33HrJmRZfm1zCTCGI+zVx8w2bqcTaSzssLx0cfDD5h8/zKS9fZHRqPCM6t4u0cssBzmp5qiPhbSuCKQx7NEMmOvPCk4lf77EhD21F64UTI9laWVYKVRc6AX7V/57OcAal7geSmo5UIrAbLvjUcn7JnnRgyZ+fkJZTE+SXajZFCdG5xpqC9AuVLaWUEibQvbusmo5iZUfYg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nhynso/P485VZwYYuLFk+hNODq1lNJNKkN0VN0aBxGs=; b=nV+3WEoqGT/Bq0FrzS0nMTIjKCK2ybBbXAxQmysRDniC5iqlWJv7SU+8ocokJJVedqWrzqgXMqNA7QU8DnpiQdHJpilkI1TIWG03+g2WOiOWnXfpvjRiiOBfv5OrPtNekMfbFUhRdJR9PrJniD9VTiBEmGeus8Uyb0p5496qlBM=
Received: from AM0PR07MB4497.eurprd07.prod.outlook.com (2603:10a6:208:7a::20) by AM0PR07MB6114.eurprd07.prod.outlook.com (2603:10a6:208:113::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9; Tue, 26 May 2020 16:20:07 +0000
Received: from AM0PR07MB4497.eurprd07.prod.outlook.com ([fe80::75d9:62a8:8868:5119]) by AM0PR07MB4497.eurprd07.prod.outlook.com ([fe80::75d9:62a8:8868:5119%7]) with mapi id 15.20.3045.013; Tue, 26 May 2020 16:20:07 +0000
From: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>
To: Sander Steffann <sander@steffann.nl>
CC: Mach Chen <mach.chen@huawei.com>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "Chengli (Cheng Li)" <c.l@huawei.com>, 6man <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Thread-Topic: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Thread-Index: AQHWM2iKHTGjzhu8xUiU5Ns4LfPFf6i6baWAgAAkhgD//9++gIAAItQA///1HQCAACPkAA==
Date: Tue, 26 May 2020 16:20:06 +0000
Message-ID: <E26D0925-9D7E-44CC-A66C-87F972B5D073@nokia.com>
References: <D46E924A-9D84-4616-BE51-7FBB7FBADAFA@nokia.com> <DA99566C-9914-42DF-B15D-6964D5044EB7@steffann.nl> <4D115A10-E841-4571-937E-DD04EB08AF0C@nokia.com> <23B27616-BC32-479D-B720-2FC237B02EF4@steffann.nl>
In-Reply-To: <23B27616-BC32-479D-B720-2FC237B02EF4@steffann.nl>
Accept-Language: nl-BE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: steffann.nl; dkim=none (message not signed) header.d=none;steffann.nl; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [2a02:1810:350a:9600:b47b:804:a201:478d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ec5b92f6-6883-4e48-0c9d-08d80190a78f
x-ms-traffictypediagnostic: AM0PR07MB6114:
x-microsoft-antispam-prvs: <AM0PR07MB6114F07E4BF756484937F7C183B00@AM0PR07MB6114.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 041517DFAB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1Vpa9eTefH6HATHFUsun/fRz0BwKpqyB/VzAUgduoRcSLnr0vhsXJTo/96Av4o61VcJKxyJ2mUZ1+IL6xfCd3Ul1qqHy+anwnGtQcSbJs3fYpn4Alo3wBaBRoWuMvPsAVtZqXpj712CXNebiVswhmo25OcffQZUWVC2ScA+z68p45mYhqLKck09lj+IjCiKimPrqjOPiJsof4gJfnh4mSaPA9VRAKRUbj2v/zzTnNj1b9j0S5Y8IgQk9pfWQE07kiYzf7YRNpiUbhAIRdM3eyDtUCHiZFU8qgX6QzGPWuRxyvbTrHYekcK/Ws9vCr0B/5+k9vyTniKP8hKTov3SKyw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4497.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(396003)(366004)(376002)(346002)(6916009)(2616005)(6486002)(316002)(478600001)(66574014)(33656002)(54906003)(36756003)(8936002)(8676002)(6512007)(4744005)(5660300002)(4326008)(2906002)(71200400001)(86362001)(76116006)(6506007)(66556008)(64756008)(186003)(66946007)(66476007)(66446008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: KfKb4EgurGhMwiYeIuSmHKgC05eFDqthHjbG1f9owNf5zZPPcUorgZQAGuDl4A+bYsUCXyEaBaejDJNplLpgjtbptvA/trQOMqufypANcRJmdHadpxaE4w+bqEbnNeHH0c4Us3jOpwGfK4dwqvLWVe0E+5BMIROp2tjC0rWtCRE4Zm/hNideQ6xrtqpaI1nGtCm8k9a15LLJj/oOZJogeibm+HFZXZVgbVgzVwPGPouxGByY+xZQ5yhBI6zFEmUknnhvZT2oi2MIB9o/+VOSnWYYkSjIfcM5NXr0uGLWh8PeWUd7vibwLDhBAjwzmCi7UisoTNcgwVmYXgNDhNbVU4oJn+jwR1SqrbBP2KgGagXA3tdoQQEcFamjrB6YhNk9Ut/1aCIIWrl7fO+w8KxSB17HXEsQnuxkj4wWYiGfFl0lHROO8Mf5LfjCQ05l9JoVHZmw9fcohxf5NmAk5/V1WqMTNt2A07V1J1j/GvBqbuMNuCLgv1bCVIOlGQVtEIf/jceaEGYBABfK5yTg4sh/el3bhnGowCl5wvxr7hRRr1LTIjILTOpQrR+k8t30Gt1C
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <561A4C88B6480D44B139B47151F7F764@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ec5b92f6-6883-4e48-0c9d-08d80190a78f
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 16:20:07.0263 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Sdnm48Ii4mGk/NAczbqHQFKGcjQlMCH9ZEJwjfqRvadgZS0hWPTNzeLd/5zS7ft5LEV2IDErmKhobXUgSkz47+0gS0xe2ZzvQMB0RqVFRC8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6114
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ti_hW60MHGGADte6a67mlc8CWPk>
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: Tue, 26 May 2020 16:20:35 -0000


On 26/05/2020, 18:11, "Sander Steffann" <sander@steffann.nl> wrote:

    Hi Wim,

    > WH> in the same way as you get CRH across the Internet. It is a tag encapsulated in an IPV6 header. It uses ipv6 encap based on RFC4023.

    That assumes that there is always a router that adds an encap to an existing packet. I want to look beyond that and allow for end nodes participating directly by adding their own CRH header. In such cases there is no encap that can contain the MPLS stack.

WH> Sander RFC8663  is supported in linux and various implementations. You can do the encap in the same way as you have done with CRH w/o a router doing the encap. 

    Cheers,
    Sander