Dear authors I reviewed the draft and have some comments on the draft as it relates to a draft being adopted in IDR which may help shed some light on your firewall issue.
The SRv6 tunnel source address is recommended by some vendors to use the loopback addressed from Algo 0 main locator block for the source address as well for operator flexibility can also be addressed by a completely different block range. There is an issue that exists with BGP next hop resolution that is being addressed in IDR WG with adoption call of draft below which has been implemented by most vendors when the next hop resolution uses the egress PE loopback in case where the loopback is addressed using a block different then the egress PE SRv6 locator block rib datastore. Draft-vroonen-idr-bgp-bestpath-nh-selection-02 The issue is related to BGP best path selection using the egress PE next hop loopback for next hop resolution in cases where the loopbacks are addressed out of a different block then the SRv6 locator for Algo 0 or any 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 draft uses a forwarding address that is set so that the next hop resolution uses this address from the SRv6 locator flex algo datastore and not the traditional egress PE loopback for the next hop resolution. This solution has already been implemented by most all vendors and now we are just updating BGP next hop resolution RFC 4271 with this IETF draft. The issue you are having with the firewall and ICMP ping issue I believe will be solved with this draft mentioned above. I did want to note that SRv6 TE steering can work through a firewall using SRv6 proxy draft below. https://datatracker.ietf.org/doc/html/draft-xuclad-spring-sr-service-chaining Also other than use of SR Proxy feature there is a way to service chain and steer traffic through a firewall which is by crafting next Sid or replace Sid policy to point to egress device locator node Sid on other side of firewall and to do so in both directions which is possible. Another point to note is that as all firewalls today are not SRv6 aware that by not using SRv6 proxy for SRv6 decap and encap the firewall in SRv6 path is not capable of DPI to parse statefully the inner payload IPv4 or IPv6 so defeating the firewall stateful packet filtering inspection capability. Recommendation is keeping firewall outside the SRv6 domain and use BGP routing path attributes to steer traffic through firewall or use SRv6 Proxy. Kind Regards Gyan
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
