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 <[email protected]> > 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:[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 >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
