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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 29 May 2020 17:04 UTC

Return-Path: <ketant@cisco.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 E4B6D3A0E09; Fri, 29 May 2020 10:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.486
X-Spam-Level:
X-Spam-Status: No, score=-9.486 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CaLwlbDI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GN2sDKH3
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 WQjOh6rIdSzO; Fri, 29 May 2020 10:04:40 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BEA3A0E05; Fri, 29 May 2020 10:04:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58236; q=dns/txt; s=iport; t=1590771880; x=1591981480; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VOx98HoJ/kSmXdZmqJ0kQrpyH3PIl3r4jZQhdZmRxrY=; b=CaLwlbDILmZMEqNfCMrUbjRO/WF/l0mf6HlhGKJ7QgM+wfvnHggkJA0G yLXxmQHin1jpNCcdxH5s356ZiQrVcRsVMzwym04LrT/nST5CfsbWDvefm BJ5MYlRwPJpYlEaNiepIpCydsu9d2cs1HWxk+f2Jt5wQ/A68rlLWVa+5A I=;
IronPort-PHdr: 9a23:3RVKyhOmQ/RttXu9kqYl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEvK8x3lPMVJ/QrfNJl+SQtLrvCiQM4peE5XYFdpEEFxoIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFHXq2e5qz8fBhu5MhB6daz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0RDO5HBPfrdb
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CxBQA2QNFe/5xdJa1mHAEBAQEBAQcBARIBAQQEAQFAgUqBIS8jLwdvDkovLAqFeIFpA41CgQGIfI5MgUKBEANQBQsBAQEMAQEYAQUPAgQBAYFQgT4dRVQCgiICJDgTAgMBAQsBAQUBAQECAQYEbYVZDIVyAQEBAQIBAQEQCBMTAQEpAgELAQQHBAIBCBEBAgEBASEBAgQHIQYLFAMGCAIEAQ0FCAwHB4MFgX5NAw4gAQ4DpTUCgTmIYXSBNIMBAQEFgTIBAwSEAQ0Lgg4DBoE4gmSJUg8agUE/gRFDgU9JBy4+gh5JAQECAYEtARIBIwUHEg0JgxGCLY5RCAoziQCDAIgKj1tMCoJUiDGLW4R9gmaJBpIohQeLUgSJc4JOjlaCWQIEAgQFAg4BAQWBaiJmcHAVO4JpUBcCDZAcJAwXFYM6hRSFQnQCATQCBggBAQMJfItMAYEPAQE
X-IronPort-AV: E=Sophos;i="5.73,449,1583193600"; d="scan'208,217";a="776509838"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2020 17:04:29 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 04TH4TVr012385 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 May 2020 17:04:29 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 May 2020 12:04:29 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 May 2020 12:04:28 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 29 May 2020 12:04:28 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FPTNiZkCRZZkw1+dQw8Z8h1oMkFlNlf/Epld5PpGqAvV1wu3ygwKOrXmnSt5taNXGOprAaRc5CFtCja1NboxmU9XI1LMIBxxwr+WmwluImDI+dWcyf2UGM1aApLhQG6LpLq/m7r0+R6fTihMWRIWJ2WE+Q0XE4Qf1FED05XLR4T3TtC/CH5Y6rYI1KXevfIEm7vVDtgo6AK0PlGWj9UlwWs7QAVdfhxnzmqX1efEwkzN/N1EqolDieZoXezKAdjfMCGImtkgftDQwRhqadrwrH1JYYD76UvSKcbxn7eKPDAEE1NwbHuMef784VM1qsVxFJXVI8C+FZBPWa8SuN5TQQ==
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=1PAk4oijW+I0/MoewmQqY2xoytmfjI9UgZc5gAHChag=; b=ach9VA7ZgRNjfvM+Yf28IINQjRE/qIMf7TYe3nXdnJXkKzvR0C+mUNTDvb9QbfMwjRErM2DzRLjZ+V9Di1CayTRLqrPI3hgOTDSpA9z+VdBpP9VJFDkmgw53gJqjr/4/WAY7YqSi9VUy+CmJPXLdaoE3UUbot6RFikdL824Pexlu4pnhJ6Ie0nf3XlXZZFcZJ4Hp5rPHja2OpIbvtg78Yg9k30g5aAx6xeE+Wo/6EyB67JvmvxMX+Ty4BLHwpiK1iBZO65hMOOsoBwzMYGtIpPc4X243EqpBssgR8cZhjy26i5gVkbPV5piBJOvJ+JQ2NyDW1SFSozYroVmtTK8kEw==
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=1PAk4oijW+I0/MoewmQqY2xoytmfjI9UgZc5gAHChag=; b=GN2sDKH3kBG7Qm7XbAZ7+ZBsxSzvBsfhTjXTuUw24+GTCmDHuCF1G0ItQrTd7Y8RaAqiMXhgpHkUGEP2E7++5iKEPFen3yYux0/9ub81r4fgtkYRH+NRukJglorcCrkrUCPSlVs/f5IefkBU4h3RoEGxPVVUX4DG2RrPlxIxwK0=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4745.namprd11.prod.outlook.com (2603:10b6:303:5e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Fri, 29 May 2020 17:04:26 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%5]) with mapi id 15.20.3045.018; Fri, 29 May 2020 17:04:26 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Erik Kline <ek.ietf@gmail.com>, "Zafar Ali (zali)" <zali@cisco.com>
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: AQHWNFukLM0xAvUWK0W7ISBmqA7+6qi8UGJQgABBSoD//88bgP//zJqAgABIy4CAAQk9sIAAHPCAgAGujnA=
Date: Fri, 29 May 2020 17:04:26 +0000
Message-ID: <MW3PR11MB4570188EB18C2897D58033DBC18F0@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <DM6PR05MB6348D86E8BE339067C5238E4AEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <30C37AC0-B03A-45B1-BE0F-7E185361BBBC@liquidtelecom.com> <64e6b98b01c64ec8b699c065bc7ee9e0@boeing.com> <94DF5577-4DCC-4491-A12B-21EAC214172F@cisco.com> <CAMGpriURYBukqQOgnnkySjrQXgeWY+XJVD=d3rOnvVUOLC-E1w@mail.gmail.com> <SA0PR11MB45761E7185932A82F58E3EFCC18E0@SA0PR11MB4576.namprd11.prod.outlook.com> <DM6PR05MB63487D96C21742F4C6991D6FAE8E0@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB63487D96C21742F4C6991D6FAE8E0@DM6PR05MB6348.namprd05.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-05-28T15:13:24Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=3024c23e-3bc8-440c-b1f1-d4ce3fe69201; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.18]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4b0094f5-6ddb-422a-d449-08d803f25805
x-ms-traffictypediagnostic: MW3PR11MB4745:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MW3PR11MB4745E07FBCEC26B2BB1B86ABC18F0@MW3PR11MB4745.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04180B6720
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LHxsFXxHYBV3chCQ/J6m97nFt2rgW6duehuUnuCvg/8FSLZvLlW6aaDGP6mi3x9zg2H1dTavHjWWsJkirthZGyq/XuFjKaBfvreNMnx08Wn55I1kHGcf1/AlMdcUF36rRrl5kSN6atlkKazQN71sb1utNe7CQA51NbgTohnjMtSqQneMC+9oV1GAGuLcyGBkLFfF5H7S7c+WYNo9AJtW7Uz/5uqUQvZpjfN1n2Re1g1924z1vUDnqAe9ztWBW4MopdR7Ui+31mBmUHcR/Ewah3k1pAKkPjWYsrjCaE8y4l+9fiUZWa16d+voGKrfvg0nV9yPUUtphmCebVPT53WLvWv6Qq1VW3akoRZ98cavF0dwijGxeVLM0HSM+4QgpwS1bTHi57C7l6a+cnAjUUV78g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(376002)(136003)(396003)(366004)(9686003)(186003)(71200400001)(54906003)(26005)(4326008)(55016002)(52536014)(8936002)(6506007)(9326002)(110136005)(76116006)(316002)(66946007)(478600001)(86362001)(30864003)(5660300002)(8676002)(66476007)(66574014)(83380400001)(33656002)(64756008)(66556008)(66446008)(166002)(6636002)(966005)(7696005)(2906002)(53546011); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: KMYz/b1GHEvLYiAHGypUkOKz89X88DfCFrCy9ACPjB2uiSQHAjj3Y2oxUP6SJkoD6pAUIkAcyqYjbmRU/nXA19m8h91qWgYaumholFlkFkvmnZKFM5W/2Qa+NyObxnEnzgFt8tBaGXKn+qu3a+18IUSBLGdc45qvtUJ8TMFaocz4g131r3a77dI5zr+lQ7aL3esbiYErs2jsSAE55DOLHrhGWygC5qVrkVChjowOvG2ivFtM2faCgE7NcQgMJgjk4YxbyBYlW9LAKxPVwvtcUJ+aa7r3s4zA0LZsmem5ndYQWMmv0aBP2DX2rh/jzwvuwLcSsBe4KLbDEfdmevl+3o9kLHDCft0mNKqryIdB9qVd2z6pqtTVtCP+7ZxCunvn8uyxgfmSu29tVHXWNswoaSJOSZNPC/1SYoBXdzIafXS3a2g/4bZOKHo+/PvFsIyRVg8nDBgSWgEyFHjzYv9Gqfue52+aTRHc8zvK6Z6bYbPHUb2ODljXdTaluCVi4c7i
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570188EB18C2897D58033DBC18F0MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b0094f5-6ddb-422a-d449-08d803f25805
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2020 17:04:26.5127 (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: TJWWZgvo79rTufgO8VeXUFsO7Z33ovtH0CWtRPeAWAJQ6cX152to7fJaIkAU3+vNJ7vH2HqS1Iuw/QOhaCH5Qg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4745
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/72Z3p0-Lt1EVPSThnzDjJGK9FWA>
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: Fri, 29 May 2020 17:04:44 -0000

Hi Ron,

The problem that I see is that the draft that we are reviewing for adoption does not explain properly how CRH based IPv6 Source Routing works it's evaluation for WG adoption.

I do find some of those details in the SRm6 draft which uses CRH but based on your response, we should not be referring to it since it might be wrong or not updated? Also, that SRm6 solution is different and meant for Spring WG evaluation?

I would again request to please document the applicability, use-cases and explain how the mechanism works along with the CRH header specification. After all, we are considering a document for adoption and it is difficult to put together all the bits and pieces spread over hundreds of emails.

Thanks,
Ketan

From: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Sent: 28 May 2020 20:43
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Erik Kline <ek.ietf@gmail.com>; Zafar Ali (zali) <zali@cisco.com>
Cc: 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?

Ketan,

Please take a look at the version of the draft that we are reviewing. Values 0-15 are no longer reserved.

                                         Ron




Juniper Business Use Only
From: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:ketant=40cisco.com@dmarc.ietf.org>>
Sent: Thursday, May 28, 2020 9:33 AM
To: Erik Kline <ek.ietf@gmail.com<mailto:ek.ietf@gmail.com>>; Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>
Cc: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6man@ietf.org<mailto: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?

[External Email. Be cautious of content]


Sometimes a known devil is better than an unknown one.



I think we need to be very careful in considering the introduction of a new label/ID mapping technology into IPv6 Routing and it's ramifications.



https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-5.1__;Iw!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BMV7uEIv$>


   The maximum 16-bit SID value is 65,535.  Because SIDs 0 through 15
   are reserved for future use, a 16-bit SID offers 65,520 usable
   values.

   The maximum 32-bit SID value is 4,294,967,295.  Because SIDs 0
   through 15 are reserved for future use, a 32-bit SID offers
   4,294,967,280 usable values.



This is the same as https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BOmRmTOF$>



So is this, then in fact, an attempt to reinvent MPLS in a new avatar?



While some are talking about the CRH proposal as a brick, I see it as a tip of an iceberg. It is not just a new RH - it has significant impact across routing and ops areas. I would think one would expect a BoF for something like this? Therefore the request for proper documentation of the applicability, use-cases and architecture and their presentation (that too in the right areas/WGs) for the proper evaluation of this proposal.



Thanks,

Ketan





-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Erik Kline
Sent: 28 May 2020 03:11
To: Zafar Ali (zali) <zali=40cisco.com@dmarc.ietf.org<mailto:zali=40cisco.com@dmarc.ietf.org>>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6man@ietf.org<mailto: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?



There are actual, meaningful differences to be contemplated; folks with no operational MPLS in there networks might not want to be forced to start.





On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali) <zali=40cisco.com@dmarc.ietf.org<mailto:zali=40cisco.com@dmarc.ietf.org>> wrote:

