Your previous responses at here https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0-o/ is also for Case 2. Where your responses for Case 1? Please give the link.
Or else, it will be registered for further clarification. -----邮件原件----- 发件人: Peter Psenak [mailto:[email protected]] 发送时间: 2025年5月28日 16:48 收件人: Aijun Wang <[email protected]>; 'Gunter van de Velde (Nokia)' <[email protected]> 抄送: [email protected] 主题: Re: 答复: 答复: 答复: [Lsr] Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt On 28/05/2025 10:46, Aijun Wang wrote: > OK, you say Gunter talk about the Case 2. It's no problem. > > Then, what's your considerations of Case 1? I have already responded to that. I'm done with this thread. Peter > > -----邮件原件----- > 发件人: Peter Psenak [mailto:[email protected]] > 发送时间: 2025年5月28日 16:40 > 收件人: Aijun Wang <[email protected]>; 'Gunter van de Velde > (Nokia)' <[email protected]> > 抄送: [email protected] > 主题: Re: 答复: 答复: [Lsr] Re: 答复: I-D Action: > draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > > On 28/05/2025 10:24, Aijun Wang wrote: >> Hi, Peter: >> >> We are talking about when to switch back to the remote failure PE, not >> switch from it. >> >> In Case 1, when UPA advertise for a configured time to "allows BGP to >> converge after the remote PE failure ", then ABR stop advertising UPA, right? >> At this moment, should the receiver switch back BGP PIC to the previous >> failure PE? > it can not switch back to failed PE, because BGP on remote nodes know that > such PE does not exist anymore - e.g. BGP has converged. > >> According to Gunter's logic, it should switch back to the previous failure >> PE, because the summary address indicates the specific failure PE is >> reachable again. > Gunter was talking about the case, where the remote PE loopback prefix > reachability was recovered shortly after the UPA was generated, so there > would still be a valid BGP path via such PE. > > Peter > > >> What's your thought? >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----邮件原件----- >> 发件人: Peter Psenak [mailto:[email protected]] >> 发送时间: 2025年5月28日 16:10 >> 收件人: Aijun Wang <[email protected]>; 'Gunter van de Velde >> (Nokia)' <[email protected]> >> 抄送: [email protected] >> 主题: Re: 答复: [Lsr] Re: 答复: I-D Action: >> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >> >> On 28/05/2025 09:35, Aijun Wang wrote: >>> Hi, Gunter: >>> >>> I don’t recommend to design one " brand-new control plane signal " to >>> signal the prefix reachability. >>> >>> What I argue with you until now, is the following statements: >>> "when a UPA stops being advertised, that unreachability signal goes away, >>> and at that point, the summary route takes over and signals reachability." >>> >>> From the UPA document, we can know there at least two reasons can lead >>> the "UPA stops being advertised": >>> Case 1: "UPA advertisements SHOULD therefore be withdrawn after some amount >>> of time, that would provide sufficient time for UPA to be flooded >>> network-wide and acted upon by receiving nodes, but limits the presence of >>> UPA in the network." >>> Case 2: " ABR or ASBR MUST withdraw the previously advertised UPA when the >>> reason for which the UPA was generated was lost " >>> >>> Then, if the reason that lead " UPA stops being advertised " is Case 1, >>> then your logic that " at that point, the summary route takes over and >>> signals reachability." is wrong. >>> When the BGP PIC FRR switch back at this moment, the traffic will be lost. >> no. >> >> The draft also says: >> >> "The time the UPA is kept in the network SHOULD also reflect the intended >> use-case for which the UPA was advertised." >> >> For BGP PIC, you need to keep it for a time that allows BGP to converge >> after the remote PE failure. >> >> Peter >> >> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> -----邮件原件----- >>> 发件人: [email protected] >>> [mailto:[email protected]] 代表 Gunter van de Velde (Nokia) >>> 发送时间: 2025年5月28日 15:04 >>> 收件人: Aijun Wang <[email protected]> >>> 抄送: [email protected]; 'Peter Psenak' <[email protected]> >>> 主题: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> [speaking as work group participant] >>> >>> Hi Aijun, >>> >>> Let’s wrap up this thread. I feel we’ve explored this topic quite >>> thoroughly from different angles, and I’d prefer not to keep circling back >>> and repeating the same points. >>> (this is my last email on this thread) >>> >>> Regarding your comment: >>> " >>> 1) The data-plane OAM tools(BFD, ICMP, STAMP, and TWAMP) should be used to >>> test and verify the prefix reachability. >>> Along the evolution of PUAM/UPA drafts, there are lots of discussions >>> among the efficiency of these OAM tools, versus the PUAM/UPA mechanism. >>> I think you may miss these previous discussions. >>> Here I want just to say, if the WG agree with you, the PUAM/UPA draft >>> shouldn't be existed. >>> " >>> >>> Let me try to explain my point again, one last time, just in a different >>> way for clarity. >>> >>> A router forwards packets based on the unicast forwarding table, which is >>> typically populated by routing protocols like OSPF or IS-IS. Once a route >>> is selected, the router uses that information to forward packets, plain and >>> simple. But here’s the thing: the router doesn’t really “know” if the >>> packet will make it all the way to its final destination. It just follows >>> the best path it has available, based on its local view. What happens >>> downstream, packet drops, blackholing, filtering, or misrouting. can’t be >>> predicted by the control plane alone. That’s just the reality of >>> distributed routing. >>> >>> At the end of the day, if we really want to be sure something is reachable >>> and working as expected, the best way to confirm that is to actually test >>> it. >>> Tools like BFD, ICMP, STAMP, and TWAMP are exactly what we use to validate >>> that, since they measure actual behavior in the data plane. >>> >>> From your comments, it sounds like you're proposing a new control plane >>> signal that says, “Hey, trust me, I’m really reachable.” But I’m not >>> convinced such a signal would be any more reliable than the routes we >>> already learn through established routing protocols like OSPF or IS-IS. >>> That kind of new control plane signal could still be based on outdated, >>> incorrect, or incomplete information, and wouldn’t really help when it >>> comes to truly assessing data plane reachability. >>> >>> Coming back to UPA. When using UPA the procedure as described in [1], [2], >>> and [3] is predictable and behaves in an operationally efficient way. That >>> way, in most cases, we don’t even need to rely on OAM data plane testing >>> tools. From my point of view, adding a new control plane message to somehow >>> validate reachability on top of an already installed unicast route doesn’t >>> really add much value. Instead, it risks introducing more complexity >>> without solving a real problem. >>> >>> Regarding your comment: >>> " >>> 2) In BGP PIC FRR scenario, when the router stops receiving the UPA signal, >>> and "switching back to the primary egress router" is wrong. >>> As stated in your reply, stop receiving the UPA signal " ...doesn’t >>> imply anything about whether the prefix is reachable ", then, when the >>> prefix is still unreachable, switch back to the primary egress router >>> will result in the traffic black hole. >>> " >>> >>> GV> If the UPA disappears then the assumption is that the prefix is indeed >>> reachable, assuming the prefix would be a member prefix covered by the >>> summary route. See [1],[2] and [3] for the procedure. This is basic network >>> behavior when using aggregate routes on ABRs. If this is not the behavior >>> desired, then an alternative is to not summarize prefixes into aggregate >>> prefixes (but this has other operational implications). >>> >>> " >>> In summary, current UPA proposal try to signal the unreachability on >>> demand, but lack of the signaling mechanism to revoke such announcement on >>> demand. >>> " >>> >>> GV> What I’m saying is pretty straightforward: when a UPA stops being >>> advertised, that unreachability signal goes away, and at that point, the >>> summary route takes over and signals reachability. Summary routes have been >>> used in networks for years and has worked reliably. That’s why I’m having a >>> hard time understanding how introducing a brand-new control plane message >>> to signal destination reachability would actually help. It doesn’t really >>> add anything new when it comes to confirming data plane reachability, and >>> we already have mechanisms that work well in practice. >>> >>> Note that this was my last email on this subject as I think we now >>> discussed this enough. >>> >>> Brgds, >>> G/ >>> [speaking as work group participant] >>> >>> [1] >>> https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0- >>> o >>> / >>> {2] >>> https://mailarchive.ietf.org/arch/msg/lsr/aAyfU1ziWTuTltmZoCGO1vht7Q >>> k >>> / >>> {3] >>> https://mailarchive.ietf.org/arch/msg/lsr/hg_v2ZAOkz5bhxE4979viIowkI >>> U >>> / >>> >>> -----Original Message----- >>> From: Aijun Wang <[email protected]> >>> Sent: Wednesday, May 28, 2025 3:06 AM >>> To: Gunter van de Velde (Nokia) <[email protected]> >>> Cc: [email protected]; 'Peter Psenak' <[email protected]> >>> Subject: 答复: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> >>> CAUTION: This is an external email. Please be very careful when clicking >>> links or opening attachments. See the URL nok.it/ext for additional >>> information. >>> >>> >>> >>> Hi, Gunter: >>> >>> There are two misunderstanding in your arguments: >>> 1) The data-plane OAM tools(BFD, ICMP, STAMP, and TWAMP) should be used to >>> test and verify the prefix reachability. >>> Along the evolution of PUAM/UPA drafts, there are lots of discussions >>> among the efficiency of these OAM tools, versus the PUAM/UPA mechanism. >>> I think you may miss these previous discussions. >>> Here I want just to say, if the WG agree with you, the PUAM/UPA draft >>> shouldn't be existed. >>> >>> 2) In BGP PIC FRR scenario, when the router stops receiving the UPA signal, >>> and "switching back to the primary egress router" is wrong. >>> As stated in your reply, stop receiving the UPA signal " ...doesn’t >>> imply anything about whether the prefix is reachable ", then, when the >>> prefix is still unreachable, switch back to the primary egress router >>> will result in the traffic black hole. >>> >>> In summary, current UPA proposal try to signal the unreachability on >>> demand, but lack of the signaling mechanism to revoke such announcement on >>> demand. >>> >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> -----邮件原件----- >>> 发件人: Gunter van de Velde (Nokia) >>> [mailto:[email protected]] >>> 发送时间: 2025年5月27日 17:39 >>> 收件人: Aijun Wang <[email protected]> >>> 抄送: [email protected]; 'Peter Psenak' <[email protected]> >>> 主题: RE: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> [speaking as work group participant] >>> >>> A router makes its forwarding decisions based on the routes it has in the >>> unicast forwarding table, which are populated by the control plane. When a >>> packet comes in, the router looks up the destination, and if there’s a >>> match, it uses the forwarding info tied to the best route it has at that >>> moment to send the packet on its way. >>> >>> It is worth pointing out that the router doesn’t actually know whether the >>> packet will make it all the way to the final destination. It simply follows >>> the best available path based on local routing information. Along the way, >>> anything from packet filtering, DDoS mitigation, or buffer drops could >>> affect delivery, that’s just the nature of network behavior. >>> >>> If there are concerns about whether a specific destination is actually >>> reachable, that’s where data-plane OAM tools come in. Things like BFD, >>> ICMP, STAMP, and TWAMP are built specifically to test and verify >>> reachability beyond what the control plane can determine. >>> >>> To clarify something mentioned earlier when I said “when the UPA is no >>> longer advertised and only the summary prefix remains, the system quickly >>> and gracefully reverts back to the original state without any issues,” I >>> meant exactly that. It doesn’t imply anything about whether the prefix is >>> reachable, it just means the system sees the UPA is gone, and so it reverts >>> to whatever route is considered best in the routing table. >>> >>> In the case of BGP PIC FRR, that usually means switching back to the >>> primary egress router, depending on how the feature is configured. Whether >>> it actually switches back or sticks with the alternate path depends on the >>> specific BGP PIC settings and current network state. >>> >>> G/ >>> (speaking as WG participant) >>> >>> >>> -----Original Message----- >>> From: Aijun Wang <[email protected]> >>> Sent: Tuesday, May 27, 2025 10:47 AM >>> To: Gunter van de Velde (Nokia) <[email protected]> >>> Cc: [email protected]; 'Peter Psenak' <[email protected]> >>> Subject: 答复: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> >>> CAUTION: This is an external email. Please be very careful when clicking >>> links or opening attachments. See the URL nok.it/ext for additional >>> information. >>> >>> >>> >>> Hi, Gunter: >>> >>> Here is the tricky issue: >>> "when the UPA is no longer advertised and only the summary prefix remains, >>> the system quickly and gracefully reverts back to the original state >>> without any issues." >>> >>> Then, you assumes that: when no UPA is advertised, the specific prefix is >>> reachable again? >>> >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> -----邮件原件----- >>> 发件人: Gunter van de Velde (Nokia) >>> [mailto:[email protected]] >>> 发送时间: 2025年5月27日 16:17 >>> 收件人: Aijun Wang <[email protected]> >>> 抄送: [email protected]; Peter Psenak <[email protected]> >>> 主题: RE: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> [speaking as work group participant] >>> >>> Hi Aijun, >>> >>> I just wanted to share a couple of thoughts in response to your message. >>> >>> First, I feel your note is revisiting the topic around the PUA draft [2] in >>> a way that runs counter to the earlier formal warning from Yingzhen [1]. >>> Reopening that discussion at this point doesn’t help strengthen the UPA >>> procedures and seems to be circling back on a topic that the working group >>> has already moved past. >>> >>> Second, based on the procedures outlined in the UPA draft [3], my >>> development team has successfully implemented UPA and is using it as >>> foundational part of our BGP PIC FRR solution. We’re quite familiar with >>> how link-state protocols operate, and we’ve found the documented behavior >>> in [3] to be sufficient for developing an interoperable and reliable >>> implementation. In our solution, the UPA is used to trigger BGP PIC fast >>> reroute exactly as Peter described [4]. When a UPA is received, the BGP PIC >>> FRR process kicks in, and when the UPA is no longer advertised and only the >>> summary prefix remains, the system quickly and gracefully reverts back to >>> the original state without any issues. This solution is now used by network >>> operators who understand the procedures of link-state routing protocols, >>> UPA and BGP PIC FRR well. >>> >>> [1] >>> https://mailarchive.ietf.org/arch/msg/lsr/S7Mqk2JljYgG8kjEPmH6KlLtbf >>> w >>> / >>> [2] >>> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-a >>> n >>> n >>> oucement/ [3] >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-an >>> n >>> o >>> unce/ [4] >>> https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0- >>> o >>> / >>> >>> Hope this helps clarify our experience and perspective. >>> >>> Gunter Van de Velde >>> (speaking as WG participant) >>> >>> >>> >>> From: Aijun Wang <[email protected]> >>> Sent: Tuesday, May 27, 2025 1:05 AM >>> To: Peter Psenak <[email protected]> >>> Cc: [email protected] >>> Subject: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> >>> CAUTION: This is an external email. Please be very careful when clicking >>> links or opening attachments. See the URL nok.it/ext for additional >>> information. >>> >>> Hi, Peter: >>> >>> Please refrain your comments. >>> As the initiators of such mechanism, we describe the whole process 3 years >>> earlier than the first version of your draft. >>> >>> Respect the creator of any idea is the basic behavior of IETF community. >>> >>> Back to your example: >>> You forgot the important part of the puzzle—-the application that the UPA >>> triggered. >>> >>> How and when the application being triggered back to its original state? >>> >>> Image one scenario, some nodes advertised accidentally the wrong UPA >>> signals within the network, how can you revoke it quickly and eliminate the >>> wrong triggered actions? >>> >>> >>> Aijun Wang >>> China Telecom >>> >>> >>> On May 26, 2025, at 17:52, Peter Psenak <mailto:[email protected]> wrote: >>> >>> On 26/05/2025 10:26, Aijun Wang wrote: >>> No, summary can’t achieve the same aim of the “Explicit Withdrawn Signal”, >>> for example, switch back to the application’s original state. >>> you don't understand the basic operation of the protocol. >>> 1. prefix p1/32 is summarized with p2/16. P1 is reachable via >>> summary 2. router that generated p1 went down 3. UPA for p1/32 was >>> generated 4. router that generated p1 came back 5. UPA was removed >>> and we are back to state (1) Peter >>> >>> 发件人: Peter Psenak [mailto:[email protected]] >>> 发送时间: 2025年5月26日 15:41 >>> 收件人: Aijun Wang mailto:[email protected] >>> 抄送: mailto:[email protected] >>> 主题: Re: 答复: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> On 26/05/2025 03:29, Aijun Wang wrote: >>> Then one new deficiency for the mechanism is emerging: >>> >>> The lack of the Explicit Withdrawn Signal(EWS) when the prefix is reachable >>> again. >>> Please note, stop sending the UPA message doesn’t mean the prefix is >>> reachable again. >>> If there is no EWS, then the network can’t back to its original state >>> before the UPA signaling when the reachable of prefix recover. >>> there is still a summary that covers the prefix reachability. >>> Peter >>> >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> >>> >>> 发件人: Peter Psenak [mailto:[email protected]] >>> 发送时间: 2025年5月23日 19:11 >>> 收件人: Aijun Wang mailto:[email protected] >>> 抄送: mailto:[email protected] >>> 主题: Re: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> On 23/05/2025 12:48, Aijun Wang wrote: >>> Then nothing needs to be standardized when the prefix becomes reachable >>> again. >>> >>> 1) In some critical scenarios, when the ABR sends one UPA message out and >>> the prefix becomes reachable immediately, what the ABR can do is to stop >>> advertising UPA. >>> and that is exactly what the text says. >>> Peter >>> >>> >>> The sent UPA message will eventually trigger the action on the receiver, >>> even the prefix is reachable immediately. >>> >>> 2) In normal situations, the ABR sends the UPA message for some time and >>> stop sending it further. At this time, when the prefix becomes reachable, >>> nothing needs to be done at ABR. >>> >>> The receiver will also act on the UPA signaling. >>> >>> It’s irrelevant then whether the prefix is reachable or not after the UPA >>> signaling is sent out. >>> >>> >>> Aijun Wang >>> China Telecom >>> >>> >>> >>> >>> On May 23, 2025, at 17:18, Peter Psenak mailto:[email protected] wrote: >>> On 23/05/2025 10:10, Aijun Wang wrote: >>> Then, what’s the differences between the two statements: >>> first is for case when the prefix reachability is not regained after UPA >>> was generated. >>> Second is when the prefix reachability was regained before the UPA was >>> withdrawn. It basically says UPA must be withdrawn at the time the prefix >>> becomes reachable. >>> >>> >>> “UPA advertisements SHOULD therefore be withdrawn after some amount of >>> time, that would provides sufficient time for UPA to be flooded >>> network-wide and acted upon by receiving nodes, but limits the presence of >>> UPA in the network.” >>> >>> And: >>> >>> “ABR or ASBR MUST withdraw the previously advertised UPA when the reason >>> for which the UPA was generated was lost - e.g. prefix reachability was >>> restored or its metric has changed such that it does not represent the >>> protocol specific maximum prefix metric.” >>> >>> Here, does “withdraw” just mean to “stop advertisement”? >>> yes. >>> Peter >>> >>> If no, what’s the mechanism of second “withdraw”? >>> >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> 发件人: mailto:[email protected] >>> [mailto:[email protected]] 代表 Peter Psenak >>> 发送时间: 2025年5月23日 14:55 >>> 收件人: Aijun Wang mailto:[email protected]; >>> mailto:[email protected] >>> 主题: [Lsr] Re: 答复: I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> On 23/05/2025 03:32, Aijun Wang wrote: >>> Hi, All: >>> >>> I must point out that the updated draft doesn't address previous issues >>> that described in [1]. >>> Especially, the activation of flawed LSInfinity feature(there is detail >>> analysis for this flawed feature that is defined in OSPF 2328). >>> >>> And, some updated contents will deteriorate the traffic pattern within the >>> network. >>> For example, It says: “ABR or ASBR MUST withdraw the previously advertised >>> UPA when the reason for which the UPA was generated was lost”. >>> The above requirement will advertise the specific prefixes within the >>> network, which will weaken the original summary effect, and attract the >>> traffic via one or some of ABRs. >>> no, above is not true, the new text does not say to advertise reachablity >>> for a summarized prefix, it only talks about removing the previously >>> advertised UPA. >>> Please read carefully before commenting. >>> Peter >>> >>> >>> [1]: Reasons of abandoning UPA: >>> https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-u >>> p >>> a >>> -proposal/ >>> >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> >>> >>> >>> >>> -----邮件原件----- >>> 发件人: mailto:[email protected] >>> [mailto:[email protected]] 代表 >>> mailto:[email protected] >>> 发送时间: 2025年5月22日 21:20 >>> 收件人: mailto:[email protected] >>> 抄送: mailto:[email protected] >>> 主题: [Lsr] I-D Action: >>> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> >>> Internet-Draft draft-ietf-lsr-igp-ureach-prefix-announce-06.txt is now >>> available. It is a work item of the Link State Routing (LSR) WG of the IETF. >>> >>> Title: IGP Unreachable Prefix Announcement >>> Authors: Peter Psenak >>> Clarence Filsfils >>> Daniel Voyer >>> Shraddha Hegde >>> Gyan Mishra >>> Name: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >>> Pages: 14 >>> Dates: 2025-05-22 >>> >>> Abstract: >>> >>> In the presence of summarization, there is a need to signal loss of >>> reachability to an individual prefix covered by the summary. This >>> enables fast convergence by steering traffic away from the node which >>> owns the prefix and is no longer reachable. >>> >>> This document describes how to use the existing protocol mechanisms >>> in IS-IS and OSPF, together with the two new flags, to advertise such >>> prefix reachability loss. >>> >>> The IETF datatracker status page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-an >>> n >>> o >>> unce/ >>> >>> There is also an HTMLized version available at: >>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-pref >>> i >>> x >>> -announce-06 >>> >>> A diff from the previous version is available at: >>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-ureach- >>> p >>> r >>> efix-announce-06 >>> >>> Internet-Drafts are also available by rsync at: >>> rsync.ietf.org::internet-drafts >>> >>> >>> _______________________________________________ >>> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email >>> to mailto:[email protected] >>> >>> >>> _______________________________________________ >>> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email >>> to mailto:[email protected] >>> >>> >>> >>> _______________________________________________ >>> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email >>> to mailto:[email protected] >>> >>> >>> _______________________________________________ >>> Lsr mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>> >> > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
