[j-nsp] RSVP-TE broken between pre and post 16.1 code?

[Andrey Kostin]

Could it be:
Number 	PR1443811
Title 	RSVP refresh-timer interoperability between 15.1 and 16.1+
Release Note

Path message with long refresh interval (equal to or more than 20 
minutes) from a node that does not support Refresh-interval Independent 
RSVP (RI-RSVP) is dropped by the receiver with RI-RSVP.

Severity 	Minor
Status 	Open
Last Modified 	2019-07-26 08:51:18 EDT
Resolved In
Release 	junos
18.3R3 	x
18.4R3 	x
17.4R3 	x
19.2R2 	x
19.3R1 	x
19.1R2 	x
Product 	J Series, M Series, T Series, MX-series, EX Series, SRX Series, 
QFX Series, NFX Series, PTX Series
Functional Area 	software
Feature Group 	Multiprotocol Label Switching (MPLS)
Workaround

1. Use default rsvp refresh-time config. No config is needed.
30 seconds in 15.1 and 20 minutes in 16.1+

2. If you must configure rsvp refresh-time, configure it to be less than 
20 minutes.
set protocols rsvp refresh-time 1199

Problem

Starting with Junos OS Release 16.1, RSVP Traffic Engineering (TE) 
protocol extensions to support Refresh-interval Independent RSVP 
(RI-RSVP) defined RFC 8370 for fast reroute (FRR) facility protection 
were introduced to allow greater scalability of label-switched paths 
(LSPs) faster convergence times and decrease RSVP signaling message 
overhead from periodic refreshes. RI-RSVP mode is enabled by default and 
includes protocol extensions to support RI-RSVP for FRR facility bypass 
originally specified in RFC 4090. The default refresh time for RSVP 
messages has increased from 30 seconds to 20 minutes.
In mixed environments, where a subset of LSPs traverse nodes that do not 
include this feature, Junos RSVP-TE running in enhanced FRR mode will 
automatically turn off the new protocol extensions in its signaling 
exchanges with nodes that do not support the new extensions. However, 
path messages with long refresh interval (equal to or more than 20 
minutes) from such nodes will be dropped by the receiver with RI-RSVP. 
It is assumed that non-RI-RSVP nodes should have lower refresh time 
because it is used for failure detection in non-RI-RSVP environments.

With this fix, configuring 'no-enhanced-frr-bypass' on 16.1+ nodes will 
solve the silent path message drop and will allow 20 minutes and higher 
refresh times to be used on non-RI-RSVP nodes.

Triggers

- 'protocols rsvp refresh-time 1200' or higher is used on a non-RI-RSVP 
node (Junos <16.1).
- There is a RI-RSVP (16.1 or later) node after non-RI-RSVP node.

Kind regards,
Andrey Kostin

adamv0025 at netconsultings.com писал 2019-08-16 06:01:
>> From: Nathan Ward <nward at daork.net>
>> Sent: Friday, August 16, 2019 8:39 AM
>> 
>> > On 1/07/2019, at 9:59 PM, adamv0025 at netconsultings.com wrote:
>> >
>> >> From: Michael Hare <michael.hare at wisc.edu>
>> >> Sent: Friday, June 28, 2019 7:02 PM
>> >>
>> >> Adam-
>> >>
>> >> Have you accounted for this behavioral change?
>> >>
>> >>
>> https://kb.juniper.net/InfoCenter/index?page=content&id=KB32883&pmv=
>> >> print&actp=LIST&searchid=&type=currentpaging
>> >>
>> > Thank you, yes please we're aware of that, but even with this the
>> > issue is still present if the refresh timer is not <1200 or CSPF is enabled.
>> 
>> I’m confused by this one - what’s the refresh timer and CSPF got to do 
>> with
>> it?
>> 
> Not much it's a bug, it appears form the logs that the path message
> has "something different" in the ERO when CSPF is enabled triggering
> the bug ...
> 
>> LSPs on 16.1 will do self-ping after they come up before they put 
>> traffic on
>> them. The lo0 filter has to permit that, or you’ve got to disable 
>> self-ping.
>> 
> LSPs will do self ping when switching onto a new/optimized path, not
> when the LSP is first brought up -which in this case doesn’t happen.
> 
>> Or am I parsing this weird, and you’re saying this is still an issue 
>> even with the
>> self ping disabled (or permitted in filters), under those conditions?
>> 
> Yes that is correct, this problem appears even before the self-ping is
> engaged (the LSP is not even signalled -the RESV msg is never sent as
> a response to PATH msg in this case).
> 
> adam
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp