Hi Yinzhen, I would like 5 minutes to present an alternative solution. The presentation should immediately follow this presentation as the hypothetical problem will have already have been presented.
There isn’t a draft yet as I’m not sure this problem really needs to be solved. Thanks, Acee > On Mar 7, 2023, at 1:34 PM, Acee Lindem <[email protected]> wrote: > > 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
