I think Ivan makes some very good points here. Let's forget about BGP for a moment, and let's concentrate on the functionality. Whatever you want to call it, it is pretty much a publish/subscribe model and we can discuss whether eventual consistency or full consistency is the requirement.
In all the cases the abstract model consists of some distribution mechanism where an entity learns about state information (routes or routes to tunnel mappings), and distributes this information to all interested parties (entities that participate in the same service function). In the Openstack/cloud lingo, you can call this RabbitMQ servers and clients, in IETF lingo you can call it XMPP clients and brokers, in BGP lingo you call it BGP speakers and Route Reflectors (since nobody would dare to use full mesh anyway). In different areas you will use different mechanisms to achieve scale. Now, what you distribute through this infrastructure and what type of policies need to be made available, are pretty much orthogonal to the pub/sub infrastructure itself. In BGPs case people have gone through a lot of pain to standardize those policies, headers, formats, and messages to interoperate, and thus lots of functionality is there. In all other cases, interoperability is TBD, since although they have been used in solutions nobody has defined exact message formats and semantics that would allow interoperability. So, my suggestion is to forget the religious wars, and let's concentrate on the functional requirements as is the charter of this group in any case without any reference to names. Quoting Juliet: "What's in a name? That which we call a rose By any other name would smell as sweet." Cheers, Dimitri > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Ivan > Pepelnjak > Sent: Friday, April 20, 2012 1:02 AM > To: 'Igor Gashinsky'; 'AshwoodsmithPeter' > Cc: 'Thomas Narten'; 'Yakov Rekhter'; [email protected]; 'Kireeti Kompella'; > [email protected] > Subject: Re: [nvo3] NVO3 charter 1530UK 12April > > 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=displ > ayKC&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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
