The MPLS WG Archive

[Ling Li <lli@axiowave.com>]

Hi, Joe,

Section 7 of the same draft says:
"To setup the detours described in Section 5 and the bypass tunnels in
   Section 6, CSPF may be used to find the optimal route.  Before CSPF
   computation, the following information should be collected at a PLR:

     - The list of downstream nodes that the protected LSP passes
       through. This information is readily available from the
       RECORD_ROUTE objects during LSP setup. Note, a protected LSP's
       ERO may not provide adequate information since the LSP could
       be a loose routed path."

Although the draft also says in Section 5.2. that "Upon receiving a Path 
message that contains a FAST_REROUTE object, a PLR needs to run CPSF 
based on the information provided", I think this is somehow misleading.
The PLR has to wait patiently for the RRO in Resv message to run CSPF.
My suggestion is please do not bother about "the PLRs must try to 
establish the detour LSPs immediately".

Hope the authors will clarify your concerns in the next revision.

Thanks, 

Ling Li 

Axiowave Networks, Inc. 
200 Nickerson Road 
Marlborough, MA 01752 
======================== 



> -----Original Message-----
> From: Barnett, Joe [mailto:joe.barnett@netplane.com]
> Sent: Friday, October 25, 2002 9:29 AM
> To: 'mpls@UU.NET'
> Subject: Concerns regarding 
> draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt
> 
> 
> > Group,
> > 
> > I have a concern about some portions of
> > draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt. My concerns 
> revolve around
> > the following network topology:
> > 
> >        ---g---
> >       /        \
> > a---b---c----d---e---f
> > 
> > 
> > Where a protected LSP using the detour method would be routed
> > [a,b,c,d,e,f], and a detour would be generated at [b](PLR) 
> to avoid node
> > [c]. There would be an expected merge at node [d](MP). 
> > 
> > The basis for my concern is that the draft specifies in section 5: 
> >       "Upon receiving the local protection requests for a 
> protected LSP, 
> >        the PLRs must try to establish the detour LSPs immediately."
> > 
> > Furthermore, what if at [c] the protected path message was 
> delayed for
> > some unknow reason which caused the detour path to reach 
> [d] first causing
> > the detour's path message to propagate downstream. 
> According to section 7,
> > it is stated:
> >  
> >       "The source address of the backup LSP is the current PLR,
> >        For setting detours (Section 5), the destination MUST be
> >        the tail-end of the protected LSP"
> > 
> > What this indicates to me is that the detours explicit path 
> generated by
> > CSPF(perhaps) would be [b,g,d,e,f], and if the delay 
> actually occured on
> > the protected path between b and d , wouldn't the detour 
> path message be
> > propagated all the way to [f]? If this was to occur, and just for
> > argument's sake, that node [d] was able to merge the 
> protected path state
> > and the detour path state, and then send on only the protected path
> > message after the merge, how would node [e] recognize that 
> the subsequent
> > path message containing the FASTREROUTE object was in 
> relation with the
> > previously received path message with a DETOUR object? I 
> ask this due to
> > the fact that if using the Sender-Template Specific method, 
> wouldn't the
> > IP address differ in the SENDER_TEMPLATE? 
> > 
> > Knowing this, the identification information presented in the draft
> > (Sender,Session) could not be used at [e], since in the 
> protected path
> > message's SENDER_TEMPLATE will contain the IP address of 
> [a]. Am I missing
> > something? (IMHO) Wouldn't it be better for all PLRs to 
> wait for the RESV
> > of the protected LSP before creating a detour? Or at least 
> specify a way
> > for CSPF to generate an ERO that ends at [d] and that the 
> MP must not
> > propagate the detour path message on downstream?
> > 
> > Kind regards,
> > Joseph Barnett
>