Hi Gyan,
Please see my answer in line. Changwang please correct me if something wrong. BR, Feng 发件人: Gyan Mishra <[email protected]> 发送时间: 2026年7月21日 12:13 收件人: yimi zhang <[email protected]> 抄送: [email protected]; spring <[email protected]>; [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. 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. 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. 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. 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. 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]
