Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

"Zafar Ali (zali)" <zali@cisco.com> Thu, 28 May 2020 06:30 UTC

Return-Path: <zali@cisco.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 55E953A03F6; Wed, 27 May 2020 23:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hl0TMw5i; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fnnEPeZZ
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 E_TYth6N1gqe; Wed, 27 May 2020 23:30:20 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDD93A03F3; Wed, 27 May 2020 23:30:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36123; q=dns/txt; s=iport; t=1590647420; x=1591857020; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vpu2P2I4kXyI4vJws+XNIVtR4W8jUUvIdOY3J60RGP8=; b=hl0TMw5iX3TKPXU8EMN+idn4VaGgVIf265n7H3qIKQquvbxmeHyh+REB QIDy2buc1PLhtfR1KIBL+SIcgYWS2bgCDi85Lb3tH7okUVueR8Vs8zjAC ARiuvpEXP82V1bAcXLZxkf+XQgh1aWG0i87AddHnjp+yHrBNs9Bphu6Fq w=;
IronPort-PHdr: 9a23:6DJ7IBOe61mmgqI/Ulkl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEvK433lvIRJja5+5Jj+fdtKWmUmsFst6Ns3EHJZpLURJNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8Xmz9CMTFgnyMQd+IeGzEYnX3Iy70umo8MjVZANFzDO2fbJ1KkCwqgPc06tegYZrJqsrjBXTpX4dcOVNzmQuLlWWzBs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CmBQCxWc9e/4gNJK1mHAEBAQEBAQcBARIBAQQEAQGCCoEhLyMvB29YLywKhBuDRgONP4l6jkiBQoEQA1ULAQEBDAEBJQgCBAEBhEQCF4IDAiQ4EwIDAQELAQEFAQEBAgEGBG2FVwyFcgEBAQEDEhEKEwEBLAsBDwIBCBEDAQIhAQIHAgICHxEdCAIEAQ0FGwQDgwQBgX5NAy4BAgykCQKBOYhhdoEygwEBAQWBMgGDdw0Lgg4DBoE4gmSJYBqBQT+BESccgh8uPoIeSQICARmBLygSDYJnM4ItkWeGJZpdSgqCVIgqi1mEXR2CZIkDkiGFB4tLiXCCTZEsAgQCBAUCDgEBBYFqIoFWcBU7KgGCCgEBMlAYDZBADBcVgzqFFIVCdAI1AgYBBwEBAwl8iygBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.73,443,1583193600"; d="scan'208,217";a="516770871"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2020 06:30:16 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04S6UGCo004092 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2020 06:30:16 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 28 May 2020 01:30:16 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 28 May 2020 01:30:15 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 28 May 2020 01:30:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gYY0/vGd0+KXbeFajrczdjt1hHc1+MACNI9T5YITC8C+2A9gYClPkOddvranGlpW9RwNr/bejdFDO/kilnlT7ujM7KhbZbk35hmJYWojxe5CLaQZoY94GBLk2xVpZnvTFhKTwucozhxNuAUmUL+ApIgcajdEoNwZGfUZvfgrzylMmLbVPawocg9xqVJxu/tzagHj54qbWA7mOD8G6paWSVIc92F9fuLFIPzsvSzKpn1qKnbTVpro5ze7ONHW/mUPUZ+XMSGnrJIrNO+Scbgdjqd6gWiRo2C1N5O/xGWFJwBlsd6eKpXgqwvHcx3L1foiFfpPHqo3kUaKMJNblLVFVQ==
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=vpu2P2I4kXyI4vJws+XNIVtR4W8jUUvIdOY3J60RGP8=; b=g67g1UublRyyvy6UhsfOyyKVxTPBooSnYIFkHoXVZ63lHNqeUEh5wo7/WlX+nInvoXrJhsjlvmQanVhtLgTWmrdUfL5gWkfrXJdtR0WH7zb1OtcELRiWo4V49YG+i/5eKJ7Xsuq9AvWFA9bPHoaqIZNu6/H38Bza8NyiXG6pMEAH5FMaYp/ZvkKWRPZo2lGNePknH8X5XR+tC2e69gNNiYrUM0of2BLDj3Qw/haU2NQBbeKYPOHQb3QuusmjhVI88cVLiiPsk/4cD+sk0E+HcsItINeyNyAIO1Lw43hHGc3NYMeS/xJlfJoOUAPYqpVkkz1/Ptw40xLEwUKLPrsyMw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vpu2P2I4kXyI4vJws+XNIVtR4W8jUUvIdOY3J60RGP8=; b=fnnEPeZZHt6Dj5+YHFs6wzLbCrpkZ5K8pFQPs1UytIhN9Nqpnt1k5+3tHfzCdK7z3KfzcMJcxBj48cEHmvS9z1Bj+yCPJON55qr3euhkjKARTyaBBMUwrLHw87tAcpViA/iqvcWvogUtPi0YVrkZua0pswQ5IRIt1RR810yItI4=
Received: from DM6PR11MB4692.namprd11.prod.outlook.com (2603:10b6:5:2aa::11) by DM6PR11MB3210.namprd11.prod.outlook.com (2603:10b6:5:e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Thu, 28 May 2020 06:30:14 +0000
Received: from DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::fcce:4248:b4d5:470b]) by DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::fcce:4248:b4d5:470b%5]) with mapi id 15.20.3045.018; Thu, 28 May 2020 06:30:09 +0000
From: "Zafar Ali (zali)" <zali@cisco.com>
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Sander Steffann <sander@steffann.nl>
CC: "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>
Thread-Topic: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Thread-Index: AQHWNFukLM0xAvUWK0W7ISBmqA7+6qi8bI4A///QawCAAEX1gIAARCkA
Date: Thu, 28 May 2020 06:30:09 +0000
Message-ID: <9EBDF9B4-952A-46C6-89DB-25BE28306AC9@cisco.com>
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <31a550f4-dc86-acdf-dd92-b0ad2c89a5ca@gmail.com> <BAAEE151-FD41-4FEC-83B5-CACBFEDE28C4@cisco.com> <BFBAC764-96F6-4778-9B71-923E073BEA46@liquidtelecom.com>
In-Reply-To: <BFBAC764-96F6-4778-9B71-923E073BEA46@liquidtelecom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: liquidtelecom.com; dkim=none (message not signed) header.d=none;liquidtelecom.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [47.185.212.154]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 76cb7415-c1cc-46d7-95c2-08d802d091a0
x-ms-traffictypediagnostic: DM6PR11MB3210:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR11MB3210BE7B325D256973B77147DE8E0@DM6PR11MB3210.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0417A3FFD2
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: g6b1uclfyN2pA2B5x7Y6fvRtEHAg5jx7ceCxS72+X+Uy4SoEpgudQYEQTx/y8b8J95NVKdq+ZVujYZ5pkzoCCLgXmXL1uAZrRQJ0AGnhYfqGfRY+8XOFlSLAnSAX+kW9vn2EsV8yRsfL1LfJAnO2bNZqFShSCQUjBLZJBxenr9bEIs/UWRRXquc5e8ZkU6KZKTbRGHSCL0sGclInrQyxiFwYFd4DfLePZgDdm84R+jviofupv+rP+mZgdxMMY7nwN9zewF7h/mqIY/XpMzmoByvytkVhdrzd2QGC7AV47ZnGCnpBamUPU2GtIJU7URTJLfV211o4MiBpL0JcP3Fr0SNzqJ02787ocsyUUg2sJqufZbHAogABNPHOKQUoH5mQNmlEY96Di5v7lbzDlgtqMQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4692.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(346002)(396003)(376002)(6486002)(2616005)(33656002)(5660300002)(86362001)(478600001)(966005)(36756003)(8676002)(54906003)(110136005)(26005)(83380400001)(53546011)(6506007)(316002)(186003)(166002)(76116006)(8936002)(66946007)(66476007)(66556008)(64756008)(66446008)(6512007)(9326002)(107886003)(4326008)(2906002)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: WgGBgsw0xRt2wq8J0Wj6hPVdmFIAq6cN8HP7j78VyZo9+Nj3tV5TCePy/jTQM33woxS7crwttZTMxipciJEf5u0H/R0DzQiad09dx/Pu1c5OImQkgqMsOkSO300N4D9xZRHI5K1G2JmcAFV4BsJ9DzNAOZ236hu3qJdb5zfAdhgmfI1Xmqltmn616zmLiCjvPXf6xMZLG7z+3es5yy0xEm1qfGQFUPpvV8LwNL7V+wY2lizVRdvRn7x/ifAOe7GyfEQviLFGNWNLlYw+zKrDo778NcRT6SpWYiFxsll0yNziSgn9ZXdClmbOYxV04CF+pI/eDvgXiRS1pPjmJvHCsuPOY5WtxJmKFoBck1PrpWDaaxxD0o44di9Bxiaod97qSq0mJmfRbnB2u3Xyi+6+/oFQzzTp7pTGNBOBOxConNooTqxZ5CvSAEAKpUVC04CitiT5SJXYZWTkSEzwR/+QjN1TC3kMXZXDBD2u1bLccLAETd7bzQ2g0p7e8tG9UgFj
Content-Type: multipart/alternative; boundary="_000_9EBDF9B4952A46C689DB25BE28306AC9ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 76cb7415-c1cc-46d7-95c2-08d802d091a0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 06:30:09.1832 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LDlrKfyMKdQXC/XmlB73hOD3yk5W/et5NSOMuUln/muzy/Gx0lMcntmQ4kz/CCpf
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3210
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/pKXcRPz_2qtmcCE6VBl1cmcdabc>
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: 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: Thu, 28 May 2020 06:30:24 -0000