>

> Fred,

>

>

>

> Is there any IETF requirement document for OMNI and AERO (I am sorry I am not aware of the technology but very much interested in learning)?

>

> Do we have some documents describing the scale you would need?

>

> Have the associated WG analyzed existing solutions?

>

> Have they feed the results of the above to 6man WG?

>

>

>

> All other routing header types have had requirements and designs from dedicated working groups with expertise in the area.

>

> Why should CRH be an exception, especially when there are multiple competing solutions in 6man and Spring?

>

>

>

> Thanks

>

>

>

> Regards ... Zafar

>

>

>

> From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>

> Date: Wednesday, May 27, 2020 at 4:33 PM

> To: Andrew Alston <Andrew.Alston@liquidtelecom.com<mailto:Andrew.Alston@liquidtelecom.com>>, Ron Bonica

> <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>, "Zafar Ali (zali)"

> <zali@cisco.com<mailto:zali@cisco.com>>, "Henderickx, Wim (Nokia - BE/Antwerp)"

> <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>, Sander Steffann <sander@steffann.nl<mailto:sander@steffann.nl>>

> Cc: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, 6man <6man@ietf.org<mailto: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?

>

>

>

> As I said, I want to use CRH for OMNI and AERO; I don't want the term

> "MPLS" to appear

