Hi Les, > On Jul 24, 2024, at 15:30, Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > > Acee – > > Regarding new Section 4, the text looks good – but one thing I think should > also be mentioned is that in order for the restarting router to successfully > compute an SPF which will end up populating its forwarding plane, the local > adjacencies that are in FULL state must be included in the SPT building even > though they are not advertised. This is a subtle point that folks may not > realize. I think it would be helpful to mention.
Good point. Thanks, Acee > > Thanx. > > Les > > From: Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>> > Sent: Wednesday, July 24, 2024 1:58 PM > To: Peter Psenak (ppsenak) <ppse...@cisco.com <mailto:ppse...@cisco.com>> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>>; > Tony Przygienda <tonysi...@gmail.com <mailto:tonysi...@gmail.com>>; Liyan > Gong <gongli...@chinamobile.com <mailto:gongli...@chinamobile.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>>; shraddha <shrad...@juniper.net > <mailto:shrad...@juniper.net>> > Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA > > Hi Peter, > > > On Jul 16, 2024, at 09:40, Acee Lindem <acee.i...@gmail.com > <mailto:acee.i...@gmail.com>> wrote: > > Hi Peter, > > > On Jul 16, 2024, at 3:59 AM, Peter Psenak <ppse...@cisco.com > <mailto:ppse...@cisco.com>> wrote: > > Hi Acee, > > On 15/07/2024 21:08, Acee Lindem wrote: > > Hi Peter, > > > On Jul 15, 2024, at 13:04, Peter Psenak <ppse...@cisco.com > <mailto:ppse...@cisco.com>> wrote: > > Hi Acee, > > On 12/07/2024 22:00, Acee Lindem wrote: > > Les - > > The SA bit solution is no more “complete" than the database exchange > solution. Let’s talk specific scenarios rather than FUD. > > So we have an LSA originated by the restarting router at time T0 and one > originated by its neighbor at time T1 where T1 is after T0. Although, they > take the same flooding path, the one originated at T1 arrives and is > processed ahead of the one originated at T0 resulting in traffic loss. > > I’m not arguing that this hypothetical situation isn’t possible with packet > loss. However, other than the added overhead and inefficiency of the SA bit > signaling resulting in some small delay, how does the SA bit solution solve > this? How does the restarting router know when its updated LSAs have > successfully been installed on all the routers in the area? It certainly > doesn’t know any better than its neighbor. > > Thanks, > Acee > P.S. One could add a small delay to the database exchange solution once the > last stale LSA is updated or purged but I don’t believe this is necessary. > I believe adding some text about delaying the origination of the Router LSA > on the restarting router, while letting the forwarding plane be updated on it > by running the SPF and using its local adjacencies during that SPF, would be > a good addition to the draft. > As others alluded to, the problem of traffic hitting the restarting router > before it had a chance to fully converge its forwarding plane has been > observed in the field numerous time. > > The data plane update delay is a local problem whereas the usage of stale > LSAs due to OSPF converging before these LSAs are updated is a OSPF protocol > problem (but only a transient problem). If a platform has a data plane update > delay, it can locally delay advertisement for all routing protocols (not just > OSPF). However, this seems to be a platform issue rather than a protocol > issue which needs to be specified in an IETF document. However, I don’t think > that the local data plane delay should require collaboration with other > routers when it can be handled locally. > > it can be addressed locally. All I'm asking for is to put some text about the > issue and possible solution. > > I can add this since the issue has the same symptom as the stale LSA usage. > > I added some text on this in -03. > > <image001.png> > draft-hegde-lsr-ospf-better-idbx-03 > <https://www.ietf.org/archive/id/draft-hegde-lsr-ospf-better-idbx-03.txt> > Text Document · 19 KB > <https://www.ietf.org/archive/id/draft-hegde-lsr-ospf-better-idbx-03.txt> > > Thanks, > Acee > > > > > > Thanks, > Acee > > > > > > thanks, > Peter > > > > > > The delay I was saying I didn’t think should be added above is the one for > stale LSA usage due to some LS updates being lost and later ones being > flooded successfully. I feel this is the only way stale LSAs wouldn’t be > updated or purged by the time the router-LSA with the adjacency to the > restarting router is received (if the procedures in the draft are followed). > > Thanks, > Acee > > > > > > thanks, > Peter > > > > > > > On Jul 12, 2024, at 14:48, Les Ginsberg (ginsberg) <ginsb...@cisco.com > <mailto:ginsb...@cisco.com>> wrote: > > Tony – > What is important to me here is a common understanding and providing a > complete solution. > Hopefully, you are at least understanding that the point I am making is > valid i.e., traffic loss can occur even with better-idbx in place. > I would also argue that you are underestimating the effect of scale. > As to your argument below, it could also be used to argue against doing > anything – after all we know that current OSPF does converge in a modest > amount of time. > Since you have decided to make things better (which I support) I do not see > why we should not define a complete solution. > If you, as a vendor, choose not to implement SA because you consider the > cost/benefit ratio unappealing – that is your choice. So long as you and your > customers are satisfied … > But our mission here is to define a solution – and I am simply arguing for a > more complete solution. > Les > From: Tony Przygienda <tonysi...@gmail.com <mailto:tonysi...@gmail.com>> > Sent: Friday, July 12, 2024 11:23 AM > To: Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com>>; > 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>>; shraddha <shrad...@juniper.net > <mailto:shrad...@juniper.net>> > Subject: Re: [Lsr] About Premature aging of LSA and Purge LSA > Les, whatever you try to suggest here, you slide into direction of trying to > guarantee common knowledge closure (that's the technical term for what you > try) and based on distributed systems theory you end up ultimately with > virtual clock synchronization of the network in some form if you _really_ > want to solve the problem rather than "hey, my stuff may work 2 hops away > rather than 1 hop so it's much better and let's not talk about 3 hops" (look > up at Lampert's clock vectors/matrices for proper theoretical underpinnings > of such undertakings if you'd like to take this discussion further) and this > will slow things to a crawl. Worse, you will discover pretty soon that going > down this path you will have to learn consistent cuts and basically > transaction scheduling most likley ;-) > IGPs are just IGPs, i.e. they do guarantee "eventual consistency" (in proper > technical terms epsilon consistency) and that makes them fast and reacting > fast to failures and that's the base of their success. This also means you > have transients and this here is just one, relatively simple fix of a local > transient and that's about the best you can do to preserve the desirable > properties (i.e. fastest possible eventual consistency with maximum > resiliency [that's the CAP paradigm part which is another way to see IGPs as > _AP type of solution]). Without this kind of underlying > understanding/language we are talking about "me likes my stuff with me bells > and whistles better than ye' thing" and it's going in circles AFAIS. so > I'm with acee here in short (and I left the fact out that as I say, flavor of > this stuff is deployed since long time and works fine at any scale in our > experience and it's damn' simple to implement comparatively speaking and > doesn't need any big rollouts on the network] compared to all the signalling > machinery suggested) -- tony On Fri, Jul 12, 2024 at 6:44 PM Acee > Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>> wrote: > So, I don’t think the case you are suggesting is plausible. Let’s say you > have a hypothetical router somewhere in the same area that has the restarting > router’s stale LSAs. > 1. The restarting router’s neighbors will only advertise an adjacency > once the stale LSAs have been updated or purged from their local databases. > 2. Only then will the adjacency be advertised - so the update or purge > precedes the adjacency advertisement. > 3. How is the neighbor router’s LSA going to pass the restarting router’s > LSA update or purge? It will take the same or possibly even better flooding > path. Will it be flooded at warp speed? > 4. Are you suggesting that the restarting router’s LSAs are dropped but > the neighbor’s advertisement is not? If so, how would the restarting router > know this and delay removing the adjacency suppression? Are you relying on > the inherent inefficiencies and convergence delays with LLS signaling > handshake between the two routers? > In any case, trying to prevent transient problems due to selective loss of > updates is an exercise in futility. > Thanks, > Acee > > > On Jul 12, 2024, at 12:13, Les Ginsberg (ginsberg) <ginsb...@cisco.com > <mailto:ginsb...@cisco.com>> wrote: > Acee – > When the restarting router goes down, the state of the LSDB in the network > becomes: > Restart Router LSA: All neighbors advertised > Neighbor Routers: Neighbor to Restarting Router is removed > When the restarting router comes back up, two changes will occur: > 1)Restarting Router updates its LSAs > 2)Neighbors updates their LSAs to indicate it once again has a neighbor to > the restarting router > You cannot guarantee the flooding order of network-wide. > Because the stale LSAs from the Restarting Router are present in all nodes, > as soon as a neighbor readvertises the adjacency to the restarting router, it > is now possible that on some nodes in the network you will temporarily have > an LSDB which has: > Stale LSA from restarting router + Updated LSA from neighbor > Whether the restarting router sends an updated LSA with neighbors or without > neighbors (as you suggest) you cannot prevent the above transient condition > from occurring because doing so requires guaranteeing that the update to the > Neighbor LSA and the update to the restarting router LSA are done atomically > network-wide. > That is why the restarting router cannot do this without help from the > neighbors. > Hope this is clear. > Les > From: Acee Lindem <acee.i...@gmail.com <mailto:acee.i...@gmail.com>> > Sent: Friday, July 12, 2024 7:55 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:49, Les Ginsberg (ginsberg) <ginsb...@cisco.com > <mailto: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 > ofhttps://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 > withhttps://datatracker.ietf.org/doc/html/rfc2328#section-14.1(Prematureaging > 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 > 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
