> 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 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