>

> either in my documents or in any documents mine cite. The 16-bit CRIDs

> in CRH are very

>

> handy for coding ULA Subnet Router Anycast addresses such as

> fd80::/16, fd81::/16,

>

> fd82::/16, etc., and the 32-bit CRIDs are very handy for coding the

> administrative address

>

> suffixes of fd80::/96. So, CRH gives everything I need (and nothing I

> don't need) for

>

> successfully spanning the (potentially) multiple segments of the AERO link.

>

>

>

> Thanks - Fred

>

>

>

> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Andrew Alston

> Sent: Wednesday, May 27, 2020 1:19 PM

> To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>; Zafar Ali

> (zali) <zali@cisco.com<mailto:zali@cisco.com>>; Henderickx, Wim (Nokia - BE/Antwerp)

> <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>; Sander Steffann <sander@steffann.nl<mailto:sander@steffann.nl>>

> Cc: spring@ietf.org<mailto:spring@ietf.org>; 6man <6man@ietf.org<mailto: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?

>

>

>

> What I find so bizarre is -

>

>

>

> You have an multiple operators - who have clearly said - we want this - we see advantage of this.  Yet still the obstructionism and denialism continues.  The "not invented here" syndrome seems to run deep - and email after email is patently ignored from the very people who have to buy the hardware.  Reference is made to Montreal - yet the emails that stated the use cases after it went by with no response.  No technical objections ever show up - other than - we don't want this and you haven't given us this mythical architecture document - which was yet another non-technical response that seems so clearly designed to stall any innovation that doesn't come from one source.

>

>

>

> All I see from the operator perspective here is obstructionism and stalling in a desperate attempt to block anything that could be a threat to what was dreamed up by someone else.  It is almost as if there is fear that the market may choose something other than what was designed - and that fear is driving this stance of throw everything we hav against the wall and hope that something sticks - because the technical arguments have failed time and again.

>

>

>

> This pitbull approach certainly doesn't garner any respect for me, does not help to promote srv6 which seems to be what you want and in fact convinces me more every day that CRH is the right move - where I can built on top of it without the obstructionism of a vendor that seems to have zero interest in what mysef and other operators are clearly stating over and over again.

>

>

>

> Yet again - I support crh - I've deployed CRH - CRH works for us - and we still continue to support it.  And irrespective of if it is adopted - the development of it will continue - and it will exist - the only question is - do we end up with something that the market wants outside of the auspices of the IETF - or do we end up with something that is properly standardized, because this level of obstructionism will not prevent the development.

>

>

>

> Can we actually get back to proper technical reasoning?

>

>

>

> Thanks

>

>

>

> Andrew

>

>

>

>

>

> From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of Ron Bonica

> <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>

> Date: Wednesday, 27 May 2020 at 23:07

> To: "Zafar Ali (zali)" <zali@cisco.com<mailto:zali@cisco.com>>, "Henderickx, Wim (Nokia -

> BE/Antwerp)" <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>, Sander Steffann

