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

[Christian de Larrinaga]

Yes the dynamic in the market is that vendors sell to networks not inter-networks.  Users are interested in end to end and so have a stake in the state of inter-networking. I wasn't suggesting you do a write up of MPLS implementation but that having one to refer to from the ISOC/IETF statement would be helpful in unpicking the issues as substantive rather than simply an institutional spat (which it seems to be). 

The Sales vector poses a question with MPLS whether or to what extent MPLS services depend on gateways between each other or whether the user is able to support an unbroken IP layer across networks that support MPLS between each other (as in a vanilla IP peer or transit ). 

A second question is raised with having two standards working across that service vector. I don't believe vendors really will implement transparently between two standards. It is hard enough to get them to implement transparently between two implementations of the same standard in a way that can be depended on across all vendor and potential network paths. I am not knocking engineering ability but the business viability or intent in covering all the potential bases across boundaries for products which are focused on sale within them. I assume that is behind what Russ Housley and IETF are arguing that certain routes and so users will be unavailable depending on the choice of MPLS you implement. 

A Third question is really a question mark raised from the experience with SIP and ENUM. The SIP example does exhibit the problems of implementing varying specifications (IETF and ITU-T) but the substantial issue that has in part come out of this has been that SIP implementation is rarely end to end. The excuse of SIP to SS7 (IP to TDM) connectivity is leading to SIP terminations (both signalling and data paths) at service providers (in Internet).  So even with a Standard that allows separate signalling paths to data paths it turns out that implementations are often not following that model. That is despite the increase in the cost to use the SIP switch gateway for both. The business model of obscuring end points is more valuable it seems. 

Even if the end point of a SIP session is another IP user SIP services still tend to intermediate and break the connection at their switch and establish a separate ongoing one from their switch to the ultimate user. This intermediation is a problem for users. If only that it breaks their ability to define and deploy rich services between each other including end to end security. SIP also shows that the market can turn up some surprises where heavyweight protocol negotiations focused on selling product into a network misses a point as is shown up by Skype for instance. Skype did its own thing and only uses SIP as standardised (somewhere) for traffic they manage between service provider gateways. For clients they wanted to implement a form of neighbour discovery and so the Skype client became P2P. 

The ENUM example points to the danger of allowing the politics between organisations lead to such compromises within the Internet sphere that the benefits that would accrue from a user orientated implementation is lost in the noise from actors using institutional bodies as cover as they scramble to catch up and or block what they see as a leakage to their incumbent business plans in another loosely competing sphere. So ENUM is not solving the SIP gateway problem but is in fact reinforcing it through private implementations of ENUM like registries. 

Now add MPLS... 


Christian 


On 26 Feb 2011, at 18:51, Fred Baker wrote:

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