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

Aijun Wang <wangaj3@chinatelecom.cn> Mon, 19 October 2020 14:50 UTC

Return-Path: <wangaj3@chinatelecom.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 712FA3A03C9; Mon, 19 Oct 2020 07:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 lT5-7RN4ar9r; Mon, 19 Oct 2020 07:50:36 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id 5B04A3A0B10; Mon, 19 Oct 2020 07:50:33 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.48:64126.1430900940
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-106.121.66.233?logid-c23347fea8674e979774d4ff41e07f22 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id C3D4C28008E; Mon, 19 Oct 2020 22:42:02 +0800 (CST)
X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn
Received: from ([172.18.0.48]) by App0024 with ESMTP id a1984f098bfd4670a67a664b8d41dd45 for jdrake=40juniper.net@dmarc.ietf.org; Mon Oct 19 22:42:38 2020
X-Transaction-ID: a1984f098bfd4670a67a664b8d41dd45
X-filter-score: filter<0>
X-Real-From: wangaj3@chinatelecom.cn
X-Receive-IP: 172.18.0.48
X-MEDUSA-Status: 0
Sender: wangaj3@chinatelecom.cn
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <wangaj3@chinatelecom.cn>
Mime-Version: 1.0 (1.0)
Message-Id: <286E3DC2-C8EC-4AAB-BF46-A2018E9341B5@chinatelecom.cn>
Date: Mon, 19 Oct 2020 22:41:38 +0800
Cc: Peter Psenak <ppsenak@cisco.com>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Christian Hopps <chopps@chopps.org>, Aijun Wang <wangaijun@tsinghua.org.cn>, lsr-chairs@ietf.org, lsr@ietf.org, Jeff Tantsura <jefftant.ietf@gmail.com>, draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
X-Mailer: iPhone Mail (18A373)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/6EZggrNW1cwvaIYy-MTYgCE2ngg>
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: Mon, 19 Oct 2020 14:50:40 -0000

Hi, John:

Would you like to illustrate your broken case more clearly and not make the conclusion so hurry?


Aijun Wang
China Telecom