> <sander@steffann.nl<mailto:sander@steffann.nl>>

> Cc: 6man <6man@ietf.org<mailto:6man@ietf.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@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,

>

>

>

> Why all the passion about stopping the CRH? Does it break any existing standard? Does it consume any scarce resource?

>

>

>

> You might argue that there is a scarcity of Routing header type numbers. But that would be a very short argument. You might argue that WG resources are scarce, and that it would take too much time to review this fourteen page document. But that argument might take more time than the document review.

>

>

>

> In your email, below, you mention "the hardware and software investment from vendors". Is that the scarce resource?

>

>

>

> Vendors are not obliged to implement every draft that is adopted as a WG item. Generally, the marketplace drives product roadmaps.

>

>

>

> If the only resource we are protecting is vendor investment, the long-standing practice of due diligence should be tempered by operator demand. The IETF should not pretend to understand operator requirements better than the operators themselves.

>

>

>

> Why not let the marketplace decide whether it needs a CRH?

>

>

>

>

> Ron

>

>

>

>

>

>

>

>

>

>

>

> Juniper Business Use Only

>

> From: Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>

> Sent: Wednesday, May 27, 2020 3:19 PM

> To: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>;

> Sander Steffann <sander@steffann.nl<mailto:sander@steffann.nl>>

> Cc: Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>; Ron Bonica

