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

[Tony Przygienda <[e-mail]>]

ok yes, I didn't think through the step 3 ...

thanks Les

-- tony

On Tue, Mar 28, 2023 at 11:44 AM Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> Tony -
>
>
>
> *From:* Tony Przygienda <[e-mail]>
> *Sent:* Monday, March 27, 2023 5:11 PM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* Acee Lindem <[e-mail]>; Liyan Gong <
> [e-mail]>; chen.mengxiao <[e-mail]>; lsr <
> [e-mail]>; Weiqiang Cheng <[e-mail]>;
> linchangwang <[e-mail]>
> *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: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
>
>