Hi Les, > On Mar 28, 2023, at 20:53, Les Ginsberg (ginsberg) <[email protected]> wrote: > > Acee - > > So your proposal is to have the neighbor of the restarting router be > responsible for ensuring that the Router LSA updates are done in the proper > order. > I agree this can work as well. > > I still think there is one element missing from your proposal i.e., > guaranteeing that the Router LSA update from the restarting router is flooded > before (or at least in the same Link State Update packet) as the updated > Router LSA from the neighbor - and that this order is maintained at each > flooding hop throughout the network. > This is likely to happen - but without some delay between flooding the > updated Router LSA from the restarting router and the updated Router LSA on > the neighbor there is still some risk.
See my response to Liyan. If we leave the Router-LSA on the neighbor’s Link State Request list when a less recent version is received, the adjacency will not go to full until the more-recent version is received. This will handle case where the restarting router’s Router-LSA is the last or only element in the list. Thanks, Acee > > Les > >> -----Original Message----- >> From: Acee Lindem <[email protected]> >> Sent: Tuesday, March 28, 2023 2:19 PM >> To: Les Ginsberg (ginsberg) <[email protected]> >> Cc: Liyan Gong <[email protected]>; Tony Przygienda >> <[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 >> >> Hi Les >> >>> On Mar 28, 2023, at 4:44 PM, Les Ginsberg (ginsberg) >> <[email protected]> wrote: >>> >>> (For some reason, email from you now goes into my Junk folder – delaying >> my response. 😊) >>> Acee – >>> Consider the simple topology: >>> A---B---C >>> A is the restarting router. >>> C represents “the rest of the network” attached to B. >>> Router A goes down. >>> Adjacency on B to A goes down. >>> The LSPDB on C now has: >>> Router LSA B w no adjacency to A >>> Router LSA A w adjacency to B (stale) >>> A comes up – adjacency between A and B forms. >>> What happens next on C (and all the routers downstream) depends on >> order. >>> Case #1 >>> New Router LSA B w adjacency to A arrives. >> >> With the change I proposed, Router B will not become adjacent to Router A >> without getting an updated version of Router A’s LSA that doesn’t include >> the link to Router B. >> >> >> >>> At this point, C believes there is two-way connectivity between A and B >> because of the presence of the stale Router LSA A >>> New Router LSA A w no adjacency to B arrives >>> Now C has the up to date information >>> Case #2 >>> New Router LSA A w no adjacency to B arrives >>> New Router LSA B w adjacency to A arrives >>> C still sees no 2way connectivity between A and B >>> The reason you need to control the ordering is to prevent Case #1 from >> occurring. >>> Yes, this is a transient – LSPDB will eventually converge – but the duration >> of “eventually’ depends on scale. >>> SA bit can be used to prevent Case #1 from ever occurring – or at least >> make it very unlikely. >> >> The change I proposed will prevent it as well. Router B will request Router >> A’s >> LSA and Router A will respond with the new version which doesn’t have the >> link to Router B. Router B will respond with the more-recent version (see >> this >> excerpt from RFC 2328 13.3): >> >> >> >> (8) Else, the database copy is more recent. If the database copy >> has LS age equal to MaxAge and LS sequence number equal to >> MaxSequenceNumber, simply discard the received LSA without >> acknowledging it. (In this case, the LSA's LS sequence number is >> wrapping, and the MaxSequenceNumber LSA must be completely >> flushed before any new LSA instance can be introduced). >> Otherwise, as long as the database copy has not been sent in a >> Link State Update within the last MinLSArrival seconds, send the >> database copy back to the sending neighbor, encapsulated within >> a Link State Update Packet. The Link State Update Packet should >> be sent directly to the neighbor. In so doing, do not put the >> database copy of the LSA on the neighbor's link state >> retransmission list, and do not acknowledge the received (less >> recent) >> LSA instance. >> >> >> Once Router A receives a more recent version and processed as described in >> section 13.4: >> >> >> However, if the received self-originated LSA is newer than the >> last instance that the router actually originated, the router >> must take special action. The reception of such an LSA >> indicates that there are LSAs in the routing domain that were >> originated by the router before the last time it was restarted. >> In most cases, the router must then advance the LSA's LS >> sequence number one past the received LS sequence number, and >> originate a new instance of the LSA. >> >> >> Thanks, >> Acee >> >> >> >> >> >> >>> Les >>> From: Acee Lindem <[email protected]> >>> Sent: Tuesday, March 28, 2023 10:02 AM >>> To: Les Ginsberg (ginsberg) <[email protected]> >>> Cc: Liyan Gong <[email protected]>; Tony Przygienda >> <[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 >>> Les, >>> >>> >>> On Mar 28, 2023, at 12:45, Les Ginsberg (ginsberg) <[email protected]> >> wrote: >>> Acee – >>> I will leave it to you and the other OSPF experts to decide what mechanism >> you want to use in OSPF. >>> My only comment is that in the solution you proposed you did not account >> for the synchronization needed between Steps 2, 3, 4. >>> This is needed I think to prevent the neighbor LSA advertising the new >> adjacency to the restarting router from being propagated before the >> updated Router LSA (w no neighbors) from the restarting router is >> propagated. >>> This is what avoids downstream routers from prematurely installing paths >> via the restarting router. >>> Paths will not be installed until both routers advertise the link in their >> Router-LSAs (due to the backlink check in the SPF computation). >>> (b) Otherwise, W is a transit vertex (router or transit >>> network). Look up the vertex W's LSA (router-LSA or >>> network-LSA) in Area A's link state database. If the >>> LSA does not exist, or its LS age is equal to MaxAge, or >>> it does not have a link back to vertex V, examine the >>> next link in V's LSA.[23] >>> >>> The restarting router can delay advertising the link to account for any >> required delays. >>> >>> >>> Thanks, >>> Acee >>> >>> >>> If you don’t want to use SA bit that’s fine – but I think you do need some >> signaling. >>> Les >>> From: Acee Lindem <[email protected]> >>> Sent: Tuesday, March 28, 2023 7:43 AM >>> To: Liyan Gong <[email protected]> >>> Cc: Les Ginsberg (ginsberg) <[email protected]>; Tony Przygienda >> <[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 >>> 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. >>> Best Regards, >>> Liyan >>> ----邮件原文---- >>> 发件人："Les Ginsberg \\(ginsberg\\)" >> <[email protected]> >>> 收件人：Tony Przygienda <[email protected]> >>> 抄 送: Acee Lindem <[email protected]>,Liyan Gong >> <[email protected]>,"chen.mengxiao" >> <[email protected]>,lsr <[email protected]>,Weiqiang Cheng >> <[email protected]>,linchangwang >> <[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]> 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:45AM 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