> <rbonica@juniper.net<mailto:rbonica@juniper.net>>; Chengli (Cheng Li) <c.l@huawei.com<mailto:c.l@huawei.com>>; 6man

> <6man@ietf.org<mailto:6man@ietf.org>>; spring@ietf.org<mailto:spring@ietf.org>; Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>

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

>

>

>

> [External Email. Be cautious of content]

>

>

>

> WH> My position remains that RFC8663 is a valid alternative and is available; I am against WG adoption of CRH.

>

>

>

> The industry widely supports RFC8663.

>

>

>

> Instead of denying the evidence, could the CRH authors and proponents finally understand that people are not opposed to new ideas?

>

>

>

> People are reminding a long-standing practice of the IETF process.

> Before tackling a new piece of work, a working group must perform a

> due diligence on

>

> whether this new work is redundant with respect to existing IETF

> protocols, whether this new work would deliver genuine benefits and use-cases.

>

>

>

> It is factually and logically clear to the working-group that the currently submitted CRH documents.

>

> fail to position CRH with respect to existing standard widely

> supported by the industry (e.g., RFC8663) fail to isolate new benefit

> or use-case [1]

>

>

>

> This positive collaborative feedback was already given in SPRING.

>

> The CRH authors may change this analysis. They need to document 1 and 2.

>

>

>

> Why did the CRH authors not leverage this guidance in SPRING WG?

>

> This was also the chair's guidance in Montreal [2] and Singapore [3]

>

>

>

> All the lengthy discussions and debates on the mailing list could be avoided if only the CRH authors would tackle 1 and 2.

>

>

>

> The CRH authors must tackle 1 and 2.

>

>

>

> This is the best way to justify a/the work from the IETF community and b/ the hardware and software investment from vendors.

> True benefits must be present to justify such a significant engineering investment (new data-pane, new control-plane).

>

>

>

> Thanks

>

>

>

> Regards ... Zafar

>

>

>

> [1]

> https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BCkxCAZs$>

> /

>

> [2]

> https://etherpad.ietf..org:9009/p/notes-ietf-105-spring?useMonospaceFon<https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BE3cPbDF$>

> t=true

>

> [3]

> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BNCmxwgB$>

> /

>

>

>

>

>

>

>

> --------------------------------------------------------------------

> IETF IPv6 working group mailing list

> ipv6@ietf.org<mailto:ipv6@ietf.org>

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BBhsPHWV$>

> --------------------------------------------------------------------



--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org<mailto:ipv6@ietf.org>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BBhsPHWV$>

--------------------------------------------------------------------