Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[linchangwang]

Hi Acee,

Sorry for the late reply.

First, let's look at the causes of the problem.

  For the establishment of OSPF neighbors, we can't guarantee the order of the 
FULL of the neighbors on both sides
  After FULL, a fully qualified LSA, such as router LSA, will be generated 
again. 
  Therefore, the protocol itself does not have a consistent time point for the 
LSDBs on both sides.
  After the device restarts, the restarted device and the peer device establish 
a neighbor, and the peer device neighbor is soon FULL. 
  The peer device uses LSAs that have not been updated by the restarted device 
(such as router LSAs, external LSAs) for routing calculations, 
  resulting in traffic being directed to the restarted device.

  There may also be problems with remote devices, which may not necessarily be 
directly connected to the restarted device.
  During LSDB flooding, it cannot be guaranteed that the LSA of the restarted 
device will flood the remote device first.


let's look at the solution to the problem:
Solution 1: Referring to the SA solution of IS-IS, the restarted device 
controls the timing of generating a LINK after the peer neighbor FULL. 
The scheme itself is relatively simple, and within an LSR working 
group, the mechanism can be similar to IS-IS.

Solution 2: Control the timing of LSDB FULL. The neighbor of the restarting 
device must ensure that the LSA of the restarted device is refreshed before the 
neighbor can be FULL. 
 Here is a detailed explanation of why the problem cannot be easily 
solved in this way:
 First, remote devices also have the restarted router's LSAs. 
Controlling the FULL timing of neighbor devices and restarted devices does not 
guarantee 
 that the restarted router's LSDBs of the entire network are refreshed 
to the latest. Flooding of LSDBs does not guarantee order;
  
Secondly, for restarted devices, in addition to LSDB synchronization, 
it is also necessary to have a stable time, such as updating the local 
forwarding table entry time and 
coordination time of peripheral modules. Therefore, the restarted 
device needs a steady state time to recover to the state before the restart.
For restarted devices, it is necessary to control the timing of traffic 
arrival.
Through the SA bit timer, the time for traffic introduction to the 
restarted device can be extended.

Thirdly, let's take a look at the problem of controlling the FULL 
scheme itself from neighboring devices. 
The principle of LSA requests is to compare the old and new LSAs. Now, 
we need to add the LSA of the restarted device to the request list, 
which in itself modifies the synchronization principle of OSPF LSDB. 
Perhaps, we can also control the timing of setting the M bit of the DD 
message, but these can complicate the state machine and introduce risk . 
In addition, for GR, additional inspection processing is required.
 
In the same LSR work group, IS-IS and OSPF have the same problems. Why don't we 
adopt the same solution?

Therefore,  I recommend to use SA bit to solve this problem.
The timing of clearing is controlled by the restart device to ensure that the 
restart device does not introduce remote traffic over a period of time.

Thanks,
Changwang


-Original Message-
From: Acee Lindem [mailto:acee.i...@gmail.com] 
Sent: Friday, March 31, 2023 8:08 PM
To: Liyan Gong
Cc: Les Ginsberg; Tony Przygienda; chenmengxiao (RD); lsr; Weiqiang Cheng; 
linchangwang (RD)
Subject: Re: 
[Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

Hi Liyan,

As I responded previously, we need an additional change to the OSPF database 
exchange.

https://mailarchive.ietf.org/arch/msg/lsr/zYB-GA9fw2mVNcTyhcRAAIPBhGE/

We’ll have something soon and then we can compare the two solutions. 

Thanks,
Acee



> On Mar 31, 2023, at 2:36 AM, Liyan Gong  wrote:
> 
> 
> Hi All，
> 
> I would like to summarize our discussion as below. If any misunderstanding, 
> please correct me, thanks a lot.  1. for A--B scenario, The blackhole occurs 
> on router B when the following order comes:
>1.1) B has the old LSA of A in its database.
>1.2) B generates new router-lsa to advertise the adjacency B->A.   
>1.3) B receives the re-originated LSA of A.
>2. for A---B---C scenario, The blackhole occurs on router C when the 
> following order comes(same with what Les says):
>2.1) C has the old lsa of A in its database.
>2.2) C receives the new router-lsa of B advertising the adjacency B->A.
>2.3) C receives the re-originated LSA of A---B
>Even if A--B scenarion is resolved, A--B--C scenario is likely to occur 
> under certain conditions, such as packet loss, out of order, or 
> MinLSInterval, MinLSArrival.
>  Because the sequence of the flooding process can not be controlled precisely 
> as 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Liyan,

As I responded previously, we need an additional change to the OSPF database 
exchange.

https://mailarchive.ietf.org/arch/msg/lsr/zYB-GA9fw2mVNcTyhcRAAIPBhGE/

We’ll have something soon and then we can compare the two solutions. 

Thanks,
Acee



> On Mar 31, 2023, at 2:36 AM, Liyan Gong  wrote:
> 
> 
> Hi All，
> 
> I would like to summarize our discussion as below. If any misunderstanding, 
> please correct me, thanks a lot.  1. for A--B scenario, The blackhole occurs 
> on router B when the following order comes:
>1.1) B has the old LSA of A in its database.
>1.2) B generates new router-lsa to advertise the adjacency B->A.   
>1.3) B receives the re-originated LSA of A.
>2. for A---B---C scenario, The blackhole occurs on router C when the 
> following order comes(same with what Les says):
>2.1) C has the old lsa of A in its database.
>2.2) C receives the new router-lsa of B advertising the adjacency B->A.
>2.3) C receives the re-originated LSA of A---B
>Even if A--B scenarion is resolved, A--B--C scenario is likely to occur 
> under certain conditions, such as packet loss, out of order, or 
> MinLSInterval, MinLSArrival.
>  Because the sequence of the flooding process can not be controlled precisely 
> as Les has mentioned in the following email.
>  Although the possibility is not so high as A--B scenario, it still should be 
> considered when choosing the solution. It is best to address both scenarios 
> at once.
>  Taking this into consideration, Let's rethink about the two solutions we 
> have discussed.
>  solution 1:  SA-bit:
> for scenario A--B, The upper step 1.2) is delayed by a signal which is 
> controled by a timer. The solution works well as the presentation slides show.
> for scenrio A--B--C, If the timer is assigned properly, greater delay can be 
> provided for upper step 2.2). This will help to guarantee step 2.3) before 
> step 2.2) .
>  solution 2: Always requesting router-lsa:
> for A---B scenario, there are two concerns to be addressed. We will leave 
> this to Acee.
> 1)It can not work for other type of routes if only requesting router-lsa.
> 2)It will cause BadLSReq, when an older lsa is received,as the same 
> time,there is an instance on the sending neighbor's request list.
>  for A--B--C scenario, Assuming the above concerns for scenario A--B have 
> been resolved, I also agree with what Les has mentioned as below:
> This is likely to happen - but without some delay between flooding the 
> updated Router LSA from the restarting router and the updated Router LSA on 
> the neighbor there is still some risk.
>  So, Leaving behind the unaddressed concerns on A--B scenario，It seems to me 
> that SA-bit is better for A--B--C scenario.
> 
> Best Regards,
> Liyan
> 
> 邮件原文
> 发件人："Les Ginsberg (ginsberg)" 
> 收件人：Tony Przygienda  
> 抄　送: Acee Lindem  ,Liyan Gong  
> ,"chen.mengxiao" ,lsr  
> ,Weiqiang Cheng ,linchangwang  
> 
> 发送时间：2023-03-30 01:14:59
> 主题：RE:[Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
> 
> 
> Tony –
>  I think we are not far apart in our POV – though the relative size of the 
> bird and the gun might be debatable. 
>  Given that the draft authors and Acee seem to be agreeing that “something” 
> should be done, I am thinking that addressing the concern that I have will 
> not add much complexity to whatever solution they agree on.
> But I will defer to the OSPF experts.
> Les
>  From: Tony Przygienda  
> Sent: Tuesday, March 28, 2023 8:35 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Acee Lindem ; Liyan Gong 
> ; chen.mengxiao ; lsr 
> ; Weiqiang Cheng ; linchangwang 
> 
> Subject: Re: 
> [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>  So Les, your concern AFAIU it is maybe bit overwrought. Local (assuming 
> remote is the unplanned bouncer, in chain example B local A remote) 
> advertises its LSA with the link failed and that gets flooded immediately (I 
> assume the link local-remote  is *not* a minimal cut in the topology so there 
> are paths to flood the whole network without the link coming up again unlike 
> the 3 router example) and then local does NOT advertise adjacency until it's 
> full no matter what which will take a bit of time. So  even if floods 
> high-version remote LSA overriding the remote's initial low-version LSA the 
> bidirectional check fails as Acee points out. Then remote overrides and 
> remote and local only flood LSAs with adjacency in them after full which 
> takes some time in any  case.  Adding additional signalling and 
> interdependencies between hellos and LSA origination seems to me shooting at 
> pretty little birds with canons

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Liyan Gong]

Hi All，





I would like to summarize our discussion as below. If any misunderstanding, 
please correct me, thanks a lot. 


 


1. for A--B scenario, The blackhole occurs on router B when the following order 
comes:


   1.1) B has the old LSA of A in its database.


   1.2) B generates new router-lsa to advertise the adjacency B->A.   


   1.3) B receives the re-originated LSA of A.


   


2. for A---B---C scenario, The blackhole occurs on router C when the following 
order comes(same with what Les says):


   2.1) C has the old lsa of A in its database.


   2.2) C receives the new router-lsa of B advertising the adjacency B->A.


   2.3) C receives the re-originated LSA of A---B


   


Even if A--B scenarion is resolved, A--B--C scenario is likely to occur under 
certain conditions, such as packet loss, out of order, or MinLSInterval, 
MinLSArrival.


 


Because the sequence of the flooding process can not be controlled precisely as 
Les has mentioned in the following email.


 


