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 actaully occured on
> as described, 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