Re: [spring] Regaining Focus on SRv6 and SRv6+

> 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 <markzzzsmith@gmail.com> wrote:

> On Sat, 7 Sep 2019 at 14:58, Huzhibo <huzhibo@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-bounces@ietf.org] On Behalf Of Robert Raszuk
> > Sent: Friday, September 06, 2019 9:33 PM
> > To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
> > Cc: spring@ietf.org; 6man@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.net@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
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>