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

From: Chandrasekar Ramachandran <[email-masked]>
Date: Wed, 2 Dec 2015 19:27:47 +0000

Mustapha,

> -----Original Message-----
> From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-
> lucent.com]
> Sent: Thursday, November 26, 2015 8:48 AM
> To: Sriganesh Kini <[email-masked]>; Loa Andersson
> <[email-masked]>; Lucy yong <[email-masked]>
> Cc: Lizhong Jin <[email-masked]>; Guijuan Wang 3
> <[email-masked]>; [email-masked];
> [email-masked]; Aissaoui, Mustapha (Mustapha)
> <[email-masked]>; [email-masked]
> Subject: RE: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
> 
> 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.

[Chandra] The primary motivation of the draft is to enable LSRs to support FRR when the LSP scale on the LSR is of the order of hundreds of thousands. The analysis of the bottlenecks as a consequence of LSP scale, that can cause disruption of the LSR has already been documented in RFC 5439. As analyzed in RFC 5439, while there is a correlation between the percentage increase in refresh time and the improvement in LSR performance, there is a degree of functionality that is lost owing to the soft-state nature of the protocol. TE-SCALE-REC (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-00) outlines the motivation for refresh independent RSVP (RI-RSVP) for all types of LSPs (packet or non-packet), and makes recommendations to enable RSVP implementations eliminate the reliance on short refresh time. This draft addresses the refresh-interval dependent behavior of RFC 4090 in order to support RI-RSVP, as facility backup FRR is a widely deployed feature in production networks.

> 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.

[Chandra] The tradeoffs between using short or long refresh intervals has been well understood. Short refresh intervals aid fast synchronization of states along the path of the LSP, but is problematic because of the control message traffic that a router has to handle at high LSP scale. Routers not only must synchronize new states as promptly as possible, but also must maintain the rate of periodic Srefresh messages to a level sufficient to refresh all existing states without being timed out. When the number of LSPs that routers carry approach half a million, there will be two problems with the control message rate.
(1) As analyzed in RFC 5439, even with RFC 2961 refresh reduction the size of Srefresh message may become very large, and the processing required may cause disruption of the LSR.
(2) Apart from the problem of RSVP message processing overhead, there is also the problem of RSVP-TE becoming a bottleneck preventing the router to scale other protocols or services.

> 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.

[Chandra] Some of the mechanisms already deployed in multi-vendor production networks involve configuring implementation specific timers or delays on LSRs. Multiple vendors support various timers or delays on Ingress and Transit LSRs. However, in practice the values configured for these timers or delays are very scale specific, and the values that work at one LSP scale usually do not work at higher LSP scale. In practice, the "scale" that impacts the behavior at specific timer or delay value is not only the number of LSPs carried on the router, but also the number of other protocol states that reside on the router. It should be noted that the reliance on such implementation specific timers or delays has been a major contributor of operational complexity in running RSVP-TE FRR. Any solution based on such timers or delays while being operationally simple at one scale ceases to be so at higher scale. It has been practically found (with existing implementations from multiple vendors) that it is operationally hard to find out the new better value as a running production network grows over time. In short, the use of such timers or delays has been found to involve guess work that seldom remain simple in the long run.

> 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.

[Chandra] The option of resetting the refresh timeout may not be viable if long refresh interval (of the order of tens of minutes) is applied on the LSPs. That leaves the other option of providing a "wait timer" (independent of refresh time) that is configurable on the MP. However, it is fairly clear that the "wait timer" that the operator should configure on MP will be problematic for two reasons. The operator should carefully analyze the performance impact of an existing timer/delay value if and when (a) the LSP scale on the same router increases, and (2) the LSP scale increases on other routers around it (that may potentially become upstream PLRs)!

> 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.

[Chandra] As described in the first response in this mail, the motivation driving the draft is to eliminate RSVP-TE's reliance of short refresh intervals. If router C were to retain the LSP state until time out, without any additional procedures that provide an explicit indication to router C on when the LSP state is no longer required, then router C would retain the LSP state potentially for hours if the refresh interval is long. So, router C will not only store the state of the LSP but also periodically send the Path message (in Srefresh) downstream - thereby unnecessarily consuming resources that could potentially be utilized for other LSPs.

It should also be noted that the transit router cannot assume that Ingress LSR will be able to complete global repair within a particular time frame. The transit LSR procedures should be able to handle cases when global repair does not complete for some valid reason for an extended period of time.

