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

[Peter Psenak <[e-mail]>]

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=[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.

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 <[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
> 
> 
>