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.
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.
(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.
Hope to get your opinion, Thanks.
Best Regards,
Liyan
----邮件原文----发件人：Liyan Gong <gongli...@chinamobile.com>收件人："acee.ietf"
<acee.i...@gmail.com>抄 送: "chen.mengxiao" <chen.mengx...@h3c.com>,Les Ginsberg
<ginsb...@cisco.com>,lsr <lsr@ietf.org>,Weiqiang Cheng
<chengweiqi...@chinamobile.com>,linchangwang
<linchangwang.04...@h3c.com>发送时间：2023-03-09 11:27:58主题：Re:
[Lsr]NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txtHi 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 <acee.i...@gmail.com>收件人：Liyan Gong
<gongli...@chinamobile.com>抄 送: "Mengxiao.Chen" <chen.mengx...@h3c.com>,Les
Ginsberg <ginsb...@cisco.com>,lsr <lsr@ietf.org>,Weiqiang Cheng
<chengweiqi...@chinamobile.com>,linchangwang
<linchangwang.04...@h3c.com>发送时间：2023-03-08 02:34:17主题：Re: [Lsr] New
VersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txtHi 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> > > Lsr@ietf.org> > > https://www.ietf.org/mailman/listinfo/lsr>
>> > _______________________________________________> > Lsr mailing list> >
Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________> Lsr mailing list>
Lsr@ietf.org> 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>
Lsr@ietf.org> 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> > > Lsr@ietf.org> > > https://www.ietf.org/mailman/listinfo/lsr>
>> > _______________________________________________> > Lsr mailing list> >
Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________> Lsr mailing list>
Lsr@ietf.org> 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>
Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________Lsr mailing
listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