> 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.

[Chandra] The problem described is different. Router B detects the failure and undertakes local actions for re-routing traffic for all protected LSPs traversing the failed link. In parallel, router B also initiates backup LSP signaling for all those protected LSPs. At scale (i.e. if the number of protected LSPs thus undergoing repair is of the order of hundreds of thousands), the initiation of backup LSP signaling for all those protected LSPs is not expected to happen within short time period. If the Ingress LSR initiates LSP tear down during this interim time duration, the existing procedures do not offer any mechanism for router B to indicate to MP that it need not hold on to that state any longer. The new procedure described in the document does not introduce any major extension but simply use PathTear message from PLR to MP even though the PLR had not reliably refreshed backup LSP Path.

Here again, one may suggest the use of some "wait timer" on MP independent of refresh time out - say if the MP does not receive backup LSP Path message within the "wait timer", the MP can delete the LSP state. But depending on a timer or delay suffers from the same drawbacks pointed out in the response to comment #1.

> 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.

[Chandra] The problem is not about the activation of bypass LSP but that there is no indication to the MP router that it does not have to hold on to the LSP state any more. The problem has been explained in the response to comment #3 and #4. On the soft-state behavior, the responses to the first three paragraphs to your mail contain the reasoning for removing the limitations of soft-state nature of the protocol.
 
> 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.

[Chandra] If refresh time is not explicitly configured on the LSR supporting RI-RSVP-FRR, then the refresh interval should be reduced to RFC 2205 default value of 30 seconds for messages sent to a neighboring router that is not RI-RSVP capable. TE-SCALE-REC draft recommends default refresh interval of 20 minutes be used in Path and Resv messages if RI-RSVP is supported by the LSR. The statement in the draft referred here is not applicable if the operator has overridden the RI-RSVP default value.

I think the text in Section 4.5.2 could have state explicitly that if downstream or upstream neighbor does not advertise RI-RSVP capability, then the router should reduce the refresh interval to 30 seconds if the refresh interval has not been configured on the router. We will update this section accordingly to clarify the proposed behavior.

Regards,
Chandra.

---

From: Guijuan Wang 3 <[email-masked]>
Date: Fri, 4 Dec 2015 02:48:50 +0000

Hi Chandra,

Glad to get your response, all of my comments are addressed, thanks!

Regards 
Jean

-----Original Message-----
From: Chandrasekar Ramachandran [mailto:[email-masked]] 
Sent: Sunday, November 29, 2015 9:19 PM
To: Guijuan Wang 3; [email-masked]; [email-masked]
Cc: [email-masked]; Loa Andersson
Subject: RE: MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr

Hello Jean,
Thanks for your comments. Please find the responses inline.

> From: Guijuan Wang 3 [mailto:[email-masked]]
> Sent: Thursday, November 05, 2015 9:00 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Loa Andersson <[email-masked]>
> Dear Authors,
> Thanks for drafting this solution, It would be useful if the FRR can 
> be completely independent of refresh.
> I read through it and here is my comment.
> 
> 
> Section 3, page 6, Problem Description:
> Per RFC 4090, section 7.2 section Handling Failures, it has required 
> the postpone of sending PathClear, wait another 30s by default. Then 
> the possibility for the first consequence should be lower than the 
> following consequence, better to move it back based on the logic that 
> the major issue comes first.

[Chandra] Yes, we will clarify that the references to "router C timing out LSP states" in Section 3 to indicate that as per RFC 4090 the state time out on C would occur after an additional time out cycle.
 
> Section 4, page 7, Solution Aspects:
>   Read through the whole solution, it requires the supporting of 
> serval other RFCs and also two working-in-progresses RFCs. Better to 
> add “Pre- Requisites” introduction in the beginning of this chapter, 
> then the user for this document know it has to read/implement the prerequisite firstly.
> At the other hand, the major change in the cited [Summary-FRR] and 
> [TE- SCALE-REC] may be monitored and brought back to this document. 
> For example a comment has been raised for the new sub-object 
> definition in [Summary-FRR], it may be changed.

[Chandra] Yes, we will introduce a new section or sub-section to clarify the pre-requisites. It is true that the bypass association procedure in Summary-FRR draft will be re-specified to use Association object. As the update to that draft has not yet been uploaded, we have not yet modified our draft.

