Re: [Lsr] NewVersionNotificationfordraft-cheng-ospf-adjacency-suppress-00.txt

[Tony Przygienda <[e-mail]>]

I didn't say "bigger", I said "random" ;-}

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 ...

--- tony

On Tue, Mar 28, 2023 at 8:04 AM Les Ginsberg (ginsberg) <[e-mail]>
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 <[e-mail]>
> *Sent:* Monday, March 27, 2023 3:29 PM
> *To:* Acee Lindem <[e-mail]>
> *Cc:* Liyan Gong <[e-mail]>; chen.mengxiao <
> [e-mail]>; Les Ginsberg (ginsberg) <[e-mail]>; lsr
> <[e-mail]>; Weiqiang Cheng <[e-mail]>;
> linchangwang <[e-mail]>
> *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:45 AM Acee Lindem <[e-mail]> wrote:
>
> Hi Liyan,
>
>
>
> On Mar 27, 2023, at 06:36, Liyan Gong <[e-mail]> 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  <[e-mail]>
> *收件人：*"acee.ietf" <[e-mail]>
> *抄 送**: *"chen.mengxiao" <[e-mail]>,Les Ginsberg  <
> [e-mail]>,lsr  <[e-mail]>,Weiqiang Cheng  <
> [e-mail]>,linchangwang  <[e-mail]>
> *发送时间：*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  <[e-mail]>
> *收件人：*Liyan Gong  <[e-mail]>
> *抄 送**: *"Mengxiao.Chen" <[e-mail]>,Les Ginsberg  <
> [e-mail]>,lsr  <[e-mail]>,Weiqiang Cheng  <
> [e-mail]>,linchangwang  <[e-mail]>
> *发送时间：*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
> > > > [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  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
> > > > [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
> >
>
> _______________________________________________
> 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
>
>