The MPLS WG Archive

["Kullberg, Alan" <akullber@netplane.com>]

> > 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.
> >
> 
> Not really. For one-to-one backup, the PLR will try to setup a detour
> only AFTER the protected LSP is up and running. When a 
> protected LSP is
> up and running, the PLR can always get the RRO and all other junk from
> the protected LSP to setup the detours.

I think that the paragraph from section 5 could be interpreted to mean
    upon reception of a PATH message containing FASTREROUTE object,
    immediately send out 2 PATH messages, 1 for the protected LSP and
    another for the detour LSP.

Therefore, I think the wording could be changed to clarify this as follows:

    Upon reception of a RESV corresponding to a PATH message that
    contains the FASTREROUTE object, the PLR must try to establish
    the detour LSP immediately.

OR, by "protected LSP is up and running", did you mean that the LSP is
active all the way from ingress to egress, which implies either the
ingress inserts the FASTREROUTE object only AFTER receiving the 1st
RESV, or all PLRs wait for a RESV_CONF message to begin detour LSP
setup.

Alan