MPLS, GMPLS and Pseudowires: The Need for Cooperation Between Standards Bodies Adrian Farrel Old Dog Consulting adrian@o

1. MPLS, GMPLS and Pseudowires:The Need for Cooperation Between Standards BodiesAdrian FarrelOld Dog Consultingadrian@olddog.co.uk www.mpls2005.com

2. Why Have Standards? • Do we all want standardization? • Sometimes I wonder! • Good for Providers • More choice and flexibility • Good for Vendors • Ease of market penetration • Good for Individuals • Transferable skill set • All of these points have equally powerful opposites

3. Why Have Standards Bodies (SDOs)? • What is the alternative? • Each company develops and documents its own solution • Everyone has to implement two or three solutions • Chaos, confusion and expense • We can learn from other people • There is a relatively small global pool of “experts” • Acapulco is very nice at this time of year • Does everyone in the SDO want standardization?

4. Which SDOs Impact MPLS and GMPLS? • Internet Engineering Task Force (IETF) • International Telecommunications Union (ITU) • Optical Interworking Forum (OIF) • Institute of Electrical and Electronic Engineers (IEEE) • MPLS, ATM and Frame Relay Alliance (MFA) • Tele Management Forum (TMF) • IP Sphere ?? • Others ??

5. Some Overlap Between SDOs • This is an understatement! • Converged networks imply converged SDOs • Examples: • IETF, ITU-T and OIF working on protocol specifications for control planes for optical networks • IETF and ITU-T overlap on MPLS applications such as • OAM • Pseudowires • MPLS transport • IETF examining ways to manage IEEE Ethernet networks • MFA and ITU-T working on MPLS NNIs etc.

6. Are Multiple MPLS and GMPLS SDOs Helpful? • Against • Do we want multiple standards for the same function? • Can we hope to attend all relevant standards meetings? • SDOs become marketing organizations • Chaos, confusion and expense • For • Different SDOs have developed specializations • Different applications, protocols or functions • Architecture versus protocol • Requirements, experimentation, development, operation • Different SDO processes are conducive to different results • It’s good for job creation • Hawaii is a pretty nice place

7. What Is the Solution? • SDOs have a duty of care to the industry • No SDO should regard itself as “better” than any other • Each SDO must protect itself from abuse • “Standards shopping” • Corporate politics • Each SDO must be aware of overlaps and potential overlaps • Communicate plans • Seek “natural homes” for work • Cooperate to a common goal

8. What Form Should Cooperation Take? • Focus on the end result • Devolve work to areas of expertise • Clear sense of ownership of protocols • Understanding of wider implications of changing protocols • Responsiveness between SDOs • Questions and clarifications • Requests for assistance or work • Formal liaison process may be helpful

9. Do We Need Formal Processes? • Skepticism, lack of trust, and turf wars • Bad history • Over-specified process may ensure smooth operation • Can relax the process in the future • Process must include a commitment to follow the process • For example: • MPLS and GMPLS Change Process (draft-andersson-rtg-gmpls-change-01) • Makes the IETF the place for developing protocol extensions for MPLS and GMPLS • Includes a commitment by the IETF to receive requirements from other SDOs