Although the possibility is not so high as A--B scenario, it still should be 
considered when choosing the solution. It is best to address both scenarios at 
once.


 


Taking this into consideration, Let39s rethink about the two solutions we have 
discussed.


 


solution 1:  SA-bit:


for scenario A--B, The upper step 1.2) is delayed by a signal which is 
controled by a timer. The solution works well as the presentation slides show.


for scenrio A--B--C, If the timer is assigned properly, greater delay can be 
provided for upper step 2.2). This will help to guarantee step 2.3) before step 
2.2) .


 


solution 2: Always requesting router-lsa:


for A---B scenario, there are two concerns to be addressed. We will leave this 
to Acee.


1)It can not work for other type of routes if only requesting router-lsa.


2)It will cause BadLSReq, when an older lsa is received,as the same time,there 
is an instance on the sending neighbor39s request list.


 


for A--B--C scenario, Assuming the above concerns for scenario A--B have been 
resolved, I also agree with what Les has mentioned as below:


This is likely to happen - but without some delay between flooding the updated 
Router LSA from the restarting router and the updated Router LSA on the 
neighbor there is still some risk.


 


So, Leaving behind the unaddressed concerns on A--B scenario，It seems to me 
that SA-bit is better for A--B--C scenario.





Best Regards,


Liyan





邮件原文发件人："Les Ginsberg (ginsberg)" 收件人：Tony 
Przygienda  抄　送: Acee Lindem  ,Liyan 
Gong  ,"chen.mengxiao" ,lsr  
,Weiqiang Cheng ,linchangwang  
发送时间：2023-03-30 
01:14:59主题：RE:[Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt









Tony –


 


I think we are not far apart in our POV – though the relative size of the bird 
and the gun might be debatable. 


 


Given that the draft authors and Acee seem to be agreeing that “something” 
should be done, I am thinking that addressing the concern that I have will not 
add much complexity to whatever solution they agree on.


But I will defer to the OSPF experts.


 


   Les


 




From: Tony Przygienda  Sent: Tuesday, March 28, 2023 8:35 
PM To: Les Ginsberg (ginsberg)  Cc: Acee Lindem 
 Liyan Gong  chen.mengxiao 
 lsr  Weiqiang Cheng 
 linchangwang  
Subject: Re: 
[Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt




 


So Les, your concern AFAIU it is maybe bit overwrought. Local (assuming remote 
is the unplanned bouncer, in chain example B local A remote) advertises its LSA 
with the link failed and that gets flooded immediately (I assume the link 
local-remote  is *not* a minimal cut in the topology so there are paths to 
flood the whole network without the link coming up again unlike the 3 router 
example) and then local does NOT advertise adjacency until it39s full no matter 
what which will take a bit of time. So  even if floods high-version remote LSA 
overriding the remote39s initial low-version LSA the bidirectional check fails 
as Acee points out. Then remote overrides and remote and local only flood LSAs 
with adjacency in them after full which takes some time in any  case.  Adding 
additional signalling and interdependencies between hellos and LSA origination 
seems to me shooting at pretty little birds with canons somewhat due to 
involved interdependencies.



 



I probably repeat partially what Acee said but it39s my 2c



 



-- tony




 


On Wed, Mar 29, 2023 at 9:53AM Les Ginsberg (ginsberg)  
wrote:



Acee - So your proposal is to have the neighbor of the restarting router be 
responsible for ensuring that the Router LSA updates are done in the proper 
order. I agree this can work as well. I still think there is one element 
missing from your proposal i.e., guaranteeing that the Router LSA update from 
the restarting router is flooded before (or at least in the same Link State 
Update packet) as the updated Ro

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Les Ginsberg (ginsberg)]

Acee -

I leave it to you and others to work out the optimal OSPF solution.

I only want to emphasize that my concern here is about the state of the LSDB on 
nodes other than the restarting router and its neighbor(s).
I think we would like to prevent those routers from ever entering a state where 
they have:

Old Router LSA from restarting router advertising adjacencies to its neighbors
New Router LSA from the neighbor(s) of the restarting router advertising 
adjacency to the restarting router

If that happens, these routers will (at least for a short while) calculate 
routes via the restarting router before that router is ready to forward them.

So long as whatever solution you come up with addresses that issue, then I am 
satisfied.

Thanx.

Les

> -Original Message-
> From: Acee Lindem 
> Sent: Tuesday, March 28, 2023 9:00 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Liyan Gong ; Tony Przygienda
> ; chen.mengxiao ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
> suppress-00.txt
> 
> Hi Les,
> 
> > On Mar 28, 2023, at 20:53, Les Ginsberg (ginsberg) 
> wrote:
> >
> > Acee -
> >
> > So your proposal is to have the neighbor of the restarting router be
> responsible for ensuring that the Router LSA updates are done in the proper
> order.
> > I agree this can work as well.
> >
> > I still think there is one element missing from your proposal i.e.,
> guaranteeing that the Router LSA update from the restarting router is
> flooded before (or at least in the same Link State Update packet) as the
> updated Router LSA from the neighbor - and that this order is maintained at
> each flooding hop throughout the network.
> > This is likely to happen - but without some delay between flooding the
> updated Router LSA from the restarting router and the updated Router LSA
> on the neighbor there is still some risk.
> 
> See my response to Liyan. If we leave the Router-LSA on the neighbor’s Link
> State Request list when a less recent version is received, the adjacency will
> not go to full until the more-recent version is received. This will handle 
> case
> where the restarting router’s Router-LSA is the last or only element in the
> list.
> 
> Thanks,
> Acee
> 
> 
> 
> >
> >   Les
> >
> >> -Original Message-
> >> From: Acee Lindem 
> >> Sent: Tuesday, March 28, 2023 2:19 PM
> >> To: Les Ginsberg (ginsberg) 
> >> Cc: Liyan Gong ; Tony Przygienda
> >> ; chen.mengxiao ; lsr
> >> ; Weiqiang Cheng ;
> >> linchangwang 
> >> Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
> >> suppress-00.txt
> >>
> >> Hi Les
> >>
> >>> On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)
> >>  wrote:
> >>>
> >>> (For some reason, email from you now goes into my Junk folder –
> delaying
> >> my response. )
> >>> Acee –
> >>> Consider the simple topology:
> >>> A---B---C
> >>> A is the restarting router.
> >>> C represents “the rest of the network” attached to B.
> >>> Router A goes down.
> >>> Adjacency on B to A goes down.
> >>> The LSPDB on C now has:
> >>> Router LSA B w no adjacency to A
> >>> Router LSA A w adjacency to B (stale)
> >>> A comes up – adjacency between A and B forms.
> >>> What happens next on C (and all the routers downstream) depends on
> >> order.
> >>> Case #1
> >>> New Router LSA B w adjacency to A arrives.
> >>
> >> With the change I proposed, Router B will not become adjacent to Router
> A
> >> without getting an updated version of Router A’s LSA that doesn’t include
> >> the link to Router B.
> >>
> >>
> >>
> >>> At this point, C believes there is two-way connectivity between A and B
> >> because of the presence of the stale Router LSA A
> >>> New Router LSA A w no adjacency to B arrives
> >>> Now C has the up to date information
> >>> Case #2
> >>> New Router LSA A w no adjacency to B arrives
> >>> New Router LSA B w adjacency to A arrives
> >>> C still sees no 2way connectivity between A and B
> >>> The reason you need to control the ordering is to prevent Case #1 from
> >> occurring.
> >>> Yes, this is a transient – LSPDB will eventually converge – but the
> duration
> >> of “eventually’ depends on scale.
> >>> SA bit can be used to prevent Case #1 from ever occurring – or at 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Les, 

> On Mar 28, 2023, at 20:53, Les Ginsberg (ginsberg)  wrote:
> 
> Acee -
> 
> So your proposal is to have the neighbor of the restarting router be 
> responsible for ensuring that the Router LSA updates are done in the proper 
> order.
> I agree this can work as well.
> 
> I still think there is one element missing from your proposal i.e., 
> guaranteeing that the Router LSA update from the restarting router is flooded 
> before (or at least in the same Link State Update packet) as the updated 
> Router LSA from the neighbor - and that this order is maintained at each 
> flooding hop throughout the network.
> This is likely to happen - but without some delay between flooding the 
> updated Router LSA from the restarting router and the updated Router LSA on 
> the neighbor there is still some risk.

See my response to Liyan. If we leave the Router-LSA on the neighbor’s Link 
State Request list when a less recent version is received, the adjacency will 
not go to full until the more-recent version is received. This will handle case 
where the restarting router’s Router-LSA is the last or only element in the 
list. 

Thanks,
Acee



