Subject: [mpls-tp] Benefits of co-routed bidirectional paths in MPLS-TP (was: Associated bidirectional transport path requirements)

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Apr 2009 13:34:35 +0300

Ben,
Lots of thanks for the clarification.

I fully agree with your comments regarding inability of the customer of a transport service to distinguish between a service delivered over a co-routed bidirectional path and that delivered over an associated one. And I also fully agree that PWs running over existing (standardized) MPLS networks are associated bi-directional paths, and this does not prevent them for delivering critical services.

While this may not bear a direct impact on the MPLS-TP Requirements draft per se,  IMHO and FWIW it would be really helpful if somebody explained the benefits of co-routed bidirectional paths vs. associated ones.

One (and so far, the only one) such benefit that I see is ability to localize a fault in the MPLS-TP layer while remaining in the framework of MPLS-TP OAM mechanisms.

If you (or others) see any other benefits, I would be most interested to hear about them. At the same time, it would be nice to understand whether localization of faults in, say, P2MP unidirectional paths can be achieved within the same framework...

And yes, I understand that this is about solutions and not about requirements. But I think that an important (even if implicit) requirement for MPLS-TP is ability to address the needs of various types of transport paths it supports within a single framework.

I'd like to join other people on this list who have said that you're doing an excellent work as the Editor of the MPLS-TP Requirements draft. I apologize if I have inadvertently contributed to this work being more uphill that it should be.

Regards,

     Sasha

________________________________________
From: Ben Niven-Jenkins [[email-masked]]
Sent: Thursday, April 16, 2009 1:07 PM
To: Alexander Vainshtein; Lou Berger; BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Sasha,

On 15/04/2009 16:34, "Alexander Vainshtein"
<[email-masked]> wrote:

> Italo, Lou and all,
>
> I apologize if I have misinterpreted some of the messages on this list, but:
>
> 1. My reading of  one of Ben's  messages is that associated bidirectional
> paths are the only types of paths that can be created in the existing
> networks; "true" co-routed bidirectional paths will have to wait until (if
> ever) new equipment becomes available.

Not really IMO. If we have the starting base of a standardised MPLS
implementation then IMO (but I don't build equipment) associated
bi-directional "only" requires changes to an individual boxes implementation
and how it internally models/represents various network elements (e.g.
LSPs).

Co-routed bi-directional paths require new protocol mechanisms (be it
reusing GMPLS or creating something new). Changing the protocols used in a
deployed network is not easy, it is painful both in terms of effecting any
migration, changing systems, upgrading equipment, reskilling operations,
etc. It is not a task undertaken lightly. Changing behaviour of a single box
is much easier (but not always child's play).

I think there are benefits to co-routed bidirectional paths but there is
also pain to getting them into existing deployed networks. Associated
bi-directional provides a means to achieve some of the benefits with less of
the pain IMO.

I would further add that from a customer of the transport network's
perspective due to the client/server relationship and independence whether
the underlying transport network uses associated bidirectional or co-routed
bidirectional is transparent to the customer provided the transport network
provides the necessary performance that the customer requires.

I would also note that PWs running over a standardised MPLS network today
are associated bi-directional entities and they are being used successfully
today to support at least some transport network services such as Circuit
Emulation.

Ben