Typo fixed on 1st major issue .. On Thu, Jul 23, 2026 at 8:48 PM Gyan Mishra <[email protected]> wrote:
> Robert > > We have had lengthy discussions on the other thread and what is proposed > in that draft vendors have already implemented. So we are just > backtracking thanks to the authors to take this on and update the standards. > > As you have discussed with Israel the next hop needs to be the tunnel and > not the loopback next hop for case where the loopback is not part of > locator block. I t believe there was agreement that you accepted that for > SRv6 the SRv6 tunnel locator next hop needs to be used. > > Major issues with the draft below: > > 1st major issue with this subject draft is it proposes using the source IP > of the SRv6 tunnel to be the service Sid which is part of IP VPN VRF. > That technically won’t work as just as the loopback IGP best path selection > lowest metric tie breaker next hop must be in the global table so does the > source IP for the tunnel must be in the global table. > > 2nd major issue with this draft is that there is only one source address > you can set for the SRv6 tunnel. > > 3rd major issue is how would that work if you have many endpoint behaviors > per vrf or CE Sid allocation that many Sid addresses in different vrf which > would you even pick. > > 4th major issue that the SRv6 tunnel carries all the IP VPN VRFs and not > just the single VRF service Sid endpoint behavior that you decide to set > the source address per this draft. > > Kind Regards > > Gyan > > On Thu, Jul 23, 2026 at 3:59 PM Robert Raszuk <[email protected]> wrote: > >> Gyan, >> >> BGP NEXT_HOP is today and should remain the actual forwarding address. If >> that is to be SID so be it. If that is to be tunnel endpoint so also be it. >> >> We can not allow for reasons already discussed in the other thread such a >> mess that NEXT_HOP in MP_REACH is carried and not used for forwarding. That >> is nonsense. >> >> So if this draft is proposing the right thing it deserves to be carefully >> reviewed. I am yet to read it , but so far noticed your bashing of it and >> using draft-vroonen-idr-bgp-bestpath-nh-selection-03 as a whip which >> would be wrong approach. >> >> Needless to say NEXT_HOP should remain in the global table of some Algo >> irrespective if this is service SID, tunnel endpoint or plain loopback >> >> Thx, >> R. >> >> On Thu, Jul 23, 2026 at 9:01 PM Gyan Mishra <[email protected]> >> wrote: >> >>> >>> This draft is trying to fix an issue where some random block not within >>> the locator block is being used as the egress PE loopback and is used as >>> the source address of the SRv6 tunnel. >>> >>> That is exactly what Oliver’s next hop selection provides a solution for >>> the case where some random block is being used that is not within the >>> locator range for all PE loopbacks. >>> >>> By using the next hop selection draft and setting the forwarding address >>> the problem is resolved with the firewall ping issue and traffic is >>> symmetrical along the correct optimal SLA path. >>> >>> Thanks >>> >>> Gyan >>> On Thu, Jul 23, 2026 at 2:53 PM Gyan Mishra <[email protected]> >>> wrote: >>> >>>> >>>> It is related as the draft under adoption call goal is to change the >>>> source address loopback for SRv6 tunnels to use the service Sid endpoint >>>> behavior in the IP VPN VRF as the source. There are many issues with doing >>>> so. >>>> >>>> As the best path selection draft fixes a sub optimal routing issue >>>> which the firewall ICMP issue is directly related which proposes to not >>>> use the egress PE loopback next hop and use the endpoint behavior service >>>> Sid next hop as the source address to resolve the firewall ping issue. By >>>> using the Oliver’s best path selection draft the path taken uses the >>>> correct algo locator SLA based path with the forwarding address set to the >>>> SRv6 locator tunnel next hop and not the loopback next hop or this draft >>>> under adoption call use of service Sid as the source IP for the SRv6 >>>> tunnels. >>>> >>>> The source IP of the SRv6 tunnel should remain the loopback and not >>>> what is proposed by this draft along with using the forwarding address for >>>> the flex algo SLA path selection would resolve the problem this draft is >>>> trying to address. >>>> >>>> Kind Regards >>>> >>>> Gyan >>>> On Thu, Jul 23, 2026 at 5:36 AM Robert Raszuk <[email protected]> >>>> wrote: >>>> >>>>> 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]
