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

[Christian de Larrinaga]

Fred I agree that greater complexity will increase cost for vendors. But why would a user pay more for something that works worse? 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".  

Also there is a small shift in the IPR expectations of a key class of users. One example is the UK Government which recently announced that its definition of Open Standards as those not bearing royalties and requiring purchasing of products supporting Open Standards wherever possible. http://www.h-online.com/open/news/item/UK-Government-defines-open-standards-as-royalty-free-1197607.html

Early days but this starts to put increased pressure on vendors and Standards bodies that customers are now getting wise to an important role of Open Standards as a driver to commoditising core technologies as a key enabler to achieve economies of scale in areas where some vendors and some operators try very hard to impose artificial walled gardens to extract unfair amours of cash. 

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? 

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. 

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. 


Christian


On 26 Feb 2011, at 06:22, Fred Baker wrote:

> 
> On Feb 25, 2011, at 7:11 PM, Alejandro Pisanty wrote:
>> 3. this is partly a statement and partly a question: with diverging standards for MPLS and VPNs available, there begin to be increased incentives to manage whole-country networks in a way that facilitates their isolation from abroad. Suppliers are subject to these incentives so there ensues a perverse virtuous circle for this market. I understand this is what is meant by the public statement we are discussing, and can be decried as one step closer to the "Kill Switch", to be denounced.
> 
> It would likely be network-wide, not country-wide, and would be about vendor lock-in of a network. Common specification and interoperable implementation is ultimately valuable to the customer, who can use any vendor as a second source. What this therefore forces is all vendors to implement both standards, which means that the vendors have to spend more money to build the product, which means that customers get to pay more for the product.
> 
>> 4. though details must emerge to make a more informed judgment, the ITU side's breach of agreement with the IETF is pretty serious and significant; it is likely not purely circumstantial and if it is indicative of a trend, that is a very bad trend. The very least it signals is that not all of the ITU is now geared to the agreements to work cooperatively with ISOC, the IETF, and ICANN, which were so hard to reach as recently as end of 2010 in the Guadalajara Plenipot.
>> 
>> So, a matter of importance, at the intersection of technology, innovation, standardization, society, and policy. Squarely in ISOC's need to attend to.
> 
> yes
> _______________________________________________
> Chapter-delegates mailing list
> Chapter-delegates at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/chapter-delegates