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 14:41 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 001E83A0FE9; Tue, 26 May 2020 07:41:38 -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 oZ1pezwbOfNk; Tue, 26 May 2020 07:41:35 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60126.outbound.protection.outlook.com [40.107.6.126]) (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 6405F3A0F9F; Tue, 26 May 2020 07:41:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iYEduzPvet43GEqd3iq0bM4LfCT2dJAWpclgh/CTJDbnIfR3SE0lNRbsEzOPhsqeSSdryntGdiVcJ9DSC0BOX1Bhgtfm8fxFWa6tmdo6a2cLOlR0kPgPmt2J156pEoPeQR/kogPeQDMXSbbqcntzk+CTRcPgB6IyHwBaxANwkB6BjzedGdeyjt2iQNtZEmr4ZmBk53f0xd3DmO9uuLeuvpBkbx0LVwv11VFKEWsHBR/RTPxWIl/t690MZJvbz4k+Y5dRjDcDLXi/4C9LyyX6ZXvebWWZTr987hDxXDxx2HIr5OvWQ2kzumVZGp1FhX0Nrhb3XA02HOE+wj6iKgrSJw==
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=IU7RKMi9x1fowbtqo2OULl6FGLwleYaxHQf+AXoHsQM=; b=foWLPG8R7dZY627TRZrrlN6pyykiR3UYPdWA/keNB+45/wFx1oPRO7txX+wxWolDqUgdFdru8Ihe0g6JxpndP5WTCZLRCqxL5RBEbrXFzzkh879pJ3266pqqTaubc24PYHetpZETKbcIhJgt/4Sim9zlE5xTt0vtya33HSS2N62pvNKS9hV+d4gM6lLJH/vL607VKrjyEjwJ3hCVFWa4hHtzD+YkdzE8xK5SiEawf7A4KeKDYfIyZV8XIBFSx6xGSK0vD00rNopl5pajDnv+Z93QeUOp3hiyj7UtOSUhqFbB8WZE/BS8/v/72pl60kuU1ToNGLutdTkFNgnOw3QnSA==
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=IU7RKMi9x1fowbtqo2OULl6FGLwleYaxHQf+AXoHsQM=; b=Zf9jmkOtXD5hdsfCZuvqZXbOu/JziDbfAP6ri+9PRsVDmPRVNQgKndAhHYMjbwIMHHkaHHz3Iz+ztcbFfA+6joOBU8jJr9Dq46KIBwTVB2fR3zEOVvsCaejQCcyLUeiLoPUjpW7rahYh+18XWXqE4uLI6cipudC4I/wapzyBzn4=
Received: from AM0PR07MB4497.eurprd07.prod.outlook.com (2603:10a6:208:7a::20) by AM0PR07MB3907.eurprd07.prod.outlook.com (2603:10a6:208:4c::11) 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 14:41:25 +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 14:41:25 +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: AQHWM2iKHTGjzhu8xUiU5Ns4LfPFf6i6baWAgAAkhgA=
Date: Tue, 26 May 2020 14:41:25 +0000
Message-ID: <D46E924A-9D84-4616-BE51-7FBB7FBADAFA@nokia.com>
References: <C70B4EA4-5B92-498F-8D94-ABA3E70AFCA4@nokia.com> <EDB1EA57-406E-46C8-B4B3-CCCF178D1AE8@steffann.nl>
In-Reply-To: <EDB1EA57-406E-46C8-B4B3-CCCF178D1AE8@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: [131.228.32.160]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 570771ae-0ea8-489a-ce27-08d80182ddda
x-ms-traffictypediagnostic: AM0PR07MB3907:
x-microsoft-antispam-prvs: <AM0PR07MB39071202823BDEA8BAC1C2FA83B00@AM0PR07MB3907.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 041517DFAB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6rRWNzYVumZ848LzKZfhkgH/0ya6XprCQXpLY9QLUie+gnk3Q4pVgZUyP3P3eSeXdUZkXtNNCtiYD48dhUilEsC4CwNLEE1jzLI1pmPpZOfcOcPn6XdKoWELw2m6MWjkE8cd/vbMj5cFO0jUFb0HNZDp5FT9koxt4yPHdRkejqrT6E5s2w9X7tY4v+jCRDVTAADDS3KALamHAb+qA2MfIF9Fai1phVFMu1IfXyuDfKajsF4FOqCc3KhG75q3S/1Nvv7PilgZHASlK1puqcIqwEehIh4333Z1NyW0w8e2QRn6AozYYI6186Bls52hvBMfHaSgrYDDm9n8jYqzUmW5Qg==
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)(86362001)(5660300002)(66574014)(33656002)(2906002)(36756003)(6486002)(2616005)(6512007)(66476007)(66946007)(6916009)(4326008)(66556008)(66446008)(64756008)(498600001)(76116006)(91956017)(71200400001)(8676002)(54906003)(8936002)(186003)(26005)(6506007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 0kQAkqbFUeXknr1866I6ySZL6FBvEGidAy/KrpEGEaHiUGOO58VR+CgcJAMr6EtwMzkJBOVntQXECu26egjQj0JCjAyGK36lNnV+aWR2VNkIkSj8CgCwvHCIZZnlsGacpIcH5KJVkSW/PLFF/h8n2zS4a8MO+i0JIAu5IZ0eEfeR4V5sMk0UP+2y0BrC4+fUbtOj7LIt5HaKLeAPwIqRiaM3Dry3QaV6bkO5DXmv5YMj1JwFaNszfLnpDUEWhL0JYywlB+HtoEex2k3n+8Du/OCIvq4F6f+9cnzQ1u0AF7+gMeEnsUAry2etE6innxMf1Xz7LJmFct51QwXsdFTmo2BykXPkiUyIwTln7JrkfGkSCB/kiLpQxrcFAiIwMDj54L0YbWlaI27yQ7Skz2O0YPHNhrx+h/38l9CgnY8oTuDfS4CH/9CQB03X5q3QkbWN/1iSl5GJ5YWCw5Fkr2Y0m1lJEo/ZiMFTWdvOA+nElldITyjqADVjyPWY08/YdJmC
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <4A8154574C355149A3C163184D6A1030@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 570771ae-0ea8-489a-ce27-08d80182ddda
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 14:41:25.0956 (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: rdf0B7pwrQu94kQfqr9S0bpHbqP0b6JdrjtctDqn3J4VWDBBeloP1kE3kH2d1eCuArvy1J8Z2odbLUAG2b5fTAniQPVwn091m99ggSTF9jc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3907
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GalFRZ60s-BhjKXD0hti8GzktxI>
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 14:41:47 -0000

It does work across domains that are not directly connected, but that scenario is not well described I have to admit. The operation is as I said very similar to CRH. 
Think of the MPLS tag as the same as the SID tag in CRH. From a data-plane all packets on the wire will use v6 addresses, so inter-domain is possible.

This is no longer MPLS as people know it. Think of it as a tag that performs a steering function as you have in mind with CRH.

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

    Hi Wim,

    > I agree that if you look into the details RFC8663 from a data-plane operation is very similar to CRH. It uses a tag and derives a destination ipv6 address from it.
    > On top it if you look at the requirements, the following is possible with RFC8663
    > 
    > 	• It can steer the packet through a specific path. Implementations exists which do well beyond 8
    > 	• No new VPN encapsulation is required
    > 	• No new service chaining needed and various options possible.
    > 	• Compliant to SPRING
    > 	• Uses MPLS but it is used here as a lookup tag, not any different than the CRH proposal. In essence if you look at the details you can implement this with a complete v6 infrastructure and use the tag as a steering function. And uses 32 bit.
    > 
    > As such I don’t see why we need another encap to achieve something we already can do and is available in various implementations and is as efficient on the wire (looking at 32 bit, which is what people agree upon)

    RFC8663 doesn't work between domains that are not directly connected. I want a solution where the connectivity between the domains is plain IPv6 (e.g. the internet). I have tried this with Andrew using CRH and that works fine. Part of the SR domain was in Kenya, part of it was in The Netherlands, and we could use CRH without any problems. That isn't possible using MPLS.

    Cheers,
    Sander