I am happy to see the converging, and I agree with both Robert and Gernando.
The problem that an EH-insertion want to solve can also be solved by using an extra encap/decap, which is obviously compliant. The more bytes used by extra encap/decap may be the tax we have to pay for using IPv6! The problem that CRH want to solve can also be solved easily by using the SRH, just use 6-10 SIDS in SRH directly. The tax is the use of IPv6 addresses (IDs of global scope) to identify the SR nodes, for the benefits that IPv6 brings! Why not ? Jingrong -----Original Message----- From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont Sent: Saturday, September 07, 2019 8:15 PM To: Robert Raszuk <rob...@raszuk.net> Cc: spring@ietf.org; Ketan Talaulikar (ketant) <ket...@cisco.com>; spring-cha...@ietf.org; draft-ietf-spring-srv6-network-programm...@ietf.org Subject: Re: [spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming On 7/9/19 14:43, Robert Raszuk wrote: > > 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. Then you have answered my previous question. This EH-insertion thing is not solving any problem that cannot be solved with the standard that we have, and instead introduces potential problems. You shouldn't be surprised if, modulo social engineering, the proposal for EH insertion doesn't fly in 6man. That said, I think EH insertion should be removed from this document, on the basis that: * It breaks an existing standard (RFC8200) that explicitly banned it for technical concerns. * It doesn't solve a problem that cannot be solved with encap/decap, and in fact introduces potential problems. > 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 ? That's certainly, at least, a cleaner design than inserting EHs in the network (and there's no such a thing as a free lunch). Inserting EHs is, if anything, a hack. As a side comment, if you have concerns wasted bits (and since you stress all the time that SR operates in a "limited domain") a quick comment would be: why do you use IPv6 addresses (IDs of global scope) to identify the SR nodes? Thanks, -- 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
