Gyan and Yimi: We will be starting additional discussions on draft-vroonen-idr-bgp-bestpath-nh-selection-02 and other next Hop path selections in the 3-4 weeks after IETF.
IDR is also discussing revisions to the flow specification for firewall filters and action distribution. There are adopted drafts for SRv6 flow specification distribution. Adopted drafts for Flow specification (FS) for SRv6 are: 1) draft-ietf-idr-flowspec-srv6 This defines flow specification (FS) filter for Flow Specification version 2 (FSv2) for Some Parts of SID [RFC8986] defines the format of SID is LOC:FUNCT:ARG::. This draft specifies filters encoded as: Encoding: <type, LOC-Len, FUNCT-Len, ARG-Len, [op, value]+> 2) draft-ietf-idr-ts-flowspec-srv6-policy – Defines flow specification (FS) technology that combines Flow Specification (RFC8955, RFC8956) NLRI plus BGP attributes to enable SRv6 VPN filtering [RFC9252] and redirection of traffic. For SRv6 scenarios, this draft suggests sending 3 the following BGP attributes and FS NLRI [RFC8955] [RFC8956] to srv6 Headend to steer traffic into SRv6 Policy 1) Color Extended Community, 2) Flow-spec Redirect to IPv6 Extended Community, and 3) BGP Prefix-SID. This technology also specifies tail-end actions. If these two existing capabilities do not aid, then IDR WG welcomes new proposals. Some of the new proposals being suggested to IDR WG are: 1) draft-li-idr-flowspec-sr-policy-04 - Action to redirect to an SR SID using a Community container 2) draft-chen-idr-srv6-flowspec-path-redirect-00 – Extended Community path redirect to SID Sue Hares (IDR chair) From: Gyan Mishra <[email protected]> Sent: Tuesday, July 21, 2026 12:13 AM To: yimi zhang <[email protected]> Cc: [email protected]; spring <[email protected]>; [email protected] Subject: [spring] Re: Call for adoption: draft-yang-spring-sid-as-source-address 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 NkdkJdXPPEBannerStart Be Careful With This Message From (Gyan Mishra <[email protected]>)<https://godaddy2.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f9422fdbc30e02a678ee80f9215e1e3d9cafaee923c96dc251a186f13954123224b7f425df7a2ac1c5bdbfd24086f3d603f075ff393a7d34b95bfcbb8d3dd94ddf53121d4778164fc2c62e17dbe8d0878814c7101cd0d163a9c8d1a9441c4bb8c0027508ef97116c2fe89c5a3094d1b1f83df65e978541958fe5f4d8ef89d367ac3ec759e7b61c047565238a5b2cb11bfade3fcc4daebcfa8a85554644ec438744e7fdc8f7634dc35a1a585620c7b08f9a61f4e97a50289da428d608a031fe2543ec1202fba4f732c42366d18713deed3600f2ac57662a0de> Learn More<https://godaddy2.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f9422fdbc30e02a678ee80f9215e1e3d9cafaee923c96dc251a186f13954123224b7f425df7a2ac1c5bdbfd24086f3d603f075ff393a7d34b95bfcbb8d3dd94ddf53121d4778164fc2c62e17dbe8d0878814c7101cd0d163a9c8d1a9441c4bb8c0027508ef97116c2fe89c5a3094d1b1f83df65e978541958fe5f4d8ef89d367ac3ec759e7b61c047565238a5b2cb11bfade3fcc4daebcfa8a85554644ec438744e7fdc8f7634dc35a1a585620c7b08f9a61f4e97a50289da428d608a031fe2543ec1202fba4f732c42366d18713deed3600f2ac57662a0de> Potential Impersonation The sender's identity could not be verified and someone may be impersonating the sender. Take caution when interacting with this message. NkdkJdXPPEBannerEnd 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dxuclad-2Dspring-2Dsr-2Dservice-2Dchaining&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=0cco8eqm9OndIMj5V4Zh_1MK3fq-j5GvbN3pIJgYgVn1ZgghUWCIYwwMvbW_XTDg&s=jE7UdPvA-WPuB5FsIL3W-8ZirwkHiMmX3_Nbx0KavCg&e=> 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]<mailto:[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]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dyang-2Dspring-2Dsid-2Das-2Dsource-2Daddress-2D13&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=0cco8eqm9OndIMj5V4Zh_1MK3fq-j5GvbN3pIJgYgVn1ZgghUWCIYwwMvbW_XTDg&s=2ArNLVS8O7BMAhRK6O_u88-BB3LY3M30U_RV_uXzERk&e=> ____________________________________________________________________________________________________________ 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ spring mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
