Hi Greg,
Thanks for the comments and suggestions! Can you elaborate a little more on what you mean here? I think that because we can not guarantee that the immediate LSR will be the merging point of p2p backup LSP one can not assume that a single p2p can be used to provide protection for local link failure case. Quintin _____ From: Greg Mirsky [mailto:gregimir...@gmail.com] Sent: Tuesday, January 05, 2010 6:20 PM To: JP Vasseur Cc: Quintin Zhao; pce@ietf.org Subject: Re: [Pce] Inter-domain-p2mp-procedures Hi Quintin and JP, in regard to applicability of p2p FRR protection of links of p2mp LSP I agree with JP that such applicability is questionable and very much depends on network topology, its meshiness. I think that because we can not guarantee that the immediate LSR will be the merging point of p2p backup LSP one can not assume that a single p2p can be used to provide protection for local link failure case. I believe that strong case can be made to recommend use p2mp for local link protection as well as when node protection required. Regards, Greg 2009/12/23 JP Vasseur <jvass...@cisco.com> Hi, On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote: 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. Well this is arguable though .. 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. Well it all depends on how you compute your P2P backup, and this may be used for a very short period of time. There are excellent off-line algorithms to achieve some good level of efficiency. 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. Which is not a major issue. See long discussions on the list some time ago on the subject matter. Thanks. JP. Regards, Quintin -----Original Message----- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: Saturday, December 19, 2009 4:51 AM To: Quintin Zhao Cc: pce@ietf.org 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:jvass...@cisco.com] Sent: Thursday, December 17, 2009 1:26 PM To: Quintin Zhao Cc: pce@ietf.org 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
