I also agree 100% with Robert and Dirk. Alright, has this tread grow, I am getting confused, here’s why:
First, is it a fair statement to say that there is no SRv6+ deployment with real experience ? Yes or no, I’m just curious to know. There are some SRv6 deployments – facts: https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01 and that’s aside of operators who doesn’t necessary want to be stated for whatever strategy. So are we suggesting here – please roll back because “on paper and over the last couple months we restarted a complete new initiative to fix things (??), but wait another year or 2 so we can have some “working group adoption” on this new alternative and another year with multi-vendor running code (because no network is one vendor only) and then roll back again” ? Second – facts: please do click the link and check the timeline: https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ and https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/, etc… That’s right, for SRH its 5 years, which means 15 IETF meetings with few 1000’s of replies and is about to become RFC. ISIS/SRv6 its 12 IETF meetings, about to go last call … So if there is something “broken” or doesn’t suite one needs, over all these years, where were you ? Please explain ! dan From: spring <spring-boun...@ietf.org> on behalf of Dirk Steinberg <d...@lapishills.com> Date: Friday, September 6, 2019 at 10:50 AM To: Robert Raszuk <rob...@raszuk.net>, SPRING WG List <spring@ietf.org> Subject: [EXT]Re: [spring] Regaining Focus on SRv6 and SRv6+ I agree with Robert 100%. If you want to use MPLS with IPv6, fine go ahead and do so. All you need is already there. No need to re-invent MPLS over UDP using a different encapsulation inappropriately named "SRv6+". SRv6 provides many distinct advantages over MPLS but nobody is forced to use it. But for those who do, let us continue to work on advancing SRv6 with uSID. Cheers Dirk If you don't like On Fri, Sep 6, 2019 at 4:37 PM Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Hi Tarek, > OK, but how about traffic engineering (or source routing) in native IPv6 > transport? SRv6 or for that matter SRv6+ works on the basis of swapping dst address in the packets. So except segment endpoints all other routers in the domain are basic IPv6 nodes. It is native IPv6 transport. So I look at SR as a service enhancing transport not a transport itself. It is IMO very very bad idea to think of SR as a new transport. If you take that view of SR-MPLS_over_IP your SIDs are just 20 bits strings. The bits sitting are SRH or CRH or just behind UDP header of rfc7510 are the exact same bits. So what technically seems to be trivial by various religious and philosophical perspectives is being blown out of proportions with complete loss of real technical details under the hood. Cheers, R. On Fri, Sep 6, 2019 at 4:16 PM Tarek Saad <tsaad....@gmail.com<mailto:tsaad....@gmail.com>> wrote: 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 <rras...@gmail.com<mailto:rras...@gmail.com>> Date: Friday, September 6, 2019 at 10:09 AM To: Tarek Saad <tsaad....@gmail.com<mailto:tsaad....@gmail.com>> Cc: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>>, "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, "6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto:6...@ietf.org>> 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 <tsaad....@gmail..com<mailto:tsaad....@gmail.com>> 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 <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on behalf of Robert Raszuk <rras...@gmail.com<mailto:rras...@gmail.com>> Date: Friday, September 6, 2019 at 9:33 AM To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>> Cc: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>>, "6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto:6...@ietf.org>> 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 <rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>> 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 i...@ietf.org<mailto:i...@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
