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 <[email protected]> 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 <[email protected]> wrote: > >> 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]> wrote: >> >> 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.* >> >> 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 <[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]> 于 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> spring mailing list -- >> 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]
