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

From: Quintin Zhao <[email-masked]>
Date: Fri, 08 Jan 2010 11:58:57 -0500

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:[email-masked]] 
Sent: Tuesday, January 05, 2010 6:20 PM
To: JP Vasseur
Cc: Quintin Zhao; [email-masked]
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 <[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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 14 Jan 2010 12:41:55 -0800

Hi Quintin,
sorry for delayed reply. If we take Fig.1 from RFC 4090 and remove link
[R3]-[R8], then that will change R1's Backup:

 [R1]------[R2]------[R3]-----[R4]------[R5]
      \           \                    /        \      /
    [R6]------[R7]--------[R8]-------[R9]

Protected LSP: [R1->R2->R3->R4->R5]
R1's Backup: [R1->R6->R7->R8->R4]
R2's Backup: [R2->R7->R8->R4]
R4's Backup: [R4->R9->R5]

As result of lower meshiness of the network the Merge point is moved from R3
to R4.
If only Link protection desired, then, with the topology as above:

R1's Backup: [R1->R6->R7->R2]
R2's Backup: [R2->R7->R8->R4]

Thus we see, that protecting even an immediate link is not always possible
to merge onto Next Hop LSR and depends on level of connectivity (meshiness)
of the network. In my view, using p2mp LSP to provide local protection for
the p2mp LSP is more generic approach.

Kind regards,
Greg

On Fri, Jan 8, 2010 at 8:58 AM, Quintin Zhao <[email-masked]> wrote:

>  ------------------------------
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Tuesday, January 05, 2010 6:20 PM
> *To:* JP Vasseur
> *Cc:* Quintin Zhao; [email-masked]
>
> *Subject:* Re: [Pce] Inter-domain-p2mp-procedures
>
>
>
> Hi Quintin and JP,

---

From: Quintin Zhao <[email-masked]>
Date: Thu, 14 Jan 2010 18:39:49 -0500

Greg,

Thanks for the clarification!

Quintin

  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: Thursday, January 14, 2010 3:42 PM
To: Quintin Zhao
Cc: [email-masked]
Subject: Re: [Pce] FW: Inter-domain-p2mp-procedures

Hi Quintin,

      \           \                    /        \      /

Kind regards,
Greg

Hi Greg,

Quintin

  _____  

Hi Quintin and JP,

Regards,
Greg

Hi,

JP,

For example, to use

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,

JP,

Thanks

JP.

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,

JP.

Hello PCE'rs,

Thanks,

Quintin