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. 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]
