"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 Tony's assertion?
Aijun, I must have mis-interpreted you, I read that you were asking for for references backing up Tony's assertion that originating purges from the non-owning routers was something to avoid... That's 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 can't we try the neighbor proxy solution? For Acee's 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 don't 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 ;'-) 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 ;-)Here's 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:28 PM 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. Let's not go there -- tony
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