> On Oct 19, 2020, at 22:15, John E Drake <jdrake=40juniper.net@dmarc.ietf.org> wrote:
> 
> Aijun,
> 
> What part of "using IP address advertisement to derive topological data is broken" do you not understand?
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -----Original Message-----
>> From: Peter Psenak <ppsenak@cisco.com>
>> Sent: Monday, October 19, 2020 6:32 AM
>> To: Aijun Wang <wangaj3@chinatelecom.cn>; Peter Psenak
>> <ppsenak=40cisco.com@dmarc.ietf.org>
>> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Aijun Wang
>> <wangaijun@tsinghua.org.cn>; Christian Hopps <chopps@chopps.org>; John E
>> Drake <jdrake@juniper.net>; lsr-chairs@ietf.org; lsr@ietf.org; Jeff Tantsura
>> <jefftant.ietf@gmail.com>; draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-
>> ads@ietf.org
>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> [External Email. Be cautious of content]
>> Hi Aijun,
>> please see inline:
>>> On 19/10/2020 12:10, Aijun Wang wrote:
>>> Hi. Peter, Les:
>>> We have defined many extensions for protocol, but only a small part of them
>> are deployed. Have you ever considered the reason?
>>> Adding more contents for their  potential usages can certainly be helpful for
>> their influences, or else, they will just stay at the IETF repository.
>> I disagree. RFCs are not deployment or use case documents. They exists to
>> address the interoperability.
>>> More replies inline below.
>>> Aijun Wang
>>> China Telecom
>>>> On Oct 19, 2020, at 17:14, Peter Psenak
>> <ppsenak=40cisco.com@dmarc.ietf.org> wrote:
>>>> Aijun,
>>>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
>>>>> Aijun -
>>>>> I am not going to continue these side discussions with you.
>>>>> The primary purpose of the protocol extensions are as stated in the draft
>> Introduction. This is analogous to the use cases for the equivalent extensions for
>> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
>>>>> You can show that you are listening to the concerns of WG members by
>> removing the Appendices - in which case you have (I believe) broad support for
>> moving the draft forward.
>>>> I agree with Les.
>>>> As a co-author, I have asked you several times to get rid of the use case
>> described in appendix.
>>> [WAJ] Moving the expansion of this use case from body part of this draft to its
>> appendix is our initial consensus, not remove it totally. We have discussed
>> intensely for its application in vary situations. The discussion results are stated
>> clearly in the appendix.
>> just because you insisted and did not listen to rest of us.
>>> Wish to hear more technical analysis/comments for the current statements of
>> this part from other experts, or from you if you have fresh consideration.
>> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
>> myself) are telling you that using IP address advertisement to derive topological
>> data is broken and you keep repeating it is valid use case and ask for more
>> reasoning.
>> thanks,
>> Peter
>>>> Trying to use prefix advertisement to derive topological data is simply
>> broken. The reason we are adding the prefix originator extension to OSPF is NOT
>> the broken use case in the appendix of the draft.
>>>> thanks,
>>>> Peter
>>>>> You can then write a separate draft to discuss other use cases and allow the
>> WG to discuss those other use cases w/o preventing the extensions from being
>> approved and deployed for the use cases which have already been
>> demonstrated as useful by IS-IS.
>>>>> If you remove the Appendices I can support the draft.
>>>>> If you do not remove the Appendices I cannot support the draft.
>>>>> Please discuss this with your co-authors and come to consensus on your
>> next step.
>>>>> Les
>>>>>> -----Original Message-----
>>>>>> From: Aijun Wang <wangaijun@tsinghua.org.cn>
>>>>>> Sent: Monday, October 19, 2020 12:06 AM
>>>>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; 'Christian Hopps'
>>>>>> <chopps@chopps.org>
>>>>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org;
>>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.ietf@gmail.com>;
>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org
>>>>>> Subject: RE: [Lsr] WG Last Call
>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>> Hi, Les:
>>>>>> As I stated clearly before, the appendix described in the draft is
>>>>>> not the new use case. It is the start point of this draft.
>>>>>> Have you noticed that the introduction part is not the final usage
>>>>>> of such protocol extension information?
>>>>>> Certainly, we will not expand all the possible use cases in very
>>>>>> detail, but putting some of them(some interesting, prominent use
>>>>>> cases) in the appendix will not hamper the protocol extension itself.
>>>>>> If the statements/descriptions in the appendix are not correct, we
>>>>>> can fix it, or remove it finally.  If not, why not let it be for
>>>>>> reference to the user of such protocol extension?
>>>>>> For the body part of this draft, we are also welcome comments.
>>>>>> More replies inline below[WAJ]
>>>>>> Best Regards
>>>>>> Aijun Wang
>>>>>> China Telecom
>>>>>> -----Original Message-----
>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf
>>>>>> Of Les Ginsberg (ginsberg)
>>>>>> Sent: Monday, October 19, 2020 2:15 PM
>>>>>> To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Christian Hopps'
>>>>>> <chopps@chopps.org>
>>>>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; 'Les
>>>>>> Ginsberg (ginsberg)' <ginsberg=40cisco.com@dmarc.ietf.org>;
>>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.ietf@gmail.com>;
>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org
>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>> Aijun -
>>>>>> The "use case" for the protocol extensions is clearly stated in the
>>>>>> Introduction:
>>>>>> "The primary use case for the extensions proposed in this document is
>>>>>> to be able to identify the originator of the prefix in the network.
>>>>>> In cases where multiple prefixes are advertised by a given router, it
>>>>>> is also useful to be able to associate all these prefixes with a
>>>>>> single router even when prefixes are advertised outside of the area
>>>>>> in which they originated.  It also helps to determine when the same
>>>>>> prefix is being originated by multiple routers across areas."
>>>>>> This is equivalent to language in RFC 7794 which defines the
>>>>>> analogous extensions for IS-IS.
>>>>>> Everything you have in the Appendix is not related to the primary
>>>>>> use case - and is fact a use case which many of us have objected to.
>>>>>> [WAJ] Very glad to know the false statements in the appendix.
>>>>>> You are entitled to write another draft advocating for your new use
>>>>>> case if you wish, but requiring that the protocol extensions in
>>>>>> support of the primary use case not go forward without your new use
>>>>>> case is - as Chris has stated very clearly - holding approval of
>>>>>> the protocol extensions hostage to your new use case.
>>>>>> [WAJ] It is not new use case. As I sated before, I am open to this
>>>>>> part, but should on the conditions that the statements in this part are
>> incorrect.
>>>>>> I am asking you (yet again) not to do this.
>>>>>> I cannot support the document moving forward with the content in
>>>>>> the Appendices included.
>>>>>> [WAJ] Would like to hear more technical analysis.
>>>>>> Les
>>>>>>> -----Original Message-----
>>>>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Aijun Wang
>>>>>>> Sent: Sunday, October 18, 2020 7:08 PM
>>>>>>> To: 'Christian Hopps' <chopps@chopps.org>
>>>>>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; 'Les
>>>>>>> Ginsberg (ginsberg)' <ginsberg=40cisco.com@dmarc.ietf.org>;
>>>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.ietf@gmail.com>;
>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org
>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>> Hi, Chris:
>>>>>>> I think we have "put the cart before the horse". For protocol
>>>>>>> extension draft, the origin is the use case.
>>>>>>> And I think we will not expand OSPF protocol, just because it lack
>>>>>>> something as compared with ISIS, right?
>>>>>>> As I stated before, the use case in current appendix is the main
>>>>>>> motivation of this draft, you can see this in main body of the
>>>>>>> earlier version of this draft(from version 0 to version 5).
>>>>>>> The reason that we move this part to the appendix, as that you
>>>>>>> said, is to let person focus on the protocol extension itself.
>>>>>>> Moving this part to appendix is acceptable, but removing it from
>>>>>>> the draft will erase the origin of this document.
>>>>>>> Is it reasonable that one document discusses the "origin"(of the
>>>>>>> prefix), can't keep its origin?
>>>>>>> More replies inline below[WAJ].
>>>>>>> Best Regards
>>>>>>> Aijun Wang
>>>>>>> China Telecom
>>>>>>> -----Original Message-----
>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf
>>>>>>> Of Christian Hopps
>>>>>>> Sent: Friday, October 16, 2020 10:47 PM
>>>>>>> To: 王爱俊 <wangaijun@tsinghua.org.cn>
>>>>>>> Cc: John E Drake <jdrake@juniper.net>; Christian Hopps
>>>>>>> <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg (ginsberg)
>>>>>>> <ginsberg=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; Jeff Tantsura
>>>>>>> <jefftant.ietf@gmail.com>;
>>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org
>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>> Isn't this just adding an analogous extension that already exists in
>> RFC7794?
>>>>>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the
>>>>>>> companion IGP protocol, OSPF can also accomplish this. And,
>>>>>>> actually, there are differences consideration in this draft for the protocol
>> extension.
>>>>>>> I don't think we need to do a lot of convincing at this point. I
>>>>>>> agree with Les, if you want to talk about use cases (especially
>>>>>>> ones that are controversial!) then the correct place for that is
>>>>>>> in a new informative
>>>>>> draft.
>>>>>>> [WAJ] we have discussed the use case before and state the
>>>>>>> discussion results at the appendix part. We will not emphasis and
>>>>>>> expand the use case more. If one does not agree the statement of
>>>>>>> this appendix, we can discuss online or offline. We just need to
>>>>>>> make the statement in
>>>>>> appendix is correct.
>>>>>>> Otherwise, especially if the cases are controversial, this can be
>>>>>>> seen as doing an "end-run" to avoid the debate b/c people want the
>>>>>>> extension, but maybe don't agree with your use case.
>>>>>>> [WAJ] One should point out which statement in the appendix is
>>>>>>> controversial, we can correct it. This use case is the origin of
>>>>>>> this draft, not the results.
>>>>>>> Legislators do this sometimes adding things they want personally
>>>>>>> to popular bills, that other people may not want, but since people
>>>>>>> want the main bill they vote for it anyway, in the US it's called
>>>>>>> "adding pork" or "pork barrel politics". :) [WAJ] The appendix is
>>>>>>> not added later, but exist at the first beginning. This is the
>>>>>>> origin of the bills.
>>>>>>> Thanks,
>>>>>>> Chris.
>>>>>>>> On Oct 16, 2020, at 10:37 AM, 王爱俊 <wangaijun@tsinghua.org.cn>
>>>>>>> wrote:
>>>>>>>> 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
>>>>>>>>>>>>> /d
>>>>>>>>>>>>> ra
>>>>>>>>>>>>> ft-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/list
>>>>>>>>>>>> in
>>>>>>>>>>>> fo
>>>>>>>>>>>> /lsr
>>>>>>>>>>>> __;!!NEt
>>>>>>>>>>>> 6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm
>>>>>>>>>> w8
>>>>>>>>>>>> Lc$
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Lsr mailing list
>>>>>>>>>>> Lsr@ietf.org
>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
>>>>>>>>>>> nfo/lsr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml
>>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Lsr mailing list
>>>>>>>>>> Lsr@ietf.org
>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin
>>>>>>>>>> fo/lsr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9
>>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$
>>>>>>>>> _______________________________________________
>>>>>>>>> Lsr mailing list
>>>>>>>>> Lsr@ietf.org
>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
>>>>>>>>> o/lsr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv
>>>>>>>>> oAZwe64fnzVvizNujmq1M$
>>>>>>> _______________________________________________
>>>>>>> Lsr mailing list
>>>>>>> Lsr@ietf.org
>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>>>>>>> lsr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw
>>>>>>> e64fnzVvizNujmq1M$
>>>>>> _______________________________________________
>>>>>> Lsr mailing list
>>>>>> Lsr@ietf.org
>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>>>> sr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6
>>>>>> 4fnzVvizNujmq1M$
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> Lsr@ietf.org
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>>> __;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz
>>>> VvizNujmq1M$
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr