Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 7 Jan 2020 09:17:18 +0000

Ron,

SPRING has already done this work and documented the SRv6 use-cases in RFC8354 before progressing with the SRv6 standardization.

Further on, draft-ietf-spring-srv6-network-programming is a Standards Track document.
I fail to see how a cite from RFC8354 or any other text on “SRv6 vs SR-MPLS” standardises anything at all.
Note that we have already removed text from draft-ietf-spring-srv6-network-programming (e.g. illustrations) because it was not standardising anything.

Thank you for the suggestion,
Pablo.

From: spring <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Monday, 30 December 2019 at 11:08
To: SPRING WG <[email-masked]>
Subject: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Pablo,

Would you consider adding a short section to the draft explaining the relative advantages of SRv6 over SR-MPLS? This section would explain why an network operator would deploy SRv6 instead of SR-MPLS.

                                                                                         Ron

Juniper Business Use Only

---

From: Ron Bonica <[email-masked]>
Date: Tue, 7 Jan 2020 18:16:49 +0000

Pablo,

RFC 8354 reinforces my analysis in https://mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI. Are you saying that you agree with this analysis?

                                             Ron

Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Tuesday, January 7, 2020 4:17 AM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Ron,

Further on, draft-ietf-spring-srv6-network-programming is a Standards Track document.
I fail to see how a cite from RFC8354 or any other text on "SRv6 vs SR-MPLS" standardises anything at all.
Note that we have already removed text from draft-ietf-spring-srv6-network-programming (e.g. illustrations) because it was not standardising anything.

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Date: Monday, 30 December 2019 at 11:08
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Pablo,

                                                                                         Ron

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 10 Jan 2020 16:55:22 +0000

Ron,

If you want to discuss your analysis please let’s do so in a separate email thread out of the context of the Working Group Last Call of draft-ietf-spring-srv6-network-programming.

As I said before: draft-ietf-spring-srv6-network-programming is a Standards Track document and this topic is not about any standardization, hence out of scope of this document.

Same applies to other content (e.g. illustrations) that was formerly in network programming and we moved to a separate draft since it was not standardizing anything at all and was merely informative.

Thanks,
Pablo.

From: Ron Bonica <[email-masked]>
Date: Tuesday, 7 January 2020 at 19:17
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Please excuse any typos, sent from my 'smart'phone.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 10 Jan 2020 19:14:15 +0000

Chairs,

I believe that we have two independent requests for a comparison of the benefits of SRv6 over SR-MPLS in the network programming draft.

                                                            Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, January 10, 2020 11:55 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Ron,

If you want to discuss your analysis please let's do so in a separate email thread out of the context of the Working Group Last Call of draft-ietf-spring-srv6-network-programming.

Thanks,
Pablo.

From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 7 January 2020 at 19:17
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Pablo,

RFC 8354 reinforces my analysis in https://mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI__;!!NEt6yMaO-gk!SolNvh35q4NS-PTVWOxXAzbTnMHltfvPWi_OSjhMYkmm_NucR6imYrrLvc35Kat6$>. Are you saying that you agree with this analysis?

                                             Ron

Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 7, 2020 4:17 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Ron,

Pablo,

                                                                                         Ron

---

From: <[email-masked]>
Date: Mon, 13 Jan 2020 13:12:25 +0000

Ron,

From: spring [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Friday, January 10, 2020 8:14 PM
To: Pablo Camarillo (pcamaril)
Cc: [email-masked]
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Chairs,

A comparison of the benefits of SRv6 over SR-MPLS is one thing that could possibly be discussed if there is interest from the WG.
E.g. to help network provider make a choice, or in the context of "beyond SRv6" to help the WG identify the benefit/cost analysis of existing solutions and what we want to achieve with new/extensions to SR data planes.

But why do you think that this would belong to draft-ietf-spring-srv6-network-programming?

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 13 Jan 2020 20:38:25 +0000

Hello Bruno.

According to the network programming draft, "Network programming combines segment routing functions, both simple and complex, to achieve a networking objective that goes beyond mere packet routing."

Sadly, the document offers little insight as to what those non-routing objectives might be.

If SRv6 offers something beyond the mere packet routing capabilities of SR-MPLS, the network programming draft would be the most appropriate place to mention it. Otherwise, SRv6 is just an IPv6 version of SR-MPLS.

                                                                   Ron

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Monday, January 13, 2020 8:12 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Ron,

Cc: [email-masked]<mailto:[email-masked]>

Chairs,

Thanks,
--Bruno

                                                            Ron

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, January 10, 2020 11:55 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

---

From: <[email-masked]>
Date: Tue, 14 Jan 2020 10:01:58 +0000

Hello Ron, Pablo,

From: Ron Bonica [mailto:[email-masked]]
Sent: Monday, January 13, 2020 9:38 PM
To: DECRAENE Bruno TGI/OLN
Cc: [email-masked]; Pablo Camarillo (pcamaril)
Subject: RE: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

Hello Bruno.

Sadly, the document offers little insight as to what those non-routing objectives might be.
Ron,
Thank you for elaborating on this comment. The scope of the revised comment seem to me more focused and now indeed related to this document.

Ron, Pablo,
May I suggest that you both follow up to progress on a resolution on the comment on this sentence?

e.g. clarify what is meant by "beyond packet routing", and/or what is exactly meant by this sentence beyond what is already stated in the SR architecture (which for example, but not restricted to, states that  "A segment can represent any instruction, topological or service based." )
If this can't be reasonably clarified, worse case could possibly be to remove this sentence or fall back to a reference to the/a SR architecture RFC/section/sentence. As of today, I don't assume that this point would be a blocking point to progress that document or to delay it for a long time.

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.