IETF Logo Mail Archive

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 18:24 UTC

Return-Path: <wim.henderickx@nokia.com>
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 8639B3A0B51; Tue, 26 May 2020 11:24:21 -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 Ex72fR_H9_TJ; Tue, 26 May 2020 11:24:20 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70090.outbound.protection.outlook.com [40.107.7.90]) (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 D26BC3A0AAC; Tue, 26 May 2020 11:24:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PK8nFYfjsk3g6nJlpPrJtRcnaxHgKh6fDbcvJK8qtAkYkQC4nmLo4Lq5EAWspQqQtLokRBkUatJ8PF+k+5WKUU7CZIIG6xsx25y6ja+90yhYqujeBPaGKpQVphTLsZvfcsy+TBLvBSZ578JaftHXVJloJpQdfS3vo7PyzeADEqcZuB5lZaN0p1R42Oy7VaMNqRfQ85dqb/uLMG8OH38BlnHobbYk8SlLw83PQPph7yHdy3iYSN/9cPUxS/C3Svl9rz0fyPPpZrwzZM8mLYqh3hLReD6o/XXR02FWGCe9m5HKiesryRTpxqIxigT2QD1aa5OS81CyHZbcn6IEkNRRxw==
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=bheAvmH6pnpqm6NwLCIvygErE4RAeoDv3OYgdyh/eIM=; b=X3EyrhDLe7nUzl/3em6VeIM9r3D3Kxe0foddXU7DavWTsc/jp9xRyHYFlXVxT8y78CT46gav3TzcF+P6rfbnI8pvA68H22Bf2xgOk48d5vemAE97bjCPgz0UmBIgTDuDE7JMSWW82XwUPttf5lUohsovShhA9B20ydcBg5Xwv93758djPJcXHDC32Hwoh1tHm0R6zUUFyCA0xNANXZt1RZtMwLJ49k+Uh3NHMMKnv5+BIpoIH0DkI4rgEjhpve+sG5+FxiYQzEN+5fN+agJy+1qlnK3nbRQTlyZTNb1kZQI3Lzwwl7qi0kv7W5TryuHZn6z5jCqXbMX5er9KaB8dcg==
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=bheAvmH6pnpqm6NwLCIvygErE4RAeoDv3OYgdyh/eIM=; b=SnTTl27rYazSLBvSlklOpBaxuZBDkX9+PrsAvm23i0cWJa+S64v7fjQH0M9gl4b44O9C+Ala0ytJdvmwn2sZBRUSYJxJwGroRJhudpqf4GmpNV6dOfeqr+DXuP5C54yQ9UlQvh2M7u/2Z0BB0pKGrVudewpLP8bScfuLj9m+jyA=
Received: from AM0PR07MB4497.eurprd07.prod.outlook.com (2603:10a6:208:7a::20) by AM0PR07MB4065.eurprd07.prod.outlook.com (2603:10a6:208:47::25) 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 18:24:17 +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 18:24:17 +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>
Thread-Topic: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Thread-Index: AQHWM2iKHTGjzhu8xUiU5Ns4LfPFf6i6baWAgAAkhgD//9++gIAAItQA///1HQCAACPkAP//6qoAAASDrID//+B1AIAAI10A///iLgCAAC3qAA==
Date: Tue, 26 May 2020 18:24:16 +0000
Message-ID: <A87CBF94-3E2C-4AA9-9034-57248832D372@nokia.com>
References: <8837F32F-1243-44AE-B7C7-8DA0D8EBE95D@nokia.com> <AC7C2B11-9F47-4EC4-8982-7A2DC6B5EC71@steffann.nl>
In-Reply-To: <AC7C2B11-9F47-4EC4-8982-7A2DC6B5EC71@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: 3de9c77b-790e-4bf0-02e3-08d801a20037
x-ms-traffictypediagnostic: AM0PR07MB4065:
x-microsoft-antispam-prvs: <AM0PR07MB40651DCB1F9945E64E18956D83B00@AM0PR07MB4065.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 041517DFAB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: u6DKzcoosBqHXiEK/lHaeI0+TrDnJ6NzDf05ofhzzuiIK8229u6+nXq8NWBelqz2Fm/nN9rRJyIuDKt/cbZbe0pPvLaWBwHsrl5lb+9lXKlIxqtA8pODv4WNJv8b6Dau8QU1RHkyrQ95wW2FvKHkDBN4Lxe2FcbVZL2stgZ37JvJHkw0AloSfeW4R6eOH0E73+bhQC8ttsr3VmRlF3KrYDDmaTP9dg0D6WcuxQhhX395kqtGk+EJEpUfq/t8iZuOzRQ1cqG3GGFIb879LLxb11CUrvlvktCJ2bIxEDxNRb18Aqpph8z3i5dmDv5slhUOxRnSUOFmD9UH11k+zrS2PA==
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)(396003)(39860400002)(346002)(376002)(366004)(136003)(5660300002)(86362001)(33656002)(2906002)(36756003)(2616005)(6486002)(6506007)(66476007)(4326008)(6512007)(66946007)(6916009)(66556008)(66446008)(478600001)(64756008)(76116006)(4744005)(8676002)(8936002)(54906003)(71200400001)(316002)(186003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: DqGSpwN0C6q8P6ouu+fTZzIkMGETcD01gTJXGfXZqhTPOt0ia9CqJhKjY8PQbAT0sshqS4e4CIJzZPICY/nGtHLwrox0z+0Me53K4T5op1c5ZRSR8prHI1vk2b0L8hN6GB4s69C9zB+IYqXw6tQW35g/rZGIWV+Qm1iR8JsU6M0mhjVIc1JKmmDhrzhnywtWbRVf3w8ngvV2dlxdTLSbDuXiX48355rk8HnXCuEwPbiOV9Ef8Z51euc62Km9cV85pnYNM/t7jBF1+dSEO38YyDq5Gwdl2WYqaTFzuWqEpKC0fwdXlYsAUmQCKUs3+69A4IqjZ3gvTbmRkceAcw1nFEpW6+gK2EHbvoYiFDAFJteqB51ZrO/IxO7KQmm54HE8wdLzmLZJ2L1ZJLW1iHbLQRpyUf5RYo4AZWFGIZe1qEuJ3PXFTzwBnJdxKoDC2t1+N6KunyH4aMTb6iEp4XPvf+5qVCU6BOd71DRVf9TsG/1KvH5x682tgTHJOg4czc7XXvvwYAiDa9B92n4Hul3DpEWpPm2Bn73iDljIIVD+lbUkY9QfAKgqmdjGZGc7J6QH
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <2A564AFF7EACD2499B95618D4E6C9DCF@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3de9c77b-790e-4bf0-02e3-08d801a20037
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 18:24:17.1940 (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: fbbfgJdWUfImAbGdbbC0T9ZzOIsfgoalnbD92+2o8Rwc/OuEPjPkiUOer1oM0m6bWBoa/fruGQcwaqQ/cdaaY/izEb2Amy2Z/Jwh2HD8sQg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4065
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/3Kt657Tdgclxe1vws1eOZlSeZfk>
Subject: Re: [spring] 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: Tue, 26 May 2020 18:24:22 -0000

Sander,

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

    Hi Wim,

    > Wh> Nothing is put in the payload when using RFC8663. The SID list is put in a next header field as per RFC 4023, whereas in CRH you put them in an EH, but the payload is intact. I have not done the exact calculation on the wire, but they are almost the same in size wrt overhead when you compare 32bit.

    But you're still encapsulating. Otherwise you're not making any sense to me...

WH> We are either all encapsulating or not, but in essence the point is that the difference is you put the sids in the extension header versus next header. Lets leave it like this. All in all what I am saying is RFC8663 allows you to do what you intend with CRH.
. 

    Sander

v2.23.0 | Report a Bug | By Email