Hi All，
I would like to summarize our discussion as below. If any misunderstanding, please correct me, thanks a lot. 1. for A--B scenario, The blackhole occurs on router B when the following order comes: 1.1) B has the old LSA of A in its database. 1.2) B generates new router-lsa to advertise the adjacency B->A. 1.3) B receives the re-originated LSA of A. 2. for A---B---C scenario, The blackhole occurs on router C when the following order comes(same with what Les says): 2.1) C has the old lsa of A in its database. 2.2) C receives the new router-lsa of B advertising the adjacency B->A. 2.3) C receives the re-originated LSA of A---B Even if A--B scenarion is resolved, A--B--C scenario is likely to occur under certain conditions, such as packet loss, out of order, or MinLSInterval, MinLSArrival. Because the sequence of the flooding process can not be controlled precisely as Les has mentioned in the following email. Although the possibility is not so high as A--B scenario, it still should be considered when choosing the solution. It is best to address both scenarios at once. Taking this into consideration, Let39s rethink about the two solutions we have discussed. solution 1: SA-bit: for scenario A--B, The upper step 1.2) is delayed by a signal which is controled by a timer. The solution works well as the presentation slides show. for scenrio A--B--C, If the timer is assigned properly, greater delay can be provided for upper step 2.2). This will help to guarantee step 2.3) before step 2.2) . solution 2: Always requesting router-lsa: for A---B scenario, there are two concerns to be addressed. We will leave this to Acee. 1)It can not work for other type of routes if only requesting router-lsa. 2)It will cause BadLSReq, when an older lsa is received,as the same time,there is an instance on the sending neighbor39s request list. for A--B--C scenario, Assuming the above concerns for scenario A--B have been resolved, I also agree with what Les has mentioned as below: 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. So, Leaving behind the unaddressed concerns on A--B scenario，It seems to me that SA-bit is better for A--B--C scenario. 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-30 01:14:59主题：RE:[Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt Tony – I think we are not far apart in our POV – though the relative size of the bird and the gun might be debatable. Given that the draft authors and Acee seem to be agreeing that “something” should be done, I am thinking that addressing the concern that I have will not add much complexity to whatever solution they agree on. But I will defer to the OSPF experts. Les From: Tony Przygienda <[email protected]> Sent: Tuesday, March 28, 2023 8:35 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 So Les, your concern AFAIU it is maybe bit overwrought. Local (assuming remote is the unplanned bouncer, in chain example B local A remote) advertises its LSA with the link failed and that gets flooded immediately (I assume the link local-remote is *not* a minimal cut in the topology so there are paths to flood the whole network without the link coming up again unlike the 3 router example) and then local does NOT advertise adjacency until it39s full no matter what which will take a bit of time. So even if floods high-version remote LSA overriding the remote39s initial low-version LSA the bidirectional check fails as Acee points out. Then remote overrides and remote and local only flood LSAs with adjacency in them after full which takes some time in any case. Adding additional signalling and interdependencies between hellos and LSA origination seems to me shooting at pretty little birds with canons somewhat due to involved interdependencies. I probably repeat partially what Acee said but it39s my 2c -- tony On Wed, Mar 29, 2023 at 9:53AM 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. 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 LSA39s 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 neighbor39s 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 LSA39s 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 W39s LSA (router-LSA or > > network-LSA) in Area A39s 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 V39s 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 didn39t say "bigger", I said "random" -} > > [LES:] Ahhh…that makes all the difference. > > I tend to agree with SA bit solution though I don39t 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 Acee39s 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 don39t 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). > > Acee39s 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 wouldn39t do since large seqnr# on > startups may trigger bugs in deployed, "not-so-hard-tested" > implementations -) > > I see Acee39s 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 we39ve 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 router39s > > 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 we39ve 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: R139s new router-LSA, seq 80000001 > > > R2 LSDB: R139s 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 R139s 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: R139s new router-LSA, seq 80000001 > > > R2 LSDB: R139s 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 R139s 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
