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 <wangai...@tsinghua.org.cn> 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 > > 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 > Acee Lindem > 发送时间: 2024年7月9日 20:14 > 收件人: Peter Psenak <ppse...@cisco.com> > 抄送: Aijun Wang <wangai...@tsinghua.org.cn>; Yingzhen Qu > <yingzhen.i...@gmail.com>; lsr <lsr@ietf.org>; lsr-chairs > <lsr-cha...@ietf.org>; tony Przygienda <tonysi...@gmail.com>; shraddha > <shrad...@juniper.net> > 主题: [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 <ppse...@cisco.com >> <mailto:ppse...@cisco.com>> 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 >>> >>> 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> >>> [mailto:forwardingalgori...@ietf.org] 代表 Acee Lindem >>> 发送时间: 2024年7月9日 3:58 >>> 收件人: Yingzhen Qu <yingzhen.i...@gmail.com> <mailto:yingzhen.i...@gmail.com> >>> 抄送: lsr <lsr@ietf.org> <mailto:lsr@ietf.org>; lsr-chairs >>> <lsr-cha...@ietf.org> <mailto:lsr-cha...@ietf.org>; tony Przygienda >>> <tonysi...@gmail.com> <mailto:tonysi...@gmail.com>; shraddha >>> <shrad...@juniper.net> <mailto:shrad...@juniper.net> >>> 主题: [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 <yingzhen.i...@gmail.com >>>> <mailto:yingzhen.i...@gmail.com>> 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 lsr-cha...@ietf.org >>>> <mailto:lsr-cha...@ietf.org> 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 -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
