Re: [Lsr] New Version Notificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Yingzhen Qu <[e-mail]>]

Noted. will add it to the agenda.

Thanks,
Yingzhen

On Mon, Mar 13, 2023 at 1:06 PM Acee Lindem <[e-mail]> wrote:

> Hi Yinzhen,
>
> I would like 5 minutes to present an alternative solution. The
> presentation should immediately follow this presentation as the
> hypothetical problem will have already have been presented.
>
> There isn’t a draft yet as I’m not sure this problem really needs to be
> solved.
>
> Thanks,
> Acee
>
> > On Mar 7, 2023, at 1:34 PM, Acee Lindem <[e-mail]> wrote:
> >
> > 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 <[e-mail]>
> 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>
> >> <image.png>
> >> Best Regards,
> >> Liyan
> >>
> >>
> >> ----邮件原文----
> >> 发件人："Mengxiao.Chen" <[e-mail]>
> >> 收件人："Les Ginsberg (ginsberg)" <ginsberg=[e-mail]>,AceeLindem
> <[e-mail]>,Liyan Gong  <[e-mail]>
> >> 抄 送: lsr  <[e-mail]>,Weiqiang Cheng  <[e-mail]>,linchangwang
> <[e-mail]>
> >> 发送时间：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 <[e-mail]> On Behalf Of Les Ginsberg (ginsberg)
> >> Sent: Tuesday, March 7, 2023 1:29 AM
> >> To: Acee Lindem <[e-mail]>; Liyan Gong <
> [e-mail]>
> >> Cc: lsr <[e-mail]>
> >> 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 <[e-mail]> On Behalf Of Acee Lindem
> >>> Sent: Monday, March 6, 2023 8:01 AM
> >>> To: Liyan Gong <[e-mail]>
> >>> Cc: lsr <[e-mail]>
> >>> 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 <[e-mail]>
> >>> 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 <[e-mail]>
> >>>> 收件人：Changwang Lin <[e-mail]>,Liyan Gong
> >>> <[e-mail]>,Mengxiao Chen
> >>> <[e-mail]>,Weiqiang Cheng
> >>> <[e-mail]>
> >>>> 抄 送: (无)
> >>>> 发送时间：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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>
> >>> _______________________________________________
> >>> Lsr mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/lsr
> >> _______________________________________________
> >> Lsr mailing list
> >> [e-mail]
> >> 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
> >> [e-mail]
> >> 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 <[e-mail]> On Behalf Of Les Ginsberg (ginsberg)
> >> Sent: Tuesday, March 7, 2023 1:29 AM
> >> To: Acee Lindem <[e-mail]>; Liyan Gong <
> [e-mail]>
> >> Cc: lsr <[e-mail]>
> >> 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 <[e-mail]> On Behalf Of Acee Lindem
> >>> Sent: Monday, March 6, 2023 8:01 AM
> >>> To: Liyan Gong <[e-mail]>
> >>> Cc: lsr <[e-mail]>
> >>> 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 <[e-mail]>
> >>> 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 <[e-mail]>
> >>>> 收件人：Changwang Lin <[e-mail]>,Liyan Gong
> >>> <[e-mail]>,Mengxiao Chen
> >>> <[e-mail]>,Weiqiang Cheng
> >>> <[e-mail]>
> >>>> 抄 送: (无)
> >>>> 发送时间：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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>
> >>> _______________________________________________
> >>> Lsr mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/lsr
> >> _______________________________________________
> >> Lsr mailing list
> >> [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/lsr
> >>
> >
>
>