Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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=
> [e-mail]> 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 <[e-mail]>
> >>> Sent: Monday, October 19, 2020 12:06 AM
> >>> To: Les Ginsberg (ginsberg) <[e-mail]>; 'Christian Hopps'
> >>> <[e-mail]>
> >>> Cc: 'John E Drake' <[e-mail]>; [e-mail];
> [e-mail];
> >>> 'Jeff Tantsura' <[e-mail]>; draft-ietf-lsr-ospf-prefix-
> >>> [e-mail]; [e-mail]
> >>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Les
> >>> Ginsberg (ginsberg)
> >>> Sent: Monday, October 19, 2020 2:15 PM
> >>> To: Aijun Wang <[e-mail]>; 'Christian Hopps'
> >>> <[e-mail]>
> >>> Cc: 'John E Drake' <[e-mail]>; [e-mail]; 'Les
> Ginsberg
> >>> (ginsberg)' <ginsberg=[e-mail]>; [e-mail]; 'Jeff
> >>> Tantsura' <[e-mail]>; draft-ietf-lsr-ospf-prefix-
> >>> [e-mail]; [e-mail]
> >>> 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 <[e-mail]> On Behalf Of Aijun Wang
> >>>> Sent: Sunday, October 18, 2020 7:08 PM
> >>>> To: 'Christian Hopps' <[e-mail]>
> >>>> Cc: 'John E Drake' <[e-mail]>; [e-mail]; 'Les
> >>>> Ginsberg (ginsberg)' <ginsberg=[e-mail]>;
> >>>> [e-mail]; 'Jeff Tantsura' <[e-mail]>;
> >>>> draft-ietf-lsr-ospf-prefix- [e-mail]; [e-mail]
> >>>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> >>>> Christian Hopps
> >>>> Sent: Friday, October 16, 2020 10:47 PM
> >>>> To: 王爱俊 <[e-mail]>
> >>>> Cc: John E Drake <[e-mail]>; Christian Hopps
> >>>> <[e-mail]>; [e-mail]; Les Ginsberg (ginsberg)
> >>>> <ginsberg=[e-mail]>; [e-mail]; Jeff Tantsura
> >>>> <[e-mail]>;
> >>>> [e-mail]; lsr- [e-mail]
> >>>> 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, 王爱俊 <[e-mail]>
> >>>> 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 &lt;[e-mail]&gt;写道:
> >>>>> -----原始邮件-----
> >>>>> 发件人： Christian Hopps &lt;[e-mail]&gt;
> >>>>> 发件时间: 2020年10月16日 星期五
> >>>>> 写道: [&quot;Les Ginsberg (ginsberg)&quot;
> >>>>> &lt;ginsberg=[e-mail]&gt;]
> >>>>> 主题： Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> >>>>>
> >>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg)
> >>>> <ginsberg=[e-mail]> 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 <[e-mail]>
> >>>>>>> Sent: Thursday, October 15, 2020 6:51 PM
> >>>>>>> To: 'Jeff Tantsura' <[e-mail]>; 'John E Drake'
> >>>>>>> <[e-mail]>
> >>>>>>> Cc: 'Christian Hopps' <[e-mail]>; [e-mail];
> >>>>>>> Les Ginsberg
> >>>>>>> (ginsberg) <[e-mail]>; [e-mail]; [e-mail];
> >>>>>>> draft-ietf- [e-mail]
> >>>>>>> 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: [e-mail] [mailto:[e-mail]] On
> >>>>>>> Behalf Of Jeff Tantsura
> >>>>>>> Sent: Friday, October 16, 2020 5:28 AM
> >>>>>>> To: John E Drake <jdrake=[e-mail]>
> >>>>>>> Cc: Christian Hopps <[e-mail]>; [e-mail]; Les
> >>>>>>> Ginsberg
> >>>>>>> (ginsberg) <ginsberg=[e-mail]>; [e-mail];
> >>>>>>> lsr- [e-mail]; [e-mail]
> >>>>>>> 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=[e-mail]> 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 <[e-mail]> On Behalf Of Les Ginsberg
> >>>>>>>>> (ginsberg)
> >>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM
> >>>>>>>>> To: Christian Hopps <[e-mail]>; [e-mail]
> >>>>>>>>> Cc: [e-mail]; [e-mail];
> >>>>>>>>> draft-ietf-lsr-ospf-prefix- [e-mail]
> >>>>>>>>> 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 <[e-mail]> On Behalf Of Christian Hopps
> >>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM
> >>>>>>>>>> To: [e-mail]
> >>>>>>>>>> Cc: [e-mail];
> >>>>>>>>>> [e-mail]; lsr- [e-mail]; Christian Hopps
> >>>>>>>>>> <[e-mail]>
> >>>>>>>>>> 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
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin
> >>>>>>>>> fo
> >>>>>>>>> /lsr
> >>>>>>>>> __;!!NEt
> >>>>>>>>> 6yMaO-
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm
> >>>>>>> w8
> >>>>>>>>> Lc$
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Lsr mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Lsr mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Lsr mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Lsr mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lsr
> >>> _______________________________________________
> >>> Lsr mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/lsr
> >
> > _______________________________________________
> > Lsr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>