Hi Gyan,
Thanks for quit reply. Please see my comment in-line. BR, Feng 发件人: Gyan Mishra <[email protected]> 发送时间: 2026年7月22日 13:19 收件人: [email protected] 抄送: yimi zhang <[email protected]>; linchangwang <[email protected]>; [email protected]; spring <[email protected]>; [email protected] 主题: 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 <[email protected] <mailto:[email protected]> > wrote: Hi Gyan, Please see my answer in line. Changwang please correct me if something wrong. BR, Feng 发件人: Gyan Mishra <[email protected] <mailto:[email protected]> > 发送时间: 2026年7月21日 12:13 收件人: yimi zhang <[email protected] <mailto:[email protected]> > 抄送: [email protected] <mailto:[email protected]> ; spring <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> 主题: [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://datatracker.ietf.org/doc/html/draft-xuclad-sprin=-sr-service-chaining> https://datatrack=r.ietf.org/doc/html/draft-xuclad-spring-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 <[email protected] <mailto:[email protected]> > 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> <[email protected] <mailto:[email protected]> > 于 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://datatrac=er.ietf.org/doc/html/draft-yang-spring-sid-as-source-address-13> https://datatracker.ietf.org/=oc/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 -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ spring mailing list -- To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