> 
>   Les
> 
>> -Original Message-
>> From: Acee Lindem 
>> Sent: Tuesday, March 28, 2023 2:19 PM
>> To: Les Ginsberg (ginsberg) 
>> Cc: Liyan Gong ; Tony Przygienda
>> ; chen.mengxiao ; lsr
>> ; Weiqiang Cheng ;
>> linchangwang 
>> Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
>> suppress-00.txt
>> 
>> Hi Les
>> 
>>> On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)
>>  wrote:
>>> 
>>> (For some reason, email from you now goes into my Junk folder – delaying
>> my response. )
>>> Acee –
>>> Consider the simple topology:
>>> A---B---C
>>> A is the restarting router.
>>> C represents “the rest of the network” attached to B.
>>> Router A goes down.
>>> Adjacency on B to A goes down.
>>> The LSPDB on C now has:
>>> Router LSA B w no adjacency to A
>>> Router LSA A w adjacency to B (stale)
>>> A comes up – adjacency between A and B forms.
>>> What happens next on C (and all the routers downstream) depends on
>> order.
>>> Case #1
>>> New Router LSA B w adjacency to A arrives.
>> 
>> With the change I proposed, Router B will not become adjacent to Router A
>> without getting an updated version of Router A’s LSA that doesn’t include
>> the link to Router B.
>> 
>> 
>> 
>>> At this point, C believes there is two-way connectivity between A and B
>> because of the presence of the stale Router LSA A
>>> New Router LSA A w no adjacency to B arrives
>>> Now C has the up to date information
>>> Case #2
>>> New Router LSA A w no adjacency to B arrives
>>> New Router LSA B w adjacency to A arrives
>>> C still sees no 2way connectivity between A and B
>>> The reason you need to control the ordering is to prevent Case #1 from
>> occurring.
>>> Yes, this is a transient – LSPDB will eventually converge – but the duration
>> of “eventually’ depends on scale.
>>> SA bit can be used to prevent Case #1 from ever occurring – or at least
>> make it very unlikely.
>> 
>> The change I proposed will prevent it as well. Router B will request Router 
>> A’s
>> LSA and Router A will respond with the new version which doesn’t have the
>> link to Router B. Router B will respond with the more-recent version (see 
>> this
>> excerpt from RFC 2328 13.3):
>> 
>> 
>> 
>>  (8) Else, the database copy is more recent. If the database copy
>>   has LS age equal to MaxAge and LS sequence number equal to
>> MaxSequenceNumber, simply discard the received LSA without
>>   acknowledging it. (In this case, the LSA's LS sequence number is
>>   wrapping, and the MaxSequenceNumber LSA must be completely
>>   flushed before any new LSA instance can be introduced).
>>   Otherwise, as long as the database copy has not been sent in a
>>   Link State Update within the last MinLSArrival seconds, send the
>>   database copy back to the sending neighbor, encapsulated within
>>   a Link State Update Packet. The Link State Update Packet should
>>   be sent directly to the neighbor. In so doing, do not put the
>>   database copy of the LSA on the neighbor's link state
>>   retransmission list, and do not acknowledge the received (less
>> recent)
>> LSA instance.
>> 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

So Les, your concern AFAIU it is maybe bit overwrought. Local (assuming
remote is the unplanned bouncer, in chain example B local A remote)
advertises its LSA with the link failed and that gets flooded immediately
(I assume the link local-remote is *not* a minimal cut in the topology so
there are paths to flood the whole network without the link coming up again
unlike the 3 router example) and then local does NOT advertise adjacency
until it's full no matter what which will take a bit of time. So even if
floods high-version remote LSA overriding the remote's initial low-version
LSA the bidirectional check fails as Acee points out. Then remote overrides
and remote and local only flood LSAs with adjacency in them after full
which takes some time in any case.  Adding additional signalling and
interdependencies between hellos and LSA origination seems to me shooting
at pretty little birds with canons somewhat due to involved
interdependencies.

I probably repeat partially what Acee said but it's my 2c

-- tony

On Wed, Mar 29, 2023 at 9:53 AM Les Ginsberg (ginsberg) 
wrote:

> Acee -
>
> So your proposal is to have the neighbor of the restarting router be
> responsible for ensuring that the Router LSA updates are done in the proper
> order.
> I agree this can work as well.
>
> I still think there is one element missing from your proposal i.e.,
> guaranteeing that the Router LSA update from the restarting router is
> flooded before (or at least in the same Link State Update packet) as the
> updated Router LSA from the neighbor - and that this order is maintained at
> each flooding hop throughout the network.
> This is likely to happen - but without some delay between flooding the
> updated Router LSA from the restarting router and the updated Router LSA on
> the neighbor there is still some risk.
>
>Les
>
> > -Original Message-
> > From: Acee Lindem 
> > Sent: Tuesday, March 28, 2023 2:19 PM
> > To: Les Ginsberg (ginsberg) 
> > Cc: Liyan Gong ; Tony Przygienda
> > ; chen.mengxiao ; lsr
> > ; Weiqiang Cheng ;
> > linchangwang 
> > Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
> > suppress-00.txt
> >
> > Hi Les
> >
> > > On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)
> >  wrote:
> > >
> > > (For some reason, email from you now goes into my Junk folder –
> delaying
> > my response. )
> > >  Acee –
> > >  Consider the simple topology:
> > >  A---B---C
> > >  A is the restarting router.
> > > C represents “the rest of the network” attached to B.
> > >  Router A goes down.
> > > Adjacency on B to A goes down.
> > > The LSPDB on C now has:
> > >  Router LSA B w no adjacency to A
> > > Router LSA A w adjacency to B (stale)
> > >  A comes up – adjacency between A and B forms.
> > > What happens next on C (and all the routers downstream) depends on
> > order.
> > >  Case #1
> > > New Router LSA B w adjacency to A arrives.
> >
> > With the change I proposed, Router B will not become adjacent to Router A
> > without getting an updated version of Router A’s LSA that doesn’t include
> > the link to Router B.
> >
> >
> >
> > > At this point, C believes there is two-way connectivity between A and B
> > because of the presence of the stale Router LSA A
> > > New Router LSA A w no adjacency to B arrives
> > > Now C has the up to date information
> > >  Case #2
> > > New Router LSA A w no adjacency to B arrives
> > > New Router LSA B w adjacency to A arrives
> > > C still sees no 2way connectivity between A and B
> > >  The reason you need to control the ordering is to prevent Case #1 from
> > occurring.
> > > Yes, this is a transient – LSPDB will eventually converge – but the
> duration
> > of “eventually’ depends on scale.
> > >  SA bit can be used to prevent Case #1 from ever occurring – or at
> least
> > make it very unlikely.
> >
> > The change I proposed will prevent it as well. Router B will request
> Router A’s
> > LSA and Router A will respond with the new version which doesn’t have the
> > link to Router B. Router B will respond with the more-recent version
> (see this
> > excerpt from RFC 2328 13.3):
> >
> >
> >
> >   (8) Else, the database copy is more recent. If the database copy
> >has LS age equal to MaxAge and LS sequence number equal to
> >  MaxSequenceNumber, simply discard the received LSA without
> >acknowledging it. (In this case, the LSA's LS sequence number
> is
> >wr

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Les Ginsberg (ginsberg)]

Acee -

So your proposal is to have the neighbor of the restarting router be 
responsible for ensuring that the Router LSA updates are done in the proper 
order.
I agree this can work as well.

I still think there is one element missing from your proposal i.e., 
guaranteeing that the Router LSA update from the restarting router is flooded 
before (or at least in the same Link State Update packet) as the updated Router 
LSA from the neighbor - and that this order is maintained at each flooding hop 
throughout the network.
This is likely to happen - but without some delay between flooding the updated 
Router LSA from the restarting router and the updated Router LSA on the 
neighbor there is still some risk.

   Les

> -Original Message-
> From: Acee Lindem 
> Sent: Tuesday, March 28, 2023 2:19 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Liyan Gong ; Tony Przygienda
> ; chen.mengxiao ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> Subject: Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-
> suppress-00.txt
> 
> Hi Les
> 
> > On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > (For some reason, email from you now goes into my Junk folder – delaying
> my response. )
> >  Acee –
> >  Consider the simple topology:
> >  A---B---C
> >  A is the restarting router.
> > C represents “the rest of the network” attached to B.
> >  Router A goes down.
> > Adjacency on B to A goes down.
> > The LSPDB on C now has:
> >  Router LSA B w no adjacency to A
> > Router LSA A w adjacency to B (stale)
> >  A comes up – adjacency between A and B forms.
> > What happens next on C (and all the routers downstream) depends on
> order.
> >  Case #1
> > New Router LSA B w adjacency to A arrives.
> 
> With the change I proposed, Router B will not become adjacent to Router A
> without getting an updated version of Router A’s LSA that doesn’t include
> the link to Router B.
> 
> 
> 
> > At this point, C believes there is two-way connectivity between A and B
> because of the presence of the stale Router LSA A
> > New Router LSA A w no adjacency to B arrives
> > Now C has the up to date information
> >  Case #2
> > New Router LSA A w no adjacency to B arrives
> > New Router LSA B w adjacency to A arrives
> > C still sees no 2way connectivity between A and B
> >  The reason you need to control the ordering is to prevent Case #1 from
> occurring.
> > Yes, this is a transient – LSPDB will eventually converge – but the duration
> of “eventually’ depends on scale.
> >  SA bit can be used to prevent Case #1 from ever occurring – or at least
> make it very unlikely.
> 
> The change I proposed will prevent it as well. Router B will request Router 
> A’s
> LSA and Router A will respond with the new version which doesn’t have the
> link to Router B. Router B will respond with the more-recent version (see this
> excerpt from RFC 2328 13.3):
> 
> 
> 
>   (8) Else, the database copy is more recent. If the database copy
>has LS age equal to MaxAge and LS sequence number equal to
>  MaxSequenceNumber, simply discard the received LSA without
>acknowledging it. (In this case, the LSA's LS sequence number is
>wrapping, and the MaxSequenceNumber LSA must be completely
>flushed before any new LSA instance can be introduced).
>Otherwise, as long as the database copy has not been sent in a
>Link State Update within the last MinLSArrival seconds, send the
>database copy back to the sending neighbor, encapsulated within
>a Link State Update Packet. The Link State Update Packet should
>be sent directly to the neighbor. In so doing, do not put the
>database copy of the LSA on the neighbor's link state
>retransmission list, and do not acknowledge the received (less
> recent)
>  LSA instance.
> 
> 
> Once Router A receives a more recent version and processed as described in
> section 13.4:
> 
> 
>   However, if the received self-originated LSA is newer than the
>   last instance that the router actually originated, the router
>   must take special action. The reception of such an LSA
>   indicates that there are LSAs in the routing domain that were
>   originated by the router before the last time it was restarted.
>   In most cases, the router must then advance the LSA's LS
>   sequence number one past the received LS sequence number, and
>   originate a new instance of the LSA.
> 
> 
> Thanks,
> Acee
> 
> 
> 
> 
> 
> 
> >Les
> >  From: Ace

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Les

