Darren,
Neither CRH nor uSID appear in the Milestones section of the SPRING charter.
But, as its name suggests, SPRING is all about Source Packet Routing. If we
don't have a packet steering solution that can support a path that contains
many segments, we are not fulfilling our charter.
It seems that a discussion of Routing header compression is in order. And even
if the charter gave special preference to uSID, it is not entirely clear that
that solution is deployable.
Ron
Juniper Business Use Only
-----Original Message-----
From: Darren Dukes (ddukes) <[email protected]>
Sent: Tuesday, November 19, 2019 5:59 PM
To: Andrew Alston <[email protected]>
Cc: Sander Steffann <[email protected]>;
[email protected]; SPRING WG <[email protected]>
Subject: Re: [spring] SRm6: Motivation?
Hi Andrew, check out the Milestones section for SPRING in Datatracker.
Darren
> On Nov 20, 2019, at 12:31 AM, Andrew Alston <[email protected]>
> wrote:
>
> Just to add to this because it’s the one thing that I am still confused about.
>
> We are referring to finishing the work on SRv6 - what does this mean?
>
> SRH is with the editors - meaning - its pretty much completed (and it
> came out of 6man not spring) Network programming and CRH are entirely
> different things - they have entirely different functions and entirely
> different use cases.
> Yes - there is micro-sid and CRH - but you cannot make one hostage to the
> other - and if you are - on the basis of what is proposed here, surely first
> come first serve would apply - look at the publication dates.
>
> So - what do we mean finish the work - what exactly are we finishing? I view
> this as the equivalent of saying - lets finish the work on BGP - yet at the
> same time - how many flow spec extensions are out there (in fact there are
> even things in pipeline while flowspec v2 is coming). You have a ton of
> extensions for different things - no one halts the progress.
>
> So - What exactly are we "finishing" and on what premise are we holding other
> things hostage on these grounds?
>
> Andrew
>
>
> On 19/11/2019, 01:00, "Sander Steffann" <[email protected]> wrote:
>
> Hi,
>
>> Hi Ron, to follow up on what was said at the mic.
>>
>> The current community analysis, comparing existing solutions (SRv6 and
>> SR-MPLS for IPv6) with SRm6, had the following result:
>> - a lot of differences (Architecture, Dataplane, Controlplane) and
>> hence engineering cost
>
> A different architecture isn't necessarily a bad thing. I think the
> architecture is sound, and I prefer a strong architecture that needs some
> engineering work to a weaker architecture that is easier to implement any
> day. Build for the future etc.
>
>> - scale, performance and complexity drawbacks
>
> Not my field of expertise, so skipping this one.
>
>> - no genuine advantage
>
> These are the advantages that I see:
> - fits cleanly within the IPv6 standard
> - packet overhead comparable to SR-MPLS
> - but doesn't need every box on the path to cooperate (I have
> participated in a test running SRm6 over the open internet: no
> tunnels, just worked)
>
> I think SRm6 strikes the right balance between clean architecture,
> overhead and complexity. I my opinion this working group should pursue work
> on SRm6 for these reasons. I understand the need for finishing the work on
> SRv6, but at the same time lets work on new developments like SRm6, work on
> interoperability, and give operators the choice to run the protocol they
> prefer.
>
> There is no need for competition here (and if there is, please take it
> outside the IETF), only the need for cooperation and coexistence.
>
> Cheers,
> Sander
>
>
>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
