Re: [sfc] Future of SFC work

[Gyan Mishra <[e-mail]>]

Thank you Diego!

One other thought is as to closing the WG versus expanding the scope of the
WG charter.

In the original email my thoughts were that maybe the chairs believe not
enough input and overall interest  on SFC thus the idea of closing the WG.

However I think the intention of the chairs may have been that the WG
charter goals have all been met meaning a successful WG with the key RFC’s
for SFC being developed with the following RFC’s to name a few as well as
implemented by vendors:

RFC 7438 SFC Problem Statement
RFC RFC 7665 SFC Architecture
RFC 8300 NSH
RFC 8924 SFC OAM

And with wrapping up OAM and once that is completed and if all goals of the
initial charter have been met then without expanding the charter goals the
WG could then be deemed successful as all goals have been met and close as
many other WGs have closed after the Charter goals have been met.

My thoughts on that is just as there are critical bread and butter Routing
Area WGs that with the SFC charter keep it as “ongoing” as there is always
continuing development work such as the big ones BESS, IDR, LSR, LSVR,
TEAS, Spring, MPLS, RTGWG, BIER, PCE, CCAMP, PIM, RIFT and smaller ones WGs
PALS, BFD, NVO3, BABEL, LISP.

I think SFC being a smaller WG that does not have time slot at each IETF as
other smaller WGs, however the work is still very important to the industry
to continue on and expanding the charter to keep the development work going.

Kind Regards

Gyan
On Wed, Feb 16, 2022 at 9:13 AM Diego R. Lopez <[e-mail]>
wrote:

> Hi,
>
>
>
> The advantage of waiting a while before expressing my opinion is the Gyan
> has perfectly done so (thanks!). I fully support his opinion about
> continuing SFC work. And I must say I have the intention to continue being
> directly involved in some work of the group, as I was in the composition
> draft or in the PoT activities.
>
>
>
> Be goode,
>
>
>
> --
>
> "Esta vez no fallaremos, Doctor Infierno"
>
>
>
> Dr Diego R. Lopez
>
> Telefonica I+D
>
> https://www.linkedin.com/in/dr2lopez/
>
>
>
> e-mail: [e-mail]
>
> Mobile:  [phone]
>
> ----------------------------------
>
>
>
> On 16/02/2022, 04:09, "sfc on behalf of Gyan Mishra" <[e-mail]
> on behalf of [e-mail]> wrote:
>
>
>
>
>
> Hi Joel, Jim & all
>
>
>
> I would say that one measure of success of a WG is that when you do a
> google search, there are many scholarly articles related to SFC service
> plane benefits as well as vendor implementations that I know of personally
> with Cisco and Juniper and there maybe other vendors out there.
>
>
>
> I think the SFC WG has garnered overall interest in the technology
> industry wide and it’s importance of a service plane.
>
>
>
> Overall I would say hats off to the chairs and WG members and all the hard
> work  as to the success!!!
>
>
>
> As far as commentary and involvement in drafts, that issue exists across
> the board as I am a member of every Routing Area WG, 54 WGs in total I
> would say the interest and involvement has been as well with other WGs
> related to personal drafts being progressed by individuals so I don’t think
> it’s just an issue with SFC WG.  My observation has been that whenever
> multiple  vendors have competing solutions they want to get to WG adoption
> and progression,  those are the hot ones that have tremendous interest.
> As well there are hot topics and the hot topics with drafts that have all
> the major vendors involvement get the most feedback and of course progress
> quickly.  The key is garnering multi vendor interest and support to
> progress an idea which goes for SFC and any WG.
>
>
>
> In my mind NFV brought about the concept of the need for service chaining
> of VNF instances and now SFC has broadened the use case with NSH service
> plane beyond NFV with physical hardware endpoints and any virtualization
> model.
>
>
>
> I am in favor of expanding the scope of the WG to include in the charter
> any networking area that involves virtualization such as DC NVO
> encapsulation overlays such as VXLAN where I see Cisco and Juniper are
> providing their own on standardized methods service chaining that is SFC
> and SFC NSH independent where I think their can be tremendous benefits as
> well as when extending the fabric to the host being able to use SFC NSH
> service plane to link the SFF instances.   I think as well maybe for TEAS
> network slicing with 5G virtualization the underlay network slice and now
> incorporating SFC NSH service plane into 5G UE services network slicing NSC
> slice controller.  There  maybe as well for OTN L1VPN and CCAMP WGs maybe a
> possibility of WG charter expansion into that arena SFC NSH possible
> considerations.
>
>
>
> Spring WG Segment Routing in my mind as it’s allows the ability for
> virtualization and abstraction of the underlay with SR-TE micro flow and
> macro flow path steering and it lends itself to  be a critical component of
> TEAS network slicing, I believe that SFC NSH service plane can really take
> off in that area with a myriad of use cases across the board.  I believe
> with the advent of SR really brings to light the criticality of SFC NSH
> service plane.
>
>
>
>
>
> I would be happy to work on all existing documents being progressed that I
> am involved as well as working on any I am not involved, as well as with
> the recharger expansion, any future development new work.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Fri, Jan 28, 2022 at 2:05 PM Joel M. Halpern <[e-mail]>
> wrote:
>
> SFC Working Group:
>
>      As part of discussing the OAM elated drafts in SFC, the chairs have
> been looking at the overall working group participation.  We note that
> very few people have spoken up about the issues being discussed.  For
> most recent drafts we have been working to advance, it has been a lot of
> work to get enough comments to justify advancement (and folks could
> argue that we did not succeed.)
>
>      We are considering various alternatives.  We could, for example,
> just close the working group.
> One possibility is to recharter the working group to expand the scope.
> There are two related questions that we would like to hear from the
> working group about this.
>
> 1) If we were to consider expanding the charter, what things would you
> like to see included in it?
>
> 2) If we do recharter will you work on the existing documents, and will
> you engage on documents other than the one or two you personally would
> like to see included?
>
> Thank you,
> Joel and Jim
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> ------------------------------
>
> 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 confidential and
> privileged 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
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*