> On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg)  
> wrote:
> 
> (For some reason, email from you now goes into my Junk folder – delaying my 
> response. )
>  Acee –
>  Consider the simple topology:
>  A---B---C
>  A is the restarting router.
> C represents “the rest of the network” attached to B.
>  Router A goes down.
> Adjacency on B to A goes down.
> The LSPDB on C now has:
>  Router LSA B w no adjacency to A
> Router LSA A w adjacency to B (stale)
>  A comes up – adjacency between A and B forms.
> What happens next on C (and all the routers downstream) depends on order.
>  Case #1
> New Router LSA B w adjacency to A arrives.

With the change I proposed, Router B will not become adjacent to Router A 
without getting an updated version of Router A’s LSA that doesn’t include the 
link to Router B. 



> At this point, C believes there is two-way connectivity between A and B 
> because of the presence of the stale Router LSA A
> New Router LSA A w no adjacency to B arrives
> Now C has the up to date information
>  Case #2
> New Router LSA A w no adjacency to B arrives
> New Router LSA B w adjacency to A arrives
> C still sees no 2way connectivity between A and B
>  The reason you need to control the ordering is to prevent Case #1 from 
> occurring.
> Yes, this is a transient – LSPDB will eventually converge – but the duration 
> of “eventually’ depends on scale.
>  SA bit can be used to prevent Case #1 from ever occurring – or at least make 
> it very unlikely.

The change I proposed will prevent it as well. Router B will request Router A’s 
LSA and Router A will respond with the new version which doesn’t have the link 
to Router B. Router B will respond with the more-recent version (see this 
excerpt from RFC 2328 13.3):
  


(8) Else, the database copy is more recent. If the database copy
 has LS age equal to MaxAge and LS sequence number equal to
 MaxSequenceNumber, simply discard the received LSA without
 acknowledging it. (In this case, the LSA's LS sequence number is
 wrapping, and the MaxSequenceNumber LSA must be completely
 flushed before any new LSA instance can be introduced).
 Otherwise, as long as the database copy has not been sent in a
 Link State Update within the last MinLSArrival seconds, send the
 database copy back to the sending neighbor, encapsulated within
 a Link State Update Packet. The Link State Update Packet should
 be sent directly to the neighbor. In so doing, do not put the
 database copy of the LSA on the neighbor's link state
 retransmission list, and do not acknowledge the received (less 
recent)
 LSA instance.


Once Router A receives a more recent version and processed as described in 
section 13.4:


However, if the received self-originated LSA is newer than the
last instance that the router actually originated, the router
must take special action. The reception of such an LSA
indicates that there are LSAs in the routing domain that were
originated by the router before the last time it was restarted.
In most cases, the router must then advance the LSA's LS
sequence number one past the received LS sequence number, and
originate a new instance of the LSA.


Thanks,
Acee






>Les
>  From: Acee Lindem  
> Sent: Tuesday, March 28, 2023 10:02 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Liyan Gong ; Tony Przygienda 
> ; chen.mengxiao ; lsr 
> ; Weiqiang Cheng ; linchangwang 
> 
> Subject: Re: 
> [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>  Les, 
> 
> 
> On Mar 28, 2023, at 12:45, Les Ginsberg (ginsberg)  wrote:
>  Acee –
>  I will leave it to you and the other OSPF experts to decide what mechanism 
> you want to use in OSPF.
>  My only comment is that in the solution you proposed you did not account for 
> the synchronization needed between Steps 2, 3, 4.
> This is needed I think to prevent the neighbor LSA advertising the new 
> adjacency to the restarting router from being propagated before the updated 
> Router LSA (w no neighbors) from the restarting router is propagated.
> This is what avoids downstream routers from prematurely installing paths via 
> the restarting router.
>  Paths will not be installed until both routers advertise the link in their 
> Router-LSAs (due to the backlink check in the SPF computation). 
>  (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
>

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Les, Liyan, 

With the change I suggested, a restarting router should be able to flood a 
Router-LSA without the link adjacencies before the corresponding neighbor comes 
full with the restarting. Additionally, if there are implementation-specific 
delays (such as SPF, route download, etc) that a restarting router wants to 
account for, it can simply delay advertising the Router-LSA link for an 
adjacency once it comes up. 

Just because we have this hello adjacency suppression hack in IS-IS doesn’t 
mean that we have to put it in OSPF. 


Thanks,
Acee 

> On Mar 28, 2023, at 01:46, Liyan Gong  wrote:
> 
>  
> Hi Les, Tony and Acee,
> 
> 
> 
> Appreciate your valuable suggestion. We will update the draft in the next 
> version as you suggested, including the title and detailed mechanism.
> 
> What Les has elabrated about the SA bit solution in the following email is 
> consistent with the idea. Thank you again for the detailed description.
> 
> Some additions are as follows:
> 
>   Yes, as Les says, this issue becomes more likely as the IGP scale increase 
> and can be seen in practice easily.
>   The key point is that, in OSPF, the LSA re-origination and neighbor full 
> are not in definite order. 
>   The larger the database, the slower the synchronization. This will delay 
> the lsa re-origination for restart router.
> 
>  
> 2.  Also because the LSA re-origination and neighbor full are not in definite 
> order,
> 
> Using the solution of requesting only router-lsa specially, The following 
> result I have mentioned becomes more likely:
> 
> Router B  has received the re-originated router lsa of router A, and 
> router A both get into the full state. Now A is reachable through spf tree 
> calculation.
> 
> As a result, the external route is also reachable, since the type 5 lsa 
> has not been re-originated.
>  
> To resolve this, the neighbor router must request all the lsas specially, 
> not only router-lsa. That is why I say this solution will cause more risk and 
> pressure.  
>  
> 3.  No obvious defect for the IS-IS SA bit has been seen in the practical 
> deployment. So, we think it is better to use the similar solution for OSPF.
> 
> 
>  <mailto:gongli...@chinamobile.com>
> 
> Best Regards,
> 
> Liyan
> 
> 
> 
> 
> 邮件原文
> 发件人："Les Ginsberg \\(ginsberg\\)"  <mailto:ginsberg=40cisco@dmarc.ietf.org>>
> 收件人：Tony Przygienda  mailto:tonysi...@gmail.com>>
> 抄　送: Acee Lindem  mailto:acee.i...@gmail.com>>,Liyan 
> Gong   <mailto:gongli...@chinamobile.com>>,"chen.mengxiao"  <mailto:chen.mengx...@h3c.com>>,lsr   <mailto:lsr@ietf.org>>,Weiqiang Cheng  <mailto:chengweiqi...@chinamobile.com>>,linchangwang  
> mailto:linchangwang.04...@h3c.com>>
> 发送时间：2023-03-28 10:44:41
> 主题：Re: 
> [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
> 
>
> Tony -
>  
> From: Tony Przygienda  
> Sent: Monday, March 27, 2023 5:11 PM
> To: Les Ginsberg (ginsberg) <>
> Cc: Acee Lindem ; Liyan Gong 
> ; chen.mengxiao ; lsr 
> ; Weiqiang Cheng ; linchangwang 
> 
> Subject: Re: [Lsr] 
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>  
> I didn't say "bigger", I said "random" ;-}
> [LES:] Ahhh…that makes all the difference. 
>  
> I tend to agree with SA bit solution though I don't grok how you can stop 
> flooding with that precisely. especially since you cannot rely on sequence of 
> hellos and DB sync packets arriving at the receiving node. And SA AFAIR 
> assumes LLC  or whatever while Acee's works on base spec ...
>  
> [LES:] Step 1: Send SA bit – neighbor continues to send Router LSA with no 
> neighbor advertisement to the restarting router
> Step 2: Complete LSPDB sync – including Restarting router generating new 
> Router LSA w no neighbors
> Step 3: Delay to allow updated Router LSA  from Restarting router to be 
> flooded
> Step 4: Clear SA bit – neighboring routers can now advertise adjacency to the 
> Restarting router
> Step 5: Restarting router generates new Router LSA advertising neighbors
>  
> (To make this “extra reliable”, at Step 3 we can use your “random delay” 
> strategy.  )
>  
>Les
>  
> --- tony
>  
> On Tue, Mar 28, 2023 at 8:04AM Les Ginsberg (ginsberg)  <mailto:ginsb...@cisco.com>> wrote:
> Tony –
>  
> It seems to me that the larger sequence # solution is less likely to work the 
> more you use it. 
> In other words, if I restart once a month, each time I need to pick an “even 
> bigger sequence #” to account for the starting point of the previous restart.
>  
> I know t

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

ok yes, I didn't think through the step 3 ...

thanks Les

-- tony

On Tue, Mar 28, 2023 at 11:44 AM Les Ginsberg (ginsberg) 
wrote:

> Tony -
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, March 27, 2023 5:11 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Acee Lindem ; Liyan Gong <
> gongli...@chinamobile.com>; chen.mengxiao ; lsr <
> lsr@ietf.org>; Weiqiang Cheng ;
> linchangwang 
> *Subject:* Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
>
> I didn't say "bigger", I said "random" ;-}
>
> *[LES:] Ahhh…that makes all the difference. ***
>
>
>
> I tend to agree with SA bit solution though I don't grok how you can stop
> flooding with that precisely. especially since you cannot rely on sequence
> of hellos and DB sync packets arriving at the receiving node. And SA AFAIR
> assumes LLC or whatever while Acee's works on base spec ...
>
>
>
> *[LES:] Step 1: Send SA bit – neighbor continues to send Router LSA with
> no neighbor advertisement to the restarting router*
>
> *Step 2: Complete LSPDB sync – including Restarting router generating new
> Router LSA w no neighbors*
>
> *Step 3: Delay to allow updated Router LSA  from Restarting router to be
> flooded*
>
> *Step 4: Clear SA bit – neighboring routers can now advertise adjacency to
> the Restarting router*
>
> *Step 5: Restarting router generates new Router LSA advertising neighbors*
>
>
>
> *(To make this “extra reliable”, at Step 3 we can use your “random delay”
> strategy. **** )*
>
>
>
> *   Les*
>
>
>
> --- tony
>
>
>
> On Tue, Mar 28, 2023 at 8:04 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Tony –
>
>
>
> It seems to me that the larger sequence # solution is less likely to work
> the more you use it. 
>
> In other words, if I restart once a month, each time I need to pick an
> “even bigger sequence #” to account for the starting point of the previous
> restart.
>
>
>
> I know that with a 32 bit sequence #, we have decades of updates
> available, but unless you save your most recent sequence # prior to restart
> you either have to make a generous WAG or risk the increasing likelihood
> that your WAG won’t be big enough.
>
>
>
> The SA bit logic is designed to allow the restarting router to control
> when the neighbors can safely resume advertising the neighbor to the
> restarting router.
>
> This has addressed problematic cases seen even at low scale in IS-IS
> because IS-IS does not have the equivalent of Exchange state on adjacency
> bringup.
>
> While I agree with Acee that historically this hasn’t been a significant
> issue with OSPF, as IGP scale increases the visibility of this issue
> becomes more likely.
>
>
>
> However, the problem has another aspect i.e., it is important that the
> updated LSA from the neighbor of the restarting router NOT be flooded prior
> to the updated LSA from the restarting router. Otherwise other routers in
> the network may prematurely think that two-way connectivity to the
> restarting router has been restored sooner than it actually has been.
> Neither the draft nor Acee’s alternative explicitly address this point.
> Proper use of the SA bit can address this aspect.
>
>
>
>Les
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, March 27, 2023 3:29 PM
> *To:* Acee Lindem 
> *Cc:* Liyan Gong ; chen.mengxiao <
> chen.mengx...@h3c.com>; Les Ginsberg (ginsberg) ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> *Subject:* Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
>
> thought about it. there are also other solutions to the problem (or rather
> to make it significantly less likely/shorter duration since perfect
> solution given we don't purge DB of an adjacenct router when we lose
> adjacency to it do not exist) such as e.g. choosing seqnr# on startup in a
> way that minimizes the problem (IMO simplest solution but only
> probabilistic).
>
>
>
> Acee's solution is significantly simpler and AFAIS will have roughly same
> behavior as the suggested draft. can be combined iwth the seqnr#
> recommendation (which I probably wouldn't do since large seqnr# on startups
> may trigger bugs in deployed, "not-so-hard-tested" implementations ;-)
>
>
>
> I see Acee's take as benign "over-compliance" to standard as we have it
> ;-) since the current wording does not say you MUST NOT do what he suggests
> ;-)
>
>
>
> -- tony
>
>
>
> On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem  wrote:
>
> Hi Liyan,
>
>
>
> On Mar 27, 2023, a

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Liyan Gong]

 