> Section 4.1.1, page 9, PLR Behavior
> Is below paragraph parallel to its former and following paragraphs? If 
> so, please change its format style, that is adding “-“ in the 
> beginning and use same indentations as others. Current style makes me 
> feel it’s the parent of the following 2 paragraphs.
> In this doc, it says:
> “In parallel to the attempt made to create NP-bypass or LP-bypass, the 
> PLR SHOULD initiate ...”

[Chandra] Yes, we will indent the paragraphs "While selecting the destination address ..." because that paragraph is a specific recommendation for selecting destination address.

> Section 4.1.2, page 9, Remote Signaling Adjacency:
> A new hello is introduced, via multiple hops. Better to give the 
> suggested default interval, the hello interval in RFC3209 is 5 ms, it 
> may be too quick for this solution.

[Chandra] Yes, you are correct that the default hello interval specified in RFC 3209 is not suitable for NodeID hello session. The TE-SCALE-REC draft (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-00) makes the recommendation of 9 seconds for the hello interval. However, we will also explicitly state in Section 4.1.2 of our draft to follow the recommendation of TE-SCALE-REC draft. 

> 4.1.5. page 11, "Remote" state on MP
> Typo, change form to “from” for below sentence.
> “the "remote"path state is not signaled explicitly form PLR.”

[Chandra] Yes, will correct the typo in the next revision.

> Section 4.1.1, page 9, first paragraph:
> No full words for TED the first time it is mentioned, would you please add it.
> And would be great if you can give a brief introduction on using the 
> TED to determine routeId.
> “If the PLR and the MP are in same area, then the PLR may Utilize the 
> TED to determine the router ID from the interface address in RRO (if 
> NodeID is not included in RRO).”

[Chandra] Yes, we will provide some additional text in Section 4.1.1 for this. We will also include TED in Terminology section.

> Section 4.1.1: page 9, paragraph 4:
> Whose timeout do you mean by “a timeout” in below paragraph? Also may 
> be better to move the “on the other hand… “ to the paragraph above it. 
> At first glance, the sentence before and after “on the other hand” 
> seems like duplicated.
> In this document, it says:
> "The PLR SHOULD wait for a time out before removing 
> SUMMARY_FRR_BYPASS_ASSIGNMENT sub-object in RRO and triggering PATH 
> downstream. On the other hand, the PLR need not wait for a time out to 
> add SUMMARY_FRR_BYPASS_ASSIGNMENT subobject in RRO and may immediately 
> trigger PATH downstream."

[Chandra] Actually, the time out indicated here is not related to state time out. But I agree that this paragraph is a bit confusing. As the procedures are expected to be specified in SUMMARY-FRR draft, we will remove the last paragraph (the one starting with "After signaling protection availability ...") and combine the previous two paragraphs. That is, we will merge the two paragraphs "In parallel to the attempt made ..." and "If the bypass LSP comes up, then the PLR should include ...".

> 4.2. page 11, Impact of Failures on LSP State:
> In the last paragraph, it says implementation doesn’t need to have a 
> way to distinguish “link-failure” and “node-failure”, but the 
> following statement for handling does distinguish the “link-failure” 
> and “node-failure”, such as LP-MP has different procedures for link 
> and node Failure defined in 4.2.2 and 4.2.3 separately. Is it conflicting?

[Chandra] Thanks for pointing out the conflict. The TE-SCALE-REC draft does recommend the use of NodeID based hello session and hence the paragraph "It should be noted that even though this section and the subsequent ..." is in conflict with that recommendation. We will remove this paragraph.

> Also in the optional way of using node-id based hello to distinguish 
> them, better to give further details on how to distinguish.

[Chandra] Please refer to my response to your previous comment. We will remove the paragraph and possibly refer to TE-SCALE-REC to clarify regarding failure detection. 

> 4.2. page 11~14, Impact of Failures on LSP State Overall, in this 
> section, several conditions are mentioned and different handling need 
> to be taken based on different conditions combinations, and 7 handling 
> cases are introduced. Is it possible to category them, or simply the 
> combinations based on below 3 considerations?
> a.	Distinguishing and understanding 7 cases is a little complex for
> implementation.
> b.	There may be conditions combination that is not enumerated in this
> document.
> c.	Some case handling are very similar such as section 4.2.2 and 4.2.4.

[Chandra] We will classify the 7 sub-sections into 3 categories - LP-MP behavior, NP-MP behavior and Router that is simultaneously LP-MP and NP-MP. Each category will contain the procedures to handle different types of failures, so that it would be clear that all possible combinations are enumerated. The behavior of non-MP should be obvious and does not require the explicit specification.

> 4.5.1, page 19, Detecting Support for Refresh interval Independent FRR 
> Seems the detection mainly counts on the detection procedure for [TE- 
> SCALE-REC] and [SUMMARY-FRR], but this document introduces extra 
> extensions, such as multiple-hop hello, and condition object, there 
> should also a new way to detect the support for them.

[Chandra] Section 2.2 of TE-SCALE-REC contains the following recommendation.

    - (If Bypass FRR [RFC4090] is supported,) MUST implement procedures
      specified in [RI-RSVP-FRR] which describes methods to facilitate
      FRR that works independently of the refresh-interval.

Hence the definition of I-bit in Section 2.2.1 of TE-SCALE-REC should include the support for the procedures in RI-RSVP-FRR draft. It should be noted that TE-SCALE-REC has specified a separate flag F-bit to enable implementations to support per-peer flow control without supporting Refresh-independent RSVP.

We will explicitly add the above clarification in Section 4.5.1.

Thanks,
Chandra.

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Fri, 18 Dec 2015 05:40:41 +0000

Mustapha,
Did my response address your concerns? If I have understood you correctly, the concerns fall in two categories and I have tried to address these concerns.
(A) The need for introducing refresh-interval independent behavior into RSVP-TE
(B) Why some kind of local implementation based timers will not be sufficient to support long refresh intervals

Do you have any specific comment on my responses? Specifically, do you still think the responses did not address (A), or (B) or both?

Regards,
Chandra.

