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

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 14 Jan 2020 17:42:30 +0000

(Updated the subject to reflect the new topic of this thread: the introduction of this draft)

Bruno,

You are correct. In essence we are saying the same thing as the 3rd line of RFC8402.
A segment can represent any instruction, topological or
   service based.

For example, for service programming we have a draft-ietf-spring-sr-service-programming. This goes beyond mere packet routing. NET-PGM provides the base and draft-ietf-spring-sr-service-programming builds on top of that.

Thanks,
Pablo

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

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.

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

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,

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]<mailto:[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6

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.

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

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,

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

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

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

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

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Thu, 16 Jan 2020 13:59:56 +0000

Pablo,

Thanks for the reply.
I’m not seen explicitly what you are proposing to address Ron’s comment, regarding the clarification of this sentence in the draft.
May I again suggest that both of you follow up to progress on a resolution to clarify the meaning of this sentence in the draft?

Thanks,
Bruno

From: Pablo Camarillo (pcamaril) [mailto:[email-masked]]
Sent: Tuesday, January 14, 2020 6:43 PM
To: [email-masked]; DECRAENE Bruno TGI/OLN
Cc: [email-masked]
Subject: Introduction of draft-ietf-spring-srv6-network-programming (was Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Bruno,

Thanks,
Pablo

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 16 Jan 2020 15:58:18 +0000

Bruno,

Would you like Pablo and me to develop text offline and bring it back to the mailing list? Or would you prefer us to craft the text in a few emails on the mailing list?

                                                                                    Ron

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Thursday, January 16, 2020 9:00 AM
To: Pablo Camarillo (pcamaril) <[email-masked]>; Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: RE: Introduction of draft-ietf-spring-srv6-network-programming (was Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Pablo,

Thanks for the reply.
I'm not seen explicitly what you are proposing to address Ron's comment, regarding the clarification of this sentence in the draft.
May I again suggest that both of you follow up to progress on a resolution to clarify the meaning of this sentence in the draft?

Thanks,
Bruno

To: [email-masked]<mailto:[email-masked]>; DECRAENE Bruno TGI/OLN

Bruno,

Thanks,
Pablo

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

Hello Ron, Pablo,

Cc: [email-masked]<mailto:[email-masked]>; Pablo Camarillo (pcamaril)

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

Ron, Pablo,

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

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

Ron,

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.

Thanks,
--Bruno

                                                            Ron

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.

Pablo,

                                             Ron

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.

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 16 Jan 2020 18:09:00 +0000

Ron,

I believe we can easily close this with the following diff:

<Old>
Network programming combines segment routing
   functions, both simple and complex, to achieve a networking objective
   that goes beyond mere packet routing.
</Old>

<New>
Network programming combines segment routing functions to achieve a networking objective
   using segments that can represent any instruction, topological or service based.
</New>

Thanks,
Pablo.

From: Ron Bonica <[email-masked]>
Date: Thursday, 16 January 2020 at 16:58
To: "[email-masked]" <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Introduction of draft-ietf-spring-srv6-network-programming (was Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Bruno,

                                                                                    Ron

Pablo,

Thanks for the reply.

Thanks,
Bruno

Bruno,

Thanks,
Pablo

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 17 Jan 2020 16:54:17 +0000

Ron,

From: Ron Bonica [mailto:[email-masked]]
Sent: Thursday, January 16, 2020 4:58 PM

Bruno,

Would you like Pablo and me to develop text offline and bring it back to the mailing list? Or would you prefer us to craft the text in a few emails on the mailing list?
[Bruno] Any option works on my side. I'm not assuming that this comment is any special.
If both of you believe that you can quickly agree on some text and that the sync would be easier offline, please do so.
However, if you can't agree within a reasonable period (1 or 2 weeks) please bring back the discussion to the list.

Thank you,
--Bruno

                                                                                    Ron

Pablo,

Thanks for the reply.

Thanks,
Bruno

Bruno,

Thanks,
Pablo

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

---

From: Ron Bonica <[email-masked]>
Date: Tue, 21 Jan 2020 14:42:18 +0000

Pablo,

It is difficult to see how you can add information by removing a few words.

Let's begin with the text in https://mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI. If you can see other advantages of SRv6 over SR-MPLS, we can add that information to the text in my original message.

                                                                                    Ron

Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Thursday, January 16, 2020 1:09 PM
To: Ron Bonica <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: Introduction of draft-ietf-spring-srv6-network-programming (was Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Ron,

<Old>

<New>

Thanks,
Pablo.

To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>

Bruno,

                                                                                    Ron

To: Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>

Pablo,

Thanks for the reply.

Thanks,
Bruno

Bruno,

Thanks,
Pablo

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 22 Jan 2020 06:56:09 +0000

Ron,

Let’s remain focus on the one sentence that you objected to.

<Old>

<New>

I have proposed a resolution for this sentence by modifying that sentence in the introduction and aligning it with -indeed copy pasting- RFC8402. Does this address your comment on that particular sentence?

Thank you,
Pablo.

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

From: Ron Bonica <[email-masked]>
Date: Tuesday, 21 January 2020 at 15:43
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Introduction of draft-ietf-spring-srv6-network-programming (was Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Pablo,

Let’s begin with the text in https://mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI. If you can see other advantages of SRv6 over SR-MPLS, we can add that information to the text in my original message.

                                                                                    Ron

Ron,

<Old>

<New>

Thanks,
Pablo.

Bruno,

                                                                                    Ron

Pablo,

Thanks for the reply.

Thanks,
Bruno

Bruno,

Thanks,
Pablo

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 22 Jan 2020 06:57:27 +0000

Hi Byron,

Thank you for your feedback.
It is very important for SPRING to know which documents are important for operators. This helps defining the action items for SPRING WG.

draft-ietf-spring-srv6-network-programming is a Standards Track document that focuses on technical specification for interoperable implementation. Any comparison of SRv6 vs SR-MPLS in my opinion does not fit within this document.
These two dataplanes for Segment Routing were introduced in RFC8402 and the IPv6 use-cases described in RFC8354.

Thank you,
Pablo.

From: "Hoskins, B. J. [CTO]" <[email-masked]>
Date: Tuesday, 21 January 2020 at 16:08
To: "[email-masked]" <[email-masked]>, Ron Bonica <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [spring] Introduction of draft-ietf-spring-srv6-network-programming (was Re: draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Hi Pablo and SPRING,

First time caller long time listener.  I just want to weigh in in support of the original request and further color on SRv6 advantages beyond “mere packet routing.”  I’ve been following the work here for some time and as an operator of an MPLS network it’s just not clear to me, if forced to choose for a brownfield scenario, what the real world advantages are that SRv6 brings over SR-MPLS.  To me, for existing deployments, the path to SR-MPLS just seems much less riskier and I just can’t see what the driver for me to choose SRv6 would be.

Regards,

B. J. Hoskins

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 17, 2020 10:54 AM
To: Ron Bonica <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] Introduction of draft-ietf-spring-srv6-network-programming (was Re: draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Ron,

Bruno,

Would you like Pablo and me to develop text offline and bring it back to the mailing list? Or would you prefer us to craft the text in a few emails on the mailing list?
[Bruno] Any option works on my side. I’m not assuming that this comment is any special.
If both of you believe that you can quickly agree on some text and that the sync would be easier offline, please do so.
However, if you can’t agree within a reasonable period (1 or 2 weeks) please bring back the discussion to the list.

Thank you,
--Bruno

                                                                                    Ron

Pablo,

Thanks for the reply.

Thanks,
Bruno

Bruno,

Thanks,
Pablo

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:bruno.decraene@orange..com>>

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Cc: [email-masked]<mailto:[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril@cisco..com<mailto:[email-masked]>>

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

RFC 8354 reinforces my analysis in https://mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F3WGuQumIfcmH281nwq3s9Un6raI__%3B!!NEt6yMaO-gk!SolNvh35q4NS-PTVWOxXAzbTnMHltfvPWi_OSjhMYkmm_NucR6imYrrLvc35Kat6%24&data=02%7C01%7CByron.Hoskins%40sprint.com%7C43b42b68413641d34c5a08d79b6df264%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C637148768858163512&sdata=xOUa%2BRAi%2Bd%2F6nSpGZrj2lVww2XPsml%2FI0lo1yYMkzms%3D&reserved=0>. Are you saying that you agree with this analysis?

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Jan 2020 16:09:19 +0000

Pablo,

If there are any advantages of SRv6 over SR-MPLS, it would be a mistake to change the sentence that you propose to change.

A better approach would be to enumerate the advantages. A brief bullet list, appended to the text that I have already offered might be enough. This might also satisfy Byron's request.

                                                   Ron

Sent: Wednesday, January 22, 2020 1:56 AM

Ron,

Let's remain focus on the one sentence that you objected to.

<Old>

<New>

Thank you,
Pablo.

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

To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Pablo,

Let's begin with the text in https://mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI__;!!NEt6yMaO-gk!QFNgjGB5jCPLEQSldG3epqC1f7ZMC9PWe_xRpmVN75UdO_LVdmdmsWWAjFKEpi5z$>. If you can see other advantages of SRv6 over SR-MPLS, we can add that information to the text in my original message.

                                                                                    Ron

To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Ron,

<Old>

<New>

Thanks,
Pablo.

Bruno,

                                                                                    Ron

Pablo,

Thanks for the reply.

Thanks,
Bruno

Bruno,

Thanks,
Pablo

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 23 Jan 2020 12:15:15 +0000

Ron,

Comparison between SRv6 and SR-MPLS is outside the scope of this document. IMHO it would be a misguided attempt to try capturing this in a mere bullet list.

This WGLC is for a Standards Track document that focuses on technical aspects requiring standardization for interoperable implementations and deployments.

The chair has asked us to clarify what is meant in that sentence by “beyond mere packet routing”. Hence the proposed text to specifically address the comment on this particular sentence.

Thank you,
Pablo.

From: Ron Bonica <[email-masked]>
Date: Wednesday, 22 January 2020 at 17:09
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>, "EXT - [email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Introduction of draft-ietf-spring-srv6-network-programming (was Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Pablo,

A better approach would be to enumerate the advantages. A brief bullet list, appended to the text that I have already offered might be enough. This might also satisfy Byron’s request.

                                                   Ron

Ron,

<Old>

<New>

Thank you,
Pablo.

Hello Bruno.

Ron, Pablo,

Pablo,

Let’s begin with the text in https://mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/3WGuQumIfcmH281nwq3s9Un6raI__;!!NEt6yMaO-gk!QFNgjGB5jCPLEQSldG3epqC1f7ZMC9PWe_xRpmVN75UdO_LVdmdmsWWAjFKEpi5z$>. If you can see other advantages of SRv6 over SR-MPLS, we can add that information to the text in my original message.

                                                                                    Ron

Ron,

<Old>

<New>

Thanks,
Pablo.

Bruno,

                                                                                    Ron

Pablo,

Thanks for the reply.

Thanks,
Bruno

Bruno,

Thanks,
Pablo

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 23 Jan 2020 13:22:44 +0000

Pablo,

So where should the advantages of SRv6 over SR-MPLS be documented?

Maybe someone in the WG will offer to start a new document?

                                  Ron

Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Thursday, January 23, 2020 7:15 AM
To: Ron Bonica <[email-masked]>; [email-masked]; EXT - [email-masked] <[email-masked]>
Cc: [email-masked]
Subject: Re: Introduction of draft-ietf-spring-srv6-network-programming (was Re: [spring] draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Ron,

The chair has asked us to clarify what is meant in that sentence by "beyond mere packet routing". Hence the proposed text to specifically address the comment on this particular sentence.

Thank you,
Pablo.

To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "EXT - [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Pablo,

                                                   Ron

Ron,

<Old>

<New>

Thank you,
Pablo.

Hello Bruno.

Ron, Pablo,

Pablo,

                                                                                    Ron

Ron,

<Old>

<New>

Thanks,
Pablo.

Bruno,

                                                                                    Ron

Pablo,

Thanks for the reply.

Thanks,
Bruno

Bruno,

Thanks,
Pablo

Hello Ron, Pablo,

Hello Bruno.

Ron, Pablo,

Thank you,
--Bruno

                                                                   Ron

Ron,

Chairs,

Thanks,
--Bruno

                                                            Ron

Ron,

Thanks,
Pablo.

Pablo,

                                             Ron

Ron,

Pablo,

                                                                                         Ron

Thank you.

Thank you.

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jan 2020 14:53:07 +0100

Hi Ron,

I am really not sure where are you going with this bumerang request.

Do you think that customers or users of the technology are so incapable
that IETF must provide them list of advantages of one protocol choice vs
alternatives ?

Is this really an IETF job to provide advantages of say ISIS over OSPF ?
IPSec/DTLS VPNs over MPLS-VPNs ? SRv6 over SR-MPLS ?

IETF works on standards defining interoperable protocol extensions if there
is support and interest from the industry. Apparently both SRv6 and SR-MPLS
demonstrated such support and interest.

It would be pretty bad and quite unhealthy now to take IETF to become a
technology judge. Especially in the subject of your request where choice of
SR transport goes fundamentally way outside of this WG.

Kind regards,
R.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 23 Jan 2020 14:59:34 +0000

Robert,

Is the question really that difficult to answer?

If not, the effort required to answer it would be much less than the effort required to avoid answering it!

                                                                           Ron

From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, January 23, 2020 8:53 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]; EXT - [email-masked] <[email-masked]>; [email-masked]; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: Re: [spring] Introduction of draft-ietf-spring-srv6-network-programming (was Re: draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Hi Ron,

Do you think that customers or users of the technology are so incapable that IETF must provide them list of advantages of one protocol choice vs alternatives ?

Is this really an IETF job to provide advantages of say ISIS over OSPF ? IPSec/DTLS VPNs over MPLS-VPNs ? SRv6 over SR-MPLS ?

IETF works on standards defining interoperable protocol extensions if there is support and interest from the industry. Apparently both SRv6 and SR-MPLS demonstrated such support and interest.

It would be pretty bad and quite unhealthy now to take IETF to become a technology judge. Especially in the subject of your request where choice of SR transport goes fundamentally way outside of this WG.

Kind regards,
R.

On Thu, Jan 23, 2020 at 2:23 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Pablo,

                                  Ron

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 23 Jan 2020 16:11:09 +0100

Ron,

The question you asked is like request to provide advantages of traveling
by plane vs by car.

To me SRv6 is completely different solution then SR-MPLS in all aspects of
it. I listed few examples but you had different opinion. And I really have
no time now to argue with you about advantages of choosing IP vs MPLS
transport in any network.

Best,
R.

On Thu, Jan 23, 2020 at 3:59 PM Ron Bonica <[email-masked]> wrote:

> *From:* spring <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, January 23, 2020 8:53 AM
> *To:* Ron Bonica <rbonica=[email-masked]>
> *Cc:* [email-masked]; EXT - [email-masked] <
> [email-masked]>; [email-masked]; Pablo Camarillo (pcamaril) <
> [email-masked]>
> *Subject:* Re: [spring] Introduction of
> draft-ietf-spring-srv6-network-programming (was Re:
> draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)
>
>
>
> Hi Ron,
>
>
>
> IETF works on standards defining interoperable protocol extensions if
> there is support and interest from the industry. Apparently both SRv6 and
> SR-MPLS demonstrated such support and interest.
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 23 Jan 2020 16:44:56 +0000

Robert,

Again, we agree on something. That is, that both of us have better things to do than to continue this discussion.

So, let us agree that the only advantages of SRv6 over SR-MPLS are those documented in RFC 8354. That is, that SRv6 can be deployed in some places where SR-MPLS cannot.

                                                                                 Ron

From: Robert Raszuk <[email-masked]>
Sent: Thursday, January 23, 2020 10:11 AM
To: Ron Bonica <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; EXT - [email-masked] <[email-masked]>; [email-masked]; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: Re: [spring] Introduction of draft-ietf-spring-srv6-network-programming (was Re: draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Ron,

The question you asked is like request to provide advantages of traveling by plane vs by car.

To me SRv6 is completely different solution then SR-MPLS in all aspects of it. I listed few examples but you had different opinion. And I really have no time now to argue with you about advantages of choosing IP vs MPLS transport in any network.

Best,
R.

On Thu, Jan 23, 2020 at 3:59 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                           Ron

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Thursday, January 23, 2020 8:53 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Introduction of draft-ietf-spring-srv6-network-programming (was Re: draft-ietf-spring-srv6-network-programming: Relative advantages of SRv6)

Hi Ron,

Kind regards,
R.

                                  Ron