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 <[email protected]> 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> > <image.png> > Best Regards, > Liyan > > > ----邮件原文---- > 发件人："Mengxiao.Chen" <[email protected]> > 收件人："Les Ginsberg (ginsberg)" > <[email protected]>,AceeLindem <[email protected]>,Liyan > Gong <[email protected]> > 抄 送: lsr <[email protected]>,Weiqiang Cheng > <[email protected]>,linchangwang <[email protected]> > 发送时间：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: R1's new router-LSA, seq 80000001 > R2 LSDB: R1's old router-LSA, seq 80000500 > > When R1 restarts from an unplanned outage, R1 will reinitialize its LSA > sequence number. But R2 has the previous copies of R1's 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 <[email protected]> On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, March 7, 2023 1:29 AM > To: Acee Lindem <[email protected]>; Liyan Gong <[email protected]> > Cc: lsr <[email protected]> > 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 <[email protected]> On Behalf Of Acee Lindem > > Sent: Monday, March 6, 2023 8:01 AM > > To: Liyan Gong <[email protected]> > > Cc: lsr <[email protected]> > > 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 <[email protected]> > > 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 <[email protected]> > > > 收件人：Changwang Lin <[email protected]>,Liyan Gong > > <[email protected]>,Mengxiao Chen > > <[email protected]>,Weiqiang Cheng > > <[email protected]> > > > 抄 送: (无) > > > 发送时间：2023-03-06 17:43:39 > > > 主题：New Version Notification for draft-cheng-ospf-adjacency-suppress- > > 00.txt > > > > > > > > > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt > > > has been successfully submitted by Mengxiao Chen and posted to the > > > IETF repository. > > > > > > Name: draft-cheng-ospf-adjacency-suppress > > > Revision: 00 > > > Title: OSPF Adjacency Suppression > > > Document date: 2023-03-06 > > > Group: Individual Submission > > > Pages: 8 > > > URL: > > > https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency- > > suppress-00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency- > > suppress/ > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-ospf- > > adjacency-suppress > > > > > > > > > Abstract: > > > This document describes a mechanism for a router to signal its > > > neighbors to suppress advertising the adjacency to it until link- > > > state database synchronization is complete. This minimizes transient > > > routing disruption when a router restarts from unplanned outages. > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > > > Subject：New Version Notification for draft-cheng-ospf-adjacency- > > suppress-00.txt > > > > > > > > > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt > > > has been successfully submitted by Mengxiao Chen and posted to the > > > IETF repository. > > > > > > Name: draft-cheng-ospf-adjacency-suppress > > > Revision: 00 > > > Title: OSPF Adjacency Suppression > > > Document date: 2023-03-06 > > > Group: Individual Submission > > > Pages: 8 > > > URL: > > > https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency- > > suppress-00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency- > > suppress/ > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-ospf- > > adjacency-suppress > > > > > > > > > Abstract: > > > This document describes a mechanism for a router to signal its > > > neighbors to suppress advertising the adjacency to it until link- > > > state database synchronization is complete. This minimizes transient > > > routing disruption when a router restarts from unplanned outages. > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > This e-mail and its attachments contain confidential information from New > H3C, which is > intended only for the person or entity whose address is listed above. Any use > of the > information contained herein in any way (including, but not limited to, total > or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender > by phone or email immediately and delete it! > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > Subject：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: R1's new router-LSA, seq 80000001 > R2 LSDB: R1's old router-LSA, seq 80000500 > > When R1 restarts from an unplanned outage, R1 will reinitialize its LSA > sequence number. But R2 has the previous copies of R1's 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 <[email protected]> On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, March 7, 2023 1:29 AM > To: Acee Lindem <[email protected]>; Liyan Gong <[email protected]> > Cc: lsr <[email protected]> > 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 <[email protected]> On Behalf Of Acee Lindem > > Sent: Monday, March 6, 2023 8:01 AM > > To: Liyan Gong <[email protected]> > > Cc: lsr <[email protected]> > > 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 <[email protected]> > > 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 <[email protected]> > > > 收件人：Changwang Lin <[email protected]>,Liyan Gong > > <[email protected]>,Mengxiao Chen > > <[email protected]>,Weiqiang Cheng > > <[email protected]> > > > 抄 送: (无) > > > 发送时间：2023-03-06 17:43:39 > > > 主题：New Version Notification for draft-cheng-ospf-adjacency-suppress- > > 00.txt > > > > > > > > > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt > > > has been successfully submitted by Mengxiao Chen and posted to the > > > IETF repository. > > > > > > Name: draft-cheng-ospf-adjacency-suppress > > > Revision: 00 > > > Title: OSPF Adjacency Suppression > > > Document date: 2023-03-06 > > > Group: Individual Submission > > > Pages: 8 > > > URL: > > > https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency- > > suppress-00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency- > > suppress/ > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-ospf- > > adjacency-suppress > > > > > > > > > Abstract: > > > This document describes a mechanism for a router to signal its > > > neighbors to suppress advertising the adjacency to it until link- > > > state database synchronization is complete. This minimizes transient > > > routing disruption when a router restarts from unplanned outages. > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > > > Subject：New Version Notification for draft-cheng-ospf-adjacency- > > suppress-00.txt > > > > > > > > > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt > > > has been successfully submitted by Mengxiao Chen and posted to the > > > IETF repository. > > > > > > Name: draft-cheng-ospf-adjacency-suppress > > > Revision: 00 > > > Title: OSPF Adjacency Suppression > > > Document date: 2023-03-06 > > > Group: Individual Submission > > > Pages: 8 > > > URL: > > > https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency- > > suppress-00.txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency- > > suppress/ > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-ospf- > > adjacency-suppress > > > > > > > > > Abstract: > > > This document describes a mechanism for a router to signal its > > > neighbors to suppress advertising the adjacency to it until link- > > > state database synchronization is complete. This minimizes transient > > > routing disruption when a router restarts from unplanned outages. > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > This e-mail and its attachments contain confidential information from New > H3C, which is > intended only for the person or entity whose address is listed above. Any use > of the > information contained herein in any way (including, but not limited to, total > or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender > by phone or email immediately and delete it! > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
