Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 16 October 2020 08:48 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 099F23A0DEE; Fri, 16 Oct 2020 01:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OyR_ia__LRjY; Fri, 16 Oct 2020 01:48:00 -0700 (PDT)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302E13A0DF3; Fri, 16 Oct 2020 01:47:58 -0700 (PDT)
Received: from localhost.localdomain (unknown [106.121.6.236]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 36CA847F56; Fri, 16 Oct 2020 16:47:53 +0800 (CST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 16 Oct 2020 16:47:52 +0800
Message-Id: <3E930E88-9404-4874-888B-881D022DFFEC@tsinghua.org.cn>
References: <BY5PR11MB433711AAAE41AF690304AC47C1030@BY5PR11MB4337.namprd11.prod.outlook.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, John E Drake <jdrake@juniper.net>, Christian Hopps <chopps@chopps.org>, lsr-chairs@ietf.org, lsr@ietf.org, lsr-ads@ietf.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org
In-Reply-To: <BY5PR11MB433711AAAE41AF690304AC47C1030@BY5PR11MB4337.namprd11.prod.outlook.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
X-Mailer: iPhone Mail (18A373)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTEwYQhhOGklNSEtOVkpNS0lDSENLTEhITUJVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hNSlVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NVE6Hgw6Kz8uATxISBQqGjwB TSgKC0NVSlVKTUtJQ0hDS0xIQ0xMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVU1VSUhNWVdZCAFZQU9NSE43Bg++
X-HM-Tid: 0a7530980f919865kuuu36ca847f56
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/z3devefCOb3dNPUxPCO57CELrqY>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
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: Fri, 16 Oct 2020 08:48:04 -0000

Hi, Les and experts in LSR:

I am open to the removal of the this appendix to forward this draft.
But as stated in previous mail, providing this can assist the user/reader of the draft. We often encounter the questions in the mail list that what the usage of protocol/bit definition in some drafts.

Actually, we did not expand the discussion of this part in this draft. The description of this part is very concise.

If you insist this, I can update the draft in recent days, together with other comments on this draft.

Other comments are welcome also!

Aijun Wang
China Telecom

> On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:
> 
> Aijun -
> 
> The point I am making is very focused.
> 
> This draft is defining a protocol extension. As such it is necessary that this be Standards track as adhering to the normative statements in the draft are necessary for interoperability.
> 
> What is discussed in the Appendix is a use case. It is not normative and there are strong opinions on both sides as to whether this is an appropriate use case or not.
> In the context of this draft, I have no interest in trying to resolve our difference of opinion on this use case. I simply want the protocol extension to move forward so that we have another tool available.
> 
> If you want to write a draft on the use case discussed in the Appendix please feel free to do so. That draft may very well not be normative - Informational or BCP may be more appropriate - because it will be discussing a deployment scenario and a proposal to use defined protocol extensions as one way to solve problems in that deployment scenario. Such a draft might also be more appropriate in another WG (e.g., TEAS). The merits of using prefix advertisements to build a topology could then be discussed on its own. 
> 
> Please do not try to avoid having a full discussion of the merits of using prefix advertisements to derive topology by adding it to a draft that is (and should be) focused on simple protocol extensions.
> 
> Thanx.
> 
>   Les
> 
> 
>> -----Original Message-----
>> From: Aijun Wang <wangaijun@tsinghua.org.cn>
>> Sent: Thursday, October 15, 2020 6:51 PM
>> To: 'Jeff Tantsura' <jefftant.ietf@gmail.com>; 'John E Drake'
>> <jdrake@juniper.net>
>> Cc: 'Christian Hopps' <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg
>> (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org; lsr-ads@ietf.org; draft-ietf-
>> lsr-ospf-prefix-originator@ietf.org
>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> 
>> Hi, Les, John and Jeff:
>> 
>> Let's reply you all together.
>> In my POV, The standard document should not define solely the protocol
>> extension, but their usages in the network deployment. As I known, almost
>> all the IETF documents following this style.
>> And, before adopting one work, we have often intense discussion for what's
>> their usages.
>> Such discussion in the mail list and statements in the doc