Hi Gyan, Thank you for your valuable feedback. We will incorporate your suggestions into the next version of the document.
Thanks, Changwang -----邮件原件----- 发件人: Gyan Mishra <[email protected]> 发送时间: 2026年7月28日 11:34 收件人: [email protected] 抄送: Robert Raszuk <[email protected]>; [email protected]; spring <[email protected]>; [email protected] 主题: Re: [spring] Re: Call for adoption: draft-yang-spring-sid-as-source-address HI Feng & authors To make the draft more useful with the concept you are trying to do you could angle it a different way. If you change the problem statement to not say asymmetrical routing that firewall is dropping the flow as this is not TCP traffic so the problem statement is not correct. You could update the use case and say to avoid DPI as firewalls are not SRv6 aware and cannot filter on the payload. However with this drafts solution I can now have 1 flow per CE or per vrf Sid allocation basically now you can do per flow level TCP stateful filtering through the firewall without requiring SRv6 proxy or firewall supporting SRv6. If you are able to make the change to the problem statement then I would happily support adoption. Kind Regards Gyan On Fri, Jul 24, 2026 at 2:39 AM Gyan Mishra <[email protected]> wrote: > Hi Feng > > Thank you for your patience going through all the relevant questions I > have on the draft. > > There are a lot of things that bother me about this draft which is > why I am speaking up. > > How was the feedback from Spring WG when you presented the draft ? > > Were any concerns raised as the ones I am mentioning? > > I think overall there are two things that bother me from a > standardization perspective. Also doing something super corner case > that could lead to issues and instability if implemented is what I am worried > about. > The protocol next hop is the SRv6 tunnel which sits in the global > table but now using the source address that is in a VRF and not in the > global table to me seems could have some unknown consequences. I have > done lots of R&D testing with SRv6 and I am surprised that this works > and would need to analyze further how it’s possible that it works. > > The second thing that also really bothers me about this draft is that > for each locator you are now adding more complexity it seems as now > you have individual SRv6 tunnel SRv6 encapsulation h.encap.red per VRF > source address. You are now essentially creating per flow state with > each tunnel session per locator anchor. That seems to be pretty crazy > overhead unnecessary state you are creating where SRv6 is meant to be > ultra simplistic and stateless. You could do multipoint something > similar to P2MP RSVP-TE with Leaf AD S2L but way super complex. > Imagine you would have a 1-1 mapping per-vrf or per-CE Sid allocation > mode to number of SRv6 tunnels which is an insane amount of state. > > See my issue with the problem statement detailed write up as there is > a big disconnect as far as TCP sync state and dropping flow versus two > unidirectional SRv6 6in6 tunnels in either direction. Most firewalls > don’t support 6in6 DPI but as long payload flow is symmetrical as > shown in your diagram nothing gets dropped. > > I will go over in more detail in my responses in-line. > > On Thu, Jul 23, 2026 at 11:18 PM <[email protected]> wrote: > >> Hi Gyan, >> >> >> >> We appreciate the time and effort you have put into raising these >> concerns. I think this draft does not have the issues that you mentioned ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。 禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。 如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
