On Sat, 7 Sep 2019 at 19:56, Robert Raszuk <rob...@raszuk.net> wrote: > > > It's tempting to write up SR over IPv4 > > You don't have to write anything ... it is already written and looks like > moving fwd :) > > https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07 >
That's tunnelling MPLS over SR over IPv4. I'm talking about native SR over IPv4 e.g. "SRv4". > Thx, > R. > > On Sat, Sep 7, 2019 at 8:05 AM Mark Smith <markzzzsm...@gmail.com> wrote: >> >> On Sat, 7 Sep 2019 at 14:58, Huzhibo <huzh...@huawei.com> wrote: >> > >> > Hi Robert: >> > >> > >> > >> > Agree with you. >> > >> > SRv6 is a completely different technology from SR MPLS. The biggest >> > difference is that SRv6's Sid itself has routing capabilities. For >> > example, it is aggregatable, it is programmable, it is globally unique >> > over a larger scope. of. Sid's routing capabilities bring many benefits to >> > the network. For example: network scalability, reliability, and simplified >> > Overlay programming. So, I think that any optimization we do for SRv6 >> > should not sacrifice Sid's own routing capabilities. If we just want to >> > solve the interoperability problem between MPLS network and IP network, we >> > can solve this problem in the field of SR MPLS. >> > >> > >> >> Does any network need a SID space that is literally bigger than the >> combination of both the current and and any possible future IPv6 >> unicast address space? >> >> It's tempting to write up SR over IPv4, because IPv4 is currently a >> far more commodity technology than both MPLS and IPv6, probably on >> some metrics in the order of one or more magnitudes, well known, well >> proven, well understood, would leverage existing IPv4 implementations >> of which there are many, and would have only have 32 bit SIDs, so the >> tunnelling overhead cost would be much lower than 128 bit SIDs as a >> result of using IPv6 addresses for SIDs. >> >> >> > >> > Thank you, >> > >> > Zhibo >> > >> > >> > >> > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk >> > Sent: Friday, September 06, 2019 9:33 PM >> > To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> >> > Cc: spring@ietf.org; 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> 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 >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > i...@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
