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. > > > > See my comments in-line. > > > > BR, > > Feng > > > > *发件人:* Gyan Mishra <[email protected]> > *发送时间:* 2026年7月24日 8:54 > *收件人:* Robert Raszuk <[email protected]> > *抄送:* [email protected]; spring <[email protected]>; > [email protected] > *主题:* [spring] Re: Call for adoption: > draft-yang-spring-sid-as-source-address > > > > I do not support adoption of this draft for the reasons below: > > > > Major issues with the draft below: > > > > 1st major issue with this subject draft is it proposes using the source IP > of SRv6 tunnel to use the service sid endpoint behavior 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. > > > > [fyang] We would like to gently point out that the draft does not modify > any control‑plane protocol, and the source address is not used for routing > decisions. In fact, if people try a very simple test that SRv6 tunnel > source address does not in global table, and that works fine. So we believe > there is no requirement for the source address to be in the global table. > > Gyan> As I started above I am very surprised this works and would have > to be throughly tested that with this corner case solution it’s not > creating any instability. Maybe some of what I have mentioned can be added > to a operational considerations section. > > 2nd major issue with this draft is that there is only one source address > you can set for the SRv6 tunnel. > > > > [fyang] Single source address is the current implementation model. This is > unnecessary restriction. We would respectfully note that the why not move > beyond this. > > Gyan> For simplicity of a single SRv6 tunnel and not creating x number > of tunnels for every source address per vrf or per CE. > In section 1 the problem statement is mentioned relating to the issue with asymmetrical flow and the firewall blocking the flow, The SRv6 tunnel is not a TCP or UDP flow, Most firewalls have TCP state sync enabled for asymmetric flows that if the source packet arrives with TCP SYN then the response packet TCP SYN/AAK should be received in the reverse direction or the flow is dropped. If the TCP SYN/ACK is not received the the flow is dropped by the firewall due to asymmetrical routing. We absolutely do not have asymmetrical routing here as well don’t even have a TCP flow for that matter. SRv6 uses the concept of explicit tunneling vs implicit tunneling as with MPLS using a locator prefix node Sid that is advertised that draws traffic across the algo 0 or flex also path based on the AG/EAG link affinity defining the path for that plane. The head SRv6 encap h.encap.red creates the outer header and reads the SRH based on active Sid or SRv6 compression performs the topological next or replace Sid function. So the DA address hop by hop is changing for full Sid or SRv6 compression next or replace Sid. Depending upon where the firewall sits the firewall in the middle of the path would be an ephemeral DA address. So the main point here is the firewall seems encapsulated IPv6 in IPv6 packets with epidermal DA address and it’s the same for the unidirectional tunnel in both directions if SR policy has a static or dynamic Sid list steering through the firewall. For both SRv6 full Sid and SRv6 compression the source addres is set to the loopback but what the firewall seems in the middle of the path as shown in figure 1 is an ephemeral DA based on the Sid list for SE policy but if no policy then the DA address would egress PE Sid + endpoint behavior. However since the tunnels are unidirectional the firewall even with stateful packet inspection would not drop any packets since it’s a one way flow. So you have two one way tunnel flows in opposite directions Forward direction PE1 - FW - PE2 - single undirectional flow Reverse direction PE2 - FW - PE1 - single unidirectional flow Both flows are independent from each other and should never get dropped by the stateful firewall The key here is stateful firewall is looking for TCP state so the two unidirectional tunnels will pass through not dropped with TCP stateful packet inspection enabled. Most firewalls as I mentioned earlier in our thread do not support DPI for 6 in 6 tunnel however even if DPI was possible and the traffic was routed symmetrically the traffic would not be dropped for inner payload TCP flows. I don’t agree with the problem statement. You are trying to fix something that is not broken and at the same time adding tremendous unnecessary complexity to SRv6. > 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. > > > > [fyang] Selection among multiple sid can be found in the subject draft > section 2. And this has been presented in spring WG meeting. > > Gyan> That is fine however I don’t agree with the problem statement that > anything is broken. > 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. > > > > [fyang] We never propose to use same VRF sid for multipole VRF. While an > SR Policy or tunnel may carry traffic from multiple VRFs, each packet is > encapsulated independently: > > - Packets belonging to VRF-A use VRF-A's SID as the SA. > - Packets belonging to VRF-B use VRF-B's SID as the SA. > > Gyan> 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. 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. > > > Kind Regards > > > > Gyan > > > > On Thu, Jul 23, 2026 at 4:26 PM Robert Raszuk <[email protected]> wrote: > > Hi, > > > > I have read the draft and support the adoption. It is a well written > and useful document. > > > > It provides a solution to data plane consistency and symmetry for ICMP. > > > > While the draft is not explicitly discussing it - it also actually solves > the problem with BGP NEXT_HOP being accidentally different from Service > SIDs creating all sources of bgp related issues. > > > > The service SID used as source can be in the same time advertised in BGP > protocol NEXT_HOP via proper use of existing update-source knob. > > > > Kind regards, > > Robert > > > > > > On Fri, Jul 10, 2026 at 2:52 PM <[email protected]> wrote: > > 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 > > > > ____________________________________________________________________________________________________________ > > 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] > 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]
