I totally agree with Igor's second argument. Unfortunately the data center switching vendors keep forgetting that most large data centers offer services to more than one tenant (or think that VLANs and VLAN-based VRFs are good enough).
As for the first one, keep in mind that TRILL and SPB both use IS-IS, the protocol that is as religiously opposed in enterprise networks as BGP and MPLS, and yet these same enterprise engineers seem willing to deploy TRILL or SPB or a vendor-specific variant of one or the other. The "trick" is in proper packaging. TRILL and SPB use IS-IS internally ... but only a reasonable subset of IS-IS (no NSAPs, no areas) and its intricacies are never exposed to the operator (unless you have to do in-depth troubleshooting). Likewise, every hypervisor vendor uses numerous protocols internally (see http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012382 for a sample list) and nobody would care if BGP is added to that list ... as long as the server/virtualization/network admins don't have to configure it. Finally, while I agree with Igor's view on BGP's lack of transactional consistency, I am far away from being as positive as he is regarding the perception of DC operators. Most people I'm speaking with either don't understand that problem or don't perceive it as being important (but admittedly their data centers are at least an order of magnitude smaller than Igor's). Kind regards, Ivan Pepelnjak > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Igor Gashinsky > Sent: Friday, April 20, 2012 8:35 AM > To: AshwoodsmithPeter > Cc: Thomas Narten; Yakov Rekhter; [email protected]; Kireeti Kompella; > [email protected] > Subject: Re: [nvo3] NVO3 charter 1530UK 12April > > On Thu, 19 Apr 2012, AshwoodsmithPeter wrote: > > :: > :: >I am very much concerned about this. I know that this point is not > :: >shared by all, but for the DC folk I've talked to (and there are > :: >others I've talked to that say *exactly* the same thing), MPLS/BGP is > :: >simply a non-starter. > :: > :: While not a statistical sample by any means I've been on the receiving > :: end of some similar comments from customers but my feeling is that they > :: are not reacting to the data plane but more to a certain implementation > :: of the control plane / usability. That is after all what they see and > :: touch. > > I obviously can't speak for all datacenter people, but I can tell you that > the reason for why MPLS is a non-starter for me inside the datacenter is > that my switches there simply don't support MPLS forwarding (and, neither > do my server NICs for that matter), and backwards compatibility with the > (modern) hardware that I have deployed today is a very hard requirement. I > also know for a fact that I'm not alone in that ;) > > As far as pushback to BGP, I suspect that it comes from 3 things: > > 1) You are absolutely right - some of it is religious (but, not much you > can do about that)... > > 2) quite a bit of it is implementation related - an implementation of a > protocol for convergence across internet-scale, with all the hacks > and optimizations around that particular set of use-cases, may not be the > right thing to use inside the datacenter due to those convergence > properties.. > > 3) (hopefully) a lot of it is coming from the fact that quite a few DC > operators believe that full transactional semantics that can be used by > some form of a guaranteed consistency model is absolutely mandatory for > this mapping system. Since as far as I know, that's not something BGP has, > then it is simply not the right tool for the job, and any number of > distributed database/state synchronization methods are a significantly > better fit, and should be used instead.. > > Hopefully that will provide some context for the pushback... > > Thanks, > -igor > > --------------------+----------------------+------------------ > Igor Gashinsky | Network Architecture | Yahoo! Inc. > [email protected] | cell 917.807.2213 | Do You... Yahoo? > --------------------+----------------------+------------------ > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
