Hi folks - I'm one of the authors. All good answers in here and all correct. One throat to choke is a great response with which we agree. The point in our book though is along the lines of the "it should work, but it doesn't" statement already given. Most vendors implement proprietary protocols that they claim to be consistent with RFCs 792, 1058, 4271, 5340 (ICMP, RIP, BGP, OSPF for IPV6) and others . These RFCs are loose enough to allow for differences in implementation. This in turn can cause a bit of a "stacked dependency" problem where 2 or more providers' gear works correctly IAW the RFCs, but not always with each other. Based on our analysis of many companies (n>200) and our personal experiences at both large and small companies the best solution is just to stick with one provider. Specifically, we often see device communication errors between providers as one of the top 5 reasons for down times across our client companies where they have heterogeneous networks. The most common fix is to replace with homogeneity - take your pick of provider.
The problem is exacerbated in that device providers don't test each other's equipment communication as well as they check their own. So more problems are bound to occur. It's really not that much different than the browser problem where your site may work with 3 browsers but get jacked up with another 2.
If you haven't had problems, it may not be worth fixing. If you are designing from scratch, our view is that it's best to stay homogeneous. Thanks for the review and the perspective!