I spoke with the authors and they plan to update the draft with my suggestion.
With the update I support adoption. Thanks Gyan On Mon, Jul 27, 2026 at 11:33 PM Gyan Mishra <[email protected]> wrote: > 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. >>> >>> >>> >>> 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]
