[Chapter-delegates] Statement relating to today’s ITU-T SG15 MPLS development decision

[Fred Baker]

On Feb 26, 2011, at 6:23 AM, Christian de Larrinaga wrote:
> Fred I agree that greater complexity will increase cost for vendors. But why would a user pay more for something that works worse?

Please don't understand me as saying that either is necessarily an inferior product. I give full marks to both organizations for engineering capability. The thing is that the technologies are normally used *within* a network, not *between* networks, and within a network the network will choose vendors and products that meet its needs using whichever technology it chooses. The thing is that vendors now are forced to have both sets of products, either by making separate product lines (ka-ching!) or more complex products (ka-ching!).

> Maybe incumbent operators have an historic political attachment to support ITU specifications but they tend to be not shy about ticking all the "its supported" boxes on the order form then ignoring to implement the one's they don't like. I suspect this will just be a tax that vendors are expected to pay to be "in the market".  

That was my point about complexity. 

> The ISOC / IETF press release can easily be interpreted as a territorial spat between standards bodies rather than a matter of content substance. It is all about process and how ITU-T has broken its agreement. All stuff that seasoned politico's can shrug a so what? 

There is certainly an element of that. The ITU was very offended when the IETF developed enum; we had to explain to them that we weren't reinventing the telephone number ("E.164 number"); we were finding a way to put theirs into our DNS. They took umbrage when we developed SIP, because they saw it as competitive with H.310, H.32x, etc. We pointed out that those various technologies were largely similar, required a lot of carrier infrastructure, and were different for each technology, while SIP was technology-independent. 3GPP decided to take SIP as a "friendly amendment" and use a common signaling protocol. And SIP was built on concepts from our other technology, HTTP; a different way to do a similar thing, but done in a very different way. 3GPP decided to take SIP as a "friendly amendment" and use a common signaling protocol. Yes, there is some of that kind of turf discussion.

In this case, I'll argue that we literally have two standards that do the same thing. And more importantly, it is a place in which the IETF and the ITU sat down and agreed and a way to sort out the issue. Breaking an agreement is a little different than "this came out of research, and it's something you might actually want to think about."

BTW, a side-point to the clean-slate folks, who say "we are doing it over here because we have lost our ability to influence industry". SIP came out of research and fundamentally changed industry. Solve a problem industry is wrestling with, and you'll find that industry is listening.

> It might help if MPLS OAM is explained in terms of where it fits in the Internet architecture and why managing it the right way has public policy consequences for users of the vanilla Internet as well as those using private MPLS services over it. Much of the argument to be made here is in understanding how MPLS is actually deployed and issues across boundaries between vendors, networks both private and public. 

There comes a point where the tutorial is larger than an email... I'll think about that next week perhaps.

> If this matters operationally and key public policy implications are involved then it might be pitched onto the operators lists such as NANOG, UKNOF etc I doubt you will see them clamouring to pay more to implement more complexity. You never know they might even turn up to IETF Prague. The beer is good. 

The IPv6 operators will show up in Prague.