> On Jul 24, 2024, at 19:37, Liyan Gong <[email protected]> wrote: > > Hi Les and All, > > Thank you all for the discussions. I have been trying to understand the new > points，but unfortunately, so far, I have not been able to grasp their > advantages. > > Can the authors update the better-idbx draft to elebrate the new points? This > will contribute to our understanding and evaluation of the work. > > Additionally, I kindly suggest that the authors consider and reply the > concerns outlined in my previous email. >
Your concerns are addressed in the updated draft. I will also cover in my presentation tomorrow in the LSR meeting. If you still have questions we can discuss on the list. I have some other things I need to do today and don’t have time for a protracted debate right now. Thanks, Acee > > Best Regards, > > Liyan > > > > ----邮件原文---- > 发件人："Les Ginsberg \\(ginsberg\\)" <[email protected]> > 收件人：Liyan Gong <[email protected]>,Christian Hopps > <[email protected]>,Aijun Wang <[email protected]> > 抄 送: Tony Przygienda <[email protected]>,Acee Lindem > <[email protected]>,"Peter Psenak (ppsenak)" <[email protected]>,Yingzhen > Qu <[email protected]>,lsr-chairs <[email protected]>,shraddha > <[email protected]>,lsr <[email protected]> > 发送时间：2024-07-22 04:43:54 > 主题：[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature aging of > LSA and Purge LSA > > > Liyan – > > > Thanx for the thoughtful post. > > > There are two issues associated with the non-stateful restart of a router: > > > 1)Ensuring that stales LSAs from the previous incarnation are flushed/updated > before paths via the restarting router are calculated by nodes in the network. > > > 2)Allowing for forwarding plane update time on the restarting router to > complete before paths via the restarting router are installed into the > forwarding planes of other routers in the network. > > > The better-idbx draft addresses #1 – and does so in a backwards compatible > way – which is a significant win. > > > The adj-suppress draft addresses #2 – though it requires cooperation from the > neighbors of the restarting router. > > > Up to now, I have advocated for a combination of both solutions – whether in > two drafts or a single combined draft. > > However, Acee has pointed out that the restarting router could – without > requiring changes on the neighbors – initially generate new versions of its > LSAs (particularly the Router LSA) which omit advertisement of the newly > acquired neighbors until the forwarding plane has been populated on the > restarting router. This addresses #2 above. > > > Given that Acee seems agreeable to add text into better-idbx (non-normative) > to mention this option, I now feel that the introduction of the SA bit is not > required. It can still be argued (as you have below) that use of the SA bit > may more reliably address flooding delays, but the added benefits seem > minimal to non-existent. And Acee’s proposal has the added benefits of not > requiring changes on the neighbors. It also likely makes it easier for the > restarting router to introduce special SPF logic to utilize the local > adjacencies even though they are not currently advertised – which is > necessary for the restarting router to populate its forwarding plane in > advance of sending LSAs which will actually attract traffic. > > > As a matter of history, the SA bit was introduced to IS-IS back in RFC 5306. > Since IS-IS does not have database exchange as a requirement to bring an > adjacency up, something new had to be introduced to address the startup > issue. SA bit was considered less disruptive than introducing non-backwards > compatible changes to the adjacency state machine. Since IS-IS has the > Overload Bit to prevent other routers from prematurely using the restarting > router for transit traffic, there was no need to use the SA bit for that > purpose. Since OSPF does not have the equivalent of the Overload bit, the > additional step of having the restarting router initially not advertise its > adjacencies is needed. > > > If you can convince the authors of better-idbx to add the SA bit, I would be > fine with that – but it is hard to strongly advocate for that at this point. > > > Les > > > > > From: Liyan Gong <[email protected]> > Sent: Wednesday, July 17, 2024 7:05 PM > To: Christian Hopps <[email protected]>; Aijun Wang > <[email protected]> > Cc: Tony Przygienda <[email protected]>; Acee Lindem <[email protected]>; > Les Ginsberg (ginsberg) <[email protected]>; Peter Psenak (ppsenak) > <[email protected]>; Yingzhen Qu <[email protected]>; lsr-chairs > <[email protected]>; shraddha <[email protected]>; lsr <[email protected]> > Subject: Re:[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature > aging of LSA and Purge LSA > > > Hi All， > Thank you for all your insightful discussions. I've given thoughtful > consideration to all the points you've raised. > In response, I am trying to explain the solution of > draft-cheng-lsr-ospf-adjacency-suppress. Hope it can address your concerns. > I've aimed to be comprehensive, but if I've missed anything or misunderstood > any aspect, please don't 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] <mailto:[email protected]>> > 收件人：Aijun Wang <[email protected] <mailto:[email protected]>> > 抄 送: Christian Hopps <[email protected] <mailto:[email protected]>>,Tony > Przygienda <[email protected] <mailto:[email protected]>>,Acee Lindem > <[email protected] <mailto:[email protected]>>,"'Les Ginsberg > (ginsberg)'" <[email protected] <mailto:[email protected]>>,Liyan Gong > <[email protected] <mailto:[email protected]>>,"'Peter Psenak > (ppsenak)'" <[email protected] <mailto:[email protected]>>,Yingzhen Qu > <[email protected] <mailto:[email protected]>>,lsr-chairs > <[email protected] <mailto:[email protected]>>,shraddha > <[email protected] <mailto:[email protected]>>,lsr <[email protected] > <mailto:[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] <mailto:[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]> > > [mailto:[email protected]] 代表 Christian Hopps > > 发送时间: 2024年7月16日 22:24 > > 收件人: Tony Przygienda <[email protected] <mailto:[email protected]>> > > 抄送: Aijun Wang <[email protected] > > <mailto:[email protected]>>; Acee Lindem <[email protected] > > <mailto:[email protected]>>; > > Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>>; > > Liyan Gong > > <[email protected] <mailto:[email protected]>>; Peter > > Psenak (ppsenak) <[email protected] <mailto:[email protected]>>; > > Yingzhen Qu <[email protected] <mailto:[email protected]>>; > > lsr-chairs <[email protected] <mailto:[email protected]>>; > > shraddha <[email protected] <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]> > > 主题: [Lsr] Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and > > Purge LSA > > > > > > Tony Przygienda <[email protected] <mailto:[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:28PM Aijun Wang <[email protected] > <mailto:[email protected]%0b>>>> 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] <mailto:[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 > > > Subject：[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature aging > of LSA and Purge LSA > > > "Aijun Wang" <[email protected] <mailto:[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]> > > [mailto:[email protected]] 代表 Christian Hopps > > 发送时间: 2024年7月16日 22:24 > > 收件人: Tony Przygienda <[email protected] <mailto:[email protected]>> > > 抄送: Aijun Wang <[email protected] > > <mailto:[email protected]>>; Acee Lindem <[email protected] > > <mailto:[email protected]>>; > > Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>>; > > Liyan Gong > > <[email protected] <mailto:[email protected]>>; Peter > > Psenak (ppsenak) <[email protected] <mailto:[email protected]>>; > > Yingzhen Qu <[email protected] <mailto:[email protected]>>; > > lsr-chairs <[email protected] <mailto:[email protected]>>; > > shraddha <[email protected] <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]> > > 主题: [Lsr] Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and > > Purge LSA > > > > > > Tony Przygienda <[email protected] <mailto:[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:28PM Aijun Wang <[email protected] > <mailto:[email protected]%0b>>>> 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] <mailto:[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 > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
