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

Xing Li <xing@cernet.edu.cn> Wed, 27 May 2020 23:22 UTC

Return-Path: <xing@cernet.edu.cn>
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 52D733A0D96; Wed, 27 May 2020 16:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 b5LiwXUwyvab; Wed, 27 May 2020 16:22:20 -0700 (PDT)
Received: from zg8tmty1ljiyny4xntqumjca.icoremail.net (zg8tmty1ljiyny4xntqumjca.icoremail.net [165.227.154.27]) by ietfa.amsl.com (Postfix) with SMTP id 091183A0D92; Wed, 27 May 2020 16:22:19 -0700 (PDT)
Received: from [192.168.0.105] (unknown [123.112.99.88]) by app-4 (Coremail) with SMTP id EgQGZQDHzsog9s5eBV1aAw--.35590S2; Thu, 28 May 2020 07:22:08 +0800 (CST)
Message-ID: <5ECEF621.4050009@cernet.edu.cn>
Date: Thu, 28 May 2020 07:22:09 +0800
From: Xing Li <xing@cernet.edu.cn>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Sander Steffann <sander@steffann.nl>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <31a550f4-dc86-acdf-dd92-b0ad2c89a5ca@gmail.com>
In-Reply-To: <31a550f4-dc86-acdf-dd92-b0ad2c89a5ca@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-CM-TRANSID: EgQGZQDHzsog9s5eBV1aAw--.35590S2
X-Coremail-Antispam: 1UD129KBjvJXoWxury7tr4xtFyrKw4ktrWDurg_yoW5Zr4DpF W5K3WxKws7JrZ2vwn7Xw18Xr10v3yrtay5Jwn5K3ykAr98W3W8Kr1xKrn09a47CrZ5WF4q vr40grsxuasYyaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_Gr0_Gr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc2xSY4AK67AK6FWl42xK82IYc2Ij 64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x 8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE 2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42 xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv 6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07b2NVkUUUUU=
X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7BEokFKe4GM-tojNjA7q-YVAuBI>
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 23:22:22 -0000

Brian E Carpenter 写道:
> 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).
>   

+1

xing

> Regards
>     Brian
>
>
>  
>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>