Hello, Ketan, Inline...
On 7/9/19 08:14, Ketan Talaulikar (ketant) wrote: > < An engineer comes out from the trenches/ > > > Hi Fernando, > > I will attempt to answer and but also setup the context first. Thanks for elaborating, by the way. > 4) This is not about the IPv6 Internet. All of SR is about within a SR domain > and as an extension so is SRv6 and SRH. At least at the time of this writing, we don't have "flavours" of IP/IPv6. The same protocol is employed everywhere, because that's the scope of the layer. > There are exactly two "features" (at least AFAIK) of a large set where we > encounter scenarios where SRH insertion/removal for this outer IPv6 header > when the customer packet transits the SR domain: > a) BSID (End.B6.Insert) : this is a SR Policy anywhere in the transit path > for TE and/or Service Chaining purposes > b) TI-LFA/Microloop Avoidance (T.insert) : These are protection techniques > for sub-50msec fast-reroute and repair for failures in this transit network > > You can get more details/references on them on this thread : > https://mailarchive.ietf.org/arch/msg/spring/Jtg9YPxEjes4Bm-1ngwXmJfeybs > [....] > > These features exist and are widely deployed today with SR-MPLS and work > similarly - difference is working with stacks of label instead of SRH. > > Now, it is most important to understand that the encap variants of these > features (End.B6.Encap & T.encap) are already defined in the SRv6 spec. > > So then we come to your Q - why the insert flavors? The motivation is to > reduce the overhead of *yet another* IPv6 header and encap when doing these > features. You will also realize by now that this aspect is not specific to > SRv6/SRH but in general to any solution based on IPv6. Anyone having some > decent experience with SR will vouch for the importance of these two features. So, double-checking if I understood correctly: You are saying that the two uses cases that you are referring to already have an alternative specification with encap/decap, but this document proposes to use EH insertion to avoid the extra overhead of adding an additional IPv6 header? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
