draft-ietf-mpls-ri-rsvp-frr-11.txt   draft-ietf-mpls-ri-rsvp-frr-12.txt 
MPLS Working Group C. Ramachandran MPLS Working Group C R. Ramachandran
Internet-Draft T. Saad Internet-Draft T S. Saad
Updates: 4090 (if approved) Juniper Networks, Inc. Updates: 4090 (if approved) Juniper Networks, Inc.
Intended status: Standards Track I. Minei Intended status: Standards Track I M. Minei
Expires: December 22, 2021 Google, Inc. Expires: 22 June 2022 Google, Inc.
D. Pacella D P. Pacella
Verizon, Inc. Verizon, Inc.
June 20, 2021 19 December 2021
Refresh-interval Independent FRR Facility Protection Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-11 draft-ietf-mpls-ri-rsvp-frr-12
Abstract Abstract
RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two
local repair techniques to reroute Label Switched Path (LSP) traffic local repair techniques to reroute Label Switched Path (LSP) traffic
over pre-established backup tunnel. Facility backup method allows over pre-established backup tunnel. Facility backup method allows
one or more LSPs traversing a connected link or node to be protected one or more LSPs traversing a connected link or node to be protected
using a bypass tunnel. The many-to-one nature of local repair using a bypass tunnel. The many-to-one nature of local repair
technique is attractive from scalability point of view. This technique is attractive from scalability point of view. This
document enumerates facility backup procedures in RFC 4090 that rely document enumerates facility backup procedures in RFC 4090 that rely
skipping to change at page 2, line 7 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 22, 2021. This Internet-Draft will expire on 22 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7 4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP
Capability . . . . . . . . . . . . . . . . . . . . . . . 8 Capability . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Signaling Handshake between PLR and MP . . . . . . . . . 9 4.2. Signaling Handshake between PLR and MP . . . . . . . . . 9
4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10
4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10
4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 12
4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12
4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 13
4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13
4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13
4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 15
4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15 4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15
4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15 4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15
4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 16
4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16 4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16
4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 17 4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 17
4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17 4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 18
4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17 4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 18
4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18 4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18
4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18 4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18
4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 18 4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 19
4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19 4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19
4.6.1. Detecting Support for Refresh interval Independent 4.6.1. Detecting Support for Refresh interval Independent
FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19 FRR . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.2. Procedures for Backward Compatibility . . . . . . . . 20 4.6.2. Procedures for Backward Compatibility . . . . . . . . 20
4.6.2.1. Lack of support on Downstream Node . . . . . . . 20 4.6.2.1. Lack of support on Downstream Node . . . . . . . 20
4.6.2.2. Lack of support on Upstream Node . . . . . . . . 21 4.6.2.2. Lack of support on Upstream Node . . . . . . . . 21
4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 21 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 22
4.6.2.4. Incremental Deployment . . . . . . . . . . . . . 22 4.6.2.4. Incremental Deployment . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 23 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 24
6.2. CONDITIONS Flags . . . . . . . . . . . . . . . . . . . . 24 6.2. CONDITIONS Flags . . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
skipping to change at page 6, line 20 skipping to change at page 6, line 20
/ \ / \
A ----- B ----- C ----- D A ----- B ----- C ----- D
\ / \ /
\ / \ /
\ / \ /
\ / \ /
\ / \ /
\ / \ /
F F
Figure 1: Example Topology Figure 1: Example Topology
In the topology in Figure 1, let us consider a large number of LSPs In the topology in Figure 1, let us consider a large number of LSPs
from A to D transiting B and C. Assume that refresh interval has from A to D transiting B and C. Assume that refresh interval has
been configured to be long of the order of minutes and refresh been configured to be long of the order of minutes and refresh
reduction extensions are enabled on all routers. reduction extensions are enabled on all routers.
Also let us assume that node protection has been configured for the Also let us assume that node protection has been configured for the
LSPs and the LSPs are protected by each router in the following way LSPs and the LSPs are protected by each router in the following way
- A has made node protection available using bypass LSP A -> E -> C; - A has made node protection available using bypass LSP A -> E -> C;
skipping to change at page 6, line 43 skipping to change at page 6, line 43
- B has made node protection available using bypass LSP B -> F -> D; - B has made node protection available using bypass LSP B -> F -> D;
B is the PLR and D is the NP-MP B is the PLR and D is the NP-MP
- C has made link protection available using bypass LSP C -> B -> F - C has made link protection available using bypass LSP C -> B -> F
-> D; C is the PLR and D is the LP-MP -> D; C is the PLR and D is the LP-MP
In the above condition, assume that B-C link fails. The following is In the above condition, assume that B-C link fails. The following is
the sequence of events that is expected to occur for all protected the sequence of events that is expected to occur for all protected
LSPs under normal conditions. LSPs under normal conditions.
1. B performs local repair and re-directs LSP traffic over the bypass 1. B performs local repair and re-directs LSP traffic over the
LSP B -> F -> D. bypass LSP B -> F -> D.
2. B also creates backup state for the LSP and triggers sending of 2. B also creates backup state for the LSP and triggers sending of
backup LSP state to D over the bypass LSP B -> F -> D. backup LSP state to D over the bypass LSP B -> F -> D.
3. D receives backup LSP states and merges the backups with the 3. D receives backup LSP states and merges the backups with the
protected LSPs. protected LSPs.
4. As the link on C, over which the LSP states are refreshed, has 4. As the link on C, over which the LSP states are refreshed, has
failed, C will no longer receive state refreshes. Consequently failed, C will no longer receive state refreshes. Consequently
the protected LSP states on C will time out and C will send the the protected LSP states on C will time out and C will send the
tear down messages for all LSPs. As each router should consider tear down messages for all LSPs. As each router should consider
itself as an MP, C will time out the state only after waiting for itself as an MP, C will time out the state only after waiting for
an additional duration equal to refresh timeout. an additional duration equal to refresh timeout.
While the above sequence of events has been described in [RFC4090], While the above sequence of events has been described in [RFC4090],
there are a few problems for which no mechanism has been specified there are a few problems for which no mechanism has been specified
explicitly. explicitly.
skipping to change at page 14, line 23 skipping to change at page 14, line 36
behavior is required for unprotected LSPs - Section 4.3.1). In the behavior is required for unprotected LSPs - Section 4.3.1). In the
data plane, that would require B to delete the label forwarding entry data plane, that would require B to delete the label forwarding 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 the NP-MP for the PLR B. to assume itself as the NP-MP for the PLR B.
The mechanism that enables D to stop considering itself as the NP-MP The mechanism that enables D to stop considering itself as the NP-MP
for B and delete the corresponding "remote" path state is given for B and delete the corresponding "remote" path state is given
below. below.
1. When C receives a Conditional PathTear from B, it decides to 1. When C receives a Conditional PathTear from B, it decides to
retain LSP state as it is the NP-MP of the PLR A. C also MUST retain LSP state as it is the NP-MP of the PLR A. C also MUST
check whether Phop B had previously signaled availability of node check whether Phop B had previously signaled availability of node
protection. As B had previously signaled NP availability by protection. As B had previously signaled NP availability by
including B-SFRR-Ready Extended Association object, C MUST remove including B-SFRR-Ready Extended Association object, C MUST remove
the B-SFRR-Ready Extended Association object containing the B-SFRR-Ready Extended Association object containing
Association Source set to B from the Path message and trigger a Association Source set to B from the Path message and trigger a
Path to D. Path to D.
2. When D receives the Path message, it realizes that it is no longer 2. When D receives the Path message, it realizes that it is no
the NP-MP for B and so it deletes the corresponding "remote" path longer the NP-MP for B and so it deletes the corresponding
state. D does not propagate the Path further down because the "remote" path state. D does not propagate the Path further down
only change is that the B-SFRR-Ready Extended Association object because the only change is that the B-SFRR-Ready Extended
corresponding to Association Source B is no longer present in the Association object corresponding to Association Source B is no
Path message. longer present in the Path message.
4.3.4. Behavior of a Router that is both LP-MP and NP-MP 4.3.4. Behavior of a Router that is both LP-MP and NP-MP
A router may simultaneously be the LP-MP as well as the NP-MP for the A router may simultaneously be the LP-MP as well as the NP-MP for the
Phop and the PPhop nodes respectively of an LSP. If the Phop link Phop and the PPhop nodes respectively of an LSP. If the Phop link
fails on such a node, the node MUST retain the PSB and RSB states fails on such a node, the node MUST retain the PSB and RSB states
corresponding to the LSP till the occurrence of any of the following corresponding to the LSP till the occurrence of any of the following
events. events.
- Both Node-ID signaling adjacencies with Phop and PPhop nodes go - Both Node-ID signaling adjacencies with Phop and PPhop nodes go
skipping to change at page 16, line 35 skipping to change at page 17, line 5
The object has the following format: The object has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class | C-type | | Length | Class | C-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |M| | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CONDITIONS Object Figure 2: CONDITIONS Object
Length: This contains the size of the object in bytes and should * Length: This contains the size of the object in bytes and should
be set to eight. be set to eight.
Class: To be assigned Class: To be assigned
C-type: 1 C-type: 1
Merge-point condition (M) bit: If the M bit is set to 1, then the Merge-point condition (M) bit: If the M bit is set to 1, then the
PathTear message MUST be processed according to the receiver PathTear message MUST be processed according to the receiver
router role, i.e. if the receiving router is an MP or not for the router role, i.e. if the receiving router is an MP or not for the
LSP. LSP.
If the M-bit is set to 0, then the PathTear message MUST be If the M-bit is set to 0, then the PathTear message MUST be
processed processed as a normal PathTear message for the LSP. processed processed as a normal PathTear message for the LSP.
4.5. Remote State Teardown 4.5. 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
skipping to change at page 17, line 19 skipping to change at page 17, line 30
would not be desirable to wait till the completion of backup LSP would not be desirable to wait till the completion of backup LSP
signaling to perform state cleanup. To enable LSP state cleanup when signaling to perform state cleanup. To enable LSP state cleanup when
the LSP is being locally repaired, the PLR MUST send a "Remote" the LSP is being locally repaired, the PLR MUST send a "Remote"
PathTear message instructing the MP to delete the PSB and RSB states PathTear message instructing the MP to delete the PSB and RSB states
corresponding to the LSP. The TTL in the "Remote" PathTear message corresponding to the LSP. The TTL in the "Remote" PathTear message
MUST be set to 255. MUST be set to 255.
Let us consider that node C in the example topology (Figure 1) has Let us consider that node C in the example topology (Figure 1) has
gone down and node B locally repairs the LSP. gone down and node B 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 a normal PathTear for the LSP to B. 2. A sends a normal PathTear for the LSP to B.
3. Assume B has not initiated the backup signaling for the LSP during 3. Assume B has not initiated the backup signaling for the LSP
local repair. To enable LSP state cleanup, B MUST send a "Remote" during local repair. To enable LSP state cleanup, B MUST send a
PathTear with destination IP address set to that of the node D "Remote" PathTear with destination IP address set to that of the
used in the Node-ID signaling adjacency with D, and the RSVP_HOP node D used in the Node-ID signaling adjacency with D, and the
object containing local address used in the Node-ID signaling RSVP_HOP object containing local address used in the Node-ID
adjacency. signaling adjacency.
4. B then deletes the PSB and RSB states corresponding to the LSP. 4. B then deletes the 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
MUST accept the "Remote" PathTear and delete the PSB and RSB MUST accept the "Remote" PathTear and delete the PSB and RSB
states corresponding to the LSP. states corresponding to the LSP.
4.5.1. PLR Behavior on Local Repair Failure 4.5.1. PLR Behavior on Local Repair Failure
If local repair fails on the PLR after a failure, then this MUST be If local repair fails on the PLR after a failure, then this MUST be
considered as a case for cleaning up LSP state from the PLR to the considered as a case for cleaning up LSP state from the PLR to the
Egress. The PLR achieves state cleanup by sending "Remote" PathTear Egress. The PLR achieves state cleanup by sending "Remote" PathTear
to the MP. The MP MUST delete the states corresponding to the LSP to the MP. The MP MUST delete the states corresponding to the LSP
also also propagate the PathTear downstream thereby achieving state also also propagate the PathTear downstream thereby achieving state
skipping to change at page 19, line 5 skipping to change at page 19, line 20
MUST send a normal PathTear and delete the PSB and RSB states MUST send a normal PathTear and delete the 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
expecting the PLR to initiate backup LSP signaling, preemption would expecting the PLR to initiate backup LSP signaling, preemption would
bring down the LSP and the node would not be NP-MP any more requiring bring down the LSP and the node would not be NP-MP any more requiring
the node to clean up LSP state. the node to clean up LSP state.
Let us consider that B-C link goes down on the same example topology Let us consider that B-C link goes down on the same example topology
(Figure 1). As C is the NP-MP for the PLR A, C will retain LSP (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP
state. state.
1. The LSP is preempted on C. 1. The LSP is preempted on C.
2. C will delete the RSB state corresponding to the LSP. But C 2. C will delete the RSB state corresponding to the LSP. But C
cannot send a PathErr or a ResvTear to the PLR A because the cannot send a PathErr or a ResvTear to the PLR A because the
backup LSP has not been signaled yet. backup LSP has not 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 an NP-MP, C MUST send a normal PathTear to failure was that it was an NP-MP, C MUST send a normal PathTear to
D and delete its PSB state also. D would also delete the PSB and D and delete its PSB state also. D would also delete the PSB and
RSB states on receiving a PathTear from C. RSB states on receiving a PathTear from C.
4. B starts backup LSP signaling to D. But as D does not have the 4. B starts backup LSP signaling to D. But as D does not have the
LSP state, it will reject the backup LSP Path and send a PathErr LSP state, it will reject the backup LSP Path and send a PathErr
to B. to B.
5. B will delete its reservation and send a ResvTear to A. 5. B will delete its reservation and send a ResvTear to A.
4.6. Backward Compatibility Procedures 4.6. Backward Compatibility Procedures
"Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set
of procedures defined in this document to elimiate the reliance of of procedures defined in this document to elimiate the reliance of
periodic refreshes. The extensions proposed in RSVP-TE Summary FRR periodic refreshes. The extensions proposed in RSVP-TE Summary FRR
[RFC8796] may apply to implementations that do not support RI-RSVP- [RFC8796] may apply to implementations that do not support RI-RSVP-
FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state
cleanup namely Conditional and "Remote" PathTear require support from cleanup namely Conditional and "Remote" PathTear require support from
one-hop and two-hop neighboring nodes along the LSP path. So one-hop and two-hop neighboring nodes along the LSP path. So
skipping to change at page 23, line 44 skipping to change at page 24, line 12
based Hello sessions that can be established on a router supporting based Hello sessions that can be established on a router supporting
the extensions defined in this document. the extensions defined in this document.
6. IANA Considerations 6. IANA Considerations
6.1. New Object - CONDITIONS 6.1. New Object - CONDITIONS
RSVP Change Guidelines [RFC3936] defines the Class-Number name space RSVP Change Guidelines [RFC3936] defines the Class-Number name space
for RSVP objects. The name space is managed by IANA. for RSVP objects. The name space is managed by IANA.
IANA registry: RSVP Parameters IANA registry: RSVP Parameters Subsection: Class Names, Class
Subsection: Class Names, Class Numbers, and Class Types Numbers, and Class Types
A new RSVP object using a Class-Number from 128-183 range called the A new RSVP object using a Class-Number from 128-183 range called the
"CONDITIONS" object is defined in Section 4.4 of this document. The "CONDITIONS" object is defined in Section 4.4 of this document. The
Class-Number from 128-183 range will be allocated by IANA. Class-Number from 128-183 range will be allocated by IANA.
6.2. CONDITIONS Flags 6.2. CONDITIONS Flags
Apart from allocating Class-Number for the CONDITIONS object, the Apart from allocating Class-Number for the CONDITIONS object, the
allocation of the Merge-point condition bit or M-bit Section 4.4 will allocation of the Merge-point condition bit or M-bit Section 4.4 will
also be done by IANA. also be done by IANA.
skipping to change at page 24, line 23 skipping to change at page 24, line 37
7. Acknowledgements 7. Acknowledgements
We are very grateful to Yakov Rekhter for his contributions to the We are very grateful to Yakov Rekhter for his contributions to the
development of the idea and thorough review of content of the draft. development of the idea and thorough review of content of the draft.
We are thankful to Raveendra Torvi and Yimin Shen for their comments We are thankful to Raveendra Torvi and Yimin Shen for their comments
and inputs on early versions of the draft. We also thank Alexander and inputs on early versions of the draft. We also thank Alexander
Okonnikov for his review and comments on the draft. Okonnikov for his review and comments on the draft.
8. Contributors 8. Contributors
Markus Jork Markus Jork Juniper Networks, Inc. Email: mjork@juniper.net Harish
Juniper Networks, Inc. Sitaraman Individual Contributor Email: harish.ietf@gmail.com Vishnu
Email: mjork@juniper.net Pavan Beeram Juniper Networks, Inc. Email: vbeeram@juniper.net Ebben
Aries Arrcus, Inc. Email: exa@arrcus.com Mike Taillon Cisco Systems,
Harish Sitaraman Inc. Email: mtaillon@cisco.com
Individual Contributor
Email: harish.ietf@gmail.com
Vishnu Pavan Beeram
Juniper Networks, Inc.
Email: vbeeram@juniper.net
Ebben Aries
Arrcus, Inc.
Email: exa@arrcus.com
Mike Taillon
Cisco Systems, Inc.
Email: mtaillon@cisco.com
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 38 change blocks. 
80 lines changed or deleted 62 lines changed or added

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