Robert, If I understand your elaborate response, you hint to keeping MPLS as demux for services and native IPv4/IPv6 for transport.. which may not address bunch that religiously don’t want to enable MPLS. OK, but how about traffic engineering (or source routing) in native IPv6 transport? Seems SRv6+ solves that there – and vanilla IPv4/v6 does not.
Regards, Tarek From: Robert Raszuk <[email protected]> Date: Friday, September 6, 2019 at 10:09 AM To: Tarek Saad <[email protected]> Cc: Ron Bonica <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+ Please see my elaborated note on that ... https://mailarchive.ietf.org/arch/msg/spring/qvRUp8SC2cWeIE5UhhU9aKGtpHM Cheers, R. On Fri, Sep 6, 2019 at 4:03 PM Tarek Saad <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]>> on behalf of Robert Raszuk <[email protected]<mailto:[email protected]>> Date: Friday, September 6, 2019 at 9:33 AM To: Ron Bonica <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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
