[spring] Re: Call for adoption: draft-yang-spring-sid-as-source-address

[Gyan Mishra <[e-mail]>]

Hi Robert

Just to recap on this thread with Spring WG on the list
that you are in agreement with the problem statement and you understand
that the solution has been implemented by every vendor out there.

https://datatracker.ietf.org/doc/html/draft-vroonen-idr-bgp-bestpath-nh-selection-03


The gap is that you don’t like the solution with the forwarding address.

Correct me if I am wrong.

The IDR draft above plays heavily into the adoption of the subject draft.

So I think it’s good for the Spring WG members to read through this draft
as it’s most critical for segment routing operation for both SR-MPLS and
more significantly the SRv6 data planes.

Kind Regards

Gyan


On Thu, Jul 23, 2026 at 8:48 PM Gyan Mishra <[e-mail]> wrote:

> Robert
>
> We have had lengthy discussions on the other thread and what is proposed
> in that draft vendors have already implemented.  So we are just
> backtracking thanks to the authors to take this on and update the standards.
>
> As you have discussed with Israel the next hop needs to be the tunnel and
> not the loopback next hop for case where the loopback is not part of
> locator block.  I t believe there was agreement that you accepted that for
> SRv6 the SRv6 tunnel locator next hop needs to be used.
>
> Major issues with the draft below:
>
> 1st major issue with this subject draft is it proposes using the source IP
> of the Sid locator which is part of IP VPN VRF.  That technically won’t
> work as just as the loopback IGP best path selection lowest metric tie
> breaker next hop must be in the global table so does the source IP for the
> tunnel must be in the global table.
>
> 2nd major issue with this draft is that there is only one source address
> you can set for the SRv6 tunnel.
>
> 3rd major issue is how would that work if you have many endpoint behaviors
> per vrf or CE Sid allocation that many Sid addresses in different vrf which
> would you even pick.
>
> 4th major issue that the SRv6 tunnel carries all the IP VPN  VRFs and not
> just the single VRF service Sid endpoint behavior that you decide to set
> the source address per this draft.
>
> Kind Regards
>
> Gyan
>
> On Thu, Jul 23, 2026 at 3:59 PM Robert Raszuk <[e-mail]> wrote:
>
>> Gyan,
>>
>> BGP NEXT_HOP is today and should remain the actual forwarding address. If
>> that is to be SID so be it. If that is to be tunnel endpoint so also be it.
>>
>> We can not allow for reasons already discussed in the other thread such a
>> mess that NEXT_HOP in MP_REACH is carried and not used for forwarding. That
>> is nonsense.
>>
>> So if this draft is proposing the right thing it deserves to be carefully
>> reviewed. I am yet to read it , but so far noticed your bashing of it and
>> using  draft-vroonen-idr-bgp-bestpath-nh-selection-03 as a whip which
>> would be wrong approach.
>>
>> Needless to say NEXT_HOP should remain in the global table of some Algo
>> irrespective if this is service SID, tunnel endpoint or plain loopback
>>
>> Thx,
>> R.
>>
>> On Thu, Jul 23, 2026 at 9:01 PM Gyan Mishra <[e-mail]>
>> wrote:
>>
>>>
>>> This draft is trying to fix an issue where some random block not within
>>> the locator block is being used as the egress PE loopback and is used as
>>> the source address of the SRv6 tunnel.
>>>
>>> That is exactly what Oliver’s next hop selection provides a solution for
>>> the case where some random block is being used that is not within the
>>> locator range for all PE loopbacks.
>>>
>>> By using the next hop selection draft and setting the forwarding address
>>> the problem is resolved with the firewall ping issue and traffic is
>>> symmetrical along the correct optimal SLA path.
>>>
>>> Thanks
>>>
>>> Gyan
>>> On Thu, Jul 23, 2026 at 2:53 PM Gyan Mishra <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> It is related as the draft under adoption call goal is to change the
>>>> source address loopback for SRv6 tunnels to use the service Sid endpoint
>>>> behavior in the IP VPN VRF as the source.  There are many issues with doing
>>>> so.
>>>>
>>>> As the best path selection draft fixes a sub optimal routing issue
>>>> which the firewall ICMP issue is directly related which proposes to not
>>>> use  the egress PE loopback next hop and use the endpoint behavior service
>>>> Sid next hop as the source address to resolve the firewall ping issue.  By
>>>> using the Oliver’s best path selection draft the path taken uses the
>>>> correct algo locator SLA based path with the forwarding address set to the
>>>> SRv6 locator tunnel next hop and not the loopback next hop or this draft
>>>> under adoption call use of service Sid as the source IP for the SRv6
>>>> tunnels.
>>>>
>>>> The source IP of the SRv6 tunnel should remain the loopback and not
>>>> what is proposed by this draft along with using the forwarding address for
>>>> the flex algo SLA path selection would resolve the problem this draft is
>>>> trying to address.
>>>>
>>>> Kind Regards
>>>>
>>>> Gyan
>>>> On Thu, Jul 23, 2026 at 5:36 AM Robert Raszuk <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Could someone explain how this draft
>>>>> https://datatracker.ietf.org/doc/draft-yang-spring-sid-as-source-address/
>>>>> is related in any form or shape
>>>>> to draft-vroonen-idr-bgp-bestpath-nh-selection-03 ?
>>>>>
>>>>> Thank You,
>>>>> R.
>>>>>
>>>>>
>>>>> M
>>>>>
>>>>> On Thu, Jul 23, 2026 at 11:04 AM Gyan Mishra <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hi Feng
>>>>>>
>>>>>> Responses in-line
>>>>>>
>>>>>> [fyang] My understanding is that SRv6 tunnels work in one direction
>>>>>> and do not participate in BGP path selection. So, the selection of source
>>>>>> addresses has no impact on traffic forwarding and will not introduce
>>>>>> forwarding failures. I am not sure if I fully grasp your point here.
>>>>>>
>>>>>>  Gyan> Yes the SRv6 tunnels are uni directional similar to MPLS LSP.
>>>>>> However the tunnel does participate in BGP best path selection  lowest IGP
>>>>>> metric tie breaker when the PE Lookbook is allocated out of the locator
>>>>>> block the next hop is the loopback which essentially takes the SRv6 locator
>>>>>> tunnel path.  If the loopback is addressed from some other block not part
>>>>>> of locator block which I mentioned addresses your firewall issue then a
>>>>>> forwarding address feature is set for the next hop to use the SRv6 locator
>>>>>> tunnel path in each direction making traffic symmetrical through your
>>>>>> firewall.  This is addressed in draft below and solves your problem.
>>>>>>
>>>>>>
>>>>>> https://datatracker.ietf.org/doc/html/draft-vroonen-idr-bgp-bestpath-nh-selection-03
>>>>>>
>>>>>> For ICMP cases, for SRv6 ping, a per-VPN-route SID alone cannot be
>>>>>> reachable via ping regardless of source address. For ICMP error messages
>>>>>> generated by transit nodes, if we use a loopback address as the source,
>>>>>> both the source and destination address of ICMP errors are the global
>>>>>> address. When the ingress PE receives these ICMP messages, it cannot
>>>>>> forward it back to the corresponding VPN instance. If we use a service SID
>>>>>> as the source address, the service SID inherently carries VPN context. This
>>>>>> gives us a way to extract the VPN association information from the ICMP
>>>>>> packet. The most straightforward engineering solution is to configure a
>>>>>> dedicated per-VPN-SID route inside the global routing table. Of course,
>>>>>> doing so is not suggested.
>>>>>> Gyan> With MPLS the next hop is implicit and is egress  PE loopback
>>>>>> single hop next hop tunnel in the global table.  For SRv6 it’s the same
>>>>>> however the tunnels is an explicit locator route defining the tunnel and
>>>>>> not implicit like MPLS and thus the explicit SRv6 tunnel path must be used
>>>>>> for low latency cSPF flex algo SLA.  We never want the underlay to be
>>>>>> pingable my customer traffic in a VRF which should be isolated which it
>>>>>> is.  So the ping fails as described from operator SP perspective.  The ping
>>>>>> through the firewall goes over the SRv6 tunnel and can be asymmetrical or
>>>>>> symmetrical is fine and the ping VRF to VRF between any PE AC end device
>>>>>> should work fine going through a firewall with no issues.
>>>>>>
>>>>>> On Wed, Jul 22, 2026 at 4:58 AM <[e-mail]> wrote:
>>>>>>
>>>>>>> Hi Gyan,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks for quit reply.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please see my comment in-line.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> BR,
>>>>>>>
>>>>>>> Feng
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *发件人:* Gyan Mishra <[e-mail]>
>>>>>>> *发送时间:* 2026年7月22日 13:19
>>>>>>> *收件人:* [e-mail]
>>>>>>> *抄送:* yimi zhang <[e-mail]>; linchangwang <
>>>>>>> [e-mail]>; [e-mail]; spring <
>>>>>>> [e-mail]>; [e-mail]
>>>>>>> *主题:* Re: [spring] Re: Call for adoption:
>>>>>>> draft-yang-spring-sid-as-source-address
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Feng
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Responses in-line
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Gyan
>>>>>>>
>>>>>>> On Tue, Jul 21, 2026 at 8:45 PM <[e-mail]> wrote:
>>>>>>>
>>>>>>> Hi Gyan,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please see my answer in line. Changwang please correct me if
>>>>>>> something wrong.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> BR,
>>>>>>>
>>>>>>> Feng
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *发件人:* Gyan Mishra <[e-mail]>
>>>>>>> *发送时间:* 2026年7月21日 12:13
>>>>>>> *收件人:* yimi zhang <[e-mail]>
>>>>>>> *抄送:* [e-mail]; spring <[e-mail]>;
>>>>>>> [e-mail]
>>>>>>> *主题:* [spring] Re: Call for adoption:
>>>>>>> draft-yang-spring-sid-as-source-address
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dear authors
>>>>>>>
>>>>>>> I reviewed the draft a=d have some comments on the draft as it
>>>>>>> relates to a draft being adopted i= IDR which may help shed some light on
>>>>>>> your firewall issue.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Since the SRv6 tunnel carries all End.DT4 and End.DT6 traffic how
>>>>>>> =an you selectively make the source address one specific service Sid
>>>>>>> endpoi=t  as that service Sid is only reachable for that specific VRF. =So
>>>>>>> let’s say you had a firewall in VRF A and the tunnel source add=ess
>>>>>>> was set to service Sid in VRF B  the ping would fail since you ca=not ping
>>>>>>> between the VRFs.
>>>>>>>
>>>>>>> *[fyang] The simplest approach is explicit configuration assignment:
>>>>>>> operators can bind a dedicated SID as the source address for a specific
>>>>>>> VRF, access circuit (AC), or IP prefix respectively.*
>>>>>>>
>>>>>>> Gyan>  Each VRF has a service SID  endpoint behavior End.DT4,
>>>>>>> End.DT6, End.DT46.  The SRv6 tunnel carries all VPN traffic and not just
>>>>>>> the one VRF that you use the service Sid as the source address for the SRv6
>>>>>>> tunnel.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Example:
>>>>>>>
>>>>>>> Locator fc00:0:1::/48
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> VRF A
>>>>>>>
>>>>>>> fc00:0:1:e000. -> This IP is in vrf and so cannot ping locator in
>>>>>>> global table
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> VRF B
>>>>>>>
>>>>>>> fc00:0:1:e001 -> This IP is in vrf and so cannot ping locator
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The source address has to be in the global table and not in the VRF
>>>>>>> as when using the service Sid as the source address so that the source
>>>>>>> address is reachable by the locator. That is why normally in most cases the
>>>>>>> loopback0 is addressed out of the Algo 0 Main in the global table.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> However if the loopback is addressed from a block different then the
>>>>>>> locator block then the BGP best path selection forwarding address set must
>>>>>>> be used as the next hop and not the loopback which is not reachable by the
>>>>>>> locator.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [fyang] My understanding is that SRv6 tunnels work in one direction
>>>>>>> and do not participate in BGP path selection. So, the selection of source
>>>>>>> addresses has no impact on traffic forwarding and will not introduce
>>>>>>> forwarding failures. I am not sure if I fully grasp your point here.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For ICMP cases, for SRv6 ping, a per-VPN-route SID alone cannot be
>>>>>>> reachable via ping regardless of source address. For ICMP error messages
>>>>>>> generated by transit nodes, if we use a loopback address as the source,
>>>>>>> both the source and destination address of ICMP errors are the global
>>>>>>> address. When the ingress PE receives these ICMP messages, it cannot
>>>>>>> forward it back to the corresponding VPN instance. If we use a service SID
>>>>>>> as the source address, the service SID inherently carries VPN context. This
>>>>>>> gives us a way to extract the VPN association information from the ICMP
>>>>>>> packet. The most straightforward engineering solution is to configure a
>>>>>>> dedicated per-VPN-SID route inside the global routing table. Of course,
>>>>>>> doing so is not suggested.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The SRv6 tunnel so=rce address  is recommended  by some vendors to
>>>>>>> use the loopback=addressed from Algo 0 main locator block for the source
>>>>>>> address as well fo= operator flexibility can also be addressed by a
>>>>>>> completely different bloc= range.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There is an issue that exists with BGP nex= hop resolution that is
>>>>>>> being addressed in IDR WG with adoption call of dr=ft below which has been
>>>>>>> implemented by most vendors when the next hop reso=ution uses the egress PE
>>>>>>> loopback in case where the loopback is addressed =sing a block different
>>>>>>> then the egress PE SRv6 locator block rib datastore=
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That is exactly the issue with the firewall ICMP issue and this =DR
>>>>>>> draft below addresses that exact issue.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Draft-vroonen-idr-b=p-bestpath-nh-selection-02
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <=iv dir="auto" style="font-size:inherit">The issue is related to
>>>>>>> BGP best path selection using the egress P= next hop loopback for next hop
>>>>>>> resolution in cases where the loopbacks ar= addressed out of a different
>>>>>>> block then the SRv6 locator for Algo 0 or an= Flex Algo 128, 129 resulting
>>>>>>> in sub optimal routing where low latency SLA=traffic will flow along a best
>>>>>>> effort loopback algo 0 default rib path.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The solution in this draf= uses a forwarding address that is set so
>>>>>>> that the next hop resolution use= this address from the SRv6 locator flex
>>>>>>> algo datastore and not the tradit=onal egress PE loopback for the next hop
>>>>>>> resolution.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This solution has already been implemented =y most all vendors and
>>>>>>> now we are just updating BGP next hop resolution RF= 4271
>>>>>>>
>>>>>>> with this IETF draft.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The issue you are having with the firewal= and ICMP ping issue I
>>>>>>> believe will be solved with this draft mentioned ab=ve.
>>>>>>>
>>>>>>> *[fyang] I am not sure I got your point. This is how BGP can learn
>>>>>>> the correct nexthop in control protocol. Let’s say there are 2 flow, one
>>>>>>> for north**àsouth direction, the other for reverse direction. North**àsouth
>>>>>>> traffic would be: src=loopback(n),dest=sid(s), while reverse direction
>>>>>>> would be: src=loopack(s),dest=sid(n).If there is a firewall in between, the
>>>>>>> easiest way is to make the address be symmetrical. If BGP just specifies a
>>>>>>> forwarding address other than sid, it seems the issue still there.*
>>>>>>>
>>>>>>>  Gyan>  The flow is asymmetrical when the src=loopback in either
>>>>>>> direction is addressed out a block different from the locator block causes
>>>>>>> the ping to fail.  You are trying to address the issue by setting the
>>>>>>> source address to use the service sid vrf address which is wrong
>>>>>>> since the VRF sid cannot reach the locator.  Also if you set it to the
>>>>>>> service Sid of one vrf it breaks the tunnel for all other VRFs and that is
>>>>>>> why you have to either use loopback in locator block or use a different
>>>>>>> block for loopbacks but then use the forwarding adddress to set the next
>>>>>>> hop to a prefix in the appropriate locator block.
>>>>>>>
>>>>>>> I did want to not= that SRv6 TE steering can work through a firewall
>>>>>>> using SRv6 proxy draft =elow.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://datatrack=r.ietf.org/doc/html/draft-xuclad-spring-sr-service-chaining
>>>>>>> <https://datatracker.ietf.org/doc/html/draft-xuclad-sprin=-sr-service-chaining>
>>>>>>>
>>>>>>>
>>>>>>> <=span>
>>>>>>>
>>>>>>> Also other than use of  SR Proxy feature there i= a way to service
>>>>>>> chain and steer traffic through a firewall which is by c=afting next Sid or
>>>>>>> replace Sid policy to point to egress device locator no=e Sid on other side
>>>>>>> of firewall and to do so i= both directions which is possible.
>>>>>>>
>>>>>>> *[fyang] Not sure. The address would still be asymmetric if just
>>>>>>> change the next sid.*
>>>>>>>
>>>>>>>  Gyan>  Here I am t trying to show that you can steer through
>>>>>>> firewall and it works by pointing each side locator on other side of the
>>>>>>> firewall and the firewall blindly forwards the srv6 encapsulated packets.
>>>>>>> Downside is you are bypassing firewall functionality.
>>>>>>>
>>>>>>> Another point to note is that as all firewalls today are not =Rv6
>>>>>>> aware that by not using SRv6 proxy for SRv6 decap and encap the firewa=l in
>>>>>>> SRv6 path is not capable of DPI to parse statefully the inner payload=IPv4
>>>>>>> or IPv6 so defeating the firewall stateful packet filtering inspectio=
>>>>>>> capability.
>>>>>>>
>>>>>>> *[fyang] Comparing with SRv6 Proxy, I would say that just change the
>>>>>>> source address to SID does not need to strip/restore traffic header. That
>>>>>>> is much easier way.*
>>>>>>>
>>>>>>>  Gyan>  That does not fix the problem since the SRv6 IPv6 in IPv6
>>>>>>> tunnel packets, the firewall cannot process the inner payload DPI  which
>>>>>>> could be IPv4 or IPv6 for stateful packet inspection.  The only way to
>>>>>>> accomplish this is with SRv6 proxy doing encap and decap with firewall in
>>>>>>> line path in SRv6 domain.
>>>>>>>
>>>>>>> Recommend=tion is keeping firewall outside the SRv6 domain and use
>>>>>>> BGP routing path =ttributes to steer traffic through firewall or use SRv6
>>>>>>> Proxy.
>>>>>>>
>>>>>>> *[fyang] In enterprise market, it is quite common to put a firewall
>>>>>>> (without service chain) in between. Today most solution is to use optionA
>>>>>>> like solution at the cost of end-to-end srv6 advantages. *
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Gyan>  You cannot put firewall in SRv6 path since  the firewall
>>>>>>> cannot do stateful packet inspection DPI.  Until firewalls support SRv6
>>>>>>> natively the only solution is to move firewall to the edge security domain
>>>>>>> outside of SRv6 core.
>>>>>>>
>>>>>>> Kind Regards
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Gyan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 20, 2026 at 11:51 PM yimi zhang <[e-mail]>
>>>>>>> wrot=:
>>>>>>>
>>>>>>> Hi WG,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I would like to ex=ress my support for the WG adoption of the draft.
>>>>>>>
>>>>>>> <=r>
>>>>>>>
>>>>>>> This draft addresses a issue caused by firewalls=in SRv6 deployments
>>>>>>> by using SID as the source address.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yimi
>>>>>>>
>>>>>>> <=r>
>>>>>>>
>>>>>>> <[e-mail]> 于 2026年7月10潹7周五 20:53写道：
>>>>>>>
>>>>>>> Dear WG,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This message starts a 3-week WG=adoption call, ending 2026-07-31,
>>>>>>> for draft-yang-spring-sid-as-source-addr=ss-13 [1]
>>>>>>>
>>>>>>>
>>>>>>> After review of the document, please indicate support (or not) for
>>>>>>> WG adopt=on of the document to the mailing list.
>>>>>>> Please also provide comments/reasons for your support (or lack
>>>>>>> thereof) as =his is a stronger way to indicate your (non) support as this
>>>>>>> is not a vote=
>>>>>>> If you are willing to work on or review the document, please state
>>>>>>> this exp=icitly. This gives the chairs an indication of the energy level of
>>>>>>> people =n the working group willing to work on the document.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Alvaro, Bruno, Joel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> https://datatracker.ietf.org/=oc/html/draft-yang-spring-sid-as-source-address-13
>>>>>>> <https://datatrac=er.ietf.org/doc/html/draft-yang-spring-sid-as-source-address-13>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________=_____________________________________________________________________
>>>>>>>
>>>>>>> Ce message et ses pieces jointes peuvent contenir des informations confiden=ielles ou privilegiees et ne doivent donc
>>>>>>>
>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=ce message par erreur, veuillez le signaler
>>>>>>>
>>>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= electroniques etant susceptibles d'alteration,
>>>>>>>
>>>>>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou =alsifie. Merci.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This message and its attachments may contain confidential or privileged inf=rmation that may be protected by law;
>>>>>>>
>>>>>>> they should not be distributed, used or copied without authorisation.
>>>>>>>
>>>>>>> If you have received this email in error, please notify the sender and dele=e this message and its attachments.
>>>>>>>
>>>>>>> As emails may be altered, Orange is not liable for messages that have been =odified, changed or falsified.
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> spring mailing list -- [e-mail]
>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> spring mailing list --
>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>>
>>>>>>> _______________________________________________
>>>>>> spring mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>