Hi All，
Thank you for all your insightful discussions. I39ve given thoughtful consideration to all the points you39ve raised. In response, I am trying to explain the solution of draft-cheng-lsr-ospf-adjacency-suppress. Hope it can address your concerns. I39ve aimed to be comprehensive, but if I39ve missed anything or misunderstood any aspect, please don39t hesitate to correct me or provide additional feedback. 1. As we have discussed, it is difficult to find a precise delay time because of the uncertainty of flooding, so we introduce a timer to control it. It has several benefits: 1)it can avoid the complexity of realization. 2)it can reslove the remote neighbor scenario 3)it facilitates for forwarding plane programming 4)it can avoid the neighbor machine deadlock 5)it is valid for the whole restart router/ospf process,we do not need to start the timer for each interface. 6)it is valid for all types of lsas. As we have explained previously, even though router-Lsas and network-Lsas have been re-originated, Type 5 routes may still have problems. 2. This solution is controlled by the restart router. The neighbors only need to respond to the restart router.The advantages are reflected in the following aspects. 1) It complies with other extended features, such as GR, NSR,stub-router, reverse-metric. Usually，if you do/not want traffic to be sent to a specific router, the controls are on the router itself, not neighbor routers. Controlling on the same side can prevent the neighbor routers from identifying different features and performing special processing when some features take effect at the same time. 2) Restarting router can distinguish interface restart and router restart, but the neighbor router can not. 3) It can be enabled by default on the restart router. Or else, The neighbor routers should enable the configuration by default, since the unexpected restart can happen at any time. Further more, the neighbor routers must resolve the upper question 2). 4) For multi-neighbors scenario, it can prevent the function failure that occur when one certain neighbor is not configured. Best Regards, Liyan ----邮件原文----发件人：Christian Hopps <[email protected]>收件人：Aijun Wang <[email protected]>抄 送: Christian Hopps <[email protected]>,Tony Przygienda <[email protected]>,Acee Lindem <[email protected]>,"39Les Ginsberg (ginsberg)39" <[email protected]>,Liyan Gong <[email protected]>,"39Peter Psenak (ppsenak)39" <[email protected]>,Yingzhen Qu <[email protected]>,lsr-chairs <[email protected]>,shraddha <[email protected]>,lsr <[email protected]>发送时间：2024-07-17 21:21:26主题：[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and Purge LSA"Aijun Wang" <[email protected]> writes:> Hi, Chirs:>> The links that you provided has no relation for the discussions of "proxy of LSA originator". Would you like to provide other pointer to support Tony39s assertion?Aijun,I must have mis-interpreted you, I read that you were asking for for references backing up Tony39s assertion that originating purges from the non-owning routers was something to avoid... That39s what my links were pointing at.If that was not relevant then please disregard.Thanks,Chris.> Hi, Tony:>> I found none discussions that you mentioned within IETF mail list. Would you like to give me some pointer(Drafts/RFCs/Discussion Topics) to support your assertion?>> And, we have now the "area proxy for IS-IS https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-12";, why can39t we try the neighbor proxy solution?>> For Acee39s proposal, it requires all the neighbors around the restarting router> to pause the advertisement of updated LSAs that related to the interfaces> connects to the restarting router, which is one typical " cache synchronization> problems " that you mentioned.>> Why don39t clear the stale LSPs in advance by the proxy neighbor?>> Best Regards>> Aijun Wang> China Telecom>>> -----邮件原件-----> 发件人: [email protected] [mailto:[email protected]] 代表 Christian Hopps> 发送时间: 2024年7月16日 22:24> 收件人: Tony Przygienda <[email protected]>> 抄送: Aijun Wang <[email protected]> Acee Lindem <[email protected]>> Les Ginsberg (ginsberg) <[email protected]> Liyan Gong> <[email protected]> Peter Psenak (ppsenak) <[email protected]>> Yingzhen Qu <[email protected]> lsr-chairs <[email protected]>> shraddha <[email protected]> [email protected]> 主题: [Lsr] Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and Purge LSA>>> Tony Przygienda <[email protected]> writes:>>> Aijun, simply check the amount of RFCs and vendor knobs on proxy purge>> origination ID, security signatures, spec implementation deviations>> etc. which will give you an indication lots of bad things happened>> with it to good and bad people running large networks alike>> 39-) AFAIR lots of discussions were on the IGP lists in last 20 years>> when "interesting" stuff with proxy purges happened in the field, last>> I dealt with was about 3-4 years ago only -)>> Here39s a couple:>> https://www.rfc-editor.org/rfc/rfc3719.html#section-7> https://www.rfc-editor.org/rfc/rfc3719.html#section-8>> Thanks,> Chris.>>>>> Beside the usual "oh, yeah, implementation bugs here galore" it all>> goes back to the SPOT architectural principle which, when deviated>> from, always ends up in cache synchronization problems which can be>> solved but are highly complex, expose lots of attack vectors and>> ultimately lead to a less available solution along the lines of CAP>> paradigm I mentioned earlier.>>>> -- tony>>>> On Mon, Jul 15, 2024 at 4:28PM Aijun Wang <[email protected]>>> wrote:>>>> Hi, Tony:>>>> Would you like to provide some detail explanations to support>> your asserts?>>>> Aijun Wang>> China Telecom>>>>>> On Jul 15, 2024, at 20:23, Tony Przygienda <>> [email protected]> wrote:>>>>>> proxy purges was one of the worst ideas in IGP operationally>> speaking for people dealing with this stuff in real networks>> for last 20+ years and still is. Let39s not go there>>>> -- tonySubject：[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and Purge LSA"Aijun Wang" <[email protected]> writes:> Hi, Chirs:>> The links that you provided has no relation for the discussions of "proxy of LSA originator". Would you like to provide other pointer to support Tony39s assertion?Aijun,I must have mis-interpreted you, I read that you were asking for for references backing up Tony39s assertion that originating purges from the non-owning routers was something to avoid... That39s what my links were pointing at.If that was not relevant then please disregard.Thanks,Chris.> Hi, Tony:>> I found none discussions that you mentioned within IETF mail list. Would you like to give me some pointer(Drafts/RFCs/Discussion Topics) to support your assertion?>> And, we have now the "area proxy for IS-IS https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-12";, why can39t we try the neighbor proxy solution?>> For Acee39s proposal, it requires all the neighbors around the restarting router> to pause the advertisement of updated LSAs that related to the interfaces> connects to the restarting router, which is one typical " cache synchronization> problems " that you mentioned.>> Why don39t clear the stale LSPs in advance by the proxy neighbor?>> Best Regards>> Aijun Wang> China Telecom>>> -----邮件原件-----> 发件人: [email protected] [mailto:[email protected]] 代表 Christian Hopps> 发送时间: 2024年7月16日 22:24> 收件人: Tony Przygienda <[email protected]>> 抄送: Aijun Wang <[email protected]> Acee Lindem <[email protected]>> Les Ginsberg (ginsberg) <[email protected]> Liyan Gong> <[email protected]> Peter Psenak (ppsenak) <[email protected]>> Yingzhen Qu <[email protected]> lsr-chairs <[email protected]>> shraddha <[email protected]> [email protected]> 主题: [Lsr] Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and Purge LSA>>> Tony Przygienda <[email protected]> writes:>>> Aijun, simply check the amount of RFCs and vendor knobs on proxy purge>> origination ID, security signatures, spec implementation deviations>> etc. which will give you an indication lots of bad things happened>> with it to good and bad people running large networks alike>> 39-) AFAIR lots of discussions were on the IGP lists in last 20 years>> when "interesting" stuff with proxy purges happened in the field, last>> I dealt with was about 3-4 years ago only -)>> Here39s a couple:>> https://www.rfc-editor.org/rfc/rfc3719.html#section-7> https://www.rfc-editor.org/rfc/rfc3719.html#section-8>> Thanks,> Chris.>>>>> Beside the usual "oh, yeah, implementation bugs here galore" it all>> goes back to the SPOT architectural principle which, when deviated>> from, always ends up in cache synchronization problems which can be>> solved but are highly complex, expose lots of attack vectors and>> ultimately lead to a less available solution along the lines of CAP>> paradigm I mentioned earlier.>>>> -- tony>>>> On Mon, Jul 15, 2024 at 4:28PM Aijun Wang <[email protected]>>> wrote:>>>> Hi, Tony:>>>> Would you like to provide some detail explanations to support>> your asserts?>>>> Aijun Wang>> China Telecom>>>>>> On Jul 15, 2024, at 20:23, Tony Przygienda <>> [email protected]> wrote:>>>>>> proxy purges was one of the worst ideas in IGP operationally>> speaking for people dealing with this stuff in real networks>> for last 20+ years and still is. Let39s not go there>>>> -- tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
