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-...@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/dra > >>>>> 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/listinfo > >>>> /lsr > >>>> __;!!NEt > >>>> 6yMaO- > >>>> > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm > >> w8 > >>>> Lc$ > >>> > >>> _______________________________________________ > >>> Lsr mailing list > >>> Lsr@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lsr > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
