[c-nsp] [External] SDx open standard?

[Robert Raszuk]

> The standardization is coming, check out
https://www.mef.net/mef-3-0-sd-wan

I spent 10 min browsing MEF web site and still do not know what "MEF"
stands for ... Looks to me like yet one more  commercial entity to drain a
little bit of cash out of the vendors while perhaps help with marketing and
sales a bit.

Is this the same as Microsoft's MEF:

"The Managed Extensibility Framework (MEF) is a library in .NET that
enables greater reuse of applications and components."

Thx,
R.

On Thu, Mar 26, 2020 at 3:11 PM <adamv0025 at netconsultings.com> wrote:

> > Sent: Sunday, March 15, 2020 6:04 PM
> > To: Hunter Fuller <hf0002 at uah.edu>
> >
> > That's what I'm asking about.
> >
> > While the thread Mark referenced, deals (in my humble opinion) primarily
> > with automation side of things, my question is how the whole SDN thing
> > became vendor-specific-closed-protocol?
> >
> > I'm not talking specifically about any particular facet of SDN, such as
> > automation or forwarding plane control over the network (though l
> > personally most interested in the latter, at least for now) or anything
> else -
> > rather, how 100% of solutions I've been presented over past year or so,
> are
> > all closed code-proprietary protocol solutions?
> >
> > Not a single one was based on an open standard, such as Open Flow, not a
> > single one is able to interoperate with others, though one particular SDN
> > solution will cost *a third *same vendor "traditional" standard compliant
> > equipment. That's for me, was begging the question - am I missing
> > something here and I'm really be better off by selling my soul to a
> single
> > vendor for eternity, rather than opting for standard compliant box? If
> there's
> > such one to begin with?
> >
> The standardization is coming, check out
> https://www.mef.net/mef-3-0-sd-wan
>
> Though the only thing that can be meaningfully standardized really are
> "some" mechanisms/protocols used to disseminate "some" decisions. -but that
> should be enough for basic inerop between vendors.
> How the controller comes to a decision is each vendors secret sauce (and
> as you might have guessed, there always will be some decisions that need to
> communicated using novel/custom mechanisms -hence my use of "some") .
>
> adam
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>