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

On Sat, 7 Sep 2019 at 19:56, Robert Raszuk <robert@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 <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