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
