No, as I indicated previously, this discussion has been had many times - it reminds me of 'Groundhog Day'.
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Aijun Wang <wangai...@tsinghua.org.cn> > Sent: Monday, October 19, 2020 11:00 AM > To: John E Drake <jdr...@juniper.net> > Cc: wang...@chinatelecom.cn; Peter Psenak <ppse...@cisco.com>; Les > Ginsberg (ginsberg) <ginsb...@cisco.com>; Christian Hopps > <cho...@chopps.org>; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura > <jefftant.i...@gmail.com>; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; > lsr- > a...@ietf.org > Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > > [External Email. Be cautious of content] > > > Would you like to refer the cases raised from Robert? > Such discussion can be fruitful for the refine or forwarding of this draft. > One should convince others based on the fact, not subjective opinion. > > Aijun Wang > China Telecom > > > On Oct 19, 2020, at 22:52, John E Drake <jdr...@juniper.net> wrote: > > > > Hi, > > > > It seems that we have been going around on this topic for an eternity, so to > explain it again would simply be an exercise in pounding sand. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > > >> -----Original Message----- > >> From: wang...@chinatelecom.cn <wang...@chinatelecom.cn> > >> Sent: Monday, October 19, 2020 10:41 AM > >> To: John E Drake <jdr...@juniper.net> > >> Cc: Peter Psenak <ppse...@cisco.com>; Peter Psenak > >> <ppse...@cisco.com>; Les Ginsberg (ginsberg) <ginsb...@cisco.com>; > >> Christian Hopps <cho...@chopps.org>; Aijun Wang > >> <wangai...@tsinghua.org.cn>; lsr- cha...@ietf.org; lsr@ietf.org; Jeff > >> Tantsura <jefftant.i...@gmail.com>; draft- > >> ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-...@ietf.org > >> Subject: Re: [Lsr] WG Last Call > >> draft-ietf-lsr-ospf-prefix-originator-06 > >> > >> [External Email. Be cautious of content] > >> > >> > >> 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....@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 <ppse...@cisco.com> > >>>> Sent: Monday, October 19, 2020 6:32 AM > >>>> To: Aijun Wang <wang...@chinatelecom.cn>; Peter Psenak > >>>> <ppsenak=40cisco....@dmarc.ietf.org> > >>>> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Aijun Wang > >>>> <wangai...@tsinghua.org.cn>; Christian Hopps <cho...@chopps.org>; > >>>> John E Drake <jdr...@juniper.net>; lsr-cha...@ietf.org; > >>>> lsr@ietf.org; Jeff Tantsura <jefftant.i...@gmail.com>; > >>>> draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- a...@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....@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 <wangai...@tsinghua.org.cn> > >>>>>>>> Sent: Monday, October 19, 2020 12:06 AM > >>>>>>>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; 'Christian Hopps' > >>>>>>>> <cho...@chopps.org> > >>>>>>>> Cc: 'John E Drake' <jdr...@juniper.net>; lsr-cha...@ietf.org; > >>>>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.i...@gmail.com>; > >>>>>>>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; > >>>>>>>> lsr-...@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-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On > >>>>>>>> Behalf Of Les Ginsberg (ginsberg) > >>>>>>>> Sent: Monday, October 19, 2020 2:15 PM > >>>>>>>> To: Aijun Wang <wangai...@tsinghua.org.cn>; 'Christian Hopps' > >>>>>>>> <cho...@chopps.org> > >>>>>>>> Cc: 'John E Drake' <jdr...@juniper.net>; lsr-cha...@ietf.org; > >>>>>>>> 'Les Ginsberg (ginsberg)' > >>>>>>>> <ginsberg=40cisco....@dmarc.ietf.org>; > >>>>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.i...@gmail.com>; > >>>>>>>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; > >>>>>>>> lsr-...@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-boun...@ietf.org> On Behalf Of Aijun Wang > >>>>>>>>> Sent: Sunday, October 18, 2020 7:08 PM > >>>>>>>>> To: 'Christian Hopps' <cho...@chopps.org> > >>>>>>>>> Cc: 'John E Drake' <jdr...@juniper.net>; lsr-cha...@ietf.org; > >>>>>>>>> 'Les Ginsberg (ginsberg)' > >>>>>>>>> <ginsberg=40cisco....@dmarc.ietf.org>; > >>>>>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.i...@gmail.com>; > >>>>>>>>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; > >>>>>>>>> lsr-...@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-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On > >>>>>>>>> Behalf Of Christian Hopps > >>>>>>>>> Sent: Friday, October 16, 2020 10:47 PM > >>>>>>>>> To: 王爱俊 <wangai...@tsinghua.org.cn> > >>>>>>>>> Cc: John E Drake <jdr...@juniper.net>; Christian Hopps > >>>>>>>>> <cho...@chopps.org>; lsr-cha...@ietf.org; Les Ginsberg > >>>>>>>>> (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; > >>>>>>>>> lsr@ietf.org; Jeff Tantsura <jefftant.i...@gmail.com>; > >>>>>>>>> draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- > >>>>>>>>> a...@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, 王爱俊 > <wangai...@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 <cho...@chopps.org>写道: > >>>>>>>>>> -----原始邮件----- > >>>>>>>>>> 发件人： Christian Hopps <cho...@chopps.org> > >>>>>>>>>> 发件时间: 2020年10月16日 星期五 > >>>>>>>>>> 写道: ["Les Ginsberg (ginsberg)" > >>>>>>>>>> <ginsberg=40cisco....@dmarc.ietf.org>] > >>>>>>>>>> 主题： 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....@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 <wangai...@tsinghua.org.cn> > >>>>>>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM > >>>>>>>>>>>> To: 'Jeff Tantsura' <jefftant.i...@gmail.com>; 'John E Drake' > >>>>>>>>>>>> <jdr...@juniper.net> > >>>>>>>>>>>> Cc: 'Christian Hopps' <cho...@chopps.org>; > >>>>>>>>>>>> lsr-cha...@ietf.org; Les Ginsberg > >>>>>>>>>>>> (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org; > >>>>>>>>>>>> lsr-...@ietf.org; > >>>>>>>>>>>> draft-ietf- lsr-ospf-prefix-origina...@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-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On > >>>>>>>>>>>> Behalf Of Jeff Tantsura > >>>>>>>>>>>> Sent: Friday, October 16, 2020 5:28 AM > >>>>>>>>>>>> To: John E Drake <jdrake=40juniper....@dmarc.ietf.org> > >>>>>>>>>>>> Cc: Christian Hopps <cho...@chopps.org>; > >>>>>>>>>>>> lsr-cha...@ietf.org; Les Ginsberg > >>>>>>>>>>>> (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; > >>>>>>>>>>>> lsr@ietf.org; > >>>>>>>>>>>> lsr- a...@ietf.org; > >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-origina...@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....@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-boun...@ietf.org> On Behalf Of Les > >>>>>>>>>>>>>> Ginsberg > >>>>>>>>>>>>>> (ginsberg) > >>>>>>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM > >>>>>>>>>>>>>> To: Christian Hopps <cho...@chopps.org>; lsr@ietf.org > >>>>>>>>>>>>>> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; > >>>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix- origina...@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-boun...@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-origina...@ietf.org; > >>>>>>>>>>>>>>> lsr-cha...@ietf.org; lsr- a...@ietf.org; Christian Hopps > >>>>>>>>>>>>>>> <cho...@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 > >>>>>>>>>>>>>>> /d > >>>>>>>>>>>>>>> oc > >>>>>>>>>>>>>>> /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/ > >>>>>>>>>>>>>> li > >>>>>>>>>>>>>> st > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>> fo > >>>>>>>>>>>>>> /lsr > >>>>>>>>>>>>>> __;!!NEt > >>>>>>>>>>>>>> 6yMaO- > >>>> > gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm > >>>>>>>>>>>> w8 > >>>>>>>>>>>>>> Lc$ > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> Lsr mailing list > >>>>>>>>>>>>> Lsr@ietf.org > >>>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/l > >>>>>>>>>>>>> is > >>>>>>>>>>>>> ti > >>>>>>>>>>>>> nfo/lsr__;!!NEt6yMaO- > >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml > >>>>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$ > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> Lsr mailing list > >>>>>>>>>>>> Lsr@ietf.org > >>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/li > >>>>>>>>>>>> st > >>>>>>>>>>>> in > >>>>>>>>>>>> fo/lsr__;!!NEt6yMaO- > >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9 > >>>>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$ > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Lsr mailing list > >>>>>>>>>>> Lsr@ietf.org > >>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/lis > >>>>>>>>>>> ti > >>>>>>>>>>> nf > >>>>>>>>>>> o/lsr__;!!NEt6yMaO- > >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv > >>>>>>>>>>> oAZwe64fnzVvizNujmq1M$ > >>>>>>>>> _______________________________________________ > >>>>>>>>> Lsr mailing list > >>>>>>>>> Lsr@ietf.org > >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > >>>>>>>>> nf > >>>>>>>>> o/ > >>>>>>>>> lsr__;!!NEt6yMaO- > >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw > >>>>>>>>> e64fnzVvizNujmq1M$ > >>>>>>>> _______________________________________________ > >>>>>>>> Lsr mailing list > >>>>>>>> Lsr@ietf.org > >>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin > >>>>>>>> fo > >>>>>>>> /l > >>>>>>>> sr__;!!NEt6yMaO- > >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6 > >>>>>>>> 4fnzVvizNujmq1M$ > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo > >>>>>> /l > >>>>>> sr > >>>>>> __;!!NEt6yMaO- > >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz > >>>>>> VvizNujmq1M$ > >>> _______________________________________________ > >>> Lsr mailing list > >>> Lsr@ietf.org > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls > >>> r_ > >>> _;!!NEt6yMaO- > >> gk!Q8iHWjMDoKYrkxE2t0hxvFtb_uQ_eHbCjOnTcroPf_Hz2Xz7ijv-8T > >>> VtojHq-LA$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
