Subject: [mpls] MPLS protection switching coordination

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 8 Apr 2010 00:49:30 +0530

Hi,
Please clarify my doubt on the draft-ietf-mpls-tp-linear-protection-01.

Can't we pre-configure the egress node to take traffic on both the working
path and protection path at a time
though we send the traffic in one path (working or protection) at any point
in time (1:1)?

Instead of taking the action to move the traffic from working path to
protection path and vice versa upon failure using PSC, can't we just run the
signalling protocol to ensure that working/protection path is alive before
any failure/degraded condition?
If we do this we can easily switch the traffic immediately without any
coordination from the peer node.

It seems PSC may create over-head on the traffic switching from working path
to protection path and vice versa.

And it seems that IETF RFC-4090 (Fast Re-routing) talks about protected path
and backup but in protection switching we use the term working path and
protection path.
Is this different convention really required?

Please bear with me if the above is very basic.

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 07 Apr 2010 21:52:18 +0200

Hi Venkatesan,

You wrote:

> Can't we pre-configure the egress node to take traffic on both the
> working path and protection path at a time
> though we send the traffic in one path (working or protection) at any
> point in time (1:1)?

What you propose is to use a merging selector, this is not allowed
in MPLS-TP.

> protection path and vice versa upon failure using PSC, can't we just run
> the signalling protocol to ensure that working/protection path is alive
> before any failure/degraded condition?

How would the signalling be sent in the absence of a control plane?
Just like APS: in-band with the data.
The APS protocol "signals" that W and P are alive by sending NR (no
request).

> coordination from the peer node.

This is possible only in case of uni-directional protection
switching where both directions switch independently, this is
possible only in 1+1.

> It seems PSC may create over-head on the traffic switching from working
> path to protection path and vice versa.

Three messages at 3.3 ms if a change is signalled, and one message
per second in stable state will not create a significant overhead.
And it is also only sent on the protection entity, so there is no
overhead on the working entity.

> And it seems that IETF RFC-4090 (Fast Re-routing) talks about protected
> path and backup but in protection switching we use the term working path
> and protection path.

In protection switching it is possible that only a section of
the whole path is protected, this section has a working and a
protection entity.
This difference can be documented in the Rosetta draft if necessary.

> Please bear with me if the above is very basic.

I hope you have a better understanding now of these basics.

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...