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

Hi, Chris: Originally, the appendix part is within the document, which is the start point/main motivation to extend the prefix origin.
There may exists other usages of this information. Pack these examples into some short sentences or introduction is viable, but expand some of them is also helpful.As I known, when we want to do protocol extension, we should  always convince other the reason/motivation/prospects to do so. On the other hand, the use case described in the current appendix is very prominent for operator to accomplish the TE task in multi-area environment.

Aijun Wang

在2020-10-16，Christian Hopps &lt;chopps@chopps.org&gt;写道:
 -----原始邮件-----
 发件人： Christian Hopps &lt;chopps@chopps.org&gt;
 发件时间: 2020年10月16日 星期五
 写道: [&quot;Les Ginsberg (ginsberg)&quot; &lt;ginsberg=40cisco.com@dmarc.ietf.org&gt;]
 主题： Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

 > On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org> 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.

 [As WG member]

 I find this very compelling and so support the removal of the referred to non-normative appendices.

 Thanks,
 Chris.

 > 
 > 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 document can certainly
 >> assist the reader/user of the document get the essence of the standard, and
 >> follow them unambiguously.
 >> 
 >> Regarding the contents of appendices, as stated in the section, "The
 >> Appendix A heuristic to rebuild the topology can normally be used if all links
 >> are numbered." I think this can apply almost most of the operator's network,
 >> and facilitate the inter-area TE path calculation for central controller, or even
 >> for the head-end router that located in one area that different from the tail-
 >> end router.
 >> 
 >> Keeping the contents of appendices does not have the negative impact of
 >> the protocol extension, it is just one reference for the usage of this
 >> extension.
 >> One can select not refer to it, if their networks are deployed with large
 >> amount of unnumbered links. But for others, the heuristic applies.
 >> 
 >> Best Regards
 >> 
 >> Aijun Wang
 >> China Telecom
 >> 
 >> 
 >> 
 >> -----Original Message-----
 >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Jeff
 >> Tantsura
 >> Sent: Friday, October 16, 2020 5:28 AM
 >> To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
 >> Cc: Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg
 >> (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; 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
 >> 
 >> +1
 >> 
 >> Regards,
 >> Jeff
 >> 
 >>> On Oct 15, 2020, at 11:33, John E Drake
 >> <jdrake=40juniper.net@dmarc.ietf.org> wrote:
 >>> 
 >>> Hi,
 >>> 
 >>> I agree with Les.  This is a simple protocol extension for a specific purpose
 >> and there is no reason to include speculation about its use for other
 >> purposes, particularly when it is inherently not suited for them.
 >>> 
 >>> Yours Irrespectively,
 >>> 
 >>> John
 >>> 
 >>> 
 >>> Juniper Business Use Only
 >>> 
 >>>> -----Original Message-----
 >>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
 >>>> Sent: Thursday, October 15, 2020 12:33 PM
 >>>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
 >>>> Cc: lsr-chairs@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
 >>>> 
 >>>> [External Email. Be cautious of content]
 >>>> 
 >>>> 
 >>>> I support moving this document forward.
 >>>> Similar functionality in IS-IS has proved useful.
 >>>> 
 >>>> I would however like to repeat comments I made earlier in the review
 >>>> of this document.
 >>>> The content of the Appendices should be removed.
 >>>> The Appendices define and discuss deriving topology information from
 >>>> prefix advertisements - which is flawed and should not be done.
 >>>> Perhaps more relevant, the purpose of the document is to define
 >>>> protocol extensions supporting advertisement of the originators of a
 >>>> prefix advertisement. There is no need to discuss how this mechanism
 >>>> might be used to build topology information.
 >>>> This document should confine itself to defining the protocol
 >>>> extensions - similar the RFC 7794.
 >>>> 
 >>>> If the authors do not agree to do this, I would encourage this point
 >>>> to be discussed during IESG review.
 >>>> 
 >>>>  Les
 >>>> 
 >>>>> -----Original Message-----
 >>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Christian Hopps
 >>>>> Sent: Wednesday, October 14, 2020 11:15 PM
 >>>>> To: lsr@ietf.org
 >>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org;
 >>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps
 >>>>> <chopps@chopps.org>
 >>>>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
 >>>>> 
 >>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
 >>>>> 
 >>>>> 
 >>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i
 >>>>> et
 >>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-
 >> gk!TaSzQThghtCFOuYPS2VjLq
 >>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
 >>>>> 
 >>>>> The following IPR has been filed
 >>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
 >>>>> !NEt6yMaO-
 >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
 >>>>> 5KtUHQ$
 >>>>> 
 >>>>> Authors,
 >>>>> 
 >>>>> Please indicate to the list, your knowledge of any other IPR
 >>>>> related to this work.
 >>>>> 
 >>>>> Thanks,
 >>>>> Chris.
 >>>> 
 >>>> _______________________________________________
 >>>> Lsr mailing list
 >>>> Lsr@ietf.org
 >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
 >>>> __;!!NEt
 >>>> 6yMaO-
 >>>> 
 >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm
 >> w8
 >>>> Lc$
 >>> 
 >>> _______________________________________________
 >>> Lsr mailing list
 >>> Lsr@ietf.org
 >>> https://www.ietf.org/mailman/listinfo/lsr
 >> 
 >> _______________________________________________
 >> Lsr mailing list
 >> Lsr@ietf.org
 >> https://www.ietf.org/mailman/listinfo/lsr
 > 
 > _______________________________________________
 > Lsr mailing list
 > Lsr@ietf.org
 > https://www.ietf.org/mailman/listinfo/lsr