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 17:26 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 124D93A0A92; Tue, 26 May 2020 10:26:45 -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=unavailable 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 4Sd8DPDycdEX; Tue, 26 May 2020 10:26:43 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50116.outbound.protection.outlook.com [40.107.5.116]) (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 372663A0A85; Tue, 26 May 2020 10:26:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F8vnFQjHFK8n+jn594hcbXtQbftl49lkjjxpC4iIUKcrusnPMjvcNmgblG6oYvIT06xqzw3WUrTk2UZodCf2Cm2miI6h/vn6GlX2fXWDXICBDyckrjA/S2n9OWETQWsuj1UikJQ0QDP3SRqsY4Z9vzGYzQiiXBcFbBLHIMYz7ZkUlyPoppUtIJKxAx+CxeEDN17s2RmAae3czf6O8VNG+wSHQRRYNkpl+D9psiLtORbc/VSUHjJ/Ma0RCO1nSPpaVilIOmtgn7yTj1no/ViZswjX6OLMP5TKkrQLxb1zsCqkbhpF+hqipQeV8JPtDwTjLTUBdW7gLd4MA2VAAX+tjQ==
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=qJ+L4PpoS5DD0rqCEdTfPYKu5kyojoWmFpVdLQm1bpU=; b=DDbKHhlf3/slQAh7bCfWMhcKQ9nDDj7j3ial3ldIN2tBnyCktJX0O6SVbecDBmXlaCkDi8R4tDDGq9nQkKEyeCswgcqelcBqg+Kl/w36rS7YqXotV4ZpZbKNnfrA5eyWS+ZjlDAhuDskbSP6QXfg4Ep33J9m5F+vo/qqMp6wgsVAfpY/7buUZVlMeMAomp9wIMPOqD2xvgliisgOLZRO9u7HattvMVpin800ryWZOR1KB3SLDrGT7BRs+iYtWf104GkZ/dArPt/9LVameZ6l13N6bEG2wSq5YkRnf2RNdghIoE+Vjt5WiHYmN3qeKhCGQVCZu0mtp6YhvHmV+X8Vmw==
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=qJ+L4PpoS5DD0rqCEdTfPYKu5kyojoWmFpVdLQm1bpU=; b=XQVql71V/LKoGZ2wRDE89fS70tSYkD2JThOUcVbWZi7AFAd9kZkHD+HWZ4shIXXvDScj68nEkZ7gHNn9tt3eIYncCsj13KnFARLh1bKL9Hun2YZ4pcjQTq306T4T9TwcJ9nJbj+9Tx3BPyR9I9Y4r2UbSXo8upp1ukqrtU9rR80=
Received: from AM0PR07MB4497.eurprd07.prod.outlook.com (2603:10a6:208:7a::20) by AM0PR07MB4212.eurprd07.prod.outlook.com (2603:10a6:208:ba::22) 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 17:26:40 +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 17:26:40 +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///1HQCAACPkAP//6qoAAASDrID//+B1AIAAI10A
Date: Tue, 26 May 2020 17:26:40 +0000
Message-ID: <8837F32F-1243-44AE-B7C7-8DA0D8EBE95D@nokia.com>
References: <A871DF20-D459-4475-AE4D-C60925A7D4FA@nokia.com> <F2F8FEDC-50F0-4765-9635-DA306B595A72@steffann.nl>
In-Reply-To: <F2F8FEDC-50F0-4765-9635-DA306B595A72@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: 3e9c6b7e-7b17-4fa4-b60b-08d80199f3cf
x-ms-traffictypediagnostic: AM0PR07MB4212:
x-microsoft-antispam-prvs: <AM0PR07MB421264B9719064F40985948B83B00@AM0PR07MB4212.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: ngE/fiKucmuU3CsBSh2G+KObtGeyk4wzDF8ktJsJ337KhpJv77j8wgZWMKFkFeU0lX/t7VCV/NZLwKF4qAVoNQq0ck/dzWh/RalJev/VSQyx5Fc9YRliubm4y6+Izeqso47SBkAvClQYOkHYhOGmuDdR2FvbCwyWTeHi5VDUS+SomNvHdpJ/xF6nTGrF0PL3X/fNou0iBdHkXKMDwWKV2bbyYXPfUFsXSjJkkoDSunSw8//7uL3hAkm8/pqe1tNX09laLvfwG8tJvcyfgPTzhu5GiiA+WgE6YMvYvCSzrophIUlM/QNhZrEi7tjeDsUlT/ZnJtLFrvgBPc+J7NGr6Q==
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)(366004)(346002)(396003)(136003)(39860400002)(376002)(6512007)(33656002)(5660300002)(66446008)(8936002)(316002)(76116006)(8676002)(2616005)(66946007)(66476007)(64756008)(66556008)(4744005)(54906003)(4326008)(71200400001)(6506007)(2906002)(6916009)(186003)(6486002)(478600001)(86362001)(36756003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: C3kyScFXlmtMpdIFf9PQGybvNXm5Gb60ZAbDdxufEVyGjevSGAWZUVvyZ6FBGlxN+2jqB3KhRV+lR4rYtQzL3Ahxep8lCt+ZtlcNCJoWDZxFjRw4goVRp39V8bYIPpX52NT/gUguyth1LyrB0xJmANF6aGMZtGJhyl+WH7g311z3OU6wDPc5zYjXwHezuhqG79zXG+Nor7xYAJhzFDwWgrcroDttrR1RRTDP2jsIGGK1n65zieImYk4Gs2zSZPAIRpFpSngROtJdvkeiZLCNGiqYGlHu5g3Sl2JbUkz4e6fnFAcLsJRUKZHqXy7p4NrfjFe+FrTH6ahfhU57t1lLsxzlldUx1wlT3MOmBNZfz3sesJifWZwib710Vt9pADIe6kSUbGotZHqzV2zGGqc82aZbQFS9y/9d6X8HA1ZAagACDYMuNc6uh1eHPdhIBELxNb44/qzZjhHraWnZ7/KSIKtI7rn1g2kF/fsL62vVfmLxemlFBo2G4f6+nTExeFUCr2qXwPv+nCX6P2PXrcXKOxycr/rMiWLf7KttzzJfjbibDY1fisXDnfyFBIjUtoLW
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <0D9D5A2517A3D445ADC0D3039A8863A6@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e9c6b7e-7b17-4fa4-b60b-08d80199f3cf
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 17:26:40.4025 (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: g18S6rTNiZSVz1DSlm98LLDZmxvHDyrLpNnyZDPdVqJ6Hbxg6lDJxm75GyA11EIm8SudGnRnDOubLMpwPmLkE4h+p47u0CpE9TBjY1W/OWE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4212
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xMGsovmdH-6GNRGJaOpe1sfCgY8>
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 17:26:48 -0000

Sander,

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

    Hi Wim,

    > WH> Why would it matter if I add the sids in an Extension Header, versus through a Next header. As long as we achieve the same goal why would you care? 

    I don't understand what you mean. If you're talking about encapsulation, I care because of the overhead. If you're talking about putting SIDs in the payload, I care because it messes with my payload and is therefore a layer violation.

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.


    Cheers,
    Sander

v2.23.0 | Report a Bug | By Email