Subject: Re: [Nfvrg] "DevOps for Software-Defined Telecom Infrastructures" draft

From: Catalin Meirosu <[email-masked]>
Date: Wed, 14 Oct 2015 14:17:30 +0000

Dear Ramki, Diego, and NFVRG contributors,

We submitted an updated version of the draft (please see the IETF confirmation message appended below), addressing comments that we received through the mailing list.

We believe that the draft is nowready for adoption as a RG document, and kindly ask the chairs to launch the call in this respect.

Best regards,
-- Catalin

CATALIN MEIROSU PhD
Master Researcher
Ericsson Research - Cloud Technologies

Ericsson
Färögatan 6
16480 Stockholm, Sweden
Phone +46 1071 44696
Mobile +46 7611 53696
[email-masked]

Legal entity: Ericsson AB, registered office in Stockholm. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: den 14 oktober 2015 16:03
To: Antonio Manzalini; Guido Marchetto; Steven Wright; Kostas Pentikousis; Catalin Meirosu; Rebecca Steinert; Ioanna Papafili
Subject: New Version Notification for draft-unify-nfvrg-devops-03.txt

A new version of I-D, draft-unify-nfvrg-devops-03.txt has been successfully submitted by Catalin Meirosu and posted to the IETF repository.

Name:                                            draft-unify-nfvrg-devops
Revision:           03
Title:                                                DevOps for Software-Defined Telecom Infrastructures
Document date:                         2015-10-14
Group:                                            Individual Submission
Pages:                                             23
URL:            https://www.ietf.org/internet-drafts/draft-unify-nfvrg-devops-03.txt
Status:         https://datatracker.ietf.org/doc/draft-unify-nfvrg-devops/
Htmlized:       https://tools.ietf.org/html/draft-unify-nfvrg-devops-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-unify-nfvrg-devops-03

Abstract:
   Carrier-grade network management was optimized for environments built
   with monolithic physical nodes and involves significant deployment,
   integration and maintenance efforts from network service providers.
   The introduction of virtualization technologies, from the physical
   layer all the way up to the application layer, however, invalidates
   several well-established assumptions in this domain. This draft opens
   the discussion in NFVRG about challenges related to transforming the
   telecom network infrastructure into an agile, model-driven production
   environment for communication services. We take inspiration from data
   center DevOps regarding how to simplify and automate management
   processes for a telecom service provider software-defined
   infrastructure (SDI). Among the identified challenges, we consider
   scalability of observability processes and automated inference of
   monitoring requirements from logical forwarding graphs, as well as
   initial placement (and re-placement) of monitoring functionality
   following changes in flow paths enforced by the controllers. In
   another category of challenges, verifying correctness of behavior for
   network functions where flow rules are no longer necessary and
   sufficient for determining the forwarding state (for example,
   stateful firewalls or load balancers) is very difficult with current
   technology. Finally, we introduce challenges associated with
   operationalizing DevOps principles at scale in software-defined
   telecom networks in three areas related to key monitoring,
   verification and troubleshooting processes.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

From: [email-masked] [mailto:[email-masked]]
Sent: den 10 september 2015 15:35
To: Catalin Meirosu
Cc: [email-masked]; [email-masked]
Subject: RE: "DevOps for Software-Defined Telecom Infrastructures" draft

Thanks Catalin, your approach sounds good and relalistic. The same holds true for references to open source code implementations, such as those used in the NFVIaaS draft, since they are continuously evolving.

Thanks,
Ramki

From: Catalin Meirosu [mailto:[email-masked]]
Sent: Thursday, September 10, 2015 1:45 AM
To: Krishnan, Ramki
Cc: [email-masked]
Subject: RE: "DevOps for Software-Defined Telecom Infrastructures" draft

Hi Ramki,

Thank you for the suggestions. We will try to address them. There are quite a lot of tools in the area, so the survey will select a few tools that we consider representative. In my opinion, the issue with including such a survey in an IRTF draft is that new features are added to these tools all the time, so it will represent a only snapshot at a certain point in time of the most prominent features of these tools.

Best regards,
-- Catalin

Legal entity: Ericsson AB, registered office in Stockholm. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

From: Nfvrg [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: den 9 september 2015 19:39
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Nfvrg] "DevOps for Software-Defined Telecom Infrastructures" draft

·       Dear All,

Below are our thoughts on the "DevOps for Software-Defined Telecom Infrastructures" draft. Link to draft: https://datatracker.ietf.org/doc/draft-unify-nfvrg-devops/.

*         Add a survey of existing open source tools in this area.

*         Identify gaps in the tools as per the identified challenges.

