Subject: [spring] SRm6: Motivation?

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 18 Nov 2019 07:24:25 +0000

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
- scale, performance and complexity drawbacks
- no genuine advantage

Hence, the very first thing you need to do is to clearly compare your solution with respect to SRv6 and SR-MPLS and demonstrate why the above analysis is incorrect.

Only with such a logical analysis, will the community be able to judge whether this proposal should be pursued within SPRING.

Thanks
   Darren

---

From: Sander Steffann <[email-masked]>
Date: Mon, 18 Nov 2019 18:00:00 +0100

Hi,

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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 18 Nov 2019 20:24:08 +0000

Hi Darren,

It's always good to hear from you. Even when we disagree, the conversation is always civil and thought provoking.

I am glad to hear that you are open to arguments suggesting that your analysis might be incorrect. So, I accept your challenge to produce a document that describes the advantages of SRm6 over SRv6, as well as the differences between SRm6 and SRv6. Expect some operational hoarse-sense as well as some architectural deep-diving.

While the document will include words on scale and performance, running code will provide the most reliable evidence.

                                                                                                         Happy holidays,
                                                                                                               Ron

Juniper Business Use Only

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]> 
Sent: Monday, November 18, 2019 2:24 AM
To: [email-masked]; SPRING WG <[email-masked]>
Subject: SRm6: Motivation?

Thanks
   Darren

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 18 Nov 2019 21:52:32 +0100

Hello Ron,

In your generous offer would you mind to also include in your document not
only advantages of SRm6 over SRv6 but also compare it with the below
parallel solutions:

https://tools.ietf.org/html/draft-filsfils-spring-sr-mpls-ipv6-control-plane-00

https://tools.ietf.org/html/draft-agrawal-spring-srv6-mpls-interworking-00

and

https://tools.ietf.org/html/draft-raszuk-teas-ip-te-np-00

Kindest regards,
Robert.

On Mon, Nov 18, 2019 at 9:24 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> I am glad to hear that you are open to arguments suggesting that your
> analysis might be incorrect. So, I accept your challenge to produce a
> document that describes the advantages of SRm6 over SRv6, as well as the
> differences between SRm6 and SRv6. Expect some operational hoarse-sense as
> well as some architectural deep-diving.
>
> While the document will include words on scale and performance, running
> code will provide the most reliable evidence.
>
>
>                                Happy holidays,
>
>                                      Ron
>
>
> The current community analysis, comparing existing solutions (SRv6 and
> SR-MPLS for IPv6) with SRm6, had the following result:
> Hence, the very first thing you need to do is to clearly compare your
> solution with respect to SRv6 and SR-MPLS and demonstrate why the above
> analysis is incorrect.
>
> Only with such a logical analysis, will the community be able to judge
> whether this proposal should be pursued within SPRING.
>
> Thanks
>    Darren
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 18 Nov 2019 23:45:16 +0000

+1

As commented on the mike at the WG meeting, SRm6 being a *mapping* technique (that allocates IDs, distributes its state as IDs, and whose FIB is based these IDs and in which does ID swapping in the forwarding path), it is more appropriate to understand the genuine benefits of SRm6 over SR-MPLS IPv6 solutions. After all SR-MPLS was designed as a label mapping based source routing solution for both IPv4 and IPv6 control planes by the WG.

Thanks,
Ketan

From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: 19 November 2019 04:53
To: Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>
Subject: Re: [spring] SRm6: Motivation?

Hello Ron,

In your generous offer would you mind to also include in your document not only advantages of SRm6 over SRv6 but also compare it with the below parallel solutions:

and

Kindest regards,
Robert.

On Mon, Nov 18, 2019 at 9:24 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Hi Darren,

                                                                                                         Happy holidays,
                                                                                                               Ron

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 18, 2019 2:24 AM
To: [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: SRm6: Motivation?

Thanks
   Darren

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Andrew Alston <[email-masked]>
Date: Tue, 19 Nov 2019 16:31:03 +0000

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-masked]> wrote:

    Hi,

    

    

    
    Cheers,
    Sander

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 19 Nov 2019 22:58:53 +0000

Hi Andrew, check out the Milestones section for SPRING in Datatracker.

Darren

> On Nov 20, 2019, at 12:31 AM, Andrew Alston <[email-masked]> wrote:
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 20 Nov 2019 01:14:47 +0000

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

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]> 
Sent: Tuesday, November 19, 2019 5:59 PM
To: Andrew Alston <[email-masked]>
Cc: Sander Steffann <[email-masked]>; [email-masked]; SPRING WG <[email-masked]>
Subject: Re: [spring] SRm6: Motivation?

Darren

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