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 19:25 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 07E9F3A0F19; Tue, 26 May 2020 12:25:16 -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 SDpqnBB7naG2; Tue, 26 May 2020 12:25:14 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2109.outbound.protection.outlook.com [40.107.22.109]) (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 11D513A0F17; Tue, 26 May 2020 12:25:13 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DO3aVnBMjv0/j1IBuIfKz2M920WHLTTn9vFRoFF/gywOWgP7GcOyrTMsodj7XM5CYLyspeieJkmJqXzfii35KC6W/4mZi+sIva2jFbJyMOD12cCL+IxbjEVPc4ZTR1wgg6Uyk2ksXGrXawmQR4+OShiAgC0GGjsplUf/mNChT/CSNuziMNfvkvzLfvdTd6e76r+UbUnO7wTGAY3oiK3jEPYj3Vti3J6jRWL4I9fJr7Y41yAnAenEabR0ysezQbfcXXgrQxERL9ttAp5gc7psWqQl1YyEzKaQcuo5ISobYhB9wB6TFSSU0BmAc+AZgcPbx9HI/iB4hOlt25h5MuN90Q==
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=mIick7I9/6BzoD0W8YCRa3ZTLkgW9yxSmUuhkyC8xr4=; b=ZaWyR/3vy58uZeRq+0wHJGf1oJUPKJOIbCAyd/S0by1zzj+ehtL69HhVSi6YB1lzTEgIctak+dGgwYwcU/QKd19FbCAtcNfGZuRPNhv+QATsdzTC4RwcRYl0p9Mw3XgA5kuyx3qUxrAQGbMksws0iEOyLbyzToXdCweovU0l4aYWLgBNac5xEDUshDsXnruJbz5hbG3LSJKKzSJr9ZLmjfP7l6ziFZkeSkDR3D5i0OxsXFY/mWZ9HLkzTQ2MHvsPBhyGWYVK5rLcSmQUFf3DEvSoiQnXO/gdBslZUNsl13W8oZ/U6+7OqpIl6tQxBNmMMqjNctgn+80k0bAAwK5x9A==
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=mIick7I9/6BzoD0W8YCRa3ZTLkgW9yxSmUuhkyC8xr4=; b=gdlcyZub7vYAlb6uJWkYaklamCZHHZ1OB9CnbB50KRxbfxBQ2aHwyYO/hXKQyiRbKrVns+G5ekkyJxcZqOFGjrqwt0j8t9Nh+QQyat4mzyzQ3RYifMM99f4WMLAJNdJehQnZMMGKfhnsBaRJcI/MIokAfslty/liKr7XQGN4p98=
Received: from AM0PR07MB4497.eurprd07.prod.outlook.com (2603:10a6:208:7a::20) by AM0PR07MB4004.eurprd07.prod.outlook.com (2603:10a6:208:47::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Tue, 26 May 2020 19:25:11 +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 19:25:11 +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///iLgCAAC3qAP//7UUAgAAjwIA=
Date: Tue, 26 May 2020 19:25:11 +0000
Message-ID: <74728B6A-BEAB-4FBA-A92A-DA4A575C35F9@nokia.com>
References: <A87CBF94-3E2C-4AA9-9034-57248832D372@nokia.com> <51B3FE50-DF61-49B3-9A28-B8B70E5DF6ED@steffann.nl>
In-Reply-To: <51B3FE50-DF61-49B3-9A28-B8B70E5DF6ED@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: 4331a9fe-f23c-4ebd-a9a0-08d801aa8263
x-ms-traffictypediagnostic: AM0PR07MB4004:
x-microsoft-antispam-prvs: <AM0PR07MB4004219722B118D0E045D81F83B00@AM0PR07MB4004.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3968;
x-forefront-prvs: 041517DFAB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: yWUXTmB6oITqQdYlCm3JY9S++maDxnmgFYdox+S2EEGFW4swmWmuNzMFVMAYR0Aj/B1m4fmISkV6e1ylCAzovfIpJqCAMoeWBbIipa91spk86K55+/tOtLmTeW6VQ4VovQJQN8933WPvVuVWSPgLv09tMDL/XSYNOXA9OB/EKRUF0ou3BxwyiniEuHowoJqSSs3xtgtxdro5OW8+gNQ5Lru/07eu/zTlzc4NccoCAcPOoqZFUrBWbjlqiU/yAtfiqvSjPp3+HL3OdmAO9U1U+FCxiAL24it+ikkJsAxLcFGYrF61SBCAjCNaoMPtGwZ1bx5OEa41JhVolIU56G4U1p3JIRfaZvlC+Zfa06Ey/Gojgm3JgZMJ8um/NOa4rJOJRQWlss9+5b34OyA9zHp0HjuBWE8xsVOSfj+h2BdXo+yMRmAFQ83MznroycULVSHI
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)(366004)(346002)(39860400002)(136003)(376002)(2616005)(86362001)(33656002)(71200400001)(8676002)(8936002)(5660300002)(4744005)(36756003)(316002)(6506007)(4326008)(66446008)(54906003)(66946007)(66476007)(478600001)(186003)(66556008)(64756008)(6486002)(2906002)(76116006)(6916009)(6512007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: Sz/Pc/l11c1nzzDhf2m6eVIHO2a+v4eafrBe7EhCXP24+ZR759kKRbCEZnFdqG27mHtGTvtBAQZ/RIHL+fyouQ14fMs80KeVhU0hVv5eFM+fV2Wl7kGHKebVBxg2Z4RncU3ijNCGzbNiC6cl5POhkky0gWbbBr9NcXdy6yOluOMbCZPeacrCarMl0Iu+z9ZyaFjHolbjhBho2gyLyANuaNUFkhtSUEcwNZ29VBDOVU1n8YHDk7gR+GDIS0CdqurTI1yADsN57TVw70Z4cxz2ng1zKJsqKDGr1y13H4qCt0MJWcCLNkv0D0OyXXynyCWvP07OxkCdwG5Xk23fj/wOpiMN3nDpy/M8l2cv98Mq7pgRgrEeP1j8584Yj42TorDSrIYL7cpTklkIsT8YepyWt4+/cuvTYga5nuvFO3cYl5qyUl/3gRwcV0KvCJrbu+wQJQ8c1N+r5kL6q2Vq77dNDP1loJpDmEBUAe3H8yw7qlJrc0qT91PlGjI7SsxkqXKdJ7N8al1RHoqo3BLfdRNBRXBJz93wmjAcjqnUgSJwPLcx0msb4iiXeE52mFCQcpHZ
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <B6E0ED8E290A0046A3A86A1D6DD0663C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4331a9fe-f23c-4ebd-a9a0-08d801aa8263
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 19:25:11.5663 (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: fEZudmxj1sPzS/W0RJwzZ02ukY4c8vkF1ytPZQDjTcj26MxcTjBtv2SuQWVzmfNyJz9DuJELkfZg3LL2p4eJxO2HdtGHtE8yUo5rXPVaoGc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4004
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/JCmKPWoElwgsZm5qQQTs5GUelag>
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 19:25:16 -0000

Sander,

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

    Hi Wim,

    > 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.

    No, I can't. You're not reading what i wrote. I want packet steering without encapsulation: a plain IPv6 pakket with a RH and plain UDP, TCP etc in the payload.

    Please stop telling me that RFC8663 is the answer, because it's not.
WH> what you are saying I only want a CRH solution and you are not open to anything else, because the SIDs are not in the right place. So there is no point in further discussions. My position remains that RFC8663 is a valid alternative and is available; I am against WG adoption of CRH.

    Sander

v2.23.0 | Report a Bug | By Email