Noted. will add it to the agenda. Thanks, Yingzhen
On Mon, Mar 13, 2023 at 1:06 PM Acee Lindem <[email protected]> wrote: > 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
