Subject: [Pce] Inter-domain-p2mp-procedures

From: Quintin Zhao <[email-masked]>
Date: Mon, 14 Dec 2009 16:15:42 -0500

Hello PCE'rs, 

I would like to follow-up on some discussions from our PCE WG session last
month. Specifically regarding Dajiang's failure and recomputation
observations on our draft. We are very interested to hear comments regarding
the need for computing secondary paths in the event of failure. Currently
our thinking is to recompute the sub-tree based in the domain where the
failure has occurred. In this case we would not need to perform a
recalculation of the entire tree. We could also recompute the entire tree,
and avoid the failed areas, as long as the TED has the updated topology.
Realistically one might have a backup core tree pre-computed so you can
switch over in the event of failure. There are also other considerations.
Would a partial recomputation provide a "worse" SPT or MCT tree, or would a
full tree recomputation provide a "better" SPT or MCT? I can think of
scenarios for both a partial and full recomputation, so perhaps we need to
implement both but allow the PCC to decide when to issue a partial or full
recomputation based on some criterion.   

Thanks, 

Quintin

---

From: dhruv dhody <[email-masked]>
Date: Tue, 15 Dec 2009 12:08:52 +0530

Hello Quintin, 

I have following comments - 

For Pre-computed Backup Core Tree

1) Is the Backup tree, the next Best core-tree [MCT or SPT]?

2) How path-diverse should the Backup tree be? 

We may need to support all re-optimization scenarios similar to P2MP
Intra-domain cases [explained in draft-ietf-pce-pcep-p2mp-extensions]. 

Thanks & Regards,

Dhruv

Huawei Technologies Co.,Ltd.

Bangalore, India

****************************************************************************
***********

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Quintin Zhao
Sent: Tuesday, December 15, 2009 2:46 AM
To: [email-masked]
Subject: [Pce] Inter-domain-p2mp-procedures

Hello PCE'rs, 

Thanks, 

Quintin 

_______________________________________________

Pce mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Dec 2009 19:25:52 +0100

Hi,

Note that this is a fairly well-known issue. The aim of local repair  
has always been to quickly recover from the failure. The degree of  
resources guarantees and optimality depends on the amount of resources  
dedicated to backup, several assumptions with regards to potential  
simultaneous failures, the algorithms used to pre-compute backup  
tunnels, etc ... The approach taken by P2P FRR has been to first  
locally reroute and trigger a head-end reoptimization using a make  
before break. I do not think that you can draw any conclusion on the  
potentially level of sub-optimality of performing local reroute as  
opposed to global reoptimization. It depends on a number of factors.

JP.