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

[Les Ginsberg (ginsberg)]

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>
Sent: Friday, July 12, 2024 7:55 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Liyan Gong <gongli...@chinamobile.com>; Aijun Wang 
<wangai...@tsinghua.org.cn>; Peter Psenak (ppsenak) <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>
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 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