draft-ietf-mpls-ri-rsvp-frr-01.txt   draft-ietf-mpls-ri-rsvp-frr-02.txt 
Network Working Group Chandra Ramachandran Network Working Group Chandra Ramachandran
Internet Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Standards Track Ina Minei Intended status: Standards Track Ina Minei
Google, Inc Google, Inc
Dante Pacella Dante Pacella
Verizon Verizon
Tarek Saad Tarek Saad
Cisco Systems Inc. Cisco Systems Inc.
Expires: August 12, 2017 February 12, 2017 Expires: February 11, 2018 August 11, 2017
Refresh Interval Independent FRR Facility Protection Refresh Interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-01 draft-ietf-mpls-ri-rsvp-frr-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
and maintain the LSP related states along the reserved path. In the and maintain the LSP related states along the reserved path. In the
absence of refresh messages, the LSP related states are absence of refresh messages, the LSP related states are
automatically deleted. Reliance on periodic refreshes and refresh automatically deleted. Reliance on periodic refreshes and refresh
timeouts are problematic from the scalability point of view. The timeouts are problematic from the scalability point of view. The
number of RSVP-TE LSPs that a router needs to maintain has been number of RSVP-TE LSPs that a router needs to maintain has been
growing in service provider networks and the implementations should growing in service provider networks and the implementations should
be capable of handling increase in LSP scale. be capable of handling increase in LSP scale.
RFC 2961 specifies mechanisms to eliminate the reliance on periodic RFC 2961 specifies mechanisms to eliminate the reliance on periodic
refresh and refresh timeout of RSVP messages, and enables a router refresh and refresh timeout of RSVP messages, and enables a router
to increase the message refresh interval to values much larger than to increase the message refresh interval to values much longer than
the default 30 seconds defined in RFC 2205. However, the protocol the default 30 seconds defined in RFC 2205. However, the protocol
extensions defined in RFC 4090 for supporting fast reroute (FRR) extensions defined in RFC 4090 for supporting fast reroute (FRR)
using bypass tunnels implicitly rely on short refresh timeouts to using bypass tunnels implicitly rely on short refresh timeouts to
cleanup stale states. cleanup stale states.
In order to eliminate the reliance on refresh timeouts, the routers In order to eliminate the reliance on refresh timeouts, the routers
should unambiguously determine when a particular LSP state should be should unambiguously determine when a particular LSP state should be
deleted. Coupling LSP state with the corresponding RSVP-TE signaling deleted. Coupling LSP state with the corresponding RSVP-TE signaling
adjacencies as recommended in RSVP-TE Scaling Recommendations adjacencies as recommended in RSVP-TE Scaling Recommendations
(draft-ietf-teas-rsvp-te-scaling-rec) will apply in scenarios other (draft-ietf-teas-rsvp-te-scaling-rec) will apply in scenarios other
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
1.1. Motivation................................................5
2. Terminology....................................................6
3. Problem Description............................................6
4. Solution Aspects...............................................8
4.1. Signaling Handshake between PLR and MP....................9
4.1.1. PLR Behavior.........................................9
4.1.2. Remote Signaling Adjacency..........................11
4.1.3. MP Behavior.........................................11
4.1.4. "Remote" state on MP................................11
4.2. Impact of Failures on LSP State..........................12
4.2.1. Non-MP Behavior.....................................13
4.2.2. LP-MP Behavior......................................13
4.2.3. NP-MP Behavior......................................13
4.2.4. Behavior of a Router that is both LP-MP and NP-MP...14
4.3. Conditional Path Tear....................................15
4.3.1. Sending Conditional Path Tear.......................15
4.3.2. Processing Conditional Path Tear....................15
4.3.3. CONDITIONS object...................................16
4.4. Remote State Teardown....................................17
4.4.1. PLR Behavior on Local Repair Failure................17
4.4.2. PLR Behavior on Resv RRO Change.....................18
4.4.3. LSP Preemption during Local Repair..................18
4.4.3.1. Preemption on LP-MP after Phop Link failure....18
4.4.3.2. Preemption on NP-MP after Phop Link failure....19
4.5. Backward Compatibility Procedures........................19
4.5.1. Detecting Support for Refresh interval Independent FRR
...........................................................20
4.5.2. Procedures for backward compatibility...............20
4.5.2.1. Lack of support on Downstream Node.............20
4.5.2.2. Lack of support on Upstream Node...............21
4.5.2.3. Incremental Deployment.........................21
5. Security Considerations.......................................22
6. IANA Considerations...........................................23
6.1. New Object - CONDITIONS..................................23
7. Normative References..........................................23
8. Informative References........................................24
9. Acknowledgments...............................................24
10. Contributors.................................................24
11. Authors' Addresses...........................................25
1. Introduction...................................................4
1.1. Motivation................................................4 1.1. Motivation................................................4
2. Terminology....................................................5 2. Terminology....................................................5
3. Problem Description............................................5 3. Problem Description............................................5
4. Solution Aspects...............................................8 4. Solution Aspects...............................................8
4.1. Signaling Handshake between PLR and MP....................8 4.1. Signaling Handshake between PLR and MP....................8
4.1.1. PLR Behavior.........................................8 4.1.1. PLR Behavior.........................................8
4.1.2. Remote Signaling Adjacency..........................10 4.1.2. Remote Signaling Adjacency..........................10
4.1.3. MP Behavior.........................................10 4.1.3. MP Behavior.........................................10
4.1.4. "Remote" state on MP................................11 4.1.4. "Remote" state on MP................................11
4.2. Impact of Failures on LSP State..........................11 4.2. Impact of Failures on LSP State..........................12
4.2.1. Non-MP Behavior.....................................12 4.2.1. Non-MP Behavior.....................................12
4.2.2. LP-MP Behavior......................................12 4.2.2. LP-MP Behavior......................................12
4.2.3. NP-MP Behavior......................................12 4.2.3. NP-MP Behavior......................................12
4.2.4. Behavior of a Router that is both LP-MP and NP-MP...13 4.2.4. Behavior of a Router that is both LP-MP and NP-MP...14
4.3. Conditional Path Tear....................................14 4.3. Conditional Path Tear....................................14
4.3.1. Sending Conditional Path Tear.......................14 4.3.1. Sending Conditional Path Tear.......................15
4.3.2. Processing Conditional Path Tear....................15 4.3.2. Processing Conditional Path Tear....................15
4.3.3. CONDITIONS object...................................15 4.3.3. CONDITIONS object...................................15
4.4. Remote State Teardown....................................16 4.4. Remote State Teardown....................................16
4.4.1. PLR Behavior on Local Repair Failure................17 4.4.1. PLR Behavior on Local Repair Failure................17
4.4.2. PLR Behavior on Resv RRO Change.....................17 4.4.2. PLR Behavior on Resv RRO Change.....................17
4.4.3. LSP Preemption during Local Repair..................17 4.4.3. LSP Preemption during Local Repair..................18
4.4.3.1. Preemption on LP-MP after Phop Link failure....18 4.4.3.1. Preemption on LP-MP after Phop Link failure....18
4.4.3.2. Preemption on NP-MP after Phop Link failure....18 4.4.3.2. Preemption on NP-MP after Phop Link failure....18
4.5. Backward Compatibility Procedures........................18 4.5. Backward Compatibility Procedures........................19
4.5.1. Detecting Support for Refresh interval Independent FRR 4.5.1. Detecting Support for Refresh interval Independent FRR
...........................................................19 ...........................................................19
4.5.2. Procedures for backward compatibility...............19 4.5.2. Procedures for backward compatibility...............20
4.5.2.1. Lack of support on Downstream Node.............20 4.5.2.1. Lack of support on Downstream Node.............20
4.5.2.2. Lack of support on Upstream Node...............20 4.5.2.2. Lack of support on Upstream Node...............20
4.5.2.3. Incremental Deployment.........................21 4.5.2.3. Incremental Deployment.........................21
5. Security Considerations.......................................21 5. Security Considerations.......................................22
6. IANA Considerations...........................................22 6. IANA Considerations...........................................22
6.1. New Object - CONDITIONS..................................22 6.1. New Object - CONDITIONS..................................22
7. Normative References..........................................22 7. Normative References..........................................22
8. Informative References........................................23 8. Informative References........................................23
9. Acknowledgments...............................................23 9. Acknowledgments...............................................23
10. Contributors.................................................23 10. Contributors.................................................24
11. Authors' Addresses...........................................24 11. Authors' Addresses...........................................24
1. Introduction 1. Introduction
RSVP-TE Fast Reroute [RFC4090] defines two local repair techniques RSVP-TE Fast Reroute [RFC4090] defines two local repair techniques
to reroute label switched path (LSP) traffic over pre-established to reroute label switched path (LSP) traffic over pre-established
backup tunnel. Facility backup method allows one or more LSPs backup tunnel. Facility backup method allows one or more LSPs
traversing a connected link or node to be protected using a bypass traversing a connected link or node to be protected using a bypass
tunnel. The many-to-one nature of local repair technique is tunnel. The many-to-one nature of local repair technique is
attractive from scalability point of view. This document enumerates attractive from scalability point of view. This document enumerates
skipping to change at page 5, line 32 skipping to change at page 4, line 42
after a tear message is lost. For more on these problems see after a tear message is lost. For more on these problems see
Section 1 of RSVP Refresh Overhead Reduction Extensions Section 1 of RSVP Refresh Overhead Reduction Extensions
[RFC2961]. [RFC2961].
The problems listed above adversely affect RSVP control plane The problems listed above adversely affect RSVP control plane
scalability and RSVP-TE [RFC3209] inherited these problems from scalability and RSVP-TE [RFC3209] inherited these problems from
standard RSVP. Procedures specified in [RFC2961] address the above standard RSVP. Procedures specified in [RFC2961] address the above
mentioned problems by eliminating dependency on refreshes for state mentioned problems by eliminating dependency on refreshes for state
synchronization and for recovering from lost RSVP messages, and by synchronization and for recovering from lost RSVP messages, and by
eliminating dependency on refresh timeout for stale state cleanup. eliminating dependency on refresh timeout for stale state cleanup.
Implementing these procedures allows to improve RSVP-TE control Implementing these procedures allows implementations to improve
plane scalability. For more details on eliminating dependency on RSVP-TE control plane scalability. For more details on eliminating
refresh timeout for stale state cleanup, refer to "Refresh Interval dependency on refresh timeout for stale state cleanup, refer to
Independent RSVP" section in [TE-SCALE-REC]. "Refresh Interval Independent RSVP" section in [TE-SCALE-REC].
However, the procedures specified in [RFC2961] do not fully address However, the procedures specified in [RFC2961] do not fully address
stale state cleanup for facility backup protection [RFC4090], as stale state cleanup for facility backup protection [RFC4090], as
facility backup protection still depends on refresh timeouts for facility backup protection still depends on refresh timeouts for
stale state cleanup. Thus [RFC2961] is insufficient to address the stale state cleanup. Thus [RFC2961] is insufficient to address the
problem of stale state cleanup when facility backup protection is problem of stale state cleanup when facility backup protection is
used. used.
The procedures specified in this document, in combination with The procedures specified in this document, in combination with
[RFC2961], eliminate facility backup protection dependency on [RFC2961], eliminate facility backup protection dependency on
skipping to change at page 6, line 26 skipping to change at page 5, line 35
PPhop node: Previous-Previous-hop router along the LSP PPhop node: Previous-Previous-hop router along the LSP
LP-MP node: Merge Point router at the tail of Link-protecting bypass LP-MP node: Merge Point router at the tail of Link-protecting bypass
tunnel tunnel
NP-MP node: Merger Point router at the tail of Node-protecting NP-MP node: Merger Point router at the tail of Node-protecting
bypass tunnel bypass tunnel
TED: Traffic Engineering Database TED: Traffic Engineering Database
LSP state: The combination of "path state" maintained as Path State
Block (PSB) and "reservation state" maintained as Reservation State
Block (RSB) forms an individual LSP state on an RSVP-TE speaker
Conditional PathTear: PathTear message containing a suggestion to a Conditional PathTear: PathTear message containing a suggestion to a
receiving downstream router to retain Path state if the receiving receiving downstream router to retain Path state if the receiving
router is NP-MP router is NP-MP
Remote PathTear: PathTear message sent from Point of Local Repair Remote PathTear: PathTear message sent from Point of Local Repair
(PLR) to MP to delete state on MP if PLR had not reliably sent (PLR) to MP to delete LSP state on MP if PLR had not reliably sent
backup Path state before backup Path state before
3. Problem Description 3. Problem Description
E E
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
A ----- B ----- C ----- D A ----- B ----- C ----- D
\ / \ /
\ / \ /
skipping to change at page 7, line 14 skipping to change at page 6, line 23
\ / \ /
\ / \ /
\ / \ /
\ / \ /
\ / \ /
F F
Figure 1: Example Topology Figure 1: Example Topology
In the topology in Figure 1, consider a large number of LSPs from A In the topology in Figure 1, consider a large number of LSPs from A
to D transiting B and C. Assume that refresh interval has been to D transiting B and C. Assume that refresh interval has been
configured to be large of the order of minutes and refresh reduction configured to be long of the order of minutes and refresh reduction
extensions are enabled on all routers. extensions are enabled on all routers.
Also assume that node protection has been configured for the LSPs Also assume that node protection has been configured for the LSPs
and the LSPs are protected by each router in the following way and the LSPs are protected by each router in the following way
- A has made node protection available using bypass LSP A -> E -> - A has made node protection available using bypass LSP A -> E ->
C; A is the Point of Local Repair (PLR) and C is Node Protecting C; A is the Point of Local Repair (PLR) and C is Node Protecting
Merge Point (NP-MP) Merge Point (NP-MP)
- B has made node protection available using bypass LSP B -> F -> - B has made node protection available using bypass LSP B -> F ->
skipping to change at page 8, line 45 skipping to change at page 8, line 14
The purpose of this document is to provide solutions to the above The purpose of this document is to provide solutions to the above
problems which will then make it practical to scale up to a large problems which will then make it practical to scale up to a large
number of protected LSPs in the network. number of protected LSPs in the network.
4. Solution Aspects 4. Solution Aspects
The solution consists of five parts. The solution consists of five parts.
- Utilize MP determination mechanism specified in [SUMMARY-FRR] - Utilize MP determination mechanism specified in [SUMMARY-FRR]
that enables the PLR to signal availability of local protection to that enables the PLR to signal the availability of local
MP. In addition, introduce PLR and MP procedures to establish protection to the MP. In addition, introduce PLR and MP procedures
Node-ID hello session between the PLR and the MP to detect router to establish Node-ID based hello session between the PLR and the
failures and to determine capability. See section 4.1 for more MP to detect router failures and to determine capability. See
details. This part of the solution re-uses some of the extensions section 4.1 for more details. This part of the solution re-uses
defined in [SUMMARY-FRR] and [TE-SCALE-REC], and the subsequent some of the extensions defined in [SUMMARY-FRR] and [TE-SCALE-
sub-sections will list the extensions in these drafts that are REC], and the subsequent sub-sections will list the extensions in
utilized in this document. these drafts that are utilized in this document.
- Handle upstream link or node failures by cleaning up LSP states - Handle upstream link or node failures by cleaning up LSP states
if the node has not found itself as MP through the MP if the node has not found itself as MP through the MP
determination mechanism. See section 4.2 for more details. determination mechanism. See section 4.2 for more details.
The combination of "path state" maintained as Path State Block
(PSB) and "reservation state" maintained as Reservation State
Block (RSB) forms an individual LSP state on an RSVP-TE speaker.
- Introduce extensions to enable a router to send tear down message - Introduce extensions to enable a router to send tear down message
to downstream router that enables the receiving router to to the downstream router that enables the receiving router to
conditionally delete its local state. See section 4.3 for more conditionally delete its local LSP state. See section 4.3 for more
details. details.
- Enhance facility protection by allowing a PLR to directly send - Enhance facility protection by allowing a PLR to directly send
tear down message to MP without requiring the PLR to either have a tear down message to MP without requiring the PLR to either have a
working bypass LSP or have already signaled backup LSP state. See working bypass LSP or have already signaled backup LSP state. See
section 4.4 for more details. section 4.4 for more details.
- Introduce extensions to enable the above procedures to be - Introduce extensions to enable the above procedures to be
backward compatible with routers along the LSP path running backward compatible with routers along the LSP path running
implementation that do not support these procedures. See section implementation that do not support these procedures. See section
skipping to change at page 9, line 44 skipping to change at page 9, line 8
4.1.1. PLR Behavior 4.1.1. PLR Behavior
As per the procedures specified in RFC 4090, when a protected LSP As per the procedures specified in RFC 4090, when a protected LSP
comes up and if the "local protection desired" flag is set in the comes up and if the "local protection desired" flag is set in the
SESSION_ATTRIBUTE object, each node along the LSP path attempts to SESSION_ATTRIBUTE object, each node along the LSP path attempts to
make local protection available for the LSP. make local protection available for the LSP.
- If the "node protection desired" flag is set, then the node - If the "node protection desired" flag is set, then the node
tries to become a PLR by attempting to create a NP-bypass LSP to tries to become a PLR by attempting to create a NP-bypass LSP to
the NNhop node avoiding the Nhop node on protected LSP path. In the NNhop node avoiding the Nhop node on protected LSP path. In
case node protection could not be made available after some time case node protection could not be made available, the node
out, the node attempts to create a LP-bypass LSP to Nhop node attempts to create a LP-bypass LSP to Nhop node avoiding only the
avoiding only the link that protected LSP takes to reach Nhop link that protected LSP takes to reach Nhop
- If the "node protection desired" flag is not set, then the PLR - If the "node protection desired" flag is not set, then the PLR
attempts to create a LP-bypass LSP to Nhop node avoiding the link attempts to create a LP-bypass LSP to Nhop node avoiding the link
that the protected LSP takes to reach Nhop that the protected LSP takes to reach Nhop
With regard to the PLR procedures described above and that are With regard to the PLR procedures described above and that are
specified in RFC 4090, this document specifies the following specified in RFC 4090, this document specifies the following
additional procedures. additional procedures.
- While selecting the destination address of the bypass LSP, the - While selecting the destination address of the bypass LSP, the
PLR SHOULD attempt to select the router ID of the NNhop or Nhop PLR SHOULD attempt to select the router ID of the NNhop or Nhop
node. If the PLR and the MP are in same area, then the PLR may node. 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 utilize the TED to determine the router ID from the interface
address in RRO (if NodeID is not included in RRO). If the PLR and address in RRO (if NodeID is not included in RRO). If the PLR and
the MP are in different IGP areas, then the PLR SHOULD use the the MP are in different IGP areas, then the PLR SHOULD use the
NodeID address of NNhop MP if included in the RRO of RESV. If the NodeID address of NNhop MP if included in the RRO of RESV. If the
NP-MP in a different area has not included NodeID in RRO, then the NP-MP in a different area has not included NodeID in RRO, then the
PLR SHOULD use NP-MP's interface address present in the RRO. The PLR SHOULD use NP-MP's interface address present in the RRO. The
PLR SHOULD use its router ID as the source address of the bypass PLR SHOULD use its router ID as the source address of the bypass
LSP. The PLR SHOULD also include its router ID in a NodeID sub- LSP.
object in PATH RRO unless configured explicitly not to include
NodeID. While including its router ID in NodeID sub-object, the - The PLR SHOULD also include its router ID in a NodeID sub-object
PLR SHOULD include the NodeID sub-object after including its in PATH RRO unless configured explicitly not to include NodeID.
IPv4/IPv6 address or unnumbered interface ID sub-object. While including its router ID in the NodeID sub-object carried in
the outgoing Path message, the PLR MUST include the NodeID sub-
object after including its IPv4/IPv6 address or unnumbered
interface ID sub-object.
- In parallel to the attempt made to create NP-bypass or LP-bypass, - In parallel to the attempt made to create NP-bypass or LP-bypass,
the PLR SHOULD initiate a Node-ID based Hello session to the NNhop the PLR SHOULD initiate a Node-ID based Hello session to the NNhop
or Nhop node respectively to establish the RSVP-TE signaling or Nhop node respectively to establish the RSVP-TE signaling
adjacency. This Hello session is used to detect MP node failure as adjacency. This Hello session is used to detect MP node failure as
well as determine the capability of the MP node. If the MP sets I- well as determine the capability of the MP node. If the MP sets I-
bit in CAPABILITY object [TE-SCALE-REC] carried in Hello message bit in CAPABILITY object [TE-SCALE-REC] carried in Hello message
corresponding to NodeID based Hello session, then the PLR SHOULD corresponding to NodeID based Hello session, then the PLR SHOULD
conclude that the MP supports refresh-interval independent FRR conclude that the MP supports refresh-interval independent FRR
procedures defined in this document. procedures defined in this document.
- If the bypass LSP comes up, then the PLR SHOULD include Bypass - If the bypass LSP comes up, then the PLR SHOULD include Bypass
Summary FRR Extended Association object and triggers PATH to be Summary FRR Extended (B-SFRR) Association object and triggers a
sent. If Bypass Summary FRR Extended Association object is PATH message to be sent. If a B-SFRR Extended Association object
included in PATH message, then the encoding rules specified in is included in the PATH message, then the encoding and ordering
rules for the B-SFRR Extended Association object specified in
[SUMMARY-FRR] MUST be followed. [SUMMARY-FRR] MUST be followed.
4.1.2. Remote Signaling Adjacency 4.1.2. Remote Signaling Adjacency
A NodeID based RSVP-TE Hello session is one in which NodeID is used A NodeID based RSVP-TE Hello session is one in which NodeID is used
in source and destination address fields in RSVP Hello. [RFC4558] in source and destination address fields in RSVP Hello. [RFC4558]
formalizes NodeID based Hello messages between two routers. This formalizes NodeID based Hello messages between two routers. This
document extends NodeID based RSVP Hello session to track the state document extends NodeID based RSVP Hello session to track the state
of RSVP-TE neighbor that is not directly connected by at least one of any RSVP-TE neighbor that is not directly connected by at least
interface. In order to apply NodeID based RSVP-TE Hello session one interface. In order to apply NodeID based RSVP-TE Hello session
between any two routers that are not immediate neighbors, the router between any two routers that are not immediate neighbors, the router
that supports the extensions defined in the document SHOULD set TTL that supports the extensions defined in the document SHOULD set TTL
to 255 in the NodeID based Hello messages exchanged between PLR and to 255 in the NodeID based Hello messages exchanged between PLR and
MP. The default hello interval for this NodeID hello session SHOULD MP. The default hello interval for this NodeID hello session SHOULD
be set to the default specified in [TE-SCALE-REC]. be set to the default specified in [TE-SCALE-REC].
In the rest of the document the term "signaling adjacency", or In the rest of the document the term "signaling adjacency", or
"remote signaling adjacency" refers specifically to the RSVP-TE "remote signaling adjacency" refers specifically to the RSVP-TE
signaling adjacency. signaling adjacency.
4.1.3. MP Behavior 4.1.3. MP Behavior
When the NNhop or Nhop node receives the triggered PATH with a When the NNhop or the Nhop node receives the triggered PATH with a
"matching" Bypass Summary FRR Extended Association object, the node "matching" Bypass Summary FRR Extended Association object, the node
should consider itself as the MP for the PLR IP address should consider itself as the MP for the PLR IP address
"corresponding" to the Bypass Summary FRR Extended Association "corresponding" to the Bypass Summary FRR Extended Association
object. The matching and ordering rules of Bypass Summary FRR object. The matching and ordering rules for Bypass Summary FRR
Extended Association specified in [SUMMARY-FRR] SHOULD be followed Extended Association specified in [SUMMARY-FRR] MUST be followed by
by implementations supporting this document. implementations supporting this document.
In addition to the above procedures, the node SHOULD check the In addition to the above procedures, the node SHOULD check the
presence of remote signaling adjacency with PLR (this check is presence of remote signaling adjacency with PLR. If a matching
needed to detect network being partitioned). If a matching Bypass Bypass Summary FRR Extended Association object is found in the PATH
Summary FRR Extended Association object is found in PATH and the and if the RSVP-TE signaling adjacency is also present, then the
RSVP-TE signaling adjacency is present, the node concludes that the node concludes that the PLR will undertake refresh-interval
PLR will undertake refresh-interval independent FRR procedures independent FRR procedures specified in this document. If the PLR
specified in this document. If the PLR has included NodeID in PATH has included NodeID sub-object in PATH RRO, then that NodeID is the
RRO, then that NodeID is the remote neighbor address. Otherwise, the remote neighbor address. Otherwise, the PLR's interface address in
PLR's interface address in RRO will be the remote neighbor address. PATH RRO will be the remote neighbor address.
If a matching Bypass Summary FRR Extended Association object is
included by PPhop node, then it is NP-MP. If a matching Bypass - If a matching Bypass Summary FRR Extended Association object is
Summary FRR Extended Association object is included by Phop node, it included by the PPhop node and if a corresponding Node-ID
concludes it is LP-MP. signaling adjacency exists with the PPhop node, then the router
SHOULD conclude it is NP-MP.
- If a matching Bypass Summary FRR Extended Association object is
included by Phop node and if a corresponding Node-ID signaling
adjacency exists with the Phop node, then the router SHOULD
conclude it is LP-MP.
4.1.4. "Remote" state on MP 4.1.4. "Remote" state on MP
Once a router concludes it is MP for a PLR running refresh-interval Once a router concludes it is the MP for a PLR running refresh-
independent FRR procedures, it SHOULD create a remote path state for interval independent FRR procedures, it SHOULD create a remote path
the LSP. The "remote" state is identical to the protected LSP path state for the LSP. The "remote" state is identical to the protected
state except for the difference in RSVP_HOP object. The RSVP_HOP LSP path state except for the difference in RSVP_HOP object. The
object in "remote" Path state contains the address that the PLR uses thatRSVP_HOP object in "remote" Path state contains the address that
to send NodeID hello messages to MP. the PLR uses to send NodeID hello messages to MP.
The MP SHOULD consider the "remote" path state automatically deleted The MP SHOULD consider the "remote" path state automatically deleted
if: if:
- MP later receives a PATH with no matching Bypass Summary FRR - MP later receives a PATH with no matching B-SFRR Extended
Extended Association object corresponding to the PLR RRO, or Association object corresponding to the PLR's IP address contained
in PATH RRO, or
- Node signaling adjacency with PLR goes down, or - Node signaling adjacency with PLR goes down, or
- MP receives backup LSP signaling from PLR or - MP receives backup LSP signaling from PLR or
- MP receives PathTear, or - MP receives PathTear, or
- MP deletes the LSP state on local policy or exception event - MP deletes the LSP state on local policy or exception event
Unlike the normal path state that is either locally generated on Unlike the normal path state that is either locally generated on the
Ingress or created from PATH message from Phop node, the "remote" Ingress or created from a PATH message from the Phop node, the
path state is not signaled explicitly from PLR. The purpose of "remote" path state is not signaled explicitly from PLR. The purpose
"remote" path state is to enable the PLR to explicitly tear down of "remote" path state is to enable the PLR to explicitly tear down
path and reservation states corresponding to the LSP by sending tear path and reservation states corresponding to the LSP by sending tear
message for the "remote" path state. Such message tearing down message for the "remote" path state. Such message tearing down
"remote" path state is called "Remote PathTear. "remote" path state is called "Remote PathTear.
The scenarios in which "Remote" PathTear is applied are described in The scenarios in which "Remote" PathTear is applied are described in
Section 4.4 - Remote State Teardown. Section 4.4 - Remote State Teardown.
4.2. Impact of Failures on LSP State 4.2. Impact of Failures on LSP State
This section describes the procedures for routers on the LSP path This section describes the procedures for routers on the LSP path
skipping to change at page 14, line 4 skipping to change at page 13, line 19
- MP receives normal or "Remote" PathTear for PSB, or - MP receives normal or "Remote" PathTear for PSB, or
- MP receives ResvTear for RSB. - MP receives ResvTear for RSB.
When a router that is NP-MP does not detect Phop link or node When a router that is NP-MP does not detect Phop link or node
failure, but receives Conditional PathTear from the Phop node, then failure, but receives Conditional PathTear from the Phop node, then
the router SHOULD retain PSB and RSB states corresponding to the LSP the router SHOULD retain PSB and RSB states corresponding to the LSP
till the occurrence of any of the following events. till the occurrence of any of the following events.
- Remote Node-ID signaling adjacency with PPhop PLR goes down, or - Remote Node-ID signaling adjacency with PPhop PLR goes down, or
- MP receives normal or "Remote" PathTear for PSB, or - MP receives normal or "Remote" PathTear for PSB, or
- MP receives ResvTear for RSB. - MP receives ResvTear for RSB.
Receiving Conditional PathTear from the Phop node will not impact Receiving Conditional PathTear from the Phop node will not impact
the "remote" state from the PLR. Note that Phop node would send the "remote" state from the PPhop PLR. Note that Phop node would
Conditional PathTear if it was not an MP. send Conditional PathTear if it was not an MP.
In the example topology in Figure 1, assume C & D are NP-MP for PLRs In the example topology in Figure 1, assume C & D are NP-MP for PLRs
A & B respectively. Now when A-B link fails, as B is not MP and its A & B respectively. Now when A-B link fails, as B is not MP and its
Phop link signaling adjacency has failed, B will delete LSP state Phop link has failed, B will delete LSP state (this behavior is
(this behavior is required for unprotected LSPs - Section 4.2.1). In required for unprotected LSPs - Section 4.2.1). In the data plane,
the data plane, that would require B to delete the label forwarding that would require B to delete the label forwarding entry
entry corresponding to the LSP. So if B's downstream nodes C and D corresponding to the LSP. So if B's downstream nodes C and D
continue to retain state, it would not be correct for D to continue continue to retain state, it would not be correct for D to continue
to assume itself as NP-MP for PLR B. to assume itself as NP-MP for PLR B.
The mechanism that enables D to stop considering itself as NP-MP and The mechanism that enables D to stop considering itself as the NP-MP
delete "remote" path state is given below. for B and delete the corresponding "remote" path state is given
below.
1. When C receives Conditional PathTear from B, it decides to 1. When C receives Conditional PathTear from B, it decides to
retain LSP state as it is NP-MP of PLR A. C also SHOULD check retain LSP state as it is NP-MP of PLR A. C also SHOULD check
whether Phop B had previously signaled availability of node whether Phop B had previously signaled availability of node
protection. As B had previously signaled NP availability in its protection. As B had previously signaled NP availability by
PATH RRO, C SHOULD remove Bypass Summary FRR Extended including B-SFRR Extended Association object, C SHOULD remove
Association object containing Association Source set to B from the B-SFRR Extended Association object containing Association
the PATH message and trigger PATH to D. Source set to B from the PATH message and trigger PATH to D.
2. When D receives triggered PATH, it realizes that it is no 2. When D receives triggered PATH, it realizes that it is no
longer NP-MP and so deletes the "remote" path state. D does not longer the NP-MP for B and so it deletes the corresponding
propagate PATH further down because the only change is that the "remote" path state. D does not propagate PATH further down
Bypass Summary FRR Extended Association object corresponding to because the only change is that the B-SFRR Extended Association
Association Source B is no longer present in the PATH message. object corresponding to Association Source B is no longer
present in the PATH message.
4.2.4. Behavior of a Router that is both LP-MP and NP-MP 4.2.4. Behavior of a Router that is both LP-MP and NP-MP
A router may be both LP-MP as well as NP-MP at the same time for A router may be both LP-MP as well as NP-MP at the same time for
Phop and PPhop nodes respectively of an LSP. If Phop link fails on Phop and PPhop nodes respectively of an LSP. If Phop link fails on
such node, the node SHOULD retain PSB and RSB states corresponding such node, the node SHOULD retain PSB and RSB states corresponding
to the LSP till the occurrence of any of the following events. to the LSP till the occurrence of any of the following events.
- Both Node-ID signaling adjacencies with Phop and PPhop nodes go - Both Node-ID signaling adjacencies with Phop and PPhop nodes go
down, or down, or
skipping to change at page 15, line 29 skipping to change at page 14, line 48
link failure", B deletes PSB and RSB states corresponding to the LSP link failure", B deletes PSB and RSB states corresponding to the LSP
once B detects its link to Phop went down as B is not MP. If B were once B detects its link to Phop went down as B is not MP. If B were
to send PathTear normally, then C would delete LSP state to send PathTear normally, then C would delete LSP state
immediately. In order to avoid this, there should be some mechanism immediately. In order to avoid this, there should be some mechanism
by which B can indicate to C that B does not require the receiving by which B can indicate to C that B does not require the receiving
node to unconditionally delete the LSP state immediately. For this, node to unconditionally delete the LSP state immediately. For this,
B SHOULD add a new optional object called CONDITIONS object in B SHOULD add a new optional object called CONDITIONS object in
PathTear. The new optional object is defined in Section 4.3.3. If PathTear. The new optional object is defined in Section 4.3.3. If
node C also understands the new object, then C SHOULD delete LSP node C also understands the new object, then C SHOULD delete LSP
state only if it is not an NP-MP - in other words C SHOULD delete state only if it is not an NP-MP - in other words C SHOULD delete
LSP state if there is no "remote" PLR state on C. LSP state if there is no "remote" PLR path state on C.
4.3.1. Sending Conditional Path Tear 4.3.1. Sending Conditional Path Tear
A router that is not an MP for an LSP SHOULD delete PSB and RSB A router that is not an MP for an LSP SHOULD delete PSB and RSB
states corresponding to the LSP if Phop link or Phop Node-ID states corresponding to the LSP if Phop link or Phop Node-ID
signaling adjacency goes down (Section 4.2.1). The router SHOULD signaling adjacency goes down (Section 4.2.1). The router SHOULD
send Conditional PathTear if the following are also true. send Conditional PathTear if the following are also true.
- Ingress has requested node protection for the LSP, and - Ingress has requested node protection for the LSP, and
- PathTear is not received from upstream node - PathTear is not received from the upstream node
4.3.2. Processing Conditional Path Tear 4.3.2. Processing Conditional Path Tear
When a router that is not an NP-MP receives Conditional PathTear, When a router that is not an NP-MP receives Conditional PathTear,
the node SHOULD delete PSB and RSB states corresponding to the LSP, the node SHOULD delete PSB and RSB states corresponding to the LSP,
and process Conditional PathTear by considering it as normal and process Conditional PathTear by considering it as normal
PathTear. Specifically, the node SHOULD NOT propagate Conditional PathTear. Specifically, the node SHOULD NOT propagate Conditional
PathTear downstream but remove the optional object and send normal PathTear downstream but remove the optional object and send normal
PathTear downstream. PathTear downstream.
When a node that is an NP-MP receives Conditional PathTear, it When a node that is an NP-MP receives Conditional PathTear, it
SHOULD NOT delete LSP state. The node SHOULD check whether the Phop SHOULD NOT delete LSP state. The node SHOULD check whether the Phop
node had previously included Bypass Summary FRR Extended Association node had previously included B-SFRR Extended Association object in
object in PATH. If the object had been included previously by Phop, PATH. If the object had been included previously by the Phop, then
then the node processing Conditional PathTear from Phop SHOULD the node processing Conditional PathTear from the Phop SHOULD remove
remove the corresponding object and trigger PATH downstream. the corresponding object and trigger PATH downstream.
If Conditional PathTear is received from a neighbor that has not If Conditional PathTear is received from a neighbor that has not
advertised support (refer to Section 4.5) for the new procedures advertised support (refer to Section 4.5) for the new procedures
defined in this document, then the node SHOULD consider the message defined in this document, then the node SHOULD consider the message
as normal PathTear. The node SHOULD propagate normal PathTear as normal PathTear. The node SHOULD propagate normal PathTear
downstream and delete LSP state. downstream and delete the LSP state.
4.3.3. CONDITIONS object 4.3.3. CONDITIONS object
As any implementation that does not support Conditional PathTear As any implementation that does not support Conditional PathTear
SHOULD ignore the new object but process the message as normal SHOULD ignore the new object but process the message as normal
PathTear without generating any error, the Class-Num of the new PathTear without generating any error, the Class-Num of the new
object SHOULD be 10bbbbbb where 'b' represents a bit (from Section object SHOULD be 10bbbbbb where 'b' represents a bit (from Section
3.10 of [RFC2205]). 3.10 of [RFC2205]).
The new object is called as "CONDITIONS" object that will specify The new object is called as "CONDITIONS" object that will specify
skipping to change at page 17, line 19 skipping to change at page 16, line 37
based on the condition if the receiver router is a Merge Point or based on the condition if the receiver router is a Merge Point or
not. not.
If M-bit is set to 0, then the PathTear message SHOULD be processed If M-bit is set to 0, then the PathTear message SHOULD be processed
as normal PathTear message. as normal PathTear message.
4.4. Remote State Teardown 4.4. Remote State Teardown
If the Ingress wants to tear down the LSP because of a management If the Ingress wants to tear down the LSP because of a management
event while the LSP is being locally repaired at a transit PLR, it event while the LSP is being locally repaired at a transit PLR, it
would not be desirable to wait till backup LSP signaling to perform would not be desirable to wait till the completion of backup LSP
state cleanup. To enable LSP state cleanup when the LSP is being signaling to perform state cleanup. To enable LSP state cleanup when
locally repaired, the PLR SHOULD send "remote" PathTear message the LSP is being locally repaired, the PLR SHOULD send "remote"
instructing the MP to delete PSB and RSB states corresponding to the PathTear message instructing the MP to delete PSB and RSB states
LSP. The TTL in "remote" PathTear message SHOULD be set to 255. corresponding to the LSP. The TTL in "remote" PathTear message
SHOULD be set to 255.
Consider node C in example topology (Figure 1) has gone down and B Consider node C in example topology (Figure 1) has gone down and B
locally repairs the LSP. locally repairs the LSP.
1. Ingress A receives a management event to tear down the LSP. 1. Ingress A receives a management event to tear down the LSP.
2. A sends normal PathTear to B. 2. A sends normal PathTear to B.
3. To enable LSP state cleanup, B SHOULD send "remote" PathTear with 3. Assume B has not initiated backup signaling for the LSR. To enable
LSP state cleanup, B SHOULD send "remote" PathTear with
destination IP address set to that of D used in Node-ID signaling destination IP address set to that of D used in Node-ID signaling
adjacency with D, and RSVP_HOP object containing local address adjacency with D, and RSVP_HOP object containing local address
used in Node-ID signaling adjacency. used in Node-ID signaling adjacency.
4. B then deletes PSB and RSB states corresponding to the LSP. 4. B then deletes PSB and RSB states corresponding to the LSP.
5. On D there would be a remote signaling adjacency with B and so D 5. On D there would be a remote signaling adjacency with B and so D
SHOULD accept the remote PathTear and delete PSB and RSB states SHOULD accept the remote PathTear and delete PSB and RSB states
corresponding to the LSP. corresponding to the LSP.
4.4.1. PLR Behavior on Local Repair Failure 4.4.1. PLR Behavior on Local Repair Failure
If local repair fails on the PLR after a failure, then this should If local repair fails on the PLR after a failure, then this should
skipping to change at page 18, line 16 skipping to change at page 17, line 35
4.4.2. PLR Behavior on Resv RRO Change 4.4.2. PLR Behavior on Resv RRO Change
When a router that has already made NP available detects a change in When a router that has already made NP available detects a change in
the RRO carried in RESV message, and if the RRO change indicates the RRO carried in RESV message, and if the RRO change indicates
that the router's former NP-MP is no longer present in the LSP path, that the router's former NP-MP is no longer present in the LSP path,
then the router SHOULD send "Remote" PathTear directly to its former then the router SHOULD send "Remote" PathTear directly to its former
NP-MP. NP-MP.
In the example topology in Figure 1, assume A has made node In the example topology in Figure 1, assume A has made node
protection available and C has concluded it is NP-MP. When the B-C protection available and C has concluded it is the NP-MP for A. When
link fails then implementing the procedure specified in Section the B-C link fails then C, implementing the procedure specified in
4.2.4 of this document, C will retain state till: remote NodeID Section 4.2.4 of this document, will retain state till: remote
control plane adjacency with A goes down, or PathTear or ResvTear is NodeID signaling adjacency with A goes down, or PathTear or ResvTear
received for PSB or RSB respectively. If B also has made node is received for PSB or RSB respectively. If B also has made node
protection available, B will eventually complete backup LSP protection available, B will eventually complete backup LSP
signaling with its NP-MP D and trigger RESV to A with RRO changed. signaling with its NP-MP D and trigger RESV to A with RRO changed.
The new RRO of the LSP carried in RESV will not contain C. When A The new RRO of the LSP carried in RESV will not contain C. When A
processes the RESV with a new RRO not containing C - its former NP- processes the RESV with a new RRO not containing C - its former NP-
MP, A SHOULD send "Remote" PathTear to C. When C receives a "Remote" MP, A SHOULD send "Remote" PathTear to C. When C receives a "Remote"
PathTear for its PSB state, C will send normal PathTear downstream PathTear for its PSB state, C will send normal PathTear downstream
to D and delete both PSB and RSB states corresponding to the LSP. As to D and delete both PSB and RSB states corresponding to the LSP. As
D has already received backup LSP signaling from B, D will retain D has already received backup LSP signaling from B, D will retain
control plane and forwarding states corresponding to the LSP. control plane and forwarding states corresponding to the LSP.
4.4.3. LSP Preemption during Local Repair 4.4.3. LSP Preemption during Local Repair
If an LSP is preempted when there is no failure along the path of
the LSP, the node on which preemption occurs would send PathErr and
ResvTear upstream and only delete the forwarding state and RSB state
corresponding to the LSP. But if the LSP is being locally repaired
upstream of the node on which the LSP is preempted, then the node
SHOULD delete both PSB and RSB states corresponding to the LSP and
send normal PathTear downstream.
4.4.3.1. Preemption on LP-MP after Phop Link failure 4.4.3.1. Preemption on LP-MP after Phop Link failure
If an LSP is preempted on LP-MP after its Phop or incoming link has If an LSP is preempted on LP-MP after its Phop or incoming link has
already failed but the backup LSP has not been signaled yet, then already failed but the backup LSP has not been signaled yet, then
the node SHOULD send normal PathTear and delete both PSB and RSB the node SHOULD send normal PathTear and delete both PSB and RSB
states corresponding to the LSP. As the LP-MP has retained LSP state states corresponding to the LSP. As the LP-MP has retained LSP state
because the PLR would signal the LSP through backup LSP signaling, expecting the PLR to perform backup LSP signaling, preemption would
preemption would bring down the LSP and the node would not be LP-MP bring down the LSP and the node would not be LP-MP any more
any more requiring the node to clean up LSP state. requiring the node to clean up LSP state.
4.4.3.2. Preemption on NP-MP after Phop Link failure 4.4.3.2. Preemption on NP-MP after Phop Link failure
If an LSP is preempted on NP-MP after its Phop link has already If an LSP is preempted on NP-MP after its Phop link has already
failed but the backup LSP has not been signaled yet, then the node failed but the backup LSP has not been signaled yet, then the node
SHOULD send normal PathTear and delete PSB and RSB states SHOULD send normal PathTear and delete PSB and RSB states
corresponding to the LSP. As the NP-MP has retained LSP state corresponding to the LSP. As the NP-MP has retained LSP state
because the PLR would signal the LSP through backup LSP signaling, expecting the PLR to perform backup LSP signaling, preemption would
preemption would bring down the LSP and the node would not be NP-MP bring down the LSP and the node would not be NP-MP any more
any more requiring the node to clean up LSP state. requiring the node to clean up LSP state.
Consider B-C link goes down on the same example topology (Figure 1). Consider B-C link goes down on the same example topology (Figure 1).
As C is NP-MP for PLR A, C will retain LSP state. As C is NP-MP for PLR A, C will retain LSP state.
1. The LSP is preempted on C. 1. The LSP is preempted on C.
2. C will delete RSB state corresponding to the LSP. But C cannot 2. C will delete RSB state corresponding to the LSP. But C cannot
send PathErr or ResvTear to PLR A because backup LSP has not send PathErr or ResvTear to PLR A because backup LSP has not
been signaled yet. been signaled yet.
3. As the only reason for C having retained state after Phop node 3. As the only reason for C having retained state after Phop node
failure was that it was NP-MP, C SHOULD send normal PathTear to failure was that it was NP-MP, C SHOULD send normal PathTear to
skipping to change at page 20, line 10 skipping to change at page 19, line 26
SHOULD be turned on only if all nodes involved in the node SHOULD be turned on only if all nodes involved in the node
protection FRR i.e. PLR, MP and intermediate node in the case of NP, protection FRR i.e. PLR, MP and intermediate node in the case of NP,
support the extensions. Note that for LSPs requesting only link support the extensions. Note that for LSPs requesting only link
protection, the PLR and the LP-MP should support the extensions. protection, the PLR and the LP-MP should support the extensions.
4.5.1. Detecting Support for Refresh interval Independent FRR 4.5.1. Detecting Support for Refresh interval Independent FRR
An implementation supporting the extensions specified in previous An implementation supporting the extensions specified in previous
sections (called RI-RSVP-FRR here after) SHOULD set the flag sections (called RI-RSVP-FRR here after) SHOULD set the flag
"Refresh interval Independent RSVP" or RI-RSVP in CAPABILITY object "Refresh interval Independent RSVP" or RI-RSVP in CAPABILITY object
in Hello messages. The RI-RSVP flag is specified in [TE-SCALE-REC]. carried in Hello messages. The RI-RSVP flag is specified in [TE-
SCALE-REC].
- As nodes supporting the extensions SHOULD initiate Node Hellos - As nodes supporting the extensions SHOULD initiate Node Hellos
with adjacent nodes, a node on the path of protected LSP can with adjacent nodes, a node on the path of protected LSP can
determine whether its Phop or Nhop neighbor supports RI-RSVP-FRR determine whether its Phop or Nhop neighbor supports RI-RSVP-FRR
enhancements from the Hello messages sent by the neighbor. enhancements from the Hello messages sent by the neighbor.
- If a node attempts to make node protection available, then the - If a node attempts to make node protection available, then the
PLR SHOULD initiate remote Node-ID signaling adjacency with NNhop. PLR SHOULD initiate remote Node-ID signaling adjacency with NNhop.
If the NNhop (a) does not reply to remote node Hello message or If the NNhop (a) does not reply to remote node Hello message or
(b) does not set "Enhanced facility protection" flag in CAPABILITY (b) does not set RI-RSVP flag in CAPABILITY object carried in its
object in the reply, then the PLR can conclude that NNhop does not Node-ID Hello messages, then the PLR can conclude that NNhop does
support RI-RSVP-FRR extensions. not support RI-RSVP-FRR extensions.
- If node protection is requested for an LSP and if (a) PPhop node - If node protection is requested for an LSP and if (a) PPhop node
has not included a matching Bypass Summary FRR Extended has not included a matching B-SFRR Extended Association object in
Association object in PATH or (b) PPhop node has not initiated PATH or (b) PPhop node has not initiated remote node Hello
remote node Hello messages, then the node SHOULD conclude that PLR messages or (c) PPhop node does not set RI-RSVP flag in CAPABILITY
does not support RI-RSVP-FRR extensions. The details are described object carried in its Node-ID Hello messages, then the node SHOULD
in the "Procedures for backward compatibility" section below. conclude that the PLR does not support RI-RSVP-FRR extensions. The
details are described in the "Procedures for backward
Any node that sets the I-bit is set in its CAPABILITY object MUST compatibility" section below.
also set Refresh-Reduction-Capable bit in common header of all RSVP-
TE messages.
4.5.2. Procedures for backward compatibility 4.5.2. Procedures for backward compatibility
The procedures defined hereafter are performed on a subset of LSPs The procedures defined hereafter are performed on a subset of LSPs
that traverse a node, rather than on all LSPs that traverse a node. that traverse a node, rather than on all LSPs that traverse a node.
This behavior is required to support backward compatibility for a This behavior is required to support backward compatibility for a
subset of LSPs traversing nodes running non-RI-RSVP-FRR subset of LSPs traversing nodes running non-RI-RSVP-FRR
implementations. implementations.
4.5.2.1. Lack of support on Downstream Node 4.5.2.1. Lack of support on Downstream Node
- If the Nhop does not support the RI-RSVP-FRR extensions, then the - If the Nhop does not support the RI-RSVP-FRR extensions, then the
node SHOULD reduce the "refresh period" in TIME_VALUES object node SHOULD reduce the "refresh period" in TIME_VALUES object
carried in PATH to default small refresh default value. carried in PATH to default short refresh default value.
- If node protection is requested and the NNhop node does not - If node protection is requested and the NNhop node does not
support the enhancements, then the node SHOULD reduce the "refresh support the enhancements, then the node SHOULD reduce the "refresh
period" in TIME_VALUES object carried in PATH to a small refresh period" in TIME_VALUES object carried in PATH to a short refresh
default value. default value.
If the node reduces the refresh time from the above procedures, it If the node reduces the refresh time from the above procedures, it
SHOULD also not send remote PathTear or Conditional PathTear SHOULD also not send remote PathTear or Conditional PathTear
messages. messages.
Consider the example topology in Figure 1. If C does not support the Consider the example topology in Figure 1. If C does not support the
RI-RSVP-FRR extensions, then: RI-RSVP-FRR extensions, then:
- A and B SHOULD reduce the refresh time to default value of 30 - A and B SHOULD reduce the refresh time to default value of 30
skipping to change at page 21, line 28 skipping to change at page 20, line 45
Conditional PathTear to C but SHOULD time out PSB state from A Conditional PathTear to C but SHOULD time out PSB state from A
normally. This would be accomplished if A would also reduce the normally. This would be accomplished if A would also reduce the
refresh time to default value. So if C does not support the RI- refresh time to default value. So if C does not support the RI-
RSVP-FRR extensions, then Phop B and PPhop A SHOULD reduce refresh RSVP-FRR extensions, then Phop B and PPhop A SHOULD reduce refresh
time to a small default value. time to a small default value.
4.5.2.2. Lack of support on Upstream Node 4.5.2.2. Lack of support on Upstream Node
- If Phop node does not support the RI-RSVP-FRR extensions, then - If Phop node does not support the RI-RSVP-FRR extensions, then
the node SHOULD reduce the "refresh period" in TIME_VALUES object the node SHOULD reduce the "refresh period" in TIME_VALUES object
carried in RESV to default small refresh time value. carried in RESV to default short refresh time value.
- If node protection is requested and the Phop node does not - If node protection is requested and the Phop node does not
support the RI-RSVP-FRR extensions, then the node SHOULD reduce support the RI-RSVP-FRR extensions, then the node SHOULD reduce
the "refresh period" in TIME_VALUES object carried in PATH to the "refresh period" in TIME_VALUES object carried in PATH to
default value. default value.
- If node protection is requested and PPhop node does not support - If node protection is requested and PPhop node does not support
the RI-RSVP-FRR extensions, then the node SHOULD reduce the the RI-RSVP-FRR extensions, then the node SHOULD reduce the
"refresh period" in TIME_VALUES object carried in RESV to default "refresh period" in TIME_VALUES object carried in RESV to default
value. value.
 End of changes. 52 change blocks. 
177 lines changed or deleted 145 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/