> 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? >
That is correct. I have been telling you this over and over again and you were choosing not to accept it. But please do think about real deployments which do SRH insertion with encapsulation on ingress to their network for TE or NP reasons. Then the same customer would like to use TI-LFA to protect data plane. So per your and few other comments he would not be able to add another local (to the protection zone) SRH to his already encapsulated on ingress packet, but would have to add another IPv6 encapsulation with SRH to be in line with RFC8200 even if the only point of the new SRH is local single dst detour and protection of arriving dst address in the outer most IPv6 header. How efficient/wise that is ? Thx, R.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
