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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 27 May 2020 21:06 UTC

Return-Path: <brian.e.carpenter@gmail.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 900F33A0BDB; Wed, 27 May 2020 14:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zBFxLbQtzhMg; Wed, 27 May 2020 14:06:16 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 4CAED3A0B8D; Wed, 27 May 2020 14:06:14 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id a13so10656303pls.8; Wed, 27 May 2020 14:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PIQN72v3FuhCZMVEJehGpf2D1rlQkSazkfQ01StABM4=; b=EgwpH/9Jlj/yFWMo/sSsMm/JXUViz56l9NNek9xu4F3gPJAXhWV++WKZ0Ogcv9fNbi wlHcQqnHDlBI6LHiVWnruCsNOYUmpsOWizL1ikmQW1QbU8vWqjKu2/j4/orV8dzwjsh9 jCf91DgbZ/WOpCzc0zhQNDf1N6tZmxZ4yTnn2w9MbiopV18S3ieBHGjuJ8QyOKJDo6j2 1iw2YBMK/ExvCNXnjOrs8rii/F1wSyXNM1NPxverPi93dMCCZUpmi7RBJF07C3DrDFEE afsc4bR+8fPG/Ce8YNxUWTY9q+kWNOATFX2PFtduC4T3yd4Ihben74hnW7WNFLVkAblo oNNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PIQN72v3FuhCZMVEJehGpf2D1rlQkSazkfQ01StABM4=; b=aj4e6ZnIj3KRedKPTOx915/g448b/xr2B6ZT4GZEFw+1+gmFiu0yeq0jeGU8VbPUF8 yZpzkXI+N51awQXauqXrRQqPZtqW5pKW45HD1VC9noseX4bHlnuJjUB5rufwt4xriCzu 36z1SNgDtnOGe2ydJqYk4Exy6AhhWUMPE0UpV07AJxfDkQR1g1rgy+U/IYDex7iAxZh0 wzirETJ2NvgBotIdoOa1iR0vUtzHRuDUT0MTLJ2tzghW6LoOzwGgC7LIymXTv/yQ8lBM XlAA0ssYyyVZ76u93tjiXq+orJzmpeYXmr3yJZ8BuYPbf04sT9D/IzfzwcE4kleCg9Td zs+A==
X-Gm-Message-State: AOAM5312GT0GRIlRTBf/qF+VCJgEHN+TDDGJRHXR9UJ1E86uTZ5qBb0t R5G6H6a3/pyMqhuyedcPH38hDnEC
X-Google-Smtp-Source: ABdhPJwzfxlgEz/oHRZRltWQCdlgiTmekLWkqDjrciow7MWNpwfV3aI1TUwQgvmAlGRzQ/vhV+rCww==
X-Received: by 2002:a17:902:bd42:: with SMTP id b2mr235889plx.219.1590613573291; Wed, 27 May 2020 14:06:13 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id gd1sm3302918pjb.14.2020.05.27.14.06.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2020 14:06:12 -0700 (PDT)
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
To: "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>, "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>
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <31a550f4-dc86-acdf-dd92-b0ad2c89a5ca@gmail.com>
Date: Thu, 28 May 2020 09:06:06 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2gjgoqBtkpEd791xt1ZJMVFMgJU>
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 21:06:18 -0000

On 28-May-20 07:18, Zafar Ali (zali) wrote:
> 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.

Can you remind us which major operators rely on RFC8633 today? After all, the RFC is only 5 months old.

> 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. 

I don't know where you get that "must" from since the IETF has no rules to govern the process of draft adoption. (There will be a draft about that shortly, for possible discussion in gendispatch, but today there are no rules).

There is some general guidance about redundancy, in RFC1958:

  "3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."

So, in so far as we have guidance on when to accept apparent duplication, it is around two judgments: "there is a good technical reason" and "improvements".
   
> 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]

Neither of those things are required in a protocol spec. I'm not saying they are unimportant, or that they should not inform the adoption decision, but they have been discussed on this mailing list and IMHO that is sufficient for the WG decision.

I'm not competent to "position" CRH. That's why I'd like hear from the Routing Area ADs. However, I will comment that it takes about 10 minutes to read and understand the CRH spec. It would take several days to read and understand the SRV6 material to the point of fully understanding RFC8574 (I know because I tried), and RFC8663 also needs a lot of background reading. There are a couple of other items in RFC1958 that seem relevant to this:

  "3.5 Keep it simple. When in doubt during design, choose the simplest
   solution.

   3.6 Modularity is good. If you can keep things separate, do so."

CRH factually and logically wins on those criteria. 

The use case is: some operators want this. That has been enough for the IETF since 1986 (and is of course much more important than vendor preferences).

Regards
    Brian