This is how you design a useful protocol
A post in the My CCIE Training Guide pointed me to the GoogleTechTalk given by Yakov Rekhter (one of the fathers of BGP) in 2007. You should watch the whole video (it helps you understand numerous BGP implementation choices), but its most important message is undoubtedly the Design by Pragmatism approach:
- They had a simple, manageable problem (get from a spanning-tree Internet topology to a mesh topology).
- They did not want to solve all potential future problems; they left that marvelous task to IDRP (which still got nowhere the last time I've looked).
- They started with simple specifications (three napkins), had two interoperable implementations in a few months, and wrote the RFC after BGP was already in production use.
- They rolled it out, learnt from its shortcomings and fixed it.
- They gradually made it easily extensible: TLV encoding, optional attributes, capabilities negotiations. This approach made it possible to carry additional address families in BGP and use it for applications like MPLS VPN and VPLS.
One could only hope that the IPv6 architects had used the same approach ... but as Yakov said in his talk, that’s “water under the bridge”.
"disregard the Juniper logo :-)"
</quote>
You could have chosen _not_ to say that. Strange.
2. Too bad the "design by pragmatism" is not accepted more elsewhere. Many technology companies think its possible to know every variable and and all costs to the penny before you even get to the purchasing phase. All possible issues and all costs forever and on-going should be known quantities. Of course, thats non-sense and it leads to endless meetings and a great deal of political hoopla to get meaningful work done. Its all about balance of course. Theres risk, but theres also also work to be done and a ticking clock on the wall.
I frequently say at work.. "We'll cross that bridge when its on fire." It scares some people, but hey... none of us are psychic.