Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun Wang <wangaijun@tsinghua.org.cn> Sat, 15 January 2022 00:58 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C3E3A1A1C for <lsr@ietfa.amsl.com>; Fri, 14 Jan 2022 16:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 gHivRdE-m3oJ for <lsr@ietfa.amsl.com>; Fri, 14 Jan 2022 16:58:41 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9B43A1A19 for <lsr@ietf.org>; Fri, 14 Jan 2022 16:58:40 -0800 (PST)
Received: from smtpclient.apple (unknown [221.223.101.81]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 2750E1C0322; Sat, 15 Jan 2022 08:58:38 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-C9E64BD8-9976-4CE8-AA5F-3CF17DBE0D6E"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 15 Jan 2022 08:58:37 +0800
Message-Id: <866D7F3E-231E-467F-A14D-B90869831375@tsinghua.org.cn>
References: <44E6BC32-0EFA-4B8C-9CD4-A8616E32C20C@chopps.org>
Cc: Robert Raszuk <robert@raszuk.net>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, lsr <lsr@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
In-Reply-To: <44E6BC32-0EFA-4B8C-9CD4-A8616E32C20C@chopps.org>
To: Christian Hopps <chopps@chopps.org>
X-Mailer: iPhone Mail (19B74)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUpMS0tKN1dZLVlBSVdZDwkaFQgSH1lBWUIaHUxWGkMYQk0dSR 9NSkkfVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6KzY6Ahw6OT5DC0xCNTURNTwY CDcKFBRVSlVKTU9JSUtDSEpDT0hJVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUpLSlVDSllXWQgBWUFKS0lCSzcG
X-HM-Tid: 0a7e5b3e52d4d993kuws2750e1c0322
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/CsiqDCpqGjEMSB30SpgwXE0C0Gg>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jan 2022 00:58:46 -0000

Hi, Christian:

Actually, https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1 is the main scenario that want to be solved by this adopting draft.
The reason that we mentioned https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute is that we should consider more possible scenarios to find the extensible solution. 
For standard activities and working group, we should look further. 

I admire everyone’s opinions and won’t expect everyone agree me. But knowing the reason or viable solution can certainly aid the solve of the problem, or make thing forward.
We all expect constructive suggestions, right?


Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:19, Christian Hopps <chopps@chopps.org> wrote:
> 
> 
> 
>> On Jan 14, 2022, at 6:39 PM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
>> 
>> Hi, Robert:
>> 
>> I would say some people are likely to hear other’s explanations, some are reluctant. 
>> Anyway, I am eager to hear the independent technical analysis.
>> 
>> For the current scenarios and solutions, we have analyzed that RFC 5316 and RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.
>> 
>> I would like to hear the constructive comments, or other solutions that better the the one in this draft.
> 
> Chair Hat,
> 
> Just to be clear, whether this draft is adopted or not does not require that people agree with your solution or provide better ones.
> 
> The WG has to decide if it actually thinks it's worthwhile to work on the problem at all. Then it also has to decide if this draft in it's current form is the right vehicle to do this work. Only if those 2 things are satisfied will the document be adopted as a WG document.
> 
> Thanks,
> Chris.
> 
> 
>> 
>> Aijun Wang
>> China Telecom
>> 
>>>> On Jan 15, 2022, at 07:15, Robert Raszuk <robert@raszuk.net> wrote:
>>> 
>>> 
>>> Hi Aijun,
>>> 
>>> If not, I would say both you and Les’s understanding of this draft is not correct.
>>> 
>>> If two (or more) subject matter experts like Les & John can not understand the IGP draft I would not draw an immediate conclusion that this is their perception fault. 
>>> 
>>> Instead I would take a step back and see that perhaps there is something wrong with the draft itself ? 
>>> 
>>> Thx,
>>> Robert.
>>> 
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>