IETF Logo Mail Archive

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

刘毅松 <liuyisong@chinamobile.com> Sat, 30 May 2020 02:50 UTC

Return-Path: <liuyisong@chinamobile.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 7BBD63A131A; Fri, 29 May 2020 19:50:36 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 slxOGmEbM196; Fri, 29 May 2020 19:50:23 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 52B903A10C3; Fri, 29 May 2020 19:50:22 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app05-12005 (RichMail) with SMTP id 2ee55ed1c9e2ff5-368fe; Sat, 30 May 2020 10:50:10 +0800 (CST)
X-RM-TRANSID: 2ee55ed1c9e2ff5-368fe
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from LAPTOP5GS3BPC8 (unknown[114.245.35.241]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee95ed1c9df0bc-3434e; Sat, 30 May 2020 10:50:09 +0800 (CST)
X-RM-TRANSID: 2ee95ed1c9df0bc-3434e
From: 刘毅松 <liuyisong@chinamobile.com>
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, 'Mach Chen' <mach.chen@huawei.com>, 'Ron Bonica' <rbonica@juniper.net>, '6man' <6man@ietf.org>, "'Chengli (Cheng Li)'" <c.l@huawei.com>, "'Zafar Ali (zali)'" <zali@cisco.com>
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Date: Sat, 30 May 2020 10:50:08 +0800
Message-ID: <03db01d6362d$08c254f0$1a46fed0$@chinamobile.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03DC_01D63670.16E71B90"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdY2LQeuJruVW1N0QDmWnMPcn/YLwA==
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zMCDG38LGRoyCvCGJqxUPbz0wh0>
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: Sat, 30 May 2020 02:50:37 -0000

Hi Zafar

 

I totally agree with you. The CRH solution is more complicated but does not show any more genuine benefits. There is still no use-case document now to provide an understanding of the intended use of CRH.

 

Thanks

Yisong

发件人: spring <spring-bounces@ietf.org> 代表 Zafar Ali (zali)
发送时间: 2020年5月28日 03:19
收件人: Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>; Sander Steffann <sander@steffann.nl>
抄送: spring@ietf.org; Mach Chen <mach.chen@huawei.com>; Ron Bonica <rbonica@juniper.net>; 6man <6man@ietf.org>; Chengli (Cheng Li) <c.l@huawei.com>; Zafar Ali (zali) <zali@cisco.com>
主题: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

 

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://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/

[2]  <https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true> https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true

[3]  <https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/

v2.23.0 | Report a Bug | By Email