> On Jul 12, 2024, at 10:49, Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > > Acee – > > The neighbors do not control when the flooding of the purge/update reaches > all routers in the network. > The neighbors have direct control of the exchange between themselves and > their immediate neighbors – nothing else.
The restarting router has no better idea. If you’re suggesting suppressing advertising adjacencies until all neighbors of the restarting router are adjacent (which is a bad idea), the restarting router can do this as well by suppressing its link advertisements. There is NOTHING additional that can be accomplished by adding LLS signaling. Acee > > Les > > From: Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>> > Sent: Friday, July 12, 2024 7:44 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>> > Cc: Liyan Gong <gongli...@chinamobile.com > <mailto:gongli...@chinamobile.com>>; Aijun Wang <wangai...@tsinghua.org.cn > <mailto:wangai...@tsinghua.org.cn>>; Peter Psenak (ppsenak) > <ppse...@cisco.com <mailto:ppse...@cisco.com>>; 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>> > Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA > > > > > On Jul 12, 2024, at 10:40, Les Ginsberg (ginsberg) <ginsb...@cisco.com > <mailto:ginsb...@cisco.com>> wrote: > > Acee – > > Having the restarting router suppress advertisement of its adjacencies does > not address the transient state where routers in the network have received > the updated LSA from the neighbor with the reestablished adjacency to the > restarting router but still have the stale LSA from the restarting router > that has the pre-restart adjacency advertisements. (point #1 I made below). > > The neighbors of the restarting router will not advertise the adjacency until > the stale LSAs are purged or updated - this is the whole point of > https://datatracker.ietf.org/doc/draft-hegde-lsr-ospf-better-idbx/ > > > Thanks, > Acee > > > > > > > So this is not a robust solution. > > Les > > From: Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>> > Sent: Friday, July 12, 2024 7:21 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>> > Cc: Liyan Gong <gongli...@chinamobile.com > <mailto:gongli...@chinamobile.com>>; Aijun Wang <wangai...@tsinghua.org.cn > <mailto:wangai...@tsinghua.org.cn>>; Peter Psenak (ppsenak) > <ppse...@cisco.com <mailto:ppse...@cisco.com>>; 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>> > Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA > > Hi Les, > > > > On Jul 12, 2024, at 02:57, Les Ginsberg (ginsberg) <ginsb...@cisco.com > <mailto:ginsb...@cisco.com>> wrote: > > I am happy that work on this problem has begun. > I believe the most robust way forward is to implement the mechanisms defined > in BOTH drafts. > > I think the mechanism defined in draft-hegde-lsr-ospf-better-idbx is sound > and not overly complex (sorry Liyan 😊) and should be done. > But it does not solve all aspects of the problem. > It does make LSDB synchronization more robust – which addresses the control > plane aspects of the problem. > It also has the advantage that it does not require any support on the > neighboring routers – and so the benefits can be realized simply by upgrading > one router at a time. > > However, draft-hegde-lsr-ospf-better-idbx does not address forwarding plane > aspects of the problem – which become more significant at scale. > There are two aspects of this problem: > > 1)You do not have control over the order in which the updated LSAs are > flooded to the rest of the network – so it is still possible for transient > forwarding issues to occur multiple hops away from the restarting router. > 2)The restarting router requires additional time – after full LSDB sync – to > program the forwarding plane. It is well known that update of the forwarding > plane takes much longer than protocol SPF calculation. > If only a few hundred routes are supported, this may not be of significant > concern, but if thousands of routes are supported the time it takes to > program the forwarding plane becomes a significant contributor. > > I fail to see how suppressing neighbor adjacency advertisement solves any > additional problems that are not solved by avoiding usage of the restarting > router’s stale LSAs. > > Note that the OSPF SPF has a check for bi-directional connectivity, > excerpted from section 16.1 of RFC2328: > > > (b) Otherwise, W is a transit vertex (router or transit > network). Look up the vertex W's LSA (router-LSA or > network-LSA) in Area A's link state database. If the > LSA does not exist, or its LS age is equal to MaxAge, or > it does not have a link back to vertex V, examine the > next link in V's LSA.[23] > > > > Consequently, the restarting router can simply suppress its own link > advertisement until such time that is required to solve the above problems. > You should be familiar with this quote: > > > “If you want a thing done well, do it yourself.” > ― Napoleon Bonaparte > > > Thanks, > Acee > > > > > > > > > draft-cheng-lsr-ospf-adjacency-suppress provides a way to address the above > two aspects by providing a means for the neighbors of the restarting router > to delay advertisement of the restored adjacency to the restarting router. > (SA signaling) > > It could be argued that using SA signaling eliminates the need to do anything > else – but given that this mechanism depends upon support by all the > neighbors of the restarting router I believe there is still good reason to > implement both mechanisms. > > NOTE: I would prefer that the two drafts be combined into a single draft – > but that is optional and up to the authors. But from the WG perspective I > would like to see both solutions progress. > > Les > > > > From: Liyan Gong <gongli...@chinamobile.com > <mailto:gongli...@chinamobile.com>> > Sent: Thursday, July 11, 2024 8:22 PM > To: Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>>; Aijun > Wang <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn>> > Cc: Peter Psenak (ppsenak) <ppse...@cisco.com <mailto:ppse...@cisco.com>>; > 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>> > Subject: [Lsr] Re: About Premature aging of LSA and Purge LSA > > Hi Acee and Aijun, > > Thank you very much for your discussion. I would like to share my thoughts on > the proposed solutions. > In my view, draft-hegde-lsr-ospf-better-idbx may not be as straight forward > as it initially appears. > Despite its local applicability, it entails a complex neighbor establishment > process, which is fundamental to the OSPF protocol and typically not altered > lightly by those familiar with its workings. > On the other hand, draft-cheng-lsr-ospf-adjacency-suppress presents a more > focused approach tailored to address the specific issue without unintended > consequences. > I still believe the key factor in evaluating any approach is whether it > impacts the current systems negatively. > > Regarding our extensive discussions on these drafts, please refer to our > previous records for more details. > https://mailarchive.ietf.org/arch/search/?q=%22draft-cheng-lsr-ospf-adjacency-suppress%22 > > Thank you for your attention to this matter. > > > Best Regards, > > Liyan > > > > ----邮件原文---- > 发件人：Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>> > 收件人：Aijun Wang <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn>> > 抄 送:Peter Psenak <ppse...@cisco.com <mailto:ppse...@cisco.com>>,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>> > 发送时间：2024-07-11 23:26:57 > 主题：[Lsr] Re: About Premature aging of LSA and Purge LSA > > As WG member: > > On Jul 11, 2024, at 05:29, Aijun Wang <wangai...@tsinghua.org.cn > <mailto:wangai...@tsinghua.org.cn>> 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 > > 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> > [mailto:forwardingalgori...@ietf.org] 代表 Aijun Wang > 发送时间: 2024年7月11日 17:20 > 收件人: 'Acee Lindem' <acee.i...@gmail.com <mailto:acee.i...@gmail.com>> > 抄送: 'Peter Psenak' <ppse...@cisco.com <mailto:ppse...@cisco.com>>; '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: 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? > > 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> > [mailto:forwardingalgori...@ietf.org] 代表 Acee Lindem > 发送时间: 2024年7月10日 22:14 > 收件人: Aijun Wang <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn>> > 抄送: Peter Psenak <ppse...@cisco.com <mailto:ppse...@cisco.com>>; 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: 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 <wangai...@tsinghua.org.cn > <mailto: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> > [mailto:forwardingalgori...@ietf.org] 代表 Acee Lindem > 发送时间: 2024年7月9日 20:14 > 收件人: Peter Psenak <ppse...@cisco.com <mailto:ppse...@cisco.com>> > 抄送: Aijun Wang <wangai...@tsinghua.org.cn > <mailto:wangai...@tsinghua.org.cn>>; 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: 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
