Hi Aijun, > On Jul 11, 2024, at 22:44, Aijun Wang <[email protected]> wrote: > > No. It sounds non-practical. > > The “Stale DB Exchange List” that you proposed exists only on the neighbors > of the restarting router, right?
Yes - but it the originator, i.e., the restarting router, that will update or purge its stale LSAs prior to advertising of a link to the restarting router. This is fundamentally the way OSPF flooding works. > > Then, will it introduce inconsistency LSDB and SPF calculations results among > the routers that locates far beyond the neighbors of the restarting router > and these direct connected routers? Nope. > > And, your proposal needs the changes of the state machines of the current > OSPF implementation, it is unconvinced that you call them “simpler”. These are listed in section 2.1. Those familiar with OSPF flooding and implementation are free to comment on these. Thanks, Acee > > Aijun Wang > China Telecom > >> On Jul 11, 2024, at 23:28, Acee Lindem <[email protected]> wrote: >> >> As WG member: >> >>> On Jul 11, 2024, at 05:29, Aijun Wang <[email protected]> wrote: >>> >>> And, there is also another draft aims to solve the similar problem >>> https://datatracker.ietf.org/doc/html/draft-cheng-lsr-ospf-adjacency-suppress-02, >>> which it declares similar with the solution in IS-IS. Why not take this >>> approach? >> >> Because this one doesn’t require any signaling and can accomplished via >> local behavior without requiring support from any other OSPF router. >> Additionally, it is simpler.. Well, at least for someone who has a deep >> understanding of the protocol. >> >> Thanks, >> Acee >> >> >> >>> >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> 发件人: [email protected] <mailto:[email protected]> >>> [mailto:[email protected]] 代表 Aijun Wang >>> 发送时间: 2024年7月11日 17:20 >>> 收件人: 'Acee Lindem' <[email protected] <mailto:[email protected]>> >>> 抄送: 'Peter Psenak' <[email protected] <mailto:[email protected]>>; >>> 'Yingzhen Qu' <[email protected] <mailto:[email protected]>>; >>> 'lsr' <[email protected] <mailto:[email protected]>>; 'lsr-chairs' >>> <[email protected] <mailto:[email protected]>>; 'tony Przygienda' >>> <[email protected] <mailto:[email protected]>>; 'shraddha' >>> <[email protected] <mailto:[email protected]>> >>> 主题: [Lsr] 答复: Re: About Premature aging of LSA and Purge LSA >>> >>> For the neighbors of the restarting router, why can’t they delete directly >>> the LSAs that originated by the restarting router instead of putting them >>> into one “Stale DB Exchange list” when they detect their neighbor is down? >>> >>> 发件人: [email protected] <mailto:[email protected]> >>> [mailto:[email protected]] 代表 Acee Lindem >>> 发送时间: 2024年7月10日 22:14 >>> 收件人: Aijun Wang <[email protected] >>> <mailto:[email protected]>> >>> 抄送: Peter Psenak <[email protected] <mailto:[email protected]>>; Yingzhen >>> Qu <[email protected] <mailto:[email protected]>>; lsr >>> <[email protected] <mailto:[email protected]>>; lsr-chairs <[email protected] >>> <mailto:[email protected]>>; tony Przygienda <[email protected] >>> <mailto:[email protected]>>; shraddha <[email protected] >>> <mailto:[email protected]>> >>> 主题: [Lsr] Re: About Premature aging of LSA and Purge LSA >>> >>> Yes - but the whole discussion of adjacency suppression and database >>> synchronization is based on preventing TEMPORARY usage of stale LSAs >>> leading to false bidirectional adjacencies during unplanned restart. RFC >>> 2328 OSPF will converge without any modifications - there can just be >>> transient traffic drops and/or loops. >>> >>> Thanks, >>> Acee >>>> On Jul 9, 2024, at 20:42, Aijun Wang <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> For the unplanned restart, shouldn’t the responsibility of the directed >>>> connect neighbors to send out such LSAs for the purge of obsolete LSA? >>>> >>>> >>>> Best Regards >>>> >>>> Aijun Wang >>>> China Telecom >>>> >>>> 发件人: [email protected] <mailto:[email protected]> >>>> [mailto:[email protected]] 代表 Acee Lindem >>>> 发送时间: 2024年7月9日 20:14 >>>> 收件人: Peter Psenak <[email protected] <mailto:[email protected]>> >>>> 抄送: Aijun Wang <[email protected] >>>> <mailto:[email protected]>>; Yingzhen Qu <[email protected] >>>> <mailto:[email protected]>>; lsr <[email protected] >>>> <mailto:[email protected]>>; lsr-chairs <[email protected] >>>> <mailto:[email protected]>>; tony Przygienda <[email protected] >>>> <mailto:[email protected]>>; shraddha <[email protected] >>>> <mailto:[email protected]>> >>>> 主题: [Lsr] Re: About Premature aging of LSA and Purge LSA >>>> >>>> Additionally, you certainly don’t need a standards track solution to this >>>> problem. An implementation could honor MinLSInterval by simply locally >>>> keeping its own list of self-originated MaxAge LSAs and delaying >>>> reorigination. >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>>> On Jul 9, 2024, at 04:13, Peter Psenak <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Aijun, >>>>> >>>>> On 09/07/2024 09:46, Aijun Wang wrote: >>>>>> Hi, Acee: >>>>>> >>>>>> Can the proposal in >>>>>> https://datatracker.ietf.org/doc/html/draft-dong-ospf-purge-lsa-00, >>>>>> together with >>>>>> https://datatracker.ietf.org/doc/html/rfc2328#section-14.1(Premature >>>>>> aging of LSAs) solve your mentioned problem? >>>>>> If so, is it simpler than your proposal? >>>>>> That is, before the router restart, it needs only send out the Purge >>>>>> LSA(when LSA sequence number is not to wrap) or premature aging of its >>>>>> LSA.(when sequence number is to wrap) >>>>> does not work for unplanned restart. >>>>> >>>>> thanks, >>>>> Peter >>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Aijun Wang >>>>>> China Telecom >>>>>> >>>>>> 发件人: [email protected] <mailto:[email protected]> >>>>>> [mailto:[email protected]] 代表 Acee Lindem >>>>>> 发送时间: 2024年7月9日 3:58 >>>>>> 收件人: Yingzhen Qu <[email protected]> >>>>>> <mailto:[email protected]> >>>>>> 抄送: lsr <[email protected]> <mailto:[email protected]>; lsr-chairs >>>>>> <[email protected]> <mailto:[email protected]>; tony Przygienda >>>>>> <[email protected]> <mailto:[email protected]>; shraddha >>>>>> <[email protected]> <mailto:[email protected]> >>>>>> 主题: [Lsr] Re: IETF 120 LSR Slot Requests >>>>>> >>>>>> Speaking as WG member: >>>>>> >>>>>> I would like a 10 minute slot to present an update to >>>>>> https://datatracker.ietf.org/doc/draft-hegde-lsr-ospf-better-idbx/ >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 25, 2024, at 14:19, Yingzhen Qu <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The draft agenda for IETF 120 has been posted: >>>>>>> IETF 120 Meeting Agenda >>>>>>> <https://datatracker.ietf.org/meeting/120/agenda/> >>>>>>> >>>>>>> The LSR session is scheduled on Friday Session I1 9:30 - 11:30, July >>>>>>> 26, 2024. >>>>>>> >>>>>>> Please send slot requests to [email protected] >>>>>>> <mailto:[email protected]> before the end of the day Wednesday July >>>>>>> 10th. Please include draft name and link, presenter, desired slot >>>>>>> length including Q&A. >>>>>>> >>>>>>> Please note that having a discussion on the LSR mailing list is a >>>>>>> prerequisite for a draft presentation in the WG session. If you need >>>>>>> any help please reach out to the chairs. >>>>>>> >>>>>>> Thanks, >>>>>>> Yingzhen >> >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