Hi Les, Tony and Acee,



Appreciate your valuable suggestion. We will update the draft in the next 
version as you suggested, including the title and detailed mechanism.

What Les has elabrated about the SA bit solution in the following email is 
consistent with the idea. Thank you again for the detailed description.

Some additions are as follows:

  Yes, as Les says, this issue becomes more likely as the IGP scale increase 
and can be seen in practice easily.  The key point is that, in OSPF, the LSA 
re-origination and neighbor full are not in definite order.   The larger the 
database, the slower the synchronization. This will delay the lsa 
re-origination for restart router.

 

2.  Also because the LSA re-origination and neighbor full are not in definite 
order,

Using the solution of requesting only router-lsa specially, The following 
result I have mentioned becomes more likely:

Router B  has received the re-originated router lsa of router A, and router 
A both get into the full state. Now A is reachable through spf tree 
calculation.


As a result, the external route is also reachable, since the type 5 lsa has 
not been re-originated. To resolve this, the neighbor router must request 
all the lsas specially, not only router-lsa. That is why I say this solution 
will cause more risk and pressure.   3.  No obvious defect for the IS-IS SA bit 
has been seen in the practical deployment. So, we think it is better to use the 
similar solution for OSPF.










Best Regards,

Liyan





邮件原文发件人："Les Ginsberg \\(ginsberg\\)" 
收件人：Tony Przygienda  
抄　送: Acee Lindem  ,Liyan Gong  
,"chen.mengxiao" ,lsr  
,Weiqiang Cheng ,linchangwang  
发送时间：2023-03-28 10:44:41主题：Re: 
[Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt


Tony -


 




From: Tony Przygienda  Sent: Monday, March 27, 2023 5:11 
PM To: Les Ginsberg (ginsberg) <> Cc: Acee Lindem  Liyan 
Gong  chen.mengxiao  lsr 
 Weiqiang Cheng  linchangwang 
 Subject: Re: [Lsr] 
NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt




 


I didn39t say "bigger", I said "random" -}


[LES:] Ahhh…that makes all the difference. 



 



I tend to agree with SA bit solution though I don39t grok how you can stop 
flooding with that precisely. especially since you cannot rely on sequence of 
hellos and DB sync packets arriving at the receiving node. And SA AFAIR assumes 
LLC  or whatever while Acee39s works on base spec ...



 


[LES:] Step 1: Send SA bit – neighbor continues to send Router LSA with no 
neighbor advertisement to the restarting router


Step 2: Complete LSPDB sync – including Restarting router generating new Router 
LSA w no neighbors


Step 3: Delay to allow updated Router LSA  from Restarting router to be flooded


Step 4: Clear SA bit – neighboring routers can now advertise adjacency to the 
Restarting router


Step 5: Restarting router generates new Router LSA advertising neighbors


 


(To make this “extra reliable”, at Step 3 we can use your “random delay” 
strategy.  )


 


   Les


 



--- tony




 


On Tue, Mar 28, 2023 at 8:04AM Les Ginsberg (ginsberg)  
wrote:



Tony –


 


It seems to me that the larger sequence # solution is less likely to work the 
more you use it. 


In other words, if I restart once a month, each time I need to pick an “even 
bigger sequence #” to account for the starting point of the previous restart.


 


I know that with a 32 bit sequence #, we have decades of updates available, but 
unless you save your most recent sequence # prior to restart you either have to 
make a generous WAG  or risk the increasing likelihood that your WAG won’t be 
big enough.


 


The SA bit logic is designed to allow the restarting router to control when the 
neighbors can safely resume advertising the neighbor to the restarting router.


This has addressed problematic cases seen even at low scale in IS-IS because 
IS-IS does not have the equivalent of Exchange state on adjacency bringup.


While I agree with Acee that historically this hasn’t been a significant issue 
with OSPF, as IGP scale increases the visibility of this issue becomes more 
likely.


 


However, the problem has another aspect i.e., it is important that the updated 
LSA from the neighbor of the restarting router NOT be flooded prior to the 
updated LSA from the restarting  router. Otherwise other routers in the network 
may prematurely think that two-way connectivity to the restarting router has 
been restored sooner than it actually has been. Neither the draft nor Acee’s 
alternative explicitly address this point. Proper use of  the SA bit can 
address this aspect.


 


   Les


 




From: Tony Przygienda  Sent: Monday, March 27, 2023 3:29 
PM To: Acee Lindem  Cc: Liyan Gong 
 chen.mengxiao  Les Ginsberg 
(ginsberg)   lsr  Weiqiang Cheng 
 linchangwang  
Subject: Re: [Lsr] 
NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-0

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Les Ginsberg (ginsberg)]

Tony -

From: Tony Przygienda 
Sent: Monday, March 27, 2023 5:11 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem ; Liyan Gong ; 
chen.mengxiao ; lsr ; Weiqiang Cheng 
; linchangwang 
Subject: Re: [Lsr] 
NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

I didn't say "bigger", I said "random" ;-}
[LES:] Ahhh…that makes all the difference. 

I tend to agree with SA bit solution though I don't grok how you can stop 
flooding with that precisely. especially since you cannot rely on sequence of 
hellos and DB sync packets arriving at the receiving node. And SA AFAIR assumes 
LLC or whatever while Acee's works on base spec ...

[LES:] Step 1: Send SA bit – neighbor continues to send Router LSA with no 
neighbor advertisement to the restarting router
Step 2: Complete LSPDB sync – including Restarting router generating new Router 
LSA w no neighbors
Step 3: Delay to allow updated Router LSA  from Restarting router to be flooded
Step 4: Clear SA bit – neighboring routers can now advertise adjacency to the 
Restarting router
Step 5: Restarting router generates new Router LSA advertising neighbors

(To make this “extra reliable”, at Step 3 we can use your “random delay” 
strategy.  )

   Les

--- tony

On Tue, Mar 28, 2023 at 8:04 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Tony –

It seems to me that the larger sequence # solution is less likely to work the 
more you use it. 
In other words, if I restart once a month, each time I need to pick an “even 
bigger sequence #” to account for the starting point of the previous restart.

I know that with a 32 bit sequence #, we have decades of updates available, but 
unless you save your most recent sequence # prior to restart you either have to 
make a generous WAG or risk the increasing likelihood that your WAG won’t be 
big enough.

The SA bit logic is designed to allow the restarting router to control when the 
neighbors can safely resume advertising the neighbor to the restarting router.
This has addressed problematic cases seen even at low scale in IS-IS because 
IS-IS does not have the equivalent of Exchange state on adjacency bringup.
While I agree with Acee that historically this hasn’t been a significant issue 
with OSPF, as IGP scale increases the visibility of this issue becomes more 
likely.

However, the problem has another aspect i.e., it is important that the updated 
LSA from the neighbor of the restarting router NOT be flooded prior to the 
updated LSA from the restarting router. Otherwise other routers in the network 
may prematurely think that two-way connectivity to the restarting router has 
been restored sooner than it actually has been. Neither the draft nor Acee’s 
alternative explicitly address this point. Proper use of the SA bit can address 
this aspect.

   Les

