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) <[email protected]> wrote: > Tony - > > > > *From:* Tony Przygienda <[email protected]> > *Sent:* Monday, March 27, 2023 5:11 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Acee Lindem <[email protected]>; Liyan Gong < > [email protected]>; chen.mengxiao <[email protected]>; lsr < > [email protected]>; Weiqiang Cheng <[email protected]>; > linchangwang <[email protected]> > *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) < > [email protected]> 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 <[email protected]> > *Sent:* Monday, March 27, 2023 3:29 PM > *To:* Acee Lindem <[email protected]> > *Cc:* Liyan Gong <[email protected]>; chen.mengxiao < > [email protected]>; Les Ginsberg (ginsberg) <[email protected]>; lsr > <[email protected]>; Weiqiang Cheng <[email protected]>; > linchangwang <[email protected]> > *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 <[email protected]> wrote: > > Hi Liyan, > > > > On Mar 27, 2023, at 06:36, Liyan Gong <[email protected]> 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&B 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&B 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 <[email protected]> > *收件人：*"acee.ietf" <[email protected]> > *抄 送**: *"chen.mengxiao" <[email protected]>,Les Ginsberg < > [email protected]>,lsr <[email protected]>,Weiqiang Cheng < > [email protected]>,linchangwang <[email protected]> > *发送时间：*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 <[email protected]> > *收件人：*Liyan Gong <[email protected]> > *抄 送**: *"Mengxiao.Chen" <[email protected]>,Les Ginsberg < > [email protected]>,lsr <[email protected]>,Weiqiang Cheng < > [email protected]>,linchangwang <[email protected]> > *发送时间：*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 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: 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 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 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 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 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 > > > > > > _______________________________________________ > 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
