draft-ietf-mpls-ri-rsvp-frr-00.txt   draft-ietf-mpls-ri-rsvp-frr-01.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: February 15, 2017 August 15, 2016 Expires: August 12, 2017 February 12, 2017
Refresh Interval Independent FRR Facility Protection Refresh Interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-00 draft-ietf-mpls-ri-rsvp-frr-01
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 1, line 38 skipping to change at page 1, line 38
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 15, 2017. This Internet-Draft will expire on August 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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................................10 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..........................11
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...13
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.......................14
4.3.2. Processing Conditional Path Tear....................14 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................16 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..................17
4.4.3.1. Preemption on LP-MP after Phop Link failure....17 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........................18
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...............19
4.5.2.1. Lack of support on Downstream Node.............19 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.........................20 4.5.2.3. Incremental Deployment.........................21
5. Security Considerations.......................................21 5. Security Considerations.......................................21
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.................................................23
11. Authors' Addresses...........................................24 11. Authors' Addresses...........................................24
1. Introduction 1. Introduction
skipping to change at page 9, line 30 skipping to change at page 10, line 22
- 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 as the NodeID in LSP. The PLR SHOULD also include its router ID in a NodeID sub-
PATH RRO unless configured explicitly not to include NodeID. object in PATH RRO unless configured explicitly not to include
NodeID. While including its router ID in NodeID sub-object, the
PLR SHOULD 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 Association object and triggers PATH to be sent. If Summary FRR Extended Association object and triggers PATH to be
Bypass Summary FRR Association object is included in PATH message, sent. If Bypass Summary FRR Extended Association object is
then the encoding rules specified in [SUMMARY-FRR] MUST be included in PATH message, then the encoding rules specified in
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 RSVP-TE neighbor that is not directly connected by at least one
interface. In order to apply NodeID based RSVP-TE Hello session 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
skipping to change at page 10, line 26 skipping to change at page 11, line 26
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 Nhop node receives the triggered PATH with a
"matching" Bypass Summary FRR Association object, the node should "matching" Bypass Summary FRR Extended Association object, the node
consider itself as the MP for the PLR IP address "corresponding" to should consider itself as the MP for the PLR IP address
the Bypass Summary FRR Association object. The matching and ordering "corresponding" to the Bypass Summary FRR Extended Association
rules of Bypass Summary FRR Association specified in [SUMMARY-FRR] object. The matching and ordering rules of Bypass Summary FRR
SHOULD be followed by implementations supporting this document. Extended Association specified in [SUMMARY-FRR] SHOULD be followed
by 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 (this check is
needed to detect network being partitioned). If a matching Bypass needed to detect network being partitioned). If a matching Bypass
Summary FRR Association object is found in PATH and the RSVP-TE Summary FRR Extended Association object is found in PATH and the
signaling adjacency is present, the node concludes that the PLR will RSVP-TE signaling adjacency is present, the node concludes that the
undertake refresh-interval independent FRR procedures specified in PLR will undertake refresh-interval independent FRR procedures
this document. If the PLR has included NodeID in PATH RRO, then that specified in this document. If the PLR has included NodeID in PATH
NodeID is the remote neighbor address. Otherwise, the PLR's RRO, then that NodeID is the remote neighbor address. Otherwise, the
interface address in RRO will be the remote neighbor address. If a PLR's interface address in RRO will be the remote neighbor address.
matching Bypass Summary FRR Association object is included by PPhop If a matching Bypass Summary FRR Extended Association object is
node, then it is NP-MP. If a matching Bypass Summary FRR Association included by PPhop node, then it is NP-MP. If a matching Bypass
object is included by Phop node, it concludes it is LP-MP. Summary FRR Extended Association object is included by Phop node, it
concludes 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 MP for a PLR running refresh-interval
independent FRR procedures, it SHOULD create a remote path state for independent FRR procedures, it SHOULD create a remote path state for
the LSP. The "remote" state is identical to the protected LSP path the LSP. The "remote" state is identical to the protected LSP path
state except for the difference in RSVP_HOP object. The RSVP_HOP state except for the difference in RSVP_HOP object. The RSVP_HOP
object in "remote" Path state contains the address that the PLR uses object in "remote" Path state contains the address that the PLR uses
to send NodeID hello messages to MP. 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 Bypass Summary FRR
Association object corresponding to the PLR RRO, or Extended Association object corresponding to the PLR 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
skipping to change at page 13, line 28 skipping to change at page 14, line 28
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 NP-MP and
delete "remote" path state is given below. delete "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 in its
PATH RRO, C SHOULD remove SUMMARY_FRR_BYPASS_ASSOCIATION sub- PATH RRO, C SHOULD remove Bypass Summary FRR Extended
object corresponding to B from the RRO and trigger PATH to D. Association object containing Association 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 NP-MP and so deletes the "remote" path state. D does not
propagate PATH further down because the only change is in PATH propagate PATH further down because the only change is that the
RRO SUMMARY_FRR_BYPASS_ASSOCIATION sub-object corresponding to Bypass Summary FRR Extended Association object corresponding to
B. 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 7 skipping to change at page 16, line 7
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 Association object node had previously included Bypass Summary FRR Extended Association
in PATH. If the object had been included previously by Phop, then object in PATH. If the object had been included previously by Phop,
the node processing Conditional PathTear from Phop SHOULD remove the then the node processing Conditional PathTear from Phop SHOULD
corresponding object and trigger PATH downstream. remove 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 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
skipping to change at page 19, line 25 skipping to change at page 20, line 25
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 "Enhanced facility protection" flag in CAPABILITY
object in the reply, then the PLR can conclude that NNhop does not object in the reply, then the PLR can conclude that NNhop does not
support RI-RSVP-FRR extensions. 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 Association object has not included a matching Bypass Summary FRR Extended
in PATH or (b) PPhop node has not initiated remote node Hello Association object in PATH or (b) PPhop node has not initiated
messages, then the node SHOULD conclude that PLR does not support remote node Hello messages, then the node SHOULD conclude that PLR
RI-RSVP-FRR extensions. The details are described in the does not support RI-RSVP-FRR extensions. The details are described
"Procedures for backward compatibility" section below. in the "Procedures for backward compatibility" section below.
Any node that sets the I-bit is set in its CAPABILITY object MUST Any node that sets the I-bit is set in its CAPABILITY object MUST
also set Refresh-Reduction-Capable bit in common header of all RSVP- also set Refresh-Reduction-Capable bit in common header of all RSVP-
TE messages. 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
 End of changes. 19 change blocks. 
44 lines changed or deleted 90 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/