I agree w/ Les, who I think has been extremely reasonable throughout this discussion.
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Sent: Monday, October 19, 2020 3:32 AM > To: Aijun Wang <wangai...@tsinghua.org.cn>; '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 > > [External Email. Be cautious of content] > > > 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. > 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/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!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV > > > > >>> 9UMD54R3w20E_CXC5-bVuZr-c$ > > > > >> > > > > >> _______________________________________________ > > > > >> Lsr mailing list > > > > >> Lsr@ietf.org > > > > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin > > > > >> fo/lsr__;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9U > > > > >> MD54R3w20E_CXC5-bVuZr-c$ > > > > > > > > > > _______________________________________________ > > > > > Lsr mailing list > > > > > Lsr@ietf.org > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf > > > > > o/lsr__;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD > > > > > 54R3w20E_CXC5-bVuZr-c$ > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls > > > r__;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD54R3w20E > > > _CXC5-bVuZr-c$ > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > > _;!!NEt6yMaO- > gk!UgEi3bxNDS6ZLnXNliOvkQtMeXCTCwwSe0ToOV9UMD54R3w20E_CXC > > 5-bVuZr-c$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
