Subject: [mpls] Question about RFC4090 : Merging Detours using the Path-Specific Method

From: <[email-masked]>
Date: Thu, 17 Nov 2011 15:38:05 +0100

Hi all,
 
I have few questions about the Merge Point behavior when detour object
is used.
If we consider the following LSP : R1 - R2 - R3 - R4 protected using FRR
one to one, node protection, detour object used.
R1 computes a detour path : R1 - R5 - R6 - R3 - R4
R2 computes a detour path : R2 - R1 - R5 - R6 - R7 - R4 
 
We can see that there is a potential issue as R1 detour is using R3
which need to be avoided by R2 detour.
 
RFC says that : 
"
     2. From the remaining set of Detour Path messages, eliminate from
        consideration those that traverse nodes that others want to
        avoid.

"
 
In this case, we except that detour be signaled by R1 as merge point
should be : R1 - R5 - R6 - R7 - R4 instead of the one computed.
But I can be clear exactly on what's happening if : R1 detour is
operational first, so R1 signals his detour along the path he computed,
and then R1 receives path msg from R2 with detour object to avoid R3.
Need R1 to break the detour signaled and signal the new one as the path
signaled doesn't fit the condition ? "eliminate from consideration those
that traverse nodes that others want to avoid."
 
After some tests on one vendor equipment, we saw some non deterministic
behavior :
- if R1 signals detour first, R2 receives a path Err from R1 when it
tries to signal his own : path can't be merged
- if R2 signals detour first, R1 merge his own with R2 detour already
signaled.

Why not always using the condition 3 as if there was no remaining path ?
: "3. If several still remain, which one to forward is a local
        decision.  If none remain, then the MP MAY try to find a new
        route that avoids all nodes that merging Detour Paths want to
        avoid; it will forward a Path message with that ERO.
", this would permit to always have a detour available with optimal
protection.
 
Can someone clarify for me the expected behavior ?

Thanks,

----
Stephane

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.