The MPLS WG Archive

["Barnett, Joe" <joe.barnett@netplane.com>]

> 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