The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <076236BAE727D611943F00508BA0F95906E752@XOVER.dedham.mindspeed.com>,
 "Kullberg, Alan" writes:
> I have a comment on draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt.
> 
> >From section 5, 2nd paragraph:
> 
>    Upon receiving the local
>    protection requests for a protected LSP, the PLRs must try to
>    establish the detour LSPs immediately.
> 
> But section 7 states that before the CSPF computation can proceed,
> the PLR should collect the RRO detailing the downstream nodes and
> links.  This RRO is in the RESV.
> 
> Section 5 and 7 seem to be contradictory when the initial PATH
> message from the ingress node includes the FASTREROUTE object.
> 
> Alan


You are right about the document not being clear.

If the LSP is strictly routed, the ERO has all the information you
need to do the CSPF.  If there are some loose hops, you have better
information when the RRO arrives.  In the worst case, the next hop is
loose and there is one more hop that is loose.  In that case, based on
the ERO alone, the only candidate for merging with the primary path is
the egress.  When the RRO arrives you can do the equivalent of
make-before-break on the detour path if the RRO provides a better
merge point.

If you create the detour before receiving the RRO, you can confuse
some routers by having the detour PATH message arrive before the
primary is set up.  Some routers can handle this some can't.

The advantage of setting up detour as quickly as possible is that
local-protect-available can be set sooner (if using those bits, which
at least one pre-standard implementation does not use).

Curtis