Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr

[Loa Andersson <[e-mail]>]

Mustapha,

Is this a recommendation not to adopt the document as a working group
document?

/Loa

On 2015-11-26 11:17, Aissaoui, Mustapha (Mustapha) wrote:
> Dear authors,
> I read this draft and I believe the intent is to provide a tighter control plane synchronization of the PLR and MP roles on a per RSVP session basis such that a LSR will know if it is a MP for a given RSVP session which requested protection. This is done such that the decision to retain or delete the state by the LSR detecting the failure of the link to the previous hop (or the failure of the previous hop itself) is made with the prior knowledge that the LSR is a MP or not on a per RSVP session basis.
>
> However,  the procedures presented in this document are fairly complex and go at odds with the original intent of making state synchronization based on a soft-state mechanism. In fact, what I fail to find is a compelling argument or data from the field which shows the issue is not resolved via much simpler methods which are used in production networks today. I describe this in the detailed comments below.
>
> Regards,
> Mustapha.
> ---------------------
> 1. Section 3.1 - Problem Description
> "
> - If the protected LSP on C times out before D receives signaling
> for the backup LSP, then D would receive PathTear from C prior to
> receiving signaling for the backup LSP, thus resulting in deleting
> the LSP state. This would be possible at scale even with default
> refresh time.
> "
> MA> Since each LSR in the path of a RSVP session which requested protection has to assume it can be a MP without prior knowledge, a simpler method is to reset the refresh timeout for each session as soon as the link to the previous hop failed. In fact, a user configurable MP timeout upon failure, independent of the refresh timeout, can be provided to tune it to the desired value to give enough time to the Path message to be received via the bypass LSP.
>
> 2. Section 3.1 - Problem Description:
> "
> - If upon the link failure C is to keep state until its timeout,
> then with long refresh interval this may result in a large amount
> of stale state on C. Alternatively, if upon the link failure C is
> to delete the state and send PathTear to D, this would result in
> deleting the state on D, thus deleting the LSP. D needs a reliable
> mechanism to determine whether it is MP or not to overcome this
> problem.
> "
> MA> What is exactly the issue with state timeout being retained until the refresh timeout? You refer to this as "stale" state but in fact it is desirable to keep the state until node D created the backup PSB. Also, remember that head-end node will perform global revertive MBB and may tear down the LSP before the state timeout.
>
> 3. Section 3.1 - Problem Statement:
> "
> - If head-end A attempts to tear down LSP after step 1 but before
> step 2 of the above sequence, then B may receive the tear down
> message before step 2 and delete the LSP state from its state
> database. If B deletes its state without informing D, with long
> refresh interval this could cause (large) buildup of stale state
> on D.
> "
> MA> I am not sure I understand the issue here. If B acting as a PLR receives a PathTear from A, all it needs to do is to check that the primary path neighbor (C in this case) is in down or in cleanup state and send the PathTear over the bypass before deleting its own local state.
> Note here a key assumption is that PLR node B must send triggered Path refresh messages to the MP over the bypass. If node B has to wait to the next refresh interval to send the Path refresh over the bypass, then you can run into the issue described here.
>
> 4. Section 3.1 - Problem Statement:
> "
> - If B fails to perform local repair in step 1, then B will delete
> the LSP state from its state database without informing D. As B
> deletes its state without informing D, with long refresh interval
> this could cause (large) buildup of stale state on D.
> "
> MA> Well this is the normal RSVP soft-state behavior and in fact this behavior can occur for defects of link B-C which are not detected and which will not trigger the activation of the bypass LSP. There is nothing abnormal about this and this behavior is not specific to the case when the bypass could not be activated.
>
> 5. Section 4.5.2 - Procedures for backward compatibility:
> MA> What is the need to set the refresh interval to the default value when a LSR detects that a downstream or upstream neighbour does not support the refresh independent procedures? I assume you meant to change it back to the configured value which may not be the default value of 30 seconds.
>