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

From: Greg Mirsky <[email-masked]>
Date: Tue, 5 Jan 2010 15:19:59 -0800

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-masked]>

> 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-masked]]
>> Sent: Saturday, December 19, 2009 4:51 AM
>> To: Quintin Zhao
>> Cc: [email-masked]
>> 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-masked]]
>>> Sent: Thursday, December 17, 2009 1:26 PM
>>> To: Quintin Zhao
>>> Cc: [email-masked]
>>> 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-masked]
>>>> https://www.ietf.org/mailman/listinfo/pce
>>>>
>>>
>>>
>>>
>>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>