The MPLS-OPS Archive

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



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

RE: Re: : Multi-vendor in MPLS domain

  • From: =?ks_c_5601-1987?B?sce9w8iv?= <kshwan@samsung.com>
  • Date: Mon, 18 Apr 2005 14:33:32 +0900
  • Importance: Normal
  • Organization: SNI
  • Resent-Date: Mon, 18 Apr 2005 02:04:23 -0400
  • X-Scanned-By: MIMEDefang 2.45

  Hi,

 

 I¡¯m going to test interoperability between Cisco¡¯s and other vender¡¯s for IP and MPLS.

 Do you have any test scenario or test results to share?

 

 

-----Original Message-----
From: Lyle Williams [mailto:lyle.williams@bigpond.com]
Sent: Saturday, April 16, 2005 8:14 PM
To: mpls-ops@mplsrc.com
Subject: [MPLS-OPS]: Re: : Multi-vendor in MPLS domain

 

 

I've just come back from a 2547 course where the vendor's (I won't name them yet) idea of what LDP "Downstream Unsolicited" was _wildly_ different from what I have seen from Cisco and Juniper.

 

I've seen interoperability reports that say that (unnamed vendor's) 2547 interworks with Cisco and Juniper, but based on what I saw last week I can't see that this can be so.

 

The vendor's ISIS implementation was also crap.  It wouldn't choose the correct route without an operator bouncing the correct outbound interface.  So much for dynamic routing.  We were allegedly working with production code.

 

Don't assume that things will interwork.  Don't accept test results from anyone you don't trust.

 

Lyle Williams

16APR05

 

 

_________________________________________________________________

 

 

Thamir,

For the most part, vendor products are RFC compliant should interoperate.

However, in some cases they do not. In particular, If you are running LDP

pay attention to ¡°modes of operation¡± which is simply: DU vs DoD, Ordered vs Independent, and Conservative vs Liberal retention.

Some combinations may cause abnormal behaviour in regards to label binding and release.

 

Joe

 

From: Thamir M.Al Hammad [mailto:thammad@stc.com.sa]
Sent: Monday, April 04, 2005 12:33 AM
To: vishwanathan mv; mpls-ops@mplsrc.com
Subject: RE: [MPLS-OPS]: Multi-vendor in MPLS domain

 

Thanks Padmini for your prompt replay,

But what services you are running? Any NGN?

Do you have mix of PEs? Or mix of Ps (mix in the core)?

 

Br,

Thamir

 

 

From: vishwanathan mv [mailto:cheerfulmvp@yahoo.com]
Sent: Monday, April 04, 2005 6:09 AM
To: Thamir M.Al Hammad
Subject: Re: [MPLS-OPS]: Multi-vendor in MPLS domain

 

Yes of course its practical.  We in India very much have this kind of configuration and things work fine provided you find the compatible routers. 

 

- Padmini

"Thamir M.Al Hammad" <thammad@stc.com.sa> 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.

Do you Yahoo!?
Make Yahoo! your home page

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.