Aijun, Regarding your appendix A -
* How can we "rebuild" topology based on comparison of prefixes and rtr-id ? * If link between S1 & S2 is not in LSDB there may be a valid operational reasons for it. "Rebuilding it" will be actually harmful from all points of view. * You should be exporting topology from all areas not just from backbone and guessing the topology based on the prefix to rtr_id associations * Imaging someone is using multiaccess in areas. Are you also going to rebuild DR & BDR ? I must agree with comments from Peter & Les here. Cheers, R. On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang <wang...@chinatelecom.cn> 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. > > 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. > 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. > > > 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/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/listin > >>>>>>>>> fo > >>>>>>>>> /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 > >>> _______________________________________________ > >>> 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
