The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Section 7.4.3 of draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt describes 
the format of the Path message that is sent into a bypass when an LSP 
has failed into that bypass.

The message is described in terms of differences between it and the Path 
message that was being sent prior to the LSP's failing-into the bypass:

1: Turn off the three local-protection bits from SESSION_ATTRIBUTES:
    local protection desired, bandwidth protection desired, node
    protection desired.

2: Change the sender address of the SENDER_TEMPLATE to the PLR's
    address.

3: Change the HOP object's address to the PLR's address

4: Strip off all ERO subobjects corresponding to nodes upstream of
    the merge point (prepending the MP's address, if necessary to keep
    the ERO valid.)

5: Set the local-protection bits in the RRO (local protection in use,
    and optionally bandwidth protection and node protection.

My question is why we should implement nos. 1 and 2.

This Path is not signaling a new LSP, but is effectively refreshing the 
existing LSP, but using the bypass.  The ingress of this LSP is not the 
PLR, but the original ingress node.  The SESSION_ATTRIBUTES bits are 
going to be forwarded further downstream beyond the merge point, and we 
don't want to disable local repair on those nodes.

It seems to me that those two clauses are only appropriate for signaling 
DETOUR LSPs - since the DETOUR is distinct from the original protected 
LSP (originating at the PLR and terminating at the MP).

Assuming that I'm just confused and the draft is correct as written, it 
begs the next question.  How will the merge point know that the Path 
message coming out of the bypass tunnel is refreshing the original 
protected LSP if the sender address has changed?  Is this new Path state 
supposed to completely supplant the original Path state, allowing the 
original to time out and be torn?

This seems rather strange to me.  I was under the assumption that the MP 
would maintain the state of the original LSP, using the Path messages 
coming out of the bypass to refresh it until it reverts back to normal 
behavior (via local or global revertive behavior.)

Have I missed something critical here or does the draft need clarification?

-- David