The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Nov> msg00016



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] Question about draft-ietf-mpls-rsvp-lsp-fastreroute-07

  • From: lidefeng <77cronux.leed0621@huawei.com>
  • Date: Wed, 10 Nov 2004 16:15:23 +0800
  • X-imss-approveListMatch: *@huawei.com
  • X-imss-result: Passed
  • X-imss-version: 2.7

In section "7.2 Procedures for Backup Path Computation", it states that:
 
"Before CSPF computation, the following information should be collected at a PLR:
-...
-...
- The upstream uni-directional links that the protected LSP
        passes through.  This information is learned from the
        RECORD_ROUTE objects; it is only needed for setting up
        one-to-one protection.  In the path-specific method, it is
        necessary to avoid the detour and the protected LSP sharing
        a common next-hop upstream of the failure.  In the
        sender-template-specific mode, this same restriction is
        necessary to avoid sharing bandwidth between the detour and
        its protected LSP, where that bandwidth has only been reserved
        once."
 
My question is
(a) In the following diagram,if failure is R3 node, then next-hop upstream of the failure is R2,right?
(b) if (a) is right? why should we avoid avoid the detour and the protected LSP sharing a common next-hop upstream of the failure in path-specific method and in sender-template-specific mode? and in the following diagram,   Protected LSP is [R1->R2->R3->R4->R5].  Detour LSP is [R2->R6->R7->R4], they share the common next-hop upstream of the failure when R3 is failure, is it a contradiction?
               L32      L33      L34      L35
           R1-------R2-------R3-------R4-------R5
                    |                |
               L46  |      L47       | L44
                    R6---------------R7
 
            Protected LSP: [R1->R2->R3->R4->R5]
            Detour LSP:    [R2->R6->R7->R4]
 
Regards
 
Defeng Li
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls