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

[Rick Casarez <[e-mail]>]

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 <
[e-mail]> wrote:

> Hi Rick,
>
>
>
> Many thanks for the feedback!
>
>
>
> 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
> ?
>
>
>
> The spelling mistakes you picked up will also be fixed in the next version.
>
>
>
> 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:* Rick Casarez [mailto:[e-mail]]
> *Sent:* den 20 oktober 2015 13:15
> *To:* Catalin Meirosu
> *Cc:* [e-mail]
> *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 <
> [e-mail]> 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 <[e-mail]>
> wrote:
>
>
>
> 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 [phone]
>
> Mobile [phone]
>
> [e-mail]
>
>
>
> 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: [e-mail] [mailto:[e-mail]
> <[e-mail]>]
>
> 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:* [e-mail] [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* den 10 september 2015 15:35
> *To:* Catalin Meirosu
> *Cc:* [e-mail]; [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* Thursday, September 10, 2015 1:45 AM
> *To:* Krishnan, Ramki
> *Cc:* [e-mail]
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *[e-mail]
> *Sent:* den 9 september 2015 19:39
> *To:* [e-mail]
> *Cc:* [e-mail]
> *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
>
>
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
>
> e-mail: [e-mail]
> Tel:    [phone]
> Mobile: [phone]
> ----------------------------------
>
>
>
>
> ------------------------------
>
>
> 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nfvrg
>
>
>