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/lis >>>>>>>>>>>>> ti >>>>>>>>>>>>> nfo/lsr__;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml >>>>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Lsr mailing list >>>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list >>>>>>>>>>>> in >>>>>>>>>>>> fo/lsr__;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9 >>>>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Lsr mailing list >>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>>>>>>>>>> nf >>>>>>>>>>> o/lsr__;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv >>>>>>>>>>> oAZwe64fnzVvizNujmq1M$ >>>>>>>>> _______________________________________________ >>>>>>>>> Lsr mailing list >>>>>>>>> Lsr@ietf.org >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf >>>>>>>>> o/ >>>>>>>>> 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/l >>>>>> sr >>>>>> __;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz >>>>>> VvizNujmq1M$ >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ >>> _;!!NEt6yMaO- >> gk!Q8iHWjMDoKYrkxE2t0hxvFtb_uQ_eHbCjOnTcroPf_Hz2Xz7ijv-8T >>> VtojHq-LA$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
