Hi Reji, > SRv6+ confirms to the V6 architecture, explains the rationale behind the > design and is non ambiguous to start with. Till now there has not been any > valid shortcomings brought forth with the Srv6+ design. I saw a mention that > SRv6+ needs to distribute the SID to address binding and hence require > extensions to protocols which is not what was intended by SR. Considering at > a bare minimum we would need a software/microcode update to support even the > SRH parsing, I didn’t understand why protocol extension and mapping for SR > support with V6 is a bad idea. Please correct me if there is a gap in my > understanding. > > In view of the above ,I support SRv6+ work to continue in the SPRING WG.
I agree with your arguments. +1 on work on this in SPRING, and preferably to focus on SRv6+ and not on SRv6/uSID/etc. Cheers, Sander
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
