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> Wed, 27 May 2020 03:22 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 DCFCA3A0D9A; Tue, 26 May 2020 20:22:05 -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 SQfjwDapr9uy; Tue, 26 May 2020 20:22:04 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30117.outbound.protection.outlook.com [40.107.3.117]) (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 605513A0D97; Tue, 26 May 2020 20:22:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BHnrWYpBT4Dpu8Okj5otR11a6zieF7PMwW7Pov/bHNBVxiYr0gKrSIl9vDWdhrBjzVYYu6RNqXvDE0+80jGac0kbTqVfTgTO5Qo/Rfzlvm9z9IicTBw5MrT+tAn54ITzqoOVjlRtzki+M1HLxKmDfzQxjjV6PY2n9Fi6otSL3s6Z9Tn+aDE+O/mQARNDQhXIaDYU/IM1eGLLLYHDmyaAcG75pmFhNRXyVoyVWZJ+X6qAu95ts7P2C6fqADGXzlPx89D4CqH0hNgIc7F0ZspQfv4wI6d/ie9R5CS037UdtusGXvYYzrAHqLwux0eSIs4NQxi8ipdX77s+A0kqXq3MMg==
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=sJH4i9RmB3dP56TNB0lnbvXdAGGTMna6iCZ2RJiXsOE=; b=kozaAw8pHHO1ECvIZ00YY5v5vsxPtJq7FYASp4L528diSNNuJcgFp82OAYDgrLIgZTSpRgdwNXQOTqguo4G5FeOCf5GmFMKS1V5cv1/rvy4by6GnS02a1JZUqLGPP70wiPSVfiGulwdPHS3iEmV8PRhZIMm/WwyfFqJSE31pRk2j1sz2z4+12jsBSEjJbBzGRxkPSSLCIffPjKqeFEgsRcJH7aa66WCcvQLdRBjUgOTPPaMHWmdodOgD81dgY0jQPGyrb3rV4lGGpyhafY2NWuG5dJbqueIgcZf1HawQ8jnJv3+eZrteqdZUlV9tlR+YpD0XArFXhIiyD5PlwW7woA==
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=sJH4i9RmB3dP56TNB0lnbvXdAGGTMna6iCZ2RJiXsOE=; b=fmN9HhWTghfenv2t+YiKx3OySEmrqU6kfDcoLmT3LHCr4c098Uyf3mBvBji7WX3eQbVR/XhyDs6ApMD7RUQlBb6dH0AV+o7Wr6aJU36ZZtrrZXcxM/K+PX+2RupPx2iVKi92kV+rhFftdlGg/G41u43FUjdzn+ui0Q8jVerEu+o=
Received: from AM0PR07MB4497.eurprd07.prod.outlook.com (2603:10a6:208:7a::20) by AM0PR07MB3842.eurprd07.prod.outlook.com (2603:10a6:208:44::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9; Wed, 27 May 2020 03:22:01 +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; Wed, 27 May 2020 03:22:01 +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//7UUAgAAjwID//+TwgAAUCSgA
Date: Wed, 27 May 2020 03:22:01 +0000
Message-ID: <6D4C2407-71C7-4F3D-8C39-9425F2685984@nokia.com>
References: <74728B6A-BEAB-4FBA-A92A-DA4A575C35F9@nokia.com> <D4C7D4E5-3A2A-4A6E-83FA-254BC5FC2312@steffann.nl>
In-Reply-To: <D4C7D4E5-3A2A-4A6E-83FA-254BC5FC2312@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: ef55e5f6-bcec-44f3-aae0-08d801ed1f18
x-ms-traffictypediagnostic: AM0PR07MB3842:
x-microsoft-antispam-prvs: <AM0PR07MB384204BA1C6A686A96DBCB9783B10@AM0PR07MB3842.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 04163EF38A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7ajlxMP1/HOueUeSSxkKjoPdtYOIuHuRujBWlUga8mLSFGhrtcP1YnmuPwRDswd+gWAihmgcmqXjyMhEg6JQw5f8GAi4WJjIRHVp2Fazgk2RbmtnD/8KSWFVpDRhQltudETnfBuDWHvyl5C0m2iyzAMYnmoMTOUDCwMGS/1xGz+5CtK+JZtgGqrZ3pwQmPtrCY+CxW8LajGxz/ArfYqT604NHF8lQnmnXtXO7VtPrEgojR2UBPgm9CWxoesR5xsil+Ezek/AwBIY98lLu9PVS1rP7m2ZkIcYc2autaiKkq7kFMwEoKX09WOzoqgRTBTdHjJPNg0R236qv+bQrMVioA==
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)(396003)(136003)(376002)(346002)(39860400002)(4326008)(2616005)(186003)(478600001)(86362001)(6506007)(54906003)(6486002)(316002)(66446008)(66476007)(64756008)(66556008)(66946007)(76116006)(2906002)(6512007)(6916009)(8676002)(8936002)(33656002)(36756003)(71200400001)(83380400001)(5660300002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: Q6XH3WobZBHIjOVQSGvZGodoFeMQGJoq2PhjXZVJ6si3mFL4JWXXCDT9dH+KE/zgP+D+fnutbaXEVpfNkGzv4HnSIQCPi1O/VCJFc7fBKn/hd48Azi8bayYr2L90zB4oxaArkh604OiHd+y+4WOiXnkM/dC4WFPu8V9Cq5E2axN7gNjpyCY0lrzyQ9JVToZpyD2nQud6WRAssfzUvakTHXSFZY9udt7Lnrg0Nr+2/pnuTbU3IVOtubg9l/krFh1LGdkhrRtympreN+D02VvfMd+NQGj6C96XLKq8QnP3IDFUlC6cdg9VD3ojVbeFK6EzOKSJfI44Z+8nj9Mr8FAfJjD2wHrEAs68r8XfC/IpomfWnxxTcX/SKi9fw9eMaMIEbQLCxVOuk1/FzerfFndupDF6+Uzmi1dDsIDPZ8m66EK4urERpvaHqJ1CXJ9kp+Ia5Y4SVXwZJsHxSCh/salXT8ALl0keS4KpHJ3eRKCaHBymrsYQHrv7/xwae4icCYNmbOVeR7hJZSoN+iLc1b5rARrfppHwacgaHe/XA683pBfiSIuyjUNnE3pAmQVFC0nq
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <41C35A7C8AEA1A4C923478459ABEC889@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef55e5f6-bcec-44f3-aae0-08d801ed1f18
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2020 03:22:01.2702 (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: EM6e7wuMc1x4t7ceZpIfBhNcHoebPxKnOsFNAIEHX0MDtc4gxJyZXifZ1Vg+oGyG1gZ7qDCIfzIz+Ery10r//hrwbpj8D7pESX7QFTUsZLo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3842
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/NNeAX0LFOxmK9nf9eZQvnXSCE_8>
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: Wed, 27 May 2020 03:22:06 -0000

Sander,

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

    Hi,

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

    No, that is not what I said. Please stop twisting my words. I want to steer a packet without needing to encapsulate it. Why is that so hard to understand?

    SRH does that using IPv6 addresses, CRH does that using shorter identifiers. Both have their use cases. I'm not just talking about SRv6 and SRm6. I'm talking about CRH as a building block that can be used by many future protocols.

WH> When we defined RFC8663, we could have done what you said, but we didn’t and the reason is simple. New networking capabilities we have defined so far, are supported naturally, like SFC, OAM, VPN, G-SID/L-SID, etc. With your approach we will reinvent the wheel for these things and we have to define a new framework to support them. So far nothing has been identified that cannot be supported with RFC8663.

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

    Your arguments don't make any sense...
WH> Make sense to me though.
    Sander

v2.23.0 | Report a Bug | By Email