Thanks,
Ramki & Diego

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 19 Oct 2015 21:29:08 +0000

Hi Catalin,

Thanks for the warning. Regarding your request for adoption, let’s talk about it at IETF’94, including the plans for harmonizing drafts along the lines of the special areas of interest we defined for NFVRG.

Be goode,

On 14 Oct 2015, at 16:17 , Catalin Meirosu <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,
-- Catalin

CATALIN MEIROSU PhD
Master Researcher

Ericsson
Färögatan 6
16480 Stockholm, Sweden
Phone +46 1071 44696
Mobile +46 7611 53696
[email-masked]<mailto:[email-masked]>

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: den 14 oktober 2015 16:03
To: Antonio Manzalini; Guido Marchetto; Steven Wright; Kostas Pentikousis; Catalin Meirosu; Rebecca Steinert; Ioanna Papafili
Subject: New Version Notification for draft-unify-nfvrg-devops-03.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: den 10 september 2015 15:35
To: Catalin Meirosu
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: "DevOps for Software-Defined Telecom Infrastructures" draft

Thanks,
Ramki

From: Catalin Meirosu [mailto:[email-masked]]
Sent: Thursday, September 10, 2015 1:45 AM
To: Krishnan, Ramki
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: "DevOps for Software-Defined Telecom Infrastructures" draft

Hi Ramki,

Best regards,
-- Catalin

·       Dear All,

Below are our thoughts on the "DevOps for Software-Defined Telecom Infrastructures" draft. Link to draft:https://datatracker.ietf.org/doc/draft-unify-nfvrg-devops/.

•         Add a survey of existing open source tools in this area.
•         Identify gaps in the tools as per the identified challenges.

Thanks,
Ramki & Diego

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Rick Casarez <[email-masked]>
Date: Tue, 20 Oct 2015 07:15:05 -0400

Hello,

Some minor points:

Section 1:

the sentence

