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
