RE: Single vs many solution(s)
"Mark Seery" <[email protected]> Tue, 20 May 2003 22:36:26 -0700
| Newsgroups | gmane.ietf.ppvpn |
|---|---|
| Message-ID | <[email protected]> |
Yakov, [SNIPPED] >> The one that reflects reality, and not the one that reflects wishful thinking. With this in mind the following from Ross' e-mail answers your question. << As I have stated before I am generally sympathetic to the idea that there are very different service providers with very different requirements; and therefore perhaps multiple standards are called for. But, some comments. I did think Ross's email was excellent, but some further color to his comments might be beneficial. In the case of developing RIP, OSPF, BGP4, etc. we kind of lucked out (or perhaps it was good intentions) in the sense that all three could be used easily in the same network - and together - because it was relatively simple to export/import routes (where applicable and advisable) because they all used the same addressing structure, so a route was a route was route which could be imported into the kernel (or its equivalent). So things worked out nicely. But what if they had all used different addressing structures, or where othewise incompatible? In the case of the Ethernet example, things actually did not work out so well. First it has to be noted that even the IEEE recognized the need for some level of interoperability, so IEEE 802.2 was defined for all (Standardized by the IEEE) Ethernet MACs. But even this did not produce good results. Bridging between Ethernet, TR, and FDDI was **very** painful. There are many reasons, some related to some interesting layer 3 encapsulations, in the case of IPX, the old canonical/non-canonical issue, function points, blah, blah, blah.....etc. Now we can argue that eventually it all worked out well because the industry trended in one direction, but for the peroid where vendors had to support all three, it was extremely painful; on both an interoperability and chip level (in the case of TR); and all three had to be supported because their vendors could claim the legitimcay of being standards. So at a minimum, it would be nice to see obvious (meaning it may be occuring but not visible) evidence of cooperation between competing proposals to identify areas of commonality, and seek interoperability. More generally, such a process may lead to other levels of cooperation. To date we have asked the binary question of single or many. Is there also some intermediate states? Best, Mark