From: Tony Przygienda mailto:tonysi...@gmail.com>>
Sent: Monday, March 27, 2023 3:29 PM
To: Acee Lindem mailto:acee.i...@gmail.com>>
Cc: Liyan Gong mailto:gongli...@chinamobile.com>>; 
chen.mengxiao mailto:chen.mengx...@h3c.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; lsr 
mailto:lsr@ietf.org>>; Weiqiang Cheng 
mailto:chengweiqi...@chinamobile.com>>; 
linchangwang mailto:linchangwang.04...@h3c.com>>
Subject: Re: [Lsr] 
NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

thought about it. there are also other solutions to the problem (or rather to 
make it significantly less likely/shorter duration since perfect solution given 
we don't purge DB of an adjacenct router when we lose adjacency to it do not 
exist) such as e.g. choosing seqnr# on startup in a way that minimizes the 
problem (IMO simplest solution but only probabilistic).

Acee's solution is significantly simpler and AFAIS will have roughly same 
behavior as the suggested draft. can be combined iwth the seqnr# recommendation 
(which I probably wouldn't do since large seqnr# on startups may trigger bugs 
in deployed, "not-so-hard-tested" implementations ;-)

I see Acee's take as benign "over-compliance" to standard as we have it ;-) 
since the current wording does not say you MUST NOT do what he suggests ;-)

-- tony

On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Hi Liyan,

On Mar 27, 2023, at 06:36, Liyan Gong 
mailto:gongli...@chinamobile.com>> wrote:



Hi Acee,



Thank you for sharing your idea about the draft. Because of the time limitation 
in the meeting, Let‘s continue here.



1. First, About your doubts about the existence of the problem, I would like to 
check whether I have elaborated it clearly through the following email and the 
presentation.



It is a real problem we've actually seen and can be reproduced easily, you 
can actually try it out.
I have no doubt that one could craft a test that would simulate the problem. My 
point was that in practice, the restarting Router-LSA is flooded to it

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

I didn't say "bigger", I said "random" ;-}

I tend to agree with SA bit solution though I don't grok how you can stop
flooding with that precisely. especially since you cannot rely on sequence
of hellos and DB sync packets arriving at the receiving node. And SA AFAIR
assumes LLC or whatever while Acee's works on base spec ...

--- tony

On Tue, Mar 28, 2023 at 8:04 AM Les Ginsberg (ginsberg) 
wrote:

> Tony –
>
>
>
> It seems to me that the larger sequence # solution is less likely to work
> the more you use it. 
>
> In other words, if I restart once a month, each time I need to pick an
> “even bigger sequence #” to account for the starting point of the previous
> restart.
>
>
>
> I know that with a 32 bit sequence #, we have decades of updates
> available, but unless you save your most recent sequence # prior to restart
> you either have to make a generous WAG or risk the increasing likelihood
> that your WAG won’t be big enough.
>
>
>
> The SA bit logic is designed to allow the restarting router to control
> when the neighbors can safely resume advertising the neighbor to the
> restarting router.
>
> This has addressed problematic cases seen even at low scale in IS-IS
> because IS-IS does not have the equivalent of Exchange state on adjacency
> bringup.
>
> While I agree with Acee that historically this hasn’t been a significant
> issue with OSPF, as IGP scale increases the visibility of this issue
> becomes more likely.
>
>
>
> However, the problem has another aspect i.e., it is important that the
> updated LSA from the neighbor of the restarting router NOT be flooded prior
> to the updated LSA from the restarting router. Otherwise other routers in
> the network may prematurely think that two-way connectivity to the
> restarting router has been restored sooner than it actually has been.
> Neither the draft nor Acee’s alternative explicitly address this point.
> Proper use of the SA bit can address this aspect.
>
>
>
>Les
>
>
>
> *From:* Tony Przygienda 
> *Sent:* Monday, March 27, 2023 3:29 PM
> *To:* Acee Lindem 
> *Cc:* Liyan Gong ; chen.mengxiao <
> chen.mengx...@h3c.com>; Les Ginsberg (ginsberg) ; lsr
> ; Weiqiang Cheng ;
> linchangwang 
> *Subject:* Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
>
> thought about it. there are also other solutions to the problem (or rather
> to make it significantly less likely/shorter duration since perfect
> solution given we don't purge DB of an adjacenct router when we lose
> adjacency to it do not exist) such as e.g. choosing seqnr# on startup in a
> way that minimizes the problem (IMO simplest solution but only
> probabilistic).
>
>
>
> Acee's solution is significantly simpler and AFAIS will have roughly same
> behavior as the suggested draft. can be combined iwth the seqnr#
> recommendation (which I probably wouldn't do since large seqnr# on startups
> may trigger bugs in deployed, "not-so-hard-tested" implementations ;-)
>
>
>
> I see Acee's take as benign "over-compliance" to standard as we have it
> ;-) since the current wording does not say you MUST NOT do what he suggests
> ;-)
>
>
>
> -- tony
>
>
>
> On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem  wrote:
>
> Hi Liyan,
>
>
>
> On Mar 27, 2023, at 06:36, Liyan Gong  wrote:
>
>
>
>
>
> Hi Acee,
>
>
>
> Thank you for sharing your idea about the draft. Because of the time
> limitation in the meeting, Let‘s continue here.
>
>
>
>
>
> 1. First, About your doubts about the existence of the problem, I would
> like to check whether I have elaborated it clearly through the following
> email and the presentation.
>
>
>
> It is a real problem we've actually seen and can be reproduced easily,
> you can actually try it out.
>
> I have no doubt that one could craft a test that would simulate the
> problem. My point was that in practice, the restarting Router-LSA is
> flooded to its neighbors during the restart and will be accepted by any
> neighbors in Exchange State or better.
>
>
>
>
>
>
>
> 2. About your proposed solution, we would like to share our comments.
>
>
>
> (1) Your solution does not work for other type of lsa except
> router-lsa. The blackhole still occurs for other type route.
>
>
>
> For example, Router B  has received the re-originated router lsa
> of router A, and router A both get into the full state. Now A is
> reachable through spf tree calculation.
>
> As a result, the external route is also reachable, since the type
> 5 lsa has not been re-originated.
>
>

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Les Ginsberg (ginsberg)]

Tony –

It seems to me that the larger sequence # solution is less likely to work the 
more you use it. 
In other words, if I restart once a month, each time I need to pick an “even 
bigger sequence #” to account for the starting point of the previous restart.

I know that with a 32 bit sequence #, we have decades of updates available, but 
unless you save your most recent sequence # prior to restart you either have to 
make a generous WAG or risk the increasing likelihood that your WAG won’t be 
big enough.

The SA bit logic is designed to allow the restarting router to control when the 
neighbors can safely resume advertising the neighbor to the restarting router.
This has addressed problematic cases seen even at low scale in IS-IS because 
IS-IS does not have the equivalent of Exchange state on adjacency bringup.
While I agree with Acee that historically this hasn’t been a significant issue 
with OSPF, as IGP scale increases the visibility of this issue becomes more 
likely.

However, the problem has another aspect i.e., it is important that the updated 
LSA from the neighbor of the restarting router NOT be flooded prior to the 
updated LSA from the restarting router. Otherwise other routers in the network 
may prematurely think that two-way connectivity to the restarting router has 
been restored sooner than it actually has been. Neither the draft nor Acee’s 
alternative explicitly address this point. Proper use of the SA bit can address 
this aspect.

   Les

From: Tony Przygienda 
Sent: Monday, March 27, 2023 3:29 PM
To: Acee Lindem 
Cc: Liyan Gong ; chen.mengxiao 
; Les Ginsberg (ginsberg) ; lsr 
; Weiqiang Cheng ; linchangwang 

Subject: Re: [Lsr] 
NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

thought about it. there are also other solutions to the problem (or rather to 
make it significantly less likely/shorter duration since perfect solution given 
we don't purge DB of an adjacenct router when we lose adjacency to it do not 
exist) such as e.g. choosing seqnr# on startup in a way that minimizes the 
problem (IMO simplest solution but only probabilistic).

Acee's solution is significantly simpler and AFAIS will have roughly same 
behavior as the suggested draft. can be combined iwth the seqnr# recommendation 
(which I probably wouldn't do since large seqnr# on startups may trigger bugs 
in deployed, "not-so-hard-tested" implementations ;-)

I see Acee's take as benign "over-compliance" to standard as we have it ;-) 
since the current wording does not say you MUST NOT do what he suggests ;-)

-- tony

On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Hi Liyan,


On Mar 27, 2023, at 06:36, Liyan Gong 
mailto:gongli...@chinamobile.com>> wrote:



Hi Acee,



Thank you for sharing your idea about the draft. Because of the time limitation 
in the meeting, Let‘s continue here.



1. First, About your doubts about the existence of the problem, I would like to 
check whether I have elaborated it clearly through the following email and the 
presentation.



It is a real problem we've actually seen and can be reproduced easily, you 
can actually try it out.
I have no doubt that one could craft a test that would simulate the problem. My 
point was that in practice, the restarting Router-LSA is flooded to its 
neighbors during the restart and will be accepted by any neighbors in Exchange 
State or better.






2. About your proposed solution, we would like to share our comments.



(1) Your solution does not work for other type of lsa except router-lsa. 
The blackhole still occurs for other type route.



For example, Router B  has received the re-originated router lsa of 
router A, and router A both get into the full state. Now A is reachable 
through spf tree calculation.

As a result, the external route is also reachable, since the type 5 lsa 
has not been re-originated.

I don’t think this can happen. Once both router A get into full sate, Router 
A will have requested and received all its stale (i.e., pre-restart LSAs) from 
Router A and will have either refreshed or purged them based it current state.





(2) Your solution can be classified into the solution 2) mentioned in our 
presentation and more complicated.

  It is a larger modification to the basic ospf protocol, equivalent to 
