Re: GMPLS Last Calls

[Ping Pan <pingpan@juniper.net>]

Bala Rajagopalan wrote:
> 
> Hi,
> 
> There are two aspects to this problem:
> 
> Pre-establishment of protection paths: This
> is something requiring signaling support during
> provisioning. Don't see any problem in supporting
> this under the current GMPLS framework.
> 
> Real-time restoration signaling: Our
> view is that a dedicated lightweight protocol
> is appropriate. (of course, there are other
> views on this :-). )
> 

Hi,

Many backbone links are SONET, which can redirect traffic to a backup
channel within 50 msec. This is the requirement that we are dealing here
in MPLS. So in backbone, we have to rely on pre-established LSP' for
restoration. I doubt there is any simple method for network nodes to
detect link failure, setup a new session and adjust all sort of stuff on
*real-time*.  I could be wrong. Does anybody have the measurement timing
data on ATM crankback?

IMHO, the only reason for using real-time restoration signaling is to
satisfy end-user applications, where based on the network feedback, the
user application can apply various adaptive mechanisms to renew
sessions. I don't think this is the within the framework of MPLS.

2 cents,

- Ping

> I don't see an obvious show-stopper here w.r.t
> progressing the current drafts for last call.
> 
> Regards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: braja@tellium.com
>