Hi Liyan, As I responded previously, we need an additional change to the OSPF database exchange.
https://mailarchive.ietf.org/arch/msg/lsr/zYB-GA9fw2mVNcTyhcRAAIPBhGE/ We’ll have something soon and then we can compare the two solutions. Thanks, Acee > On Mar 31, 2023, at 2:36 AM, Liyan Gong <[email protected]> wrote: > > > 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, Let's 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 neighbor's 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 it's > full no matter what which will take a bit of time. So even if floods > high-version remote LSA overriding the remote's 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 it's 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 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