Hi Andrew,

Re: “Yes, originally, CRH was heavily linked to SRm6.  But – over time, thinking and ideas evolve.”

I looked at the following diffs https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-11.txt (rev. 10 to rev. 11 in Feb. 2020).
All I find is surgical removal of SRm6 and positing of CRH as replacement of RH0.

When the WG played the “hide and seek”, all aspects of SRm6 came back on the table [1] and [I can cite MANY specific references to the ML, if you like].
I am sorry, I fail to see the evolution (except may be the RH0 replacement positioning).



Please realize that there are other competing solutions to CRH in Spring.

It is only fair and in best interest of industry/ IETF that all solutions are discussed and progress together.


I already REQUESTED: “could the CRH authors and proponents finally understand that people are not opposed to new ideas?”

[1] https://mailarchive.ietf.org/arch/msg/ipv6/zRZJe68FZX3X0wla-muo3IkCJv8/

Thanks

Regards … Zafar

From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Date: Wednesday, May 27, 2020 at 6:26 PM
To: "Zafar Ali (zali)" <zali@cisco.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Sander Steffann <sander@steffann.nl>
Cc: "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Zafar,

It amazes me how totally selective you are with your reading.

I won’t even bother dignifying much of the word twisting and gaming and selective reading with a response – but what I will say is this.  Yes, originally, CRH was heavily linked to SRm6.  But – over time, thinking and ideas evolve.  And the realization was pretty clear that CRH served so many purposes outside of SRm6.  CRH is a brick, a building block, the tyre on a car – and yes – the normative reference to SRm6 was removed because – CRH is not normative to SRm6 – SRm6 is normative to CRH.  The realization that CRH had many many applications and could be used outside of the segment routing paradigm was simply an evolution in thinking – and that – is the nature of innovation.  To innovate you have to have a willingness to let your thoughts evolve and not remain wedded to something when you realize that the possibilities of something go beyond the original intention.

