Gyan, You are either mistaken that every vendor does it already in a unified way or you do not fully understand the solution proposed.
See what is proposed is this: Path Resolution tuple (UPDATE) ● Replaced the previous "forwarding address and context" model with a formalized Path Resolution Tuple, directly addressing IDR group feedback. ● The Key of the tuple can be: ○ NEXT_HOP ○ The Tunnel Egress Endpoint Sub-TLV contained in Tunnel Encapsulation attribute defined in [RFC9012] ○ SRv6 SID Information Sub-TLV contained within L3 or L2 SRv6 SID defined in [RFC9252] ● The optional context of the tuple can be: ○ The Tunnel Encapsulation attribute defined in [RFC9012] ○ The Color extended community defined in [RFC9012] ○ The SRv6 Sub-TLV and Sub-sub-TLV contained within L3 or L2 SRv6 SID TLV as defined in [RFC9252] other than the SID itself And I am perfectly fine with providing the optional context to next hop tracking and next hop resolution. What I am strongly against (for lots of technical reasons) is to disregard BGP NEXT_HOP and use it only for additional tracking while not using it for forwarding. So the key in the BGP protocol for best path selection has always been NEXT_HOP (when we get to such best path step). RFCs 9012 & RFC 9252 *only* ask for path validation with additional attribute context. They do not go as far as draft-vroonen is aiming not to use NEXT_HOP in best path selection. I have already provided on IDR list lot's of issue why replacing BGP NEXT_HOP (without explicit CLI or YANG augmentation) is really a bad thing. But for SPRING WG interest another operational consideration is important. Imagine that you are using SRv6 for your services across 10K PEs in your OAD. Take two examples - VPN option B - on ASBRs you rewrite BGP NEXT_HOP. There is no procedure to rewrite service SID attribute on those ASBRs. How is that service going to work where your locators may no longer be reachable across ASNs ? - VPN option C - today you register for tracking 10K next hops. With the current proposal in draft-vroonen you would register for tracking 10K BGP NEXT_HOPs and 10K SRv6 service SID endpoints. And why would you react when NEXT_HOP changes or goes down if your SRv6 segment endpoint is all fine ? So recognizing the situation we are in I suggest to simply place either tunnel endpoint RFC9012 (if different from BGP NEXT_HOP) into BGP MP_REACH_NLRI NEXT_HOP field or do the same with service SID (RFC9252). Attributes can still carry them as well for backwords compatibility - but this approach is pragmatic and solves the issue. Yes when registering such next hop if additional context is carried in RFC9012/RFC9252 attributes or color is carried in EC those can be augmenting BGP NEXT_HOP when registering it for tracking. So simple and fully backwards compatible solution. Can you or anyone tell me why would we not want to go that path ? Cheers, Robert On Fri, Jul 24, 2026 at 3:07 AM Gyan Mishra <[email protected]> wrote: > Hi Robert > > Just to recap on this thread with Spring WG on the list > that you are in agreement with the problem statement and you understand > that the solution has been implemented by every vendor out there. > > > https://datatracker.ietf.org/doc/html/draft-vroonen-idr-bgp-bestpath-nh-selection-03 > > > The gap is that you don’t like the solution with the forwarding address. > > Correct me if I am wrong. > > The IDR draft above plays heavily into the adoption of the subject draft. > > So I think it’s good for the Spring WG members to read through this draft > as it’s most critical for segment routing operation for both SR-MPLS and > more significantly the SRv6 data planes. > > Kind Regards > > Gyan > > > 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 Sid locator 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]
