Hi Robert, >> * If operators choose not to use MPLS transport SR-MPLS can be easily >> transported over IPv4 or IPv6 vanilla data plane I’m little confused about the above argument – given it starts with don’t want to use MPLS, can you clarify?
Regards, Tarek From: spring <[email protected]> on behalf of Robert Raszuk <[email protected]> Date: Friday, September 6, 2019 at 9:33 AM To: Ron Bonica <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+ Dear Ron, I think you forgot few main points in the summary: * Many operators use SR-MPLS successfully and it has been both standardized and successfully deployed in the network with interoperable implementations * The overhead on the data plane of SRv6+ is very comparable to overhead of SR-MPLS * The control plane extensions BGP, IGP are available for SR-MPLS and non are available for SRv6+ * SRv6+ requires a new mapping of SIDs to prefixes to be distributed by control plane * If operators choose not to use MPLS transport SR-MPLS can be easily transported over IPv4 or IPv6 vanilla data plane * Extensions for additional applications like L3VPNs or L2VPNs will require another set of protocol and implementation changes. * If there are vendors who do not want to provide SR-MPLS SID mapping to IPv6 addresses in their control planes let's focus standardization and industry work in this direction. With all of the above I think it would be a serious mistake - at this point of time - to continue work on SRv6+ in the IETF. Thank you, Robert. On Fri, Sep 6, 2019 at 3:08 PM Ron Bonica <[email protected]<mailto:[email protected]>> wrote: Folks, We have explored many facets of SRv6 and SRv6, sometime passionately. I think that this exploration is a good thing. In the words of Tolkien, “All who wander are not lost.” But it may be time to refocus on the following: · For many operators, SRv6 is not deployable unless the problem of header length is addressed · Many objections the uSID proposal remain unanswered · SRv6+ offers an alternative solution Given these three facts, I think that it would be a mistake to discontinue work on SRv6+. Ron Juniper Business Use Only -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
