The MPLS WG Archive

[Atsushi Iwata <iwata@ccm.CL.nec.co.jp>]

David,

Thank you for your comments.

At 13:32 01/08/06 -0400, David Allan wrote:

>A simple question (which I did not get a chance to ask in the meeting today): 
>
>When the "Backup LSP trigger" message is issued up the primary path, 
should it not also contain an ERO object for the primary path as well as 
the first backup route.

I see your point. I forgot to mention it on my presentation. 

Yes. We have to include the ERO object for the primary path as well for 
computing the disjoint path from this primary path.


>Seems to me I should care a whole lot about the tributaries to the shared 
backup being diverse with the primary path. (I'll call them tributaries as 
I couldn't find a specific term for them). Right now I do not think I can 
make that statement unless every LSR in the primary path retains ERO 
information (in order to verify this when performing the shared path 
computation), and it would not currently (IMHO) have reason to do so.  So 
my shared path computation becomes, "shortest path to the first backup LSP 
that is route diverse with the primary LSP".

I understand your concern. Even if we allow the primary path to retain the 
ERO information, there is a case where Path message for estabishing the 
primary only includes the loose source route information. In such a case, 
such a ERO information is not enough to compute the disjoint path from the 
primary path. Therefore, as I described above, we need to include the ERO 
object for the primary path in the Backup LSP Trigger message. 


>This is really a separate issue from the suggestion that there is no 
shared path computation required, and the backup LSP from any LSR in the 
primary path simply be opportunistic in merging with any other backup paths 
for the same LSP encountered along the optimal backup route. This would 
appear to have the same effect as constantly updating the ERO propagated 
with the "backup LSP trigger" after the establishment of each backup tributary.

Interesting to me. This might be an another option. We can reoptimize it by 
using such a soft state your proposed here.


>BTW, I'm inclined to note that if there is any resource committment 
associated with these LSPs, it makes 1+1 look positively frugal. Perhaps we 
could invest some effort in fault propagation efficiency and save a whole 
lot of bandwidth....

Good comment.

If we use 1+1, then we need to add another capability on my proposed share 
fast-reroute. On the merging point of shared backup path, we have to have a 
intelligent filtering which only forwards one of the the others to 
downstream node so that the data should not be replicated at the merging point. 

Thank you for your valuable comments. I'll reflect your comments in the 
future draft.

Best Regards,

----------------------------------------------------------------
Atsushi Iwata, Ph.D.
Principal Researcher
Network Architecture TG, Networking Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
Internet E-mail:     a-iwata@ah.jp.nec.com
NEC-internal E-mail: iwata@ccm.CL.nec.co.jp

*** Organization has been a bit changed since Apr.2001 ***