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] <mailto:[email protected]>>
> Sent: Tuesday, March 28, 2023 7:43 AM
> To: Liyan Gong <[email protected] <mailto:[email protected]>>
> Cc: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>>;
> Tony Przygienda <[email protected] <mailto:[email protected]>>;
> chen.mengxiao <[email protected] <mailto:[email protected]>>; lsr
> <[email protected] <mailto:[email protected]>>; Weiqiang Cheng
> <[email protected] <mailto:[email protected]>>;
> linchangwang <[email protected] <mailto:[email protected]>>
> 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]
> <mailto:[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\\) <file://(ginsberg/)>"
> <[email protected]
> <mailto:[email protected]>>
> 收件人：Tony Przygienda <[email protected] <mailto:[email protected]>>
> 抄 送: Acee Lindem <[email protected] <mailto:[email protected]>>,Liyan
> Gong <[email protected]
> <mailto:[email protected]>>,"chen.mengxiao" <[email protected]
> <mailto:[email protected]>>,lsr <[email protected]
> <mailto:[email protected]>>,Weiqiang Cheng <[email protected]
> <mailto:[email protected]>>,linchangwang
> <[email protected] <mailto:[email protected]>>
> 发送时间：2023-03-28 10:44:41
> 主题：Re:
> [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
>
> Tony -
>
> From: Tony Przygienda <[email protected] <mailto:[email protected]>>
> Sent: Monday, March 27, 2023 5:11 PM
> To: Les Ginsberg (ginsberg) <>
> Cc: Acee Lindem <[email protected] <mailto:[email protected]>>; Liyan
> Gong <[email protected] <mailto:[email protected]>>;
> chen.mengxiao <[email protected] <mailto:[email protected]>>; lsr
> <[email protected] <mailto:[email protected]>>; Weiqiang Cheng
> <[email protected] <mailto:[email protected]>>;
> linchangwang <[email protected] <mailto:[email protected]>>
> Subject: Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
> I didn't say "bigger", I said "random" ;-}
> [LES:] Ahhh…that makes all the difference.
>
> I tend to agree with SA bit solution though I don't grok how you can stop
> flooding with that precisely. especially since you cannot rely on sequence of
> hellos and DB sync packets arriving at the receiving node. And SA AFAIR
> assumes LLC or whatever while Acee's works on base spec ...
>
> [LES:] Step 1: Send SA bit – neighbor continues to send Router LSA with no
> neighbor advertisement to the restarting router
> Step 2: Complete LSPDB sync – including Restarting router generating new
> Router LSA w no neighbors
> Step 3: Delay to allow updated Router LSA from Restarting router to be
> flooded
> Step 4: Clear SA bit – neighboring routers can now advertise adjacency to the
> Restarting router
> Step 5: Restarting router generates new Router LSA advertising neighbors
>
> (To make this “extra reliable”, at Step 3 we can use your “random delay”
> strategy. )
>
> Les
>
> --- tony
>
> On Tue, Mar 28, 2023 at 8:04AM Les Ginsberg (ginsberg) <[email protected]
> <mailto:[email protected]>> wrote:
> Tony –
>
> It seems to me that the larger sequence # solution is less likely to work the
> more you use it.
> In other words, if I restart once a month, each time I need to pick an “even
> bigger sequence #” to account for the starting point of the previous restart.
>
> I know that with a 32 bit sequence #, we have decades of updates available,
> but unless you save your most recent sequence # prior to restart you either
> have to make a generous WAG or risk the increasing likelihood that your WAG
> won’t be big enough.
>
> The SA bit logic is designed to allow the restarting router to control when
> the neighbors can safely resume advertising the neighbor to the restarting
> router.
> This has addressed problematic cases seen even at low scale in IS-IS because
> IS-IS does not have the equivalent of Exchange state on adjacency bringup.
> While I agree with Acee that historically this hasn’t been a significant
> issue with OSPF, as IGP scale increases the visibility of this issue becomes
> more likely.
>
> However, the problem has another aspect i.e., it is important that the
> updated LSA from the neighbor of the restarting router NOT be flooded prior
> to the updated LSA from the restarting router. Otherwise other routers in
> the network may prematurely think that two-way connectivity to the restarting
> router has been restored sooner than it actually has been. Neither the draft
> nor Acee’s alternative explicitly address this point. Proper use of the SA
> bit can address this aspect.
>
> Les
>
> From: Tony Przygienda <[email protected] <mailto:[email protected]>>
> Sent: Monday, March 27, 2023 3:29 PM
> To: Acee Lindem <[email protected] <mailto:[email protected]>>
> Cc: Liyan Gong <[email protected]
> <mailto:[email protected]>>; chen.mengxiao <[email protected]
> <mailto:[email protected]>>; Les Ginsberg (ginsberg) <[email protected]
> <mailto:[email protected]>>; lsr <[email protected] <mailto:[email protected]>>;
> Weiqiang Cheng <[email protected]
> <mailto:[email protected]>>; linchangwang
> <[email protected] <mailto:[email protected]>>
> Subject: Re: [Lsr]
> NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
> thought about it. there are also other solutions to the problem (or rather to
> make it significantly less likely/shorter duration since perfect solution
> given we don't purge DB of an adjacenct router when we lose adjacency to it
> do not exist) such as e.g. choosing seqnr# on startup in a way that minimizes
> the problem (IMO simplest solution but only probabilistic).
>
> Acee's solution is significantly simpler and AFAIS will have roughly same
> behavior as the suggested draft. can be combined iwth the seqnr#
> recommendation (which I probably wouldn't do since large seqnr# on startups
> may trigger bugs in deployed, "not-so-hard-tested" implementations ;-)
>
> I see Acee's take as benign "over-compliance" to standard as we have it ;-)
> since the current wording does not say you MUST NOT do what he suggests ;-)
>
> -- tony
>
> On Tue, Mar 28, 2023 at 1:45AM Acee Lindem <[email protected]
> <mailto:[email protected]>> wrote:
> Hi Liyan,
>
> On Mar 27, 2023, at 06:36, Liyan Gong <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Hi Acee,
>
>
> Thank you for sharing your idea about the draft. Because of the time
> limitation in the meeting, Let‘s continue here.
>
>
>
> 1. First, About your doubts about the existence of the problem, I would like
> to check whether I have elaborated it clearly through the following email and
> the presentation.
>
>
> It is a real problem we've actually seen and can be reproduced easily,
> you can actually try it out.
>
> I have no doubt that one could craft a test that would simulate the problem.
> My point was that in practice, the restarting Router-LSA is flooded to its
> neighbors during the restart and will be accepted by any neighbors in
> Exchange State or better.
>
>
>
> 2. About your proposed solution, we would like to share our comments.
>
>
> (1) Your solution does not work for other type of lsa except router-lsa.
> The blackhole still occurs for other type route.
>
>
> For example, Router B has received the re-originated router lsa of
> router A, and router A&B both get into the full state. Now A is reachable
> through spf tree calculation.
>
> As a result, the external route is also reachable, since the type 5
> lsa has not been re-originated.
>
>
> I don’t think this can happen. Once both router A&B get into full sate,
> Router A will have requested and received all its stale (i.e., pre-restart
> LSAs) from Router A and will have either refreshed or purged them based it
> current state.
>
>
> (2) Your solution can be classified into the solution 2) mentioned in our
> presentation and more complicated.
>
> It is a larger modification to the basic ospf protocol, equivalent
> to abandon the action of DD exchange. It will cause more risk and pressure
> for all the routers in the network.
>
> I disagree strongly that my solution is more complicated, it only add the
> Router-LSA to the link state request list. I don’t see how this could be
> judged more complex than using an independent hand-shake involved. OSPF
> Hello to keep Router B from forming an adjacency. BTW, the use case(s) and
> precisely how the mechanism will be used was specified in the slides but not
> the draft. The draft only says:
>
> With the proposed mechanism, the starting router's
> neighbors will suppress advertising an adjacency to the starting
> router until the starting router has been able to propagate newer
> versions of LSAs, so that the temporary blackholes can be avoided.
>
> I’m not saying this should be normative text, just a better example of how
> the mechanism would be used.
>
> Also, if you do republish, please include the WG in the draft name so it can
> easily be found, i.e., draft-cheng-lsr-ospf-adjacency-suppress-00
>
>
> Thanks,
> Acee
>
>
>
> Hope to get your opinion, Thanks.
>
>
> Best Regards,
>
> Liyan
>
>
> ----邮件原文----
> 发件人：Liyan Gong <[email protected] <mailto:[email protected]>>
> 收件人："acee.ietf" <[email protected] <mailto:[email protected]>>
> 抄 送: "chen.mengxiao" <[email protected]
> <mailto:[email protected]>>,Les Ginsberg <[email protected]
> <mailto:[email protected]>>,lsr <[email protected]
> <mailto:[email protected]>>,Weiqiang Cheng <[email protected]
> <mailto:[email protected]>>,linchangwang
> <[email protected] <mailto:[email protected]>>
> 发送时间：2023-03-09 11:27:58
> 主题：Re:
> [Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
> Hi Acee,
>
>
> Yes,it is a real problem we've actually seen.
>
>
> Especially when the neighbor Rouer B has many more LSAs than the Restart
> Router A.
>
>
> In this scenario, the time between the following two key points will be
> prolonged greatly.
>
>
> Further discussion is welcome, thanks a lot.
>
>
> Best Regards,
>
> Liyan
>
>
>
>
> ----邮件原文----
> 发件人：Acee Lindem <[email protected] <mailto:[email protected]>>
> 收件人：Liyan Gong <[email protected] <mailto:[email protected]>>
> 抄 送: "Mengxiao.Chen" <[email protected]
> <mailto:[email protected]>>,Les Ginsberg <[email protected]
> <mailto:[email protected]>>,lsr <[email protected]
> <mailto:[email protected]>>,Weiqiang Cheng <[email protected]
> <mailto:[email protected]>>,linchangwang
> <[email protected] <mailto:[email protected]>>
> 发送时间：2023-03-08 02:34:17
> 主题：Re: [Lsr] New
> VersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt
>
> Hi Liyan,
>
> This is very unlikely to happen as flooding between the routers commences as
> soon as they reach Exchange state. I’m wondering if you’ve actually seen this
> situation or it is hypothetical.
>
> In any case, I have a better solution which wouldn’t add the delay for the
> next hello packet without the SA flag to be received before advertising the
> link. I’m busy with some other things right now and want to think about it
> more.
>
> For now, we will add your presentation to the list for IETF 116.
>
> Thanks,
> Acee
>
>
>
> > On Mar 7, 2023, at 3:54 AM, Liyan Gong wrote:
> >
> >
> > Hi Les and Acee,
> >
> > Let me explain it further through the following diagram.
> >
> > 1) The neighbor relationship between Router A and Router B is stable. The
> > route 10.1.1.1/32 <http://10.1.1.1/32> is reachable.
> > 2）Router A unplanned restarts and the loopback address has been deleted.The
> > process of the neighbor establish is as follows.
> > 3）The temporary blackhole occurs during the time range stated in the right
> > brace.
> >
> > There are two key points:
> > 1)Neighbor router reached the full state earlier.
> > 2)Neighbor router received the reoriginated lsas late.
> >
> > So,this purpose of the draft is to delay the point 1).
> >
> > Hope this helps,thank you.
> >
> > <1.png>
> >
> > Best Regards,
> > Liyan
> >
> >
> > ----邮件原文----
> > 发件人："Mengxiao.Chen"
> > 收件人："Les Ginsberg (ginsberg)" ,AceeLindem ,Liyan Gong
> > 抄 送: lsr ,Weiqiang Cheng ,linchangwang
> > 发送时间：2023-03-07 15:19:59
> > 主题：Re: [Lsr] New Version Notification
> > fordraft-cheng-ospf-adjacency-suppress-00.txt
> >
> > Hi Les,
> >
> > Thank you for your comments.
> > OSPF does include the LSDB sync requirement. But OSPF state machine does
> > not guarantee the two routers attain FULL state at the same time.
> >
> > R1(restart)------R2------R3
> >
> > R1 LSDB: R1's new router-LSA, seq 80000001
> > R2 LSDB: R1's old router-LSA, seq 80000500
> >
> > When R1 restarts from an unplanned outage, R1 will reinitialize its LSA
> > sequence number. But R2 has the previous copies of R1's LSA, which has
> > larger sequence number.
> > R2 thinks its local LSAs are "newer". So, R2 will attain FULL state,
> > without requesting R1 to update.
> > This may cause temporary blackholes to occur until R1 regenerates and
> > floods its own LSAs with higher sequence numbers.
> >
> > Thanks,
> > Mengxiao
> >
> > -----Original Message-----
> > From: Lsr On Behalf Of Les Ginsberg (ginsberg)
> > Sent: Tuesday, March 7, 2023 1:29 AM
> > To: Acee Lindem ; Liyan Gong
> > Cc: lsr
> > Subject: Re: [Lsr] New Version Notification for
> > draft-cheng-ospf-adjacency-suppress-00.txt
> >
> > +1 to what Acee has said.
> >
> > As historical context, the SA bit was defined in IS-IS precisely because
> > IS-IS adjacency state machine does NOT include LSPDB sync as a requirement
> > before the adjacency is usable (unlike OSPF).
> > OSPF does not need SA bit.
> >
> > Les
> >
> > > -----Original Message-----
> > > From: Lsr On Behalf Of Acee Lindem
> > > Sent: Monday, March 6, 2023 8:01 AM
> > > To: Liyan Gong
> > > Cc: lsr
> > > Subject: Re: [Lsr] New Version Notification for
> > > draft-cheng-ospf-adjacency-
> > > suppress-00.txt
> > >
> > > Hi Liyan,
> > >
> > > I should replied to this Email rather than your request for an IETF 116
> > > slot.
> > > Please reply to this one.
> > >
> > > I’m sorry but I don’t get this draft from a quick read. An OSPF router
> > > would
> > > not advertise an adjacency until the router is in FULL state. An OSPF
> > > router
> > > will not attain FULL state until database synchronization is complete.
> > > The following statement from you use case is incorrect:
> > >
> > > So, without requesting the starting router to update its LSAs, the
> > > neighbors of the starting router may transition to "Full" state and
> > > route the traffic through the starting router.
> > >
> > > Why do you think you need this extension?
> > >
> > >
> > > Thanks,
> > > Acee
> > >
> > >
> > > > On Mar 6, 2023, at 9:10 AM, Liyan Gong
> > > wrote:
> > > >
> > > > Dear All,
> > > > We have posted a new draft https://datatracker.ietf.org/doc/draft-cheng-
> > > ospf-adjacency-suppress/.
> > > > This draft describes the extension of OSPF LLS to signal adjacency
> > > suppression which is functionally similar to the SA bit of Restart TLV in
> > > IS-IS.
> > > > The purpose is to avoid the temporary blackhole when a router restarts
> > > from unplanned outages.
> > > > We are looing forward to your comments.Thanks a lot.
> > > >
> > > > Best Regards,
> > > > Liyan
> > > >
> > > > ----邮件原文----
> > > > 发件人：internet-drafts
> > > > 收件人：Changwang Lin ,Liyan Gong
> > > ,Mengxiao Chen
> > > ,Weiqiang Cheng
> > >
> > > > 抄 送: (无)
> > > > 发送时间：2023-03-06 17:43:39
> > > > 主题：New Version Notification for draft-cheng-ospf-adjacency-suppress-
> > > 00.txt
> > > >
> > > >
> > > > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> > > > has been successfully submitted by Mengxiao Chen and posted to the
> > > > IETF repository.
> > > >
> > > > Name: draft-cheng-ospf-adjacency-suppress
> > > > Revision: 00
> > > > Title: OSPF Adjacency Suppression
> > > > Document date: 2023-03-06
> > > > Group: Individual Submission
> > > > Pages: 8
> > > > URL:
> > > > https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-
> > > suppress-00.txt
> > > > Status:
> > > > https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-
> > > suppress/
> > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-ospf-
> > > adjacency-suppress
> > > >
> > > >
> > > > Abstract:
> > > > This document describes a mechanism for a router to signal its
> > > > neighbors to suppress advertising the adjacency to it until link-
> > > > state database synchronization is complete. This minimizes transient
> > > > routing disruption when a router restarts from unplanned outages.
> > > >
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > >
> > > >
> > > >
> > > > Subject：New Version Notification for draft-cheng-ospf-adjacency-
> > > suppress-00.txt
> > > >
> > > >
> > > > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> > > > has been successfully submitted by Mengxiao Chen and posted to the
> > > > IETF repository.
> > > >
> > > > Name: draft-cheng-ospf-adjacency-suppress
> > > > Revision: 00
> > > > Title: OSPF Adjacency Suppression
> > > > Document date: 2023-03-06
> > > > Group: Individual Submission
> > > > Pages: 8
> > > > URL:
> > > > https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-
> > > suppress-00.txt
> > > > Status:
> > > > https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-
> > > suppress/
> > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-ospf-
> > > adjacency-suppress
> > > >
> > > >
> > > > Abstract:
> > > > This document describes a mechanism for a router to signal its
> > > > neighbors to suppress advertising the adjacency to it until link-
> > > > state database synchronization is complete. This minimizes transient
> > > > routing disruption when a router restarts from unplanned outages.
> > > >
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Lsr mailing list
> > > > [email protected] <mailto:[email protected]>
> > > > https://www.ietf.org/mailman/listinfo/lsr
> > >
> > > _______________________________________________
> > > Lsr mailing list
> > > [email protected] <mailto:[email protected]>
> > > https://www.ietf.org/mailman/listinfo/lsr
> > _______________________________________________
> > Lsr mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/lsr
> > -------------------------------------------------------------------------------------------------------------------------------------
> > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
> > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> > 邮件！
> > This e-mail and its attachments contain confidential information from New
> > H3C, which is
> > intended only for the person or entity whose address is listed above. Any
> > use of the
> > information contained herein in any way (including, but not limited to,
> > total or partial
> > disclosure, reproduction, or dissemination) by persons other than the
> > intended
> > recipient(s) is prohibited. If you receive this e-mail in error, please
> > notify the sender
> > by phone or email immediately and delete it!
> > _______________________________________________
> > Lsr mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/lsr
> >
> > Subject：Re: [Lsr] New Version Notification
> > fordraft-cheng-ospf-adjacency-suppress-00.txt
> >
> > Hi Les,
> >
> > Thank you for your comments.
> > OSPF does include the LSDB sync requirement. But OSPF state machine does
> > not guarantee the two routers attain FULL state at the same time.
> >
> > R1(restart)------R2------R3
> >
> > R1 LSDB: R1's new router-LSA, seq 80000001
> > R2 LSDB: R1's old router-LSA, seq 80000500
> >
> > When R1 restarts from an unplanned outage, R1 will reinitialize its LSA
> > sequence number. But R2 has the previous copies of R1's LSA, which has
> > larger sequence number.
> > R2 thinks its local LSAs are "newer". So, R2 will attain FULL state,
> > without requesting R1 to update.
> > This may cause temporary blackholes to occur until R1 regenerates and
> > floods its own LSAs with higher sequence numbers.
> >
> > Thanks,
> > Mengxiao
> >
> > -----Original Message-----
> > From: Lsr On Behalf Of Les Ginsberg (ginsberg)
> > Sent: Tuesday, March 7, 2023 1:29 AM
> > To: Acee Lindem ; Liyan Gong
> > Cc: lsr
> > Subject: Re: [Lsr] New Version Notification for
> > draft-cheng-ospf-adjacency-suppress-00.txt
> >
> > +1 to what Acee has said.
> >
> > As historical context, the SA bit was defined in IS-IS precisely because
> > IS-IS adjacency state machine does NOT include LSPDB sync as a requirement
> > before the adjacency is usable (unlike OSPF).
> > OSPF does not need SA bit.
> >
> > Les
> >
> > > -----Original Message-----
> > > From: Lsr On Behalf Of Acee Lindem
> > > Sent: Monday, March 6, 2023 8:01 AM
> > > To: Liyan Gong
> > > Cc: lsr
> > > Subject: Re: [Lsr] New Version Notification for
> > > draft-cheng-ospf-adjacency-
> > > suppress-00.txt
> > >
> > > Hi Liyan,
> > >
> > > I should replied to this Email rather than your request for an IETF 116
> > > slot.
> > > Please reply to this one.
> > >
> > > I’m sorry but I don’t get this draft from a quick read. An OSPF router
> > > would
> > > not advertise an adjacency until the router is in FULL state. An OSPF
> > > router
> > > will not attain FULL state until database synchronization is complete.
> > > The following statement from you use case is incorrect:
> > >
> > > So, without requesting the starting router to update its LSAs, the
> > > neighbors of the starting router may transition to "Full" state and
> > > route the traffic through the starting router.
> > >
> > > Why do you think you need this extension?
> > >
> > >
> > > Thanks,
> > > Acee
> > >
> > >
> > > > On Mar 6, 2023, at 9:10 AM, Liyan Gong
> > > wrote:
> > > >
> > > > Dear All,
> > > > We have posted a new draft https://datatracker.ietf.org/doc/draft-cheng-
> > > ospf-adjacency-suppress/.
> > > > This draft describes the extension of OSPF LLS to signal adjacency
> > > suppression which is functionally similar to the SA bit of Restart TLV in
> > > IS-IS.
> > > > The purpose is to avoid the temporary blackhole when a router restarts
> > > from unplanned outages.
> > > > We are looing forward to your comments.Thanks a lot.
> > > >
> > > > Best Regards,
> > > > Liyan
> > > >
> > > > ----邮件原文----
> > > > 发件人：internet-drafts
> > > > 收件人：Changwang Lin ,Liyan Gong
> > > ,Mengxiao Chen
> > > ,Weiqiang Cheng
> > >
> > > > 抄 送: (无)
> > > > 发送时间：2023-03-06 17:43:39
> > > > 主题：New Version Notification for draft-cheng-ospf-adjacency-suppress-
> > > 00.txt
> > > >
> > > >
> > > > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> > > > has been successfully submitted by Mengxiao Chen and posted to the
> > > > IETF repository.
> > > >
> > > > Name: draft-cheng-ospf-adjacency-suppress
> > > > Revision: 00
> > > > Title: OSPF Adjacency Suppression
> > > > Document date: 2023-03-06
> > > > Group: Individual Submission
> > > > Pages: 8
> > > > URL:
> > > > https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-
> > > suppress-00.txt
> > > > Status:
> > > > https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-
> > > suppress/
> > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-ospf-
> > > adjacency-suppress
> > > >
> > > >
> > > > Abstract:
> > > > This document describes a mechanism for a router to signal its
> > > > neighbors to suppress advertising the adjacency to it until link-
> > > > state database synchronization is complete. This minimizes transient
> > > > routing disruption when a router restarts from unplanned outages.
> > > >
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > >
> > > >
> > > >
> > > > Subject：New Version Notification for draft-cheng-ospf-adjacency-
> > > suppress-00.txt
> > > >
> > > >
> > > > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> > > > has been successfully submitted by Mengxiao Chen and posted to the
> > > > IETF repository.
> > > >
> > > > Name: draft-cheng-ospf-adjacency-suppress
> > > > Revision: 00
> > > > Title: OSPF Adjacency Suppression
> > > > Document date: 2023-03-06
> > > > Group: Individual Submission
> > > > Pages: 8
> > > > URL:
> > > > https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-
> > > suppress-00.txt
> > > > Status:
> > > > https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-
> > > suppress/
> > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-ospf-
> > > adjacency-suppress
> > > >
> > > >
> > > > Abstract:
> > > > This document describes a mechanism for a router to signal its
> > > > neighbors to suppress advertising the adjacency to it until link-
> > > > state database synchronization is complete. This minimizes transient
> > > > routing disruption when a router restarts from unplanned outages.
> > > >
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Lsr mailing list
> > > > [email protected] <mailto:[email protected]>
> > > > https://www.ietf.org/mailman/listinfo/lsr
> > >
> > > _______________________________________________
> > > Lsr mailing list
> > > [email protected] <mailto:[email protected]>
> > > https://www.ietf.org/mailman/listinfo/lsr
> > _______________________________________________
> > Lsr mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/lsr
> > -------------------------------------------------------------------------------------------------------------------------------------
> > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
> > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> > 邮件！
> > This e-mail and its attachments contain confidential information from New
> > H3C, which is
> > intended only for the person or entity whose address is listed above. Any
> > use of the
> > information contained herein in any way (including, but not limited to,
> > total or partial
> > disclosure, reproduction, or dissemination) by persons other than the
> > intended
> > recipient(s) is prohibited. If you receive this e-mail in error, please
> > notify the sender
> > by phone or email immediately and delete it!
> > _______________________________________________
> > Lsr mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/lsr
> >
>
> _______________________________________________
> Lsr mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> _______________________________________________
> Lsr mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
