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]> 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]> 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 <rbonica= > [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] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
