JP, Good question! I guess that I should use "more complex to be implemented" instead of "less applicable" in my previous email when I refer to using FRR for P2MP node protection.
What I was trying to mean is that p2p backup is easily to be used for the link protection for p2mp. To use FRR for the node protection in p2mp, it is not that straight forward comparing to p2p node protection, especially from the point view of bandwidth cost and label allocation. For example, to use the p2p tunnel to backup the branch node, we need multiple p2p tunnels to protect a single branch node. If the p2mp backup tunnel is used for the branch node protection, then the upstream label allocation might be needed. Regards, Quintin -----Original Message----- From: JP Vasseur [mailto:[email protected]] Sent: Saturday, December 19, 2009 4:51 AM To: Quintin Zhao Cc: [email protected] Subject: Re: [Pce] Inter-domain-p2mp-procedures Hi, On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote: > > JP, > > Thanks for your comments and suggestions. > > I agree with you that for a quickly recovery, FRR is a good choice. > For the > p2mp TE LSP, if the failures are about link failures, FRR can be > used for > the recovery. If the failures are about the p2mp nodes which can be > the > root/branch/bud/leaf nodes, FRR might not be an easy way to cover > these > cases. What makes you think that the use of FRR is less applicable to node failures ? (for which you could either use a set of P2P backup or a single P2MP backup) Thanks JP. > This may lead to other possible solutions and the pre-computed > backup sub-tree or the whole backup tree might be needed for the > possible > solutions. As you mentioned, using the FRR itself will eventually > need the > head end reoptimization using a make before break. > > The pre-computed backup p2mp path/sub-path or the new computed path > during > reoptimization process using make before breaks are the optimal path > subject > to the OF and all other current constrains when the path is computed > by the > PCE. I agree with you that we can not draw the conclusion on the > potentially > level of sub-optimality of performing local reroute as opposed to > global > reoptimization. > > Also we can not draw the conclusion if these backup path or > optimized path > after the failure is better or worse than the primary path. These > pre-computed backup paths/sub-paths or the optimized paths under the > failure > condition are the best path which can be used for the recovery of the > failure while satisfying all the conditions. > > Regards, > Quintin > > > -----Original Message----- > From: JP Vasseur [mailto:[email protected]] > Sent: Thursday, December 17, 2009 1:26 PM > To: Quintin Zhao > Cc: [email protected] > Subject: Re: [Pce] Inter-domain-p2mp-procedures > > 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. > > On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote: > >> >> 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 >> >> _______________________________________________ >> Pce mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