If you wish to remain tied to something no matter the findings – and no matter the progression through the process – both in terms of your own thinking and the comments and thoughts of others – you are no longer innovating – you are stuck in the mire.  So yes – the thinking evolved over time and new applications were seen.

And as for the claims it was positioned as a replacement for RH0 – that has been asked and answered – many times.  Yes – there were references to RH0 – it was never a like for like replacement and I dispute that that was ever said – but I guess no matter how many times things are repeated – selective reading still applies.

Andrew


  *   During IETF106. This is what the draft authors agreed on the mailing list [2].

o    “I accept your challenge to produce a document that describes the advantages of SRm6 over SRv6, as well as the differences between SRm6 and SRv6. Expect some operational hoarse-sense as well as some architectural deep-diving.”

·         No such document was produced.

  *   Instead, in Feb. 2020, authors removed normative reference to SRm6.
  *   Authors positioned CRH as a replacement of RH0
  *   RH0 replacement was later removed before the adoption call.
  *   There are other competing solutions that are discussed in Spring (and will come to 6man via the “routing area”).

Why CRH authors are trying to “skip the queue” and “skip the routing area”?

[1] https://mailarchive.ietf.org/arch/msg/ipv6/fasaPY3vGhMEmPreUFEJ4j7281o/
[2] https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs/

Thanks

Regards … Zafar