The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2005-Apr> msg00012



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: Multi-vendor in MPLS domain

  • From: Truman Boyes <truman@suspicious.org>
  • Date: Sun, 10 Apr 2005 22:35:23 +0700
  • Cc: <mpls-ops@mplsrc.com>
  • Resent-Date: Mon, 11 Apr 2005 04:39:46 -0400
  • X-MIME-Autoconverted: from quoted-printable to 8bit by host.secure4-hosting.net id j3B8Cw6j025405
  • X-Scanned-By: MIMEDefang 2.45

Hi Thamir,

Whether or not to run equipment supplied from multiple vendors is a 
multidimensional question. My first response is that YES it is doable, 
and most carriers in some form or another would opt for this approach. 
However, this is not always practical as it leaves you with the lowest 
common denominator in feature sets. In MPLS networks, most standardized 
technologies (2547bis / RSVP-TE / MP-BGP), are deployed across major 
vendors in this space.

Of course your NGN may comprise of more components than just MPLS 
packets and some signaling mechanisms. Your QoS designs may have to be 
thought out clearly when using different vendors, as it is usually the 
subtle things that matter most.

I have worked with many carriers that choose the product based on 
functionality, and install this product as a network standard. As in 
your example, they may decide to use vendor A for their IPVPN PE 
routers, vendor B for BRAS PE Nodes, and vendor C for P nodes. All 
nodes in this network must meet a common set of requirements, while 
some additional functionality might be present in "A" nodes as these PE 
nodes may require advanced features.

The P nodes by vendor "C" might have a stable proven track record 
operating as LSR, but might not be up to spec to handle advanced 
queueing if this product was also deployed on the edge.

The IETF drafts will always be in motion, so unfortunately we will 
always have to deal with vendors investing into technologies and 
protocols that never make it mainstream. CR-LDP is a perfect example. I 
know a few carriers that implemented CR-LDP and then spent a good deal 
of time moving over to LDP over RSVP-TE.

I have worked with many carriers that run multiple vendor products in 
their NGNs and their networks are relatively sound. Supporting multiple 
vendor products comes with a price tag that some people do not see 
until they have a serious bug. The best advice I would say is to pick 
your products based on functionality, reliability, and performance (in 
any order you choose ;) ). Then test the heck out of your network 
designs before putting them into production.

Cheers,
Truman



On 3/04/2005, at 9:54 PM, Thamir M.Al Hammad wrote:

> Hi,
>
>   
>
> I want to know your opinion regarding running MPLS from multi-vendors, 
> is it practical? I mean the PE from vendor and the P from other vendor 
> or  mix of PEs and Ps from different vendors? Specially, in NGN 
> environment where no doubt about TE, QoS, L2VPN & multicasting.
>
> I am afraid about this because I think any of these technologies still 
> draft in IETF and there are different philosophies from different 
> vendors.
>
>    
>
> Do you know any case which successful or failed? Any white paper? What 
> is the possible risk?
>
>  
>
> Br,
>
>  Thamir  Alhammad
>
>  
>
>  
>
> Disclaimer: The information in this email and in any files transmitted 
> with it,
>  is intended only for the addressee and may contain confidential 
> and/or privileged material.
>  Access to this email by anyone else is unauthorized. If you receive 
> this in error,
>  please contact the sender immediately and delete the material from 
> any computer.
>  If you are not the intended recipient, any disclosure, copying, 
> distribution or
>  any action taken or omitted to be taken in reliance on it, is 
> strictly prohibited.
>  Statement and opinions expressed in this e-mail are those of the 
> sender, and do not
>  necessarily reflect those of STC.
>


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

MPLScon 2005 - May 16-19, NYC, NY
http://www.mplscon.com/