Metro Ethernet Forum - https://www.mef.net/
On Thu, 26 Mar 2020 at 15:03, Robert Raszuk <[email protected]> wrote: > > 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 <[email protected]> wrote: > > > > Sent: Sunday, March 15, 2020 6:04 PM > > > To: Hunter Fuller <[email protected]> > > > > > > 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 [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
