[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] =?utf-8?q?WG_Last_Call_draft-ietf-lsr-ospf-prefix-originat?=
From: 王爱 <wangaijun () tsinghua ! org ! cn>
Date: 2020-10-16 14:37:53
Message-ID: AAkAHAAhDWbG7PkMOi2SNaqM.3.1602859073007.Hmail.wangaijun () tsinghua ! org ! cn
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
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 <chopps@chopps.org>写道:
-----原始邮件-----
发件人： Christian Hopps <chopps@chopps.org>
发件时间: 2020年10月16日 星期五
写道: ["Les Ginsberg (ginsberg)" \
<ginsberg=40cisco.com@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.com@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 <wangaijun@tsinghua.org.cn>
>> Sent: Thursday, October 15, 2020 6:51 PM
>> To: 'Jeff Tantsura' <jefftant.ietf@gmail.com>; 'John E Drake'
>> <jdrake@juniper.net>
>> Cc: 'Christian Hopps' <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg
>> (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org; lsr-ads@ietf.org; draft-ietf-
>> lsr-ospf-prefix-originator@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-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Jeff
>> Tantsura
>> Sent: Friday, October 16, 2020 5:28 AM
>> To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
>> Cc: Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg
>> (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; lsr-
>> ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@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.net@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-bounces@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
>>>> Sent: Thursday, October 15, 2020 12:33 PM
>>>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org;
>>>> draft-ietf-lsr-ospf-prefix- originator@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-bounces@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-originator@ietf.org;
>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps
>>>>> <chopps@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/draft-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
[Attachment #5 (text/html)]
<br>Hi, Chris: <div>Originally, the appendix part is within the document, which \
is the start point/main motivation to extend the prefix origin.</div><div>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.<div>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.</div><div><br><div id="spnEditorSign_app">Aijun Wang</div> \
<br>在2020-10-16，Christian Hopps &lt;chopps@chopps.org&gt;写道:
<br>-----原始邮件-----
<br>发件人： Christian Hopps &lt;chopps@chopps.org&gt;
<br>发件时间: 2020年10月16日 星期五
<br>写道: [&quot;Les Ginsberg (ginsberg)&quot; &lt;ginsberg=40cisco.com@dmarc.ietf.org&gt;]
<br>主题： Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
<br>
<br>> On Oct 16, 2020, at 1:51 AM, Les  \
;Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org> wrote:
<br>>
<br>> Aijun -
<br>>
<br>> The point I am making is very focused.
<br>>
<br>> This draft is defining a protocol extensio \
n. As such it is necessary that this be S \
tandards track as adhering to the normative stateme \
nts in the draft are necessary for interoperability.
<br>>
<br>> What is discussed in the Appendix is \
a use case. It is not normative and there  \
;are strong opinions on both sides as to wheth \
er this is an appropriate use case or not. \
<br>> In the context of this draft, I have& \
nbsp;no interest in trying to resolve our differenc \
e of opinion on this use case. I simply w \
ant the protocol extension to move forward so that we have another tool available.
<br>>
<br>> 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 w \
ell not be normative - Informational or BCP ma \
y be more appropriate - because it will be&nbs \
p;discussing a deployment scenario and a proposal t \
o use defined protocol extensions as one way t \
o solve problems in that deployment scenario. Such& \
nbsp;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.
<br>>
<br>> Please do not try to avoid having a&n \
bsp;full discussion of the merits of using prefix&n \
bsp;advertisements to derive topology by adding it \
to a draft that is (and should be) focused on simple protocol extensions.
<br>
<br>[As WG member]
<br>
<br>I find this very compelling and so support  \
;the removal of the referred to non-normative appendices.
<br>
<br>Thanks,
<br>Chris.
<br>
<br>>
<br>> Thanx.
<br>>
<br>> Les
<br>>
<br>>
<br>>> -----Original Message-----
<br>>> From: Aijun Wang <wangaijun@tsinghua.org.cn>
<br>>> Sent: Thursday, October 15, 2020 6:51 PM
<br>>> To: 'Jeff Tantsura' <jefftant.ietf@gmail.com>; 'John E Drake'
<br>>> <jdrake@juniper.net>
<br>>> Cc: 'Christian Hopps' <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg
<br>>> (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org; lsr-ads@ietf.org; draft-ietf-
<br>>> lsr-ospf-prefix-originator@ietf.org
<br>>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
<br>>>
<br>>> Hi, Les, John and Jeff:
<br>>>
<br>>> Let's reply you all together.
<br>>> In my POV, The standard document should not define solely the protocol
<br>>> extension, but their usages in the network deployment. As I known, almost
<br>>> all the IETF documents following this style.
<br>>> And, before adopting one work, we have often intense discussion for what's
<br>>> their usages.
<br>>> Such discussion in the mail list and statements in the document can certainly
<br>>> assist the reader/user of the document get the essence of the standard, and
<br>>> follow them unambiguously.
<br>>>
<br>>> Regarding the contents of appendices, as stated in the section, "The
<br>>> Appendix A heuristic to rebuild the topology can normally be used if all links
<br>>> are numbered." I think this can apply almost most of the operator's network,
<br>>> and facilitate the inter-area TE path calculation for central controller, or even
<br>>> for the head-end router that located in one area that different from the tail-
<br>>> end router.
<br>>>
<br>>> Keeping the contents of appendices does not have the negative impact of
<br>>> the protocol extension, it is just one reference for the usage of this
<br>>> extension.
<br>>> One can select not refer to it, if their networks are deployed with large
<br>>> amount of unnumbered links. But for others, the heuristic applies.
<br>>>
<br>>> Best Regards
<br>>>
<br>>> Aijun Wang
<br>>> China Telecom
<br>>>
<br>>>
<br>>>
<br>>> -----Original Message-----
<br>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Jeff
<br>>> Tantsura
<br>>> Sent: Friday, October 16, 2020 5:28 AM
<br>>> To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
<br>>> Cc: Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg
<br>>> (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; lsr-
<br>>> ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org
<br>>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
<br>>>
<br>>> +1
<br>>>
<br>>> Regards,
<br>>> Jeff
<br>>>
<br>>>> On Oct 15, 2020, at 11:33, John E Drake
<br>>> <jdrake=40juniper.net@dmarc.ietf.org> wrote:
<br>>>>
<br>>>> Hi,
<br>>>>
<br>>>> I agree with Les. This is a& \
nbsp;simple protocol extension for a specific purpose \
<br>>> and there is no reason to include speculation about its use for other
<br>>> purposes, particularly when it is inherently not suited for them.
<br>>>>
<br>>>> Yours Irrespectively,
<br>>>>
<br>>>> John
<br>>>>
<br>>>>
<br>>>> Juniper Business Use Only
<br>>>>
<br>>>>> -----Original Message-----
<br>>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
<br>>>>> Sent: Thursday, October 15, 2020 12:33 PM
<br>>>>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
<br>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org;
<br>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org
<br>>>>> Subject: Re: [Lsr] WG Last Call
<br>>>>> draft-ietf-lsr-ospf-prefix-originator-06
<br>>>>>
<br>>>>> [External Email. Be cautious of content]
<br>>>>>
<br>>>>>
<br>>>>> I support moving this document forward.
<br>>>>> Similar functionality in IS-IS has proved useful.
<br>>>>>
<br>>>>> I would however like to repeat comments I made earlier in the review
<br>>>>> of this document.
<br>>>>> The content of the Appendices should be removed.
<br>>>>> The Appendices define and discuss deriving topology information from
<br>>>>> prefix advertisements - which is flawed and should not be done.
<br>>>>> Perhaps more relevant, the purpose of the document is to define
<br>>>>> protocol extensions supporting advertisement of the originators of a
<br>>>>> prefix advertisement. There is no need to discuss how this mechanism
<br>>>>> might be used to build topology information.
<br>>>>> This document should confine itself to defining the protocol
<br>>>>> extensions - similar the RFC 7794.
<br>>>>>
<br>>>>> If the authors do not agree to do this, I would encourage this point
<br>>>>> to be discussed during IESG review.
<br>>>>>
<br>>>>> Les
<br>>>>>
<br>>>>>> -----Original Message-----
<br>>>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Christian Hopps
<br>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM
<br>>>>>> To: lsr@ietf.org
<br>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org;
<br>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps
<br>>>>>> <chopps@chopps.org>
<br>>>>>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
<br>>>>>>
<br>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
<br>>>>>>
<br>>>>>>
<br>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i
<br>>>>>> et
<br>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-
<br>>> gk!TaSzQThghtCFOuYPS2VjLq
<br>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
<br>>>>>>
<br>>>>>> The following IPR has been filed
<br>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
<br>>>>>> !NEt6yMaO-
<br>>>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
<br>>>>>> 5KtUHQ$
<br>>>>>>
<br>>>>>> Authors,
<br>>>>>>
<br>>>>>> Please indicate to the list, your knowledge of any other IPR
<br>>>>>> related to this work.
<br>>>>>>
<br>>>>>> Thanks,
<br>>>>>> Chris.
<br>>>>>
<br>>>>> _______________________________________________
<br>>>>> Lsr mailing list
<br>>>>> Lsr@ietf.org
<br>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
<br>>>>> __;!!NEt
<br>>>>> 6yMaO-
<br>>>>>
<br>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm
<br>>> w8
<br>>>>> Lc$
<br>>>>
<br>>>> _______________________________________________
<br>>>> Lsr mailing list
<br>>>> Lsr@ietf.org
<br>>>> https://www.ietf.org/mailman/listinfo/lsr
<br>>>
<br>>> _______________________________________________
<br>>> Lsr mailing list
<br>>> Lsr@ietf.org
<br>>> https://www.ietf.org/mailman/listinfo/lsr
<br>>
<br>> _______________________________________________
<br>> Lsr mailing list
<br>> Lsr@ietf.org
<br>> https://www.ietf.org/mailman/listinfo/lsr
<br>
<br>
<br></div></div><br>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic