Dear authors I reviewed the draft and have some comments on the draft as it relates to a draft being adopted in IDR which may help shed some light on your firewall issue.
Since the SRv6 tunnel carries all End.DT4 and End.DT6 traffic how can you selectively make the source address one specific service Sid endpoint 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 address was set to service Sid in VRF B the ping would fail since you cannot ping between the VRFs. The SRv6 tunnel source address is recommended by some vendors to use the loopback addressed from Algo 0 main locator block for the source address as well for operator flexibility can also be addressed by a completely different block range. There is an issue that exists with BGP next hop resolution that is being addressed in IDR WG with adoption call of draft below which has been implemented by most vendors when the next hop resolution uses the egress PE loopback in case where the loopback is addressed using a block different then the egress PE SRv6 locator block rib datastore. That is exactly the issue with the firewall ICMP issue and this IDR draft below addresses that exact issue. Draft-vroonen-idr-bgp-bestpath-nh-selection-02 The issue is related to BGP best path selection using the egress PE next hop loopback for next hop resolution in cases where the loopbacks are addressed out of a different block then the SRv6 locator for Algo 0 or any 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 draft uses a forwarding address that is set so that the next hop resolution uses this address from the SRv6 locator flex algo datastore and not the traditional egress PE loopback for the next hop resolution. This solution has already been implemented by most all vendors and now we are just updating BGP next hop resolution RFC 4271 with this IETF draft. The issue you are having with the firewall and ICMP ping issue I believe will be solved with this draft mentioned above. I did want to note that SRv6 TE steering can work through a firewall using SRv6 proxy draft below. https://datatracker.ietf.org/doc/html/draft-xuclad-spring-sr-service-chaining Also other than use of SR Proxy feature there is a way to service chain and steer traffic through a firewall which is by crafting next Sid or replace Sid policy to point to egress device locator node Sid on other side of firewall and to do so in both directions which is possible. Another point to note is that as all firewalls today are not SRv6 aware that by not using SRv6 proxy for SRv6 decap and encap the firewall in SRv6 path is not capable of DPI to parse statefully the inner payload IPv4 or IPv6 so defeating the firewall stateful packet filtering inspection capability. Recommendation is keeping firewall outside the SRv6 domain and use BGP routing path attributes to steer traffic through firewall or use SRv6 Proxy. Kind Regards Gyan On Mon, Jul 20, 2026 at 11:51 PM yimi zhang <[email protected]> wrote: > Hi WG, > > I would like to express my support for the WG adoption of the draft. > > This draft addresses a issue caused by firewalls in SRv6 deployments by > using SID as the source address. > > Thanks, > Yimi > > > <[email protected]> 于 2026年7月10日周五 20:53写道： > >> Dear WG, >> >> >> >> This message starts a 3-week WG adoption call, ending 2026-07-31, for >> draft-yang-spring-sid-as-source-address-13 [1] >> >> >> After review of the document, please indicate support (or not) for WG >> adoption of the document to the mailing list. >> Please also provide comments/reasons for your support (or lack thereof) >> as this 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 >> explicitly. This gives the chairs an indication of the energy level of >> people in the working group willing to work on the document. >> >> Thanks! >> Alvaro, Bruno, Joel >> >> >> >> [1] >> https://datatracker.ietf.org/doc/html/draft-yang-spring-sid-as-source-address-13 >> >> >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles 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 messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information 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 >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> spring mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