> From: mpls [mailto:[email-masked]] On Behalf Of Chandrasekar
> Ramachandran
> Sent: Thursday, December 03, 2015 12:58 AM
> To: Aissaoui, Mustapha (Mustapha) <[email-masked]>;
> Sriganesh Kini <[email-masked]>; Loa Andersson <[email-masked]>;
> Lucy yong <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-chandra-mpls-ri-rsvp-
> [email-masked]; Guijuan Wang 3 <[email-masked]>; Lizhong Jin
> <[email-masked]>
> Subject: Re: [mpls] MPLS-RT review of draft-chandra-mpls-ri-rsvp-frr
> 
> Mustapha,
> 
> [Chandra] The primary motivation of the draft is to enable LSRs to support FRR
> when the LSP scale on the LSR is of the order of hundreds of thousands. The
> analysis of the bottlenecks as a consequence of LSP scale, that can cause
> disruption of the LSR has already been documented in RFC 5439. As analyzed in
> RFC 5439, while there is a correlation between the percentage increase in
> refresh time and the improvement in LSR performance, there is a degree of
> functionality that is lost owing to the soft-state nature of the protocol. TE-
> SCALE-REC (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-00)
> outlines the motivation for refresh independent RSVP (RI-RSVP) for all types of
> LSPs (packet or non-packet), and makes recommendations to enable RSVP
> implementations eliminate the reliance on short refresh time. This draft
> addresses the refresh-interval dependent behavior of RFC 4090 in order to
> support RI-RSVP, as facility backup FRR is a widely deployed feature in
> production networ
>  ks.
> 
> [Chandra] The tradeoffs between using short or long refresh intervals has been
> well understood. Short refresh intervals aid fast synchronization of states along
> the path of the LSP, but is problematic because of the control message traffic
> that a router has to handle at high LSP scale. Routers not only must synchronize
> new states as promptly as possible, but also must maintain the rate of periodic
> Srefresh messages to a level sufficient to refresh all existing states without being
> timed out. When the number of LSPs that routers carry approach half a million,
> there will be two problems with the control message rate.
> (1) As analyzed in RFC 5439, even with RFC 2961 refresh reduction the size of
> Srefresh message may become very large, and the processing required may
> cause disruption of the LSR.
> (2) Apart from the problem of RSVP message processing overhead, there is also
> the problem of RSVP-TE becoming a bottleneck preventing the router to scale
> other protocols or services.
> 
> [Chandra] Some of the mechanisms already deployed in multi-vendor production
> networks involve configuring implementation specific timers or delays on LSRs.
> Multiple vendors support various timers or delays on Ingress and Transit LSRs.
> However, in practice the values configured for these timers or delays are very
> scale specific, and the values that work at one LSP scale usually do not work at
> higher LSP scale. In practice, the "scale" that impacts the behavior at specific
> timer or delay value is not only the number of LSPs carried on the router, but
> also the number of other protocol states that reside on the router. It should be
> noted that the reliance on such implementation specific timers or delays has
> been a major contributor of operational complexity in running RSVP-TE FRR. Any
> solution based on such timers or delays while being operationally simple at one
> scale ceases to be so at higher scale. It has been practically found (with existing
> implementations from multiple vendors) tha
>  t it is operationally hard to find out the new better value as a running
> production network grows over time. In short, the use of such timers or delays
> has been found to involve guess work that seldom remain simple in the long run.
> 
> > Regards,
> > Mustapha.
> > ---------------------
> [Chandra] The option of resetting the refresh timeout may not be viable if long
> refresh interval (of the order of tens of minutes) is applied on the LSPs. That
> leaves the other option of providing a "wait timer" (independent of refresh time)
> that is configurable on the MP. However, it is fairly clear that the "wait timer"
> that the operator should configure on MP will be problematic for two reasons.
> The operator should carefully analyze the performance impact of an existing
> timer/delay value if and when (a) the LSP scale on the same router increases,
> and (2) the LSP scale increases on other routers around it (that may potentially
> become upstream PLRs)!
> 
> [Chandra] As described in the first response in this mail, the motivation driving
> the draft is to eliminate RSVP-TE's reliance of short refresh intervals. If router C
> were to retain the LSP state until time out, without any additional procedures
> that provide an explicit indication to router C on when the LSP state is no longer
> required, then router C would retain the LSP state potentially for hours if the
> refresh interval is long. So, router C will not only store the state of the LSP but
> also periodically send the Path message (in Srefresh) downstream - thereby
> unnecessarily consuming resources that could potentially be utilized for other
> LSPs.
> 
> It should also be noted that the transit router cannot assume that Ingress LSR
> will be able to complete global repair within a particular time frame. The transit
> LSR procedures should be able to handle cases when global repair does not
> complete for some valid reason for an extended period of time.
> 
> [Chandra] The problem described is different. Router B detects the failure and
> undertakes local actions for re-routing traffic for all protected LSPs traversing
> the failed link. In parallel, router B also initiates backup LSP signaling for all
> those protected LSPs. At scale (i.e. if the number of protected LSPs thus
> undergoing repair is of the order of hundreds of thousands), the initiation of
> backup LSP signaling for all those protected LSPs is not expected to happen
> within short time period. If the Ingress LSR initiates LSP tear down during this
> interim time duration, the existing procedures do not offer any mechanism for
> router B to indicate to MP that it need not hold on to that state any longer. The
> new procedure described in the document does not introduce any major
> extension but simply use PathTear message from PLR to MP even though the
> PLR had not reliably refreshed backup LSP Path.
> 
> Here again, one may suggest the use of some "wait timer" on MP independent
> of refresh time out - say if the MP does not receive backup LSP Path message
> within the "wait timer", the MP can delete the LSP state. But depending on a
> timer or delay suffers from the same drawbacks pointed out in the response to
> comment #1.
> 
> [Chandra] The problem is not about the activation of bypass LSP but that there is
> no indication to the MP router that it does not have to hold on to the LSP state
> any more. The problem has been explained in the response to comment #3 and
> #4. On the soft-state behavior, the responses to the first three paragraphs to
> your mail contain the reasoning for removing the limitations of soft-state nature
> of the protocol.
> 
> [Chandra] If refresh time is not explicitly configured on the LSR supporting RI-
> RSVP-FRR, then the refresh interval should be reduced to RFC 2205 default value
> of 30 seconds for messages sent to a neighboring router that is not RI-RSVP
> capable. TE-SCALE-REC draft recommends default refresh interval of 20 minutes
> be used in Path and Resv messages if RI-RSVP is supported by the LSR. The
> statement in the draft referred here is not applicable if the operator has
> overridden the RI-RSVP default value.
> 
> I think the text in Section 4.5.2 could have state explicitly that if downstream or
> upstream neighbor does not advertise RI-RSVP capability, then the router should
> reduce the refresh interval to 30 seconds if the refresh interval has not been
> configured on the router. We will update this section accordingly to clarify the
> proposed behavior.
> 
> Regards,
> Chandra.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls