[Lsr] Re: About Premature aging of LSA and Purge LSA

[Acee Lindem]

Hi Liyan, 

> On Jul 11, 2024, at 23:22, Liyan Gong <gongli...@chinamobile.com> wrote:
> 
> 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.


With adjacency suppression, the restarting router needs to go through similar 
logic to determine when it has flushed all its stale LSAs. Neighbors have 
additional logic to tie link advertisement to received Hello LLS state. These 
are new protocol interactions. 

In contrast, the database exchange changes are confined to database exchange 
and reception of LSA - two paths that already involved in maintaining the LS 
Request list. I think if your draft would specify the details to the level of 
ours, it would be patently obvious that it is more complex. 


> 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

The current version addresses the deficiency of handling stale LSAs that are 
not in restarting router’s LSDB and need to be purged. I don’t believe there 
are any other deficiencies. 

Thanks,
Acee



>  
> Thank you for your attention to this matter.
> 
> 
> Best Regards,
> 
> Liyan
> 
> 
> 
> ----邮件原文----
> 发件人：Acee Lindem  <acee.i...@gmail.com>
> 收件人：Aijun Wang  <wangai...@tsinghua.org.cn>
> 抄　送: Peter Psenak  <ppse...@cisco.com>,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>
> 发送时间：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> 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