abandon the action of DD exchange. It will cause more risk and pressure for all 
the routers in the network.
I disagree strongly that my solution is more complicated, it only add the 
Router-LSA to the link state request list. I don’t see how this could be judged 
more complex than using an independent hand-shake involved. OSPF Hello to keep 
Router B from forming an adjacency. BTW, the use case(s) and precisely how the 
mechanism will be used was specified in the slides but not the draft. The draft 
only says:

   With the proposed mechanism, the starting router's

   neighbors will s

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda]

thought about it. there are also other solutions to the problem (or rather
to make it significantly less likely/shorter duration since perfect
solution given we don't purge DB of an adjacenct router when we lose
adjacency to it do not exist) such as e.g. choosing seqnr# on startup in a
way that minimizes the problem (IMO simplest solution but only
probabilistic).

Acee's solution is significantly simpler and AFAIS will have roughly same
behavior as the suggested draft. can be combined iwth the seqnr#
recommendation (which I probably wouldn't do since large seqnr# on startups
may trigger bugs in deployed, "not-so-hard-tested" implementations ;-)

I see Acee's take as benign "over-compliance" to standard as we have it ;-)
since the current wording does not say you MUST NOT do what he suggests ;-)

-- tony

On Tue, Mar 28, 2023 at 1:45 AM Acee Lindem  wrote:

> Hi Liyan,
>
> On Mar 27, 2023, at 06:36, Liyan Gong  wrote:
>
>
> Hi Acee,
>
>
> Thank you for sharing your idea about the draft. Because of the time
> limitation in the meeting, Let‘s continue here.
>
>
>
> 1. First, About your doubts about the existence of the problem, I would
> like to check whether I have elaborated it clearly through the following
> email and the presentation.
>
>
> It is a real problem we've actually seen and can be reproduced easily,
> you can actually try it out.
>
> I have no doubt that one could craft a test that would simulate the
> problem. My point was that in practice, the restarting Router-LSA is
> flooded to its neighbors during the restart and will be accepted by any
> neighbors in Exchange State or better.
>
>
>
> 2. About your proposed solution, we would like to share our comments.
>
>
> (1) Your solution does not work for other type of lsa except
> router-lsa. The blackhole still occurs for other type route.
>
>
> For example, Router B  has received the re-originated router lsa
> of router A, and router A both get into the full state. Now A is
> reachable through spf tree calculation.
>
> As a result, the external route is also reachable, since the type
> 5 lsa has not been re-originated.
>
>
> I don’t think this can happen. Once both router A get into full sate,
> Router A will have requested and received all its stale (i.e., pre-restart
> LSAs) from Router A and will have either refreshed or purged them based it
> current state.
>
>
> (2) Your solution can be classified into the solution 2) mentioned in
> our presentation and more complicated.
>
>   It is a larger modification to the basic ospf protocol, equivalent
> to abandon the action of DD exchange. It will cause more risk and
> pressure for all the routers in the network.
>
> I disagree strongly that my solution is more complicated, it only add the
> Router-LSA to the link state request list. I don’t see how this could be
> judged more complex than using an independent hand-shake involved. OSPF
> Hello to keep Router B from forming an adjacency. BTW, the use case(s) and
> precisely how the mechanism will be used was specified in the slides but
> not the draft. The draft only says:
>
>With the proposed mechanism, the starting router's
>
>neighbors will suppress advertising an adjacency to the starting
>router until the starting router has been able to propagate newer
>
> versions of LSAs, so that the temporary blackholes can be avoided.
>
> I’m not saying this should be normative text, just a better example of
> how the mechanism would be used.
>
> Also, if you do republish, please include the WG in the draft name so it
> can easily be found, i.e., draft-cheng-lsr-ospf-adjacency-suppress-00
>
>
> Thanks,
> Acee
>
>
>
> Hope to get your opinion, Thanks.
>
>
> Best Regards,
>
> Liyan
>
>
> 邮件原文----
> *发件人：*Liyan Gong  
> *收件人：*"acee.ietf" 
> *抄 送: *"chen.mengxiao" ,Les Ginsberg  <
> ginsb...@cisco.com>,lsr  ,Weiqiang Cheng  <
> chengweiqi...@chinamobile.com>,linchangwang  
> *发送时间：*2023-03-09 11:27:58
> *主题：*
> Re: [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
> Hi Acee,
>
>
> Yes,it is a real problem we've actually seen.
>
>
> Especially when the neighbor Rouer B has many more LSAs than the Restart
> Router A.
>
>
> In this scenario, the time between the following two key points will be
> prolonged greatly.
>
>
> Further discussion is welcome, thanks a lot.
>
>
> Best Regards,
>
> Liyan
>
>
>
>
> 邮件原文
> *发件人：*Acee Lindem  
> *收件人：*Liyan Gong  
> *抄 送: *"Mengxiao.Chen" ,Les Ginsberg  <
> ginsb...@cisco.com>,lsr  ,Weiqiang 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Liyan, 

> On Mar 27, 2023, at 06:36, Liyan Gong  wrote:
> 
> 
> Hi Acee,
> 
> 
> 
> Thank you for sharing your idea about the draft. Because of the time 
> limitation in the meeting, Let‘s continue here.
> 
> 
>  
> 1. First, About your doubts about the existence of the problem, I would like 
> to check whether I have elaborated it clearly through the following email and 
> the presentation.
> 
> 
> 
> It is a real problem we've actually seen and can be reproduced easily, 
> you can actually try it out.
> 
I have no doubt that one could craft a test that would simulate the problem. My 
point was that in practice, the restarting Router-LSA is flooded to its 
neighbors during the restart and will be accepted by any neighbors in Exchange 
State or better. 


> 
> 2. About your proposed solution, we would like to share our comments.
> 
> 
> 
> (1) Your solution does not work for other type of lsa except router-lsa. 
> The blackhole still occurs for other type route.
> 
> 
> 
> For example, Router B  has received the re-originated router lsa of 
> router A, and router A both get into the full state. Now A is reachable 
> through spf tree calculation.
> 
> As a result, the external route is also reachable, since the type 5 
> lsa has not been re-originated.
> 

I don’t think this can happen. Once both router A get into full sate, Router 
A will have requested and received all its stale (i.e., pre-restart LSAs) from 
Router A and will have either refreshed or purged them based it current state. 

> 
> (2) Your solution can be classified into the solution 2) mentioned in our 
> presentation and more complicated.  
> 
>   It is a larger modification to the basic ospf protocol, equivalent 
> to abandon the action of DD exchange. It will cause more risk and pressure 
> for all the routers in the network.
> 
I disagree strongly that my solution is more complicated, it only add the 
Router-LSA to the link state request list. I don’t see how this could be judged 
more complex than using an independent hand-shake involved. OSPF Hello to keep 
Router B from forming an adjacency. BTW, the use case(s) and precisely how the 
mechanism will be used was specified in the slides but not the draft. The draft 
only says:

   With the proposed mechanism, the starting router's
   neighbors will suppress advertising an adjacency to the starting
   router until the starting router has been able to propagate newer 
   versions of LSAs, so that the temporary blackholes can be avoided.

I’m not saying this should be normative text, just a better example of how the 
mechanism would be used.

Also, if you do republish, please include the WG in the draft name so it can 
easily be found, i.e., draft-cheng-lsr-ospf-adjacency-suppress-00 


Thanks,
Acee


> 
> Hope to get your opinion, Thanks.
> 
> 
> 
> Best Regards,
> 
> Liyan
> 
> 
> 
> ----邮件原文
> 发件人：Liyan Gong  
> 收件人："acee.ietf" 
> 抄　送: "chen.mengxiao" ,Les Ginsberg  
> ,lsr  ,Weiqiang Cheng  
> ,linchangwang  
> 发送时间：2023-03-09 11:27:58
> 主题：Re: 
> [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
> 
> Hi Acee,
> 
> 
> 
> Yes,it is a real problem we've actually seen. 
> 
> 
> 
> Especially when the neighbor Rouer B has many more LSAs than the Restart 
> Router A.
> 
> 
> 
> In this scenario, the time between the following two key points will be 
> prolonged greatly.
> 
> 
> 
> Further discussion is welcome, thanks a lot.
> 
> 
> 
> Best Regards,
> 
> Liyan
> 
> 
> 
> 
> 
> 
> 
> 邮件原文
> 发件人：Acee Lindem  
> 收件人：Liyan Gong  
> 抄　送: "Mengxiao.Chen" ,Les Ginsberg  
> ,lsr  ,Weiqiang Cheng  
> ,linchangwang  
> 发送时间：2023-03-08 02:34:17
> 主题：Re: [Lsr] New 
> VersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
> 
> Hi Liyan, 
> 
> This is very unlikely to happen as flooding between the routers commences as 
> soon as they reach Exchange state. I’m wondering if you’ve actually seen this 
> situation or it is hypothetical. 
> 
> In any case, I have a better solution which wouldn’t add the delay for the 
> next hello packet without the SA flag to be received before advertising the 
> link. I’m busy with some other things right now and want to think about it 
> more.
> 
> For now, we will add your presentation to the list for IETF 116.
> 
> Thanks,
> Acee   
> 
> 
> 
> > On Mar 7, 2023, at 3:54 AM, Liyan Gong  wrote:
> > 
> > 
> > Hi Les and Acee,
> > 
> > Let me explain it further through the following diagram.
> > 
> > 1) The neighbor relationship between R

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Liyan Gong]

Hi Acee,



Thank you for sharing your idea about the draft. Because of the time limitation 
in the meeting, Let‘s continue here.





 


1. First, About your doubts about the existence of the problem, I would like to 
check whether I have elaborated it clearly through the following email and the 
presentation.





It is a real problem we39ve actually seen and can be reproduced easily, you 
can actually try it out. 





2. About your proposed solution, we would like to share our comments. 





(1) Your solution does not work for other type of lsa except router-lsa. 
The blackhole still occurs for other type route.





For example, Router B  has received the re-originated router lsa of 
router A, and router A both get into the full state. Now A is reachable 
through spf tree calculation.


As a result, the external route is also reachable, since the type 5 lsa 
has not been re-originated. 





(2) Your solution can be classified into the solution 2) mentioned in our 
presentation and more complicated.  


  It is a larger modification to the basic ospf protocol, equivalent to 
abandon the action of DD exchange. It will cause more risk and pressure for all 
the routers in the network.





Hope to get your opinion, Thanks.





Best Regards,


Liyan







邮件原文发件人：Liyan Gong  收件人："acee.ietf" 
抄　送: "chen.mengxiao" ,Les Ginsberg  
,lsr  ,Weiqiang Cheng  
,linchangwang  
发送时间：2023-03-09 11:27:58主题：Re: 
[Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txtHi Acee,



Yes,it is a real problem we39ve actually seen. 



Especially when the neighbor Rouer B has many more LSAs than the Restart Router 
A.



In this scenario, the time between the following two key points will be 
prolonged greatly.



Further discussion is welcome, thanks a lot.



Best Regards,

Liyan







邮件原文发件人：Acee Lindem  收件人：Liyan Gong  
抄　送: "Mengxiao.Chen" ,Les 
Ginsberg  ,lsr  ,Weiqiang Cheng  
,linchangwang  
发送时间：2023-03-08 02:34:17主题：Re: [Lsr] New 
VersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txtHi Liyan, This 
is very unlikely to happen as flooding between the routers commences as soon as 
they reach Exchange state. I’m wondering if you’ve actually seen this situation 
or it is hypothetical. In any case, I have a better solution which wouldn’t add 
the delay for the next hello packet without the SA flag to be received before 
advertising the link. I’m busy with some other things right now and want to 
think about it more.For now, we will add your presentation to the list for IETF 
116.Thanks,Acee   > On Mar 7, 2023, at 3:54 AM, Liyan Gong  wrote:> > > Hi Les 
and Acee,> > Let me explain it further through the following diagram.> > 1) The 
neighbor relationship between Router A and Router B is stable. The route 
10.1.1.1/32 is reachable.  > 2）Router A unplanned restarts and the loopback 
address has been deleted.The process of the neighbor establish is as follows.> 
3）The temporary blackhole occurs during the time range stated in the right 
brace.> > There are two key points:> 1)Neighbor router reached the full state 
earlier.> 2)Neighbor router received the reoriginated lsas late.> > So,this 
purpose of the draft is to delay the point 1).> > Hope this helps,thank you. > 
> <1.png>> > Best Regards,> Liyan> > > 邮件原文> 发件人："Mengxiao.Chen" > 
收件人："Les Ginsberg (ginsberg)" ,AceeLindem ,Liyan Gong  > 抄　送: lsr  ,Weiqiang 
Cheng  ,linchangwang  > 发送时间：2023-03-07 15:19:59> 主题：Re: [Lsr] New Version 
Notification fordraft-cheng-ospf-adjacency-suppress-00.txt> > Hi Les,> > Thank 
you for your comments.> OSPF does include the LSDB sync requirement. But OSPF 
state machine does not guarantee the two routers attain FULL state at the same 
time.> > R1(restart)--R2--R3> > R1 LSDB: R139s new router-LSA, seq 
8001> R2 LSDB: R139s old router-LSA, seq 8500> > When R1 restarts from 
an unplanned outage, R1 will reinitialize its LSA sequence number. But R2 has 
the previous copies of R139s LSA, which has larger sequence number.> R2 thinks 
its local LSAs are "newer". So, R2 will attain FULL state, without requesting 
R1 to update.> This may cause temporary blackholes to occur until R1 
regenerates and floods its own LSAs with higher sequence numbers.> > Thanks,> 
Mengxiao> > -Original Message-> From: Lsr  On Behalf Of Les Ginsberg 
(ginsberg)> Sent: Tuesday, March 7, 2023 1:29 AM> To: Acee Lindem  Liyan Gong > 
Cc: lsr > Subject: Re: [Lsr] New Version Notification for 
draft-cheng-ospf-adjacency-suppress-00.txt> > +1 to what Acee has said.> > As 
historical context, the SA bit was defined in IS-IS precisely because IS-IS 
adjacency state machine does NOT include LSPDB sync as a requirement before the 
adjacency is usable (unlike OSPF).> OSPF does not need SA bit.> >Les> > > 
-Original Message-> > From: Lsr  On Behalf Of Acee Lindem> > Sent: 
Monday, March 6, 2023 8:01 AM> > To: Liyan Gong > > Cc: lsr > > Subject: Re: 

Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Liyan Gong]

Hi Acee,



Yes,it is a real problem we39ve actually seen. 



Especially when the neighbor Rouer B has many more LSAs than the Restart Router 
A.



In this scenario, the time between the following two key points will be 
prolonged greatly.



Further discussion is welcome, thanks a lot.



Best Regards,

Liyan







邮件原文发件人：Acee Lindem  收件人：Liyan Gong  
抄　送: "Mengxiao.Chen" ,Les 
Ginsberg  ,lsr  ,Weiqiang Cheng  
,linchangwang  
发送时间：2023-03-08 02:34:17主题：Re: [Lsr] New 
VersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txtHi Liyan, This 
is very unlikely to happen as flooding between the routers commences as soon as 
they reach Exchange state. I’m wondering if you’ve actually seen this situation 
or it is hypothetical. In any case, I have a better solution which wouldn’t add 
the delay for the next hello packet without the SA flag to be received before 
advertising the link. I’m busy with some other things right now and want to 
think about it more.For now, we will add your presentation to the list for IETF 
116.Thanks,Acee   > On Mar 7, 2023, at 3:54 AM, Liyan Gong  wrote:> > > Hi Les 
and Acee,> > Let me explain it further through the following diagram.> > 1) The 
neighbor relationship between Router A and Router B is stable. The route 
10.1.1.1/32 is reachable.  > 2）Router A unplanned restarts and the loopback 
address has been deleted.The process of the neighbor establish is as follows.> 
3）The temporary blackhole occurs during the time range stated in the right 
brace.> > There are two key points:> 1)Neighbor router reached the full state 
earlier.> 2)Neighbor router received the reoriginated lsas late.> > So,this 
purpose of the draft is to delay the point 1).> > Hope this helps,thank you. > 
> <1.png>> > Best Regards,> Liyan> > > 邮件原文> 发件人："Mengxiao.Chen" > 
收件人："Les Ginsberg (ginsberg)" ,AceeLindem ,Liyan Gong  > 抄　送: lsr  ,Weiqiang 
Cheng  ,linchangwang  > 发送时间：2023-03-07 15:19:59> 主题：Re: [Lsr] New Version 
Notification fordraft-cheng-ospf-adjacency-suppress-00.txt> > Hi Les,> > Thank 
you for your comments.> OSPF does include the LSDB sync requirement. But OSPF 
state machine does not guarantee the two routers attain FULL state at the same 
time.> > R1(restart)--R2--R3> > R1 LSDB: R139s new router-LSA, seq 
8001> R2 LSDB: R139s old router-LSA, seq 8500> > When R1 restarts from 
an unplanned outage, R1 will reinitialize its LSA sequence number. But R2 has 
the previous copies of R139s LSA, which has larger sequence number.> R2 thinks 
its local LSAs are "newer". So, R2 will attain FULL state, without requesting 
R1 to update.> This may cause temporary blackholes to occur until R1 
regenerates and floods its own LSAs with higher sequence numbers.> > Thanks,> 
Mengxiao> > -Original Message-> From: Lsr  On Behalf Of Les Ginsberg 
(ginsberg)> Sent: Tuesday, March 7, 2023 1:29 AM> To: Acee Lindem  Liyan Gong > 
Cc: lsr > Subject: Re: [Lsr] New Version Notification for 
draft-cheng-ospf-adjacency-suppress-00.txt> > +1 to what Acee has said.> > As 
historical context, the SA bit was defined in IS-IS precisely because IS-IS 
adjacency state machine does NOT include LSPDB sync as a requirement before the 
adjacency is usable (unlike OSPF).> OSPF does not need SA bit.> >Les> > > 
-Original Message-> > From: Lsr  On Behalf Of Acee Lindem> > Sent: 
Monday, March 6, 2023 8:01 AM> > To: Liyan Gong > > Cc: lsr > > Subject: Re: 
[Lsr] New Version Notification for draft-cheng-ospf-adjacency-> > 
suppress-00.txt> >> > Hi Liyan,> >> > I should replied to this Email rather 
than your request for an IETF 116 slot.> > Please reply to this one.> >> > I’m 
sorry but I don’t get this draft from a quick read. An OSPF router would> > not 
advertise an adjacency until the router is in FULL state. An OSPF router> > 
will not attain FULL state until database synchronization is complete.> > The 
following statement from you use case is incorrect:> >> > So, without 
requesting the starting router to update its LSAs, the> > neighbors of the 
starting router may transition to "Full" state and> > route the traffic 
through the starting router.> >> > Why do you think you need this extension?> 
>> >> > Thanks,> > Acee> >> >> > > On Mar 6, 2023, at 9:10 AM, Liyan Gong > > 
wrote:> > >> > > Dear All,> > > We have posted a new draft 
https://datatracker.ietf.org/doc/draft-cheng-> > ospf-adjacency-suppress/.> > > 
This draft describes the extension of OSPF LLS to signal adjacency> > 
suppression which is functionally similar to the SA bit of Restart TLV in 
IS-IS.> > > The purpose is to avoid the temporary blackhole when a router 
restarts> > from unplanned outages.> > > We are looing forward to your 
comments.Thanks a lot.> > >> > > Best Regards,> > > Liyan> > >> > > 
邮件原文> > > 发件人：internet-drafts > > > 收件人：Changwang Lin ,Liyan Gong> > 
,Mengxiao Chen> > ,Weiqiang Cheng> > > > > 抄　送: (无)> > > 发送时间：2023-03-06 
17:43:39> > > 主题：New Version Notification