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”.

3 comments:

  1. <quote>
    "disregard the Juniper logo :-)"
    </quote>

    You could have chosen _not_ to say that. Strange.

    ReplyDelete
  2. Ivan Pepelnjak05 March, 2010 21:49

    Welcome to the Internet ;) I have nothing to do with that remark. Just because I'm linking to the web site where I've found the information about the video does not mean I'm endorsing everything that's written there.

    ReplyDelete
  3. Derick Winkworth20 March, 2010 16:46

    1. I like Juniper. I like Cisco too, but JUNOS has some great things going for it.

    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.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.