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

Andrew Alston <Andrew.Alston@liquidtelecom.com> Wed, 27 May 2020 22:26 UTC

Return-Path: <andrew.alston@liquidtelecom.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 BF70A3A0D24 for <ipv6@ietfa.amsl.com>; Wed, 27 May 2020 15:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 60MRMd1rM_42 for <ipv6@ietfa.amsl.com>; Wed, 27 May 2020 15:26:21 -0700 (PDT)
Received: from eu-smtp-delivery-182.mimecast.com (eu-smtp-delivery-182.mimecast.com [185.58.86.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38BB3A0D23 for <6man@ietf.org>; Wed, 27 May 2020 15:26:20 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2108.outbound.protection.outlook.com [104.47.17.108]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-59-yOLw1tyzP5OdkqTjWvZCZw-1; Wed, 27 May 2020 23:26:14 +0100
X-MC-Unique: yOLw1tyzP5OdkqTjWvZCZw-1
Received: from VI1PR03MB5056.eurprd03.prod.outlook.com (2603:10a6:803:bf::31) by VI1PR03MB6221.eurprd03.prod.outlook.com (2603:10a6:800:134::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Wed, 27 May 2020 22:26:12 +0000
Received: from VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::e433:d25a:4afe:ae67]) by VI1PR03MB5056.eurprd03.prod.outlook.com ([fe80::e433:d25a:4afe:ae67%7]) with mapi id 15.20.3045.018; Wed, 27 May 2020 22:26:12 +0000
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
To: "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>, 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?
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: AQHWNHR401pkueZikki7cybhGmnUeai8tQWA
Date: Wed, 27 May 2020 22:26:11 +0000
Message-ID: <BFBAC764-96F6-4778-9B71-923E073BEA46@liquidtelecom.com>
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <31a550f4-dc86-acdf-dd92-b0ad2c89a5ca@gmail.com> <BAAEE151-FD41-4FEC-83B5-CACBFEDE28C4@cisco.com>
In-Reply-To: <BAAEE151-FD41-4FEC-83B5-CACBFEDE28C4@cisco.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
x-originating-ip: [2c0f:fe40:3:3:a0a9:cf99:d78c:dff0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0814041f-c441-4e41-a1a1-08d8028cf646
x-ms-traffictypediagnostic: VI1PR03MB6221:
x-microsoft-antispam-prvs: <VI1PR03MB6221527C328136DB2ED709AFEEB10@VI1PR03MB6221.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04163EF38A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2MJhVNwYPFi5Zc2T3qB4oDGbTEp5wBKoKuZrsh1g1kP0k+rY5zQcolfei6HCTB8MFnZGRMMZ/ojZfjBsoacgZ/0qAmfSFnRSl8WMiU2JEFzjGajaHdAUe2wwceCiCquhT7eK8EZkBLVO5NaGMaMrPBgQ44tcD9fYCCIIJpQdZmvixRW4YJX3NcPSDoYtz+kNeFd9n2V5qgY8R6F54UwdENxYDRXQXCz3S9bho8snC0+DYLJYYba8YEwFXl/lJmBMZsRh1+g7PEyEQLjEKnGn+EqBA65WQ0ioVxVMN7XDVOJCXusI3wBRYcP1zffjdCB974qClU9ln/f+vrtFKhYqiLd1Bqo4LkvJ4G772Rd4KDpbLR1qxTdTVR+L5K4ZFkTG8lX61vYpifAqu7i7JtXjXg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB5056.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(346002)(376002)(136003)(86362001)(6486002)(110136005)(71200400001)(8936002)(478600001)(316002)(5660300002)(83380400001)(66946007)(54906003)(76116006)(91956017)(66446008)(66556008)(64756008)(6506007)(186003)(33656002)(966005)(8676002)(66476007)(166002)(2616005)(4326008)(2906002)(36756003)(6512007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: dAUS1lM4gQJGIlvYeG+Fr6V9HKcpYuabUu68IL9TCBVGRs/OhFpk38/dddtWFpFHsyePwaNkZyM4NnlcJ1PwGixJ8n5eUmdkRqXuPB6piVtwTs+BpqMRyMU+tI7tmlp2C3ONw49qA+jgwVc3Z01rNHZW3Mu08CZDWyKF3rVk3+eTz+OlbmbHWgVRv4awyvpsPZWF2aE4chKo1pyouVnlW6d7H3Xprbpk0IOpBIHznoWqRgyp69Hna3UzdQKMdT0q4Z7N9uf+Sfz+vUOBmdBdVTRGavdOmkC+eHXwSlF/wT5u/o2YCnoVrM/QeZ7t8jIRmRo2oIpo0rz58zoHSkhNUdCOT6Q2O3WVY5JpENFQdaocv402NoCzMNde2Iuyrx/P+l0W/0dEnLUheUTsZkL7JQXGlm1csWUOLpwqMEDMQZHHyDeWG8i1i3liK0KrgtR48z+rsCttiI8bb4WVBTjdIabOUrpwVp81mI6mj//ByOvvm9OyFlBvptnpt/aWElfdlvSky98VuTW+Oft6hF4WN/wN2OhnuLJbQINsbirL36M=
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: liquidtelecom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0814041f-c441-4e41-a1a1-08d8028cf646
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2020 22:26:11.6190 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68792612-0f0e-46cb-b16a-fcb82fd80cb1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JYWHeAW5sdAuK05FoDPg2kj3kvHagCXJw+8YbgcCtj8TEJjTQlRNWXcR8dSrzERuXyI4DjgTyNVdsiG0XgwPCqtnP2dvT03YSMA4ZwQhtHs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6221
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: liquidtelecom.com
Content-Type: multipart/alternative; boundary="_000_BFBAC76496F647789B71923E073BEA46liquidtelecomcom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7RQed4N2ilr6KTK_AeNVJkN9Shg>
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: Wed, 27 May 2020 22:26:26 -0000

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/<https://mailarchive.ietf.org/arch/msg/ipv6/fasaPY3vGhMEmPreUFEJ4j7281o/>
[2] https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs/<https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs/>

Thanks

Regards … Zafar