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

Robert Raszuk <robert@raszuk.net> Wed, 27 May 2020 22:06 UTC

Return-Path: <robert@raszuk.net>
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 E4B943A0CF4 for <spring@ietfa.amsl.com>; Wed, 27 May 2020 15:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 0OjmMyHwtskH for <spring@ietfa.amsl.com>; Wed, 27 May 2020 15:06:25 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E4F3A0CEE for <spring@ietf.org>; Wed, 27 May 2020 15:06:24 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id z5so29913147ejb.3 for <spring@ietf.org>; Wed, 27 May 2020 15:06:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iLz2wiKFb0+/xN9W47XLS8oMIYbfYBhpAK3WkxjQp8w=; b=Mvmzuc1E5ytYkWfBoiXC8P5nclA1Ao27kI/9kFF5S2ReGCsT+gCuHE5N/38pc4PIah RXOLRlvG8NNDB+Rve0VbarNz/VPHMvkl7KpTqWTBg0KcTp+2mluB36PiEC4kph24PsV2 DbQJmU5ctlJtCL30O8pJ6Y4pTRJ2yaOpB6H94dTwefEe1KWnTrYJZsUkrTCT2u+z+SQ8 hvbG1L1VRmyhy/Cx/Uc9eNgbzqFjMZlBey+UNAFZXcyqLyeRnkRmB9kbJI16LBX/yjE3 pn5NMUxCH9GYLlgTJCmARcGPfIDoXakgKeWDmtCDuvsld9Py1FLsl6Fp9RVAXDchuco1 WJig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iLz2wiKFb0+/xN9W47XLS8oMIYbfYBhpAK3WkxjQp8w=; b=kJTsPhrb11I+N/h4swlCiOJ2rWBjmNPBcAn/puMYHayiU/6zV6f8DO0P4l2GZ3PMFf OwxJLcaM58UqDEk5XyniHm58YIQ1qV2edhG7MC3VgUEh0t65X/7ckSmU/QMrxSQ8izJN UY5w3YGmucpNexzs/kARirLgRveXDStootSKCv5/l2uamrOBhRsfZ7Fl9KjcQ4Vf32xB pZpKF+M1Q3vuYK2p3f2VHVCRYM8SvdlgmIeIJNicssGCNZZAd89iDwQz8LpDxg5fMS94 jjKlcaJkPvcge2aMfH5au5X4Q6oavoL2gUPQp4bwATKbhZntf2W2D4KPPCbO0eps/hIj tXKQ==
X-Gm-Message-State: AOAM531lgA322ro00zrENIBA9swvSg1JJB8wtyE9cO6BdCu15ZtWp8Bj odx9bfn60nM2hWRPp3v1wc3zSKs4JHEWYGB78ihzoQ==
X-Google-Smtp-Source: ABdhPJz41/KU2DfgKUZhALmUsq5cBHH+QMWoCNAlMNlWwejWtdYPmyyOM36wsWJ2jxAPACEaO+Im+IHo/k6jfee7Yr8=
X-Received: by 2002:a17:906:7fd7:: with SMTP id r23mr374393ejs.386.1590617183268; Wed, 27 May 2020 15:06:23 -0700 (PDT)
MIME-Version: 1.0
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <DM6PR05MB6348D86E8BE339067C5238E4AEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <30C37AC0-B03A-45B1-BE0F-7E185361BBBC@liquidtelecom.com> <CAOj+MME+kkfTKFQaS1zvW7wgQvLqui6jFQH9-eai6eY32t9fmQ@mail.gmail.com> <DM6PR05MB6348817A06F9905BCC23A767AEB10@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB6348817A06F9905BCC23A767AEB10@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 28 May 2020 00:06:14 +0200
Message-ID: <CAOj+MMG_U-sAcnDACqOQD_gjTg98Q=7Oo3ai11tJ-Wk8a4xi4A@mail.gmail.com>
To: Ron Bonica <rbonica@juniper.net>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Sander Steffann <sander@steffann.nl>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002ec8ab05a6a86c19"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/i4dvJ4LVMprxvOnlCgLiwL4x56Q>
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: Wed, 27 May 2020 22:06:28 -0000

Hi Ron,

If there would never been SRm6 I would welcome that we have a technical
discussion and compare pros and cons between CRH and RbR .. then we proceed
with best option for the industry.

If you are open to such discussion my doors are open.

Best,
Robert

On Wed, May 27, 2020 at 11:59 PM Ron Bonica <rbonica@juniper.net> wrote:

> Robert,
>
>
>
> If there had never been an SRm6 proposal, would you still object to the
> CRH?
>
>
>
>
>                                             Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Wednesday, May 27, 2020 5:50 PM
> *To:* EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com
> >
> *Cc:* Ron Bonica <rbonica@juniper.net>; Zafar Ali (zali) <zali@cisco.com>;
> Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>; Sander
> Steffann <sander@steffann.nl>; 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?
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Andrew,
>
>
>
> I don't think this is about killing innovation. After all no one is saying
> you can not use it in your network.
>
>
>
> WG acceptance calls are evaluated in terms of WG rough consensu if
> significant number of members of WG find a proposal useful and if they are
> willing to work on it.
>
>
>
> It seems clear that other then one vendor and very few individuals
> majority of the WG members do not support the adoption.
>
>
>
> I am not against CRH. But what I am against is that CRH/SRm6 authors
> already bounced back via SPRING doors so they have chosen to try to enter
> via 6man window. That is not proper style for any proposal.
>
>
>
> Regards,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, May 27, 2020 at 10:19 PM Andrew Alston <
> Andrew.Alston@liquidtelecom.com> wrote:
>
> 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> on behalf of Ron Bonica <rbonica=
> 40juniper.net@dmarc.ietf.org>
> *Date: *Wednesday, 27 May 2020 at 23:07
> *To: *"Zafar Ali (zali)" <zali@cisco.com>, "Henderickx, Wim (Nokia -
> BE/Antwerp)" <wim.henderickx@nokia.com>, Sander Steffann <
> sander@steffann.nl>
> *Cc: *6man <6man@ietf.org>, "spring@ietf.org" <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>
> *Sent:* Wednesday, May 27, 2020 3:19 PM
> *To:* Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>;
> Sander Steffann <sander@steffann.nl>
> *Cc:* Mach Chen <mach.chen@huawei.com>; Ron Bonica <rbonica@juniper.net>;
> Chengli (Cheng Li) <c.l@huawei.com>; 6man <6man@ietf.org>; spring@ietf.org;
> Zafar Ali (zali) <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
>
>    1. whether this new work is redundant with respect to existing IETF
>    protocols,
>    2. 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.
>
>    1. fail to position CRH with respect to existing standard widely
>    supported by the industry (e.g., RFC8663)
>    2. 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!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl0PT0CIY$>
>
> [2]
> https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true
> <https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl8aoFdbw$>
>
> [3]
> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVlypBDeuG$>
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> 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!WIXBKUmrm0y3g6Tak4T7QExZahofjlB9YL76AQtpLEloLcYX8nyN5RA4KY45RnTt$>
> --------------------------------------------------------------------
>
>