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 <[email protected]> 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&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. > > 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:[email protected]> > > Best Regards, > > Liyan > > > > > ----邮件原文---- > 发件人："Les Ginsberg \\(ginsberg\\)" <[email protected] > <mailto:[email protected]>> > 收件人：Tony Przygienda <[email protected] <mailto:[email protected]>> > 抄 送: Acee Lindem <[email protected] <mailto:[email protected]>>,Liyan > Gong <[email protected] > <mailto:[email protected]>>,"chen.mengxiao" <[email protected] > <mailto:[email protected]>>,lsr <[email protected] > <mailto:[email protected]>>,Weiqiang Cheng <[email protected] > <mailto:[email protected]>>,linchangwang > <[email protected] <mailto:[email protected]>> > 发送时间：2023-03-28 10:44:41 > 主题：Re: > [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt > > > Tony - > > From: Tony Przygienda <[email protected]> > Sent: Monday, March 27, 2023 5:11 PM > To: Les Ginsberg (ginsberg) <> > 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:04AM Les Ginsberg (ginsberg) <[email protected] > <mailto:[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] <mailto:[email protected]>> > Sent: Monday, March 27, 2023 3:29 PM > To: Acee Lindem <[email protected] <mailto:[email protected]>> > Cc: Liyan Gong <[email protected] > <mailto:[email protected]>>; chen.mengxiao <[email protected] > <mailto:[email protected]>>; Les Ginsberg (ginsberg) <[email protected] > <mailto:[email protected]>>; lsr <[email protected] <mailto:[email protected]>>; > Weiqiang Cheng <[email protected] > <mailto:[email protected]>>; linchangwang > <[email protected] <mailto:[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:45AM Acee Lindem <[email protected] > <mailto:[email protected]>> wrote: > Hi Liyan, > > On Mar 27, 2023, at 06:36, Liyan Gong <[email protected] > <mailto:[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] <mailto:[email protected]>> > 收件人："acee.ietf" <[email protected] <mailto:[email protected]>> > 抄 送: "chen.mengxiao" <[email protected] > <mailto:[email protected]>>,Les Ginsberg <[email protected] > <mailto:[email protected]>>,lsr <[email protected] > <mailto:[email protected]>>,Weiqiang Cheng <[email protected] > <mailto:[email protected]>>,linchangwang > <[email protected] <mailto:[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] <mailto:[email protected]>> > 收件人：Liyan Gong <[email protected] <mailto:[email protected]>> > 抄 送: "Mengxiao.Chen" <[email protected] > <mailto:[email protected]>>,Les Ginsberg <[email protected] > <mailto:[email protected]>>,lsr <[email protected] > <mailto:[email protected]>>,Weiqiang Cheng <[email protected] > <mailto:[email protected]>>,linchangwang > <[email protected] <mailto:[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 <http://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] <mailto:[email protected]> > > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] <mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > > Lsr mailing list > > [email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]> > > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] <mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > > Lsr mailing list > > [email protected] <mailto:[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] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