"For example, IETF working groups have activities in the area of OAM and
Verification for Service Function Chaining [I-D.aldrin-sfc-oam-framework
<https://tools.ietf.org/html/draft-unify-nfvrg-devops-03#ref-I-D.aldrin-sfc-oam-framework>]
[I-D.lee-sfc-verification
<https://tools.ietf.org/html/draft-unify-nfvrg-devops-03#ref-I-D.lee-sfc-verification>]
for Service Function Chaining."

Should have the last 4 words removed.

"For example, IETF working groups have activities in the area of OAM and
Verification for Service Function Chaining [I-D.aldrin-sfc-oam-framework
<https://tools.ietf.org/html/draft-unify-nfvrg-devops-03#ref-I-D.aldrin-sfc-oam-framework>]
[I-D.lee-sfc-verification
<https://tools.ietf.org/html/draft-unify-nfvrg-devops-03#ref-I-D.lee-sfc-verification>
]."

Section 2:

"Agile methods used in many software focused companies are focused on
releasing small interactions of code tom implement VNFs with high velocity
and high quality into a production environment."

Wow, corporate speak. What is velocity defined as exactly? Also, are we
going to define Agile for those who do not know it? Finally, I know of many
places getting away from Agile since it is only one style of doing things.
Do we want this document associated with it?

I highlight above another editing mistake that needs to be fixed in the
sentence.

Overall I do like the document. For myself I know it covers more than a few
challenges I am seeing "in the wild". I will read it again to be sure but
one thing that can be mentioned is the concept of "Service Ownership". This
is where the Service Owner is responsible for said service for the entire
service lifecycle. This includes on-call support and other support
functions. Essentially no more throwing things over the wall to the Ops
group.

-------------------
Cheers, Rick

Experiences not things.

On Mon, Oct 19, 2015 at 5:29 PM, DIEGO LOPEZ GARCIA <
[email-masked]> wrote:

> Hi Catalin,
>
> Thanks for the warning. Regarding your request for adoption, let’s talk
> about it at IETF’94, including the plans for harmonizing drafts along the
> lines of the special areas of interest we defined for NFVRG.
>
> Be goode,
>
> On 14 Oct 2015, at 16:17 , Catalin Meirosu <[email-masked]>
> wrote:
>
> We submitted an updated version of the draft (please see the IETF
> confirmation message appended below), addressing comments that we received
> through the mailing list.
>
> We believe that the draft is nowready for adoption as a RG document, and
> kindly ask the chairs to launch the call in this respect.
>
> Best regards,
> -- Catalin
>
>
> CATALIN MEIROSU PhD
> Master Researcher
> Legal entity: Ericsson AB, registered office in Stockholm. This
> Communication is Confidential. We only send and receive email on the basis
> of the terms set out at www.ericsson.com/email_disclaimer
>
>
> From: [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> To: Antonio Manzalini; Guido Marchetto; Steven Wright; Kostas Pentikousis;
> Catalin Meirosu; Rebecca Steinert; Ioanna Papafili
> A new version of I-D, draft-unify-nfvrg-devops-03.txt has been
> successfully submitted by Catalin Meirosu and posted to the IETF repository.
>
> URL:
> https://www.ietf.org/internet-drafts/draft-unify-nfvrg-devops-03.txt
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-unify-nfvrg-devops-03
>
> Abstract:
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* den 10 september 2015 15:35
> *To:* Catalin Meirosu
> *Cc:* [email-masked]; [email-masked]
> *Subject:* RE: "DevOps for Software-Defined Telecom Infrastructures" draft
>
> Thanks Catalin, your approach sounds good and relalistic. The same holds
> true for references to open source code implementations, such as those used
> in the NFVIaaS draft, since they are continuously evolving.
>
> Thanks,
> Ramki
>
> *From:* Catalin Meirosu [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Thursday, September 10, 2015 1:45 AM
> *To:* Krishnan, Ramki
> *Cc:* [email-masked]
> *Subject:* RE: "DevOps for Software-Defined Telecom Infrastructures" draft
>
> Hi Ramki,
>
> Thank you for the suggestions. We will try to address them. There are
> quite a lot of tools in the area, so the survey will select a few tools
> that we consider representative. In my opinion, the issue with including
> such a survey in an IRTF draft is that new features are added to these
> tools all the time, so it will represent a only snapshot at a certain point
> in time of the most prominent features of these tools.
>
> Best regards,
> -- Catalin
>
> Legal entity: Ericsson AB, registered office in Stockholm. This
> Communication is Confidential. We only send and receive email on the basis
> of the terms set out at www.ericsson.com/email_disclaimer
>
>
> *From:* Nfvrg [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *Sent:* den 9 september 2015 19:39
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [Nfvrg] "DevOps for Software-Defined Telecom Infrastructures"
> draft
>
> ·       Dear All,
>
> Below are our thoughts on the "DevOps for Software-Defined Telecom
> Infrastructures" draft. Link to draft:
> https://datatracker.ietf.org/doc/draft-unify-nfvrg-devops/.
>
> ·         Add a survey of existing open source tools in this area.
> ·         Identify gaps in the tools as per the identified challenges.
>
> Thanks,
> Ramki & Diego
>
>
> --
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _______________________________________________
> Nfvrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nfvrg
>
>

---

From: Catalin Meirosu <[email-masked]>
Date: Tue, 20 Oct 2015 15:34:41 +0000

Hi Rick,

Many thanks for the feedback!

Regarding the Section 2 comment: sorry for the corporate speak, will attempt to fix that ☺

To me, in this context, a simple definition of velocity would be the number of VNF features successfully implemented and deployed in a certain time interval. I know that there are much more formal definitions of velocity in the general context of agile development. But then we’d get onto the question on whether we need the define Agile and to whether it should be a focus. The purpose of that sentence was to very briefly introduce DevOps from a historical perspective as an operations-oriented face of Agile. Perhaps we need to clarify that the Dev in DevOps has options beyond Agile.

The reason we talk about roles in the draft (and I realized now that we don’t explain why – so more changes in the coming -04 …) is that the same person could / should / might be able to (depending on the organization, resources and culture) assume part(s) of multiple roles. The Service Ownership is part of the current definition of the Service Developer role, although we could definitely improve in the text “This could be determined by the product owner for a particular family of services offered by a telecom provider” that I believe reflects it, to make sure that the responsibility actually extends over the service lifecycle. Would this help ?

The spelling mistakes you picked up will also be fixed in the next version.

Best regards,
-- Catalin

From: Rick Casarez [mailto:[email-masked]]
Sent: den 20 oktober 2015 13:15
To: Catalin Meirosu
Cc: [email-masked]
Subject: Re: [Nfvrg] "DevOps for Software-Defined Telecom Infrastructures" draft

Hello,
Some minor points:
Section 1:
the sentence

"For example, IETF working groups have activities in the area of OAM and Verification for Service Function Chaining [I-D.aldrin-sfc-oam-framework<https://tools.ietf.org/html/draft-unify-nfvrg-devops-03#ref-I-D.aldrin-sfc-oam-framework>] [I-D.lee-sfc-verification<https://tools.ietf.org/html/draft-unify-nfvrg-devops-03#ref-I-D.lee-sfc-verification>] for Service Function Chaining."
Should have the last 4 words removed.

"For example, IETF working groups have activities in the area of OAM and Verification for Service Function Chaining [I-D.aldrin-sfc-oam-framework<https://tools.ietf.org/html/draft-unify-nfvrg-devops-03#ref-I-D.aldrin-sfc-oam-framework>] [I-D.lee-sfc-verification<https://tools.ietf.org/html/draft-unify-nfvrg-devops-03#ref-I-D.lee-sfc-verification>]."
Section 2:

"Agile methods used in many software focused companies are focused on releasing small interactions of code tom implement VNFs with high velocity and high quality into a production environment."
Wow, corporate speak. What is velocity defined as exactly? Also, are we going to define Agile for those who do not know it? Finally, I know of many places getting away from Agile since it is only one style of doing things. Do we want this document associated with it?
I highlight above another editing mistake that needs to be fixed in the sentence.
Overall I do like the document. For myself I know it covers more than a few challenges I am seeing "in the wild". I will read it again to be sure but one thing that can be mentioned is the concept of "Service Ownership". This is where the Service Owner is responsible for said service for the entire service lifecycle. This includes on-call support and other support functions. Essentially no more throwing things over the wall to the Ops group.

-------------------
Cheers, Rick

Experiences not things.

On Mon, Oct 19, 2015 at 5:29 PM, DIEGO LOPEZ GARCIA <[email-masked]<mailto:[email-masked]>> wrote:
Hi Catalin,

Be goode,

Best regards,
-- Catalin

CATALIN MEIROSU PhD
Master Researcher

Ericsson
Färögatan 6
16480 Stockholm, Sweden
Phone +46 1071 44696
Mobile +46 7611 53696

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: den 14 oktober 2015 16:03
To: Antonio Manzalini; Guido Marchetto; Steven Wright; Kostas Pentikousis; Catalin Meirosu; Rebecca Steinert; Ioanna Papafili
Subject: New Version Notification for draft-unify-nfvrg-devops-03.txt

Abstract:

The IETF Secretariat

Thanks,
Ramki

Hi Ramki,

Best regards,
-- Catalin

·       Dear All,

Thanks,
Ramki & Diego

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

_______________________________________________
Nfvrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nfvrg

---

From: Rick Casarez <[email-masked]>
Date: Fri, 23 Oct 2015 11:05:49 -0400

Hey there,

Apologies for the delay.

Agile/Velocity - Yeah, I think strong definitions or explanations are
required. A lot of people like to sling the term around but, frankly, it is
a vague term unless defined. I do not mind it being referenced if properly
defined but it does need that definition as well as an alternative outlook.

As for everything else I think that would be awesome.

-------------------
Cheers, Rick

Experiences not things.

On Tue, Oct 20, 2015 at 11:34 AM, Catalin Meirosu <
[email-masked]> wrote:

> Regarding the Section 2 comment: sorry for the corporate speak, will
> attempt to fix that J
>
>
>
> To me, in this context, a simple definition of velocity would be the
> number of VNF features successfully implemented and deployed in a certain
> time interval. I know that there are much more formal definitions of
> velocity in the general context of agile development. But then we’d get
> onto the question on whether we need the define Agile and to whether it
> should be a focus. The purpose of that sentence was to very briefly
> introduce DevOps from a historical perspective as an operations-oriented
> face of Agile. Perhaps we need to clarify that the Dev in DevOps has
> options beyond Agile.
>
>
>
> The reason we talk about roles in the draft (and I realized now that we
> don’t explain why – so more changes in the coming -04 …) is that the same
> person could / should / might be able to (depending on the organization,
> resources and culture) assume part(s) of multiple roles. The Service
> Ownership is part of the current definition of the Service Developer role,
> although we could definitely improve in the text “This could be determined
> by the product owner for a particular family of services offered by a
> telecom provider” that I believe reflects it, to make sure that the
> responsibility actually extends over the service lifecycle. Would this help
> ?
>
>
>
> *From:* Rick Casarez [mailto:[email-masked]]
> *Sent:* den 20 oktober 2015 13:15
> *To:* Catalin Meirosu
> *Cc:* [email-masked]
> *Subject:* Re: [Nfvrg] "DevOps for Software-Defined Telecom
> Infrastructures" draft
>
>
>
> Hello,
>
> Some minor points:
>
> Section 1:
>
> the sentence
>
> releasing small interactions of code tom implement VNFs with high
> velocity and high quality into a production environment."
>
> Overall I do like the document. For myself I know it covers more than a
> few challenges I am seeing "in the wild". I will read it again to be sure
> but one thing that can be mentioned is the concept of "Service Ownership".
> This is where the Service Owner is responsible for said service for the
> entire service lifecycle. This includes on-call support and other support