draft-ietf-teas-rsvp-te-scaling-rec-04.txt   draft-ietf-teas-rsvp-te-scaling-rec-05.txt 
TEAS Working Group V. Beeram, Ed. TEAS Working Group V. Beeram, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: September 13, 2017 R. Shakir Expires: January 3, 2018 R. Shakir
Google, Inc Google, Inc
D. Pacella D. Pacella
Verizon Verizon
T. Saad T. Saad
Cisco Systems Cisco Systems
March 12, 2017 July 2, 2017
Implementation Recommendations to Improve the Scalability of RSVP-TE Implementation Recommendations to Improve the Scalability of RSVP-TE
Deployments Deployments
draft-ietf-teas-rsvp-te-scaling-rec-04 draft-ietf-teas-rsvp-te-scaling-rec-05
Abstract Abstract
The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed
is growing continually and the onus is on RSVP-TE implementations is growing continually and the onus is on RSVP-TE implementations
across the board to keep up with this increasing demand. across the board to keep up with this increasing demand.
This document makes a set of implementation recommendations to help This document introduces a couple of techniques - "Refresh-Interval
RSVP-TE deployments push the envelope on scaling and advocates the Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help
use of a couple of techniques - "Refresh-Interval Independent RSVP RSVP-TE deployments push the envelope on scaling.
(RI-RSVP)" and "Per-Peer Flow-Control" - for improving scaling.
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). 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 13, 2017. This Internet-Draft will expire on January 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 2, line 25 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. "RFC2961 specific" Recommendations . . . . . . . . . . . 3 2.1. "RFC2961 Specific" Recommendations . . . . . . . . . . . 3
2.1.1. Basic Pre-Requisites . . . . . . . . . . . . . . . . 3 2.1.1. Basic Prerequisites . . . . . . . . . . . . . . . . . 3
2.1.2. Making Acknowledgements mandatory . . . . . . . . . . 4 2.1.2. Making Acknowledgements Mandatory . . . . . . . . . . 4
2.1.3. Clarifications on reaching Rapid Retry Limit (Rl) . . 4 2.1.3. Clarifications On Reaching Rapid Retry Limit (Rl) . . 4
2.2. Refresh-Interval Independent RSVP . . . . . . . . . . . . 4 2.2. Refresh-Interval Independent RSVP . . . . . . . . . . . . 5
2.2.1. Capability Advertisement . . . . . . . . . . . . . . 5 2.2.1. Capability Advertisement . . . . . . . . . . . . . . 5
2.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Compatibility . . . . . . . . . . . . . . . . . . . . 6
2.3. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . 6 2.3. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . 6
2.3.1. Capability Advertisement . . . . . . . . . . . . . . 7 2.3.1. Capability Advertisement . . . . . . . . . . . . . . 7
2.3.2. Compatibility . . . . . . . . . . . . . . . . . . . . 7 2.3.2. Compatibility . . . . . . . . . . . . . . . . . . . . 7
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. Capability Object Values . . . . . . . . . . . . . . . . 8 5.1. Capability Object Values . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9 Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
skipping to change at page 3, line 26 skipping to change at page 3, line 21
to achieve sufficient processing to maintain LSP state. to achieve sufficient processing to maintain LSP state.
This document advocates the use of a couple of techniques - "Refresh- This document advocates the use of a couple of techniques - "Refresh-
Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" -
for significantly cutting down the amount of processing cycles for significantly cutting down the amount of processing cycles
required to maintain LSP state. "RI-RSVP" helps completely eliminate required to maintain LSP state. "RI-RSVP" helps completely eliminate
RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer
Flow-Control" enables a busy RSVP speaker to apply back pressure to Flow-Control" enables a busy RSVP speaker to apply back pressure to
its peer(s). In order to reap maximum scaling benefits, it is its peer(s). In order to reap maximum scaling benefits, it is
strongly RECOMMENDED that implementations support both the strongly RECOMMENDED that implementations support both the
techniques, but it is possible for an implementation to support just techniques.
one but not the other.
1.1. Conventions used in this document 1.1. Conventions used in this document
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 [RFC2119] document are to be interpreted as described in [RFC2119]
2. Recommendations 2. Recommendations
2.1. "RFC2961 specific" Recommendations 2.1. "RFC2961 Specific" Recommendations
The implementation recommendations discussed in this section are The implementation recommendations discussed in this section are
based on the proposals made in [RFC2961] and act as pre-requisites based on the proposals made in [RFC2961] and act as prerequisites for
for implementing either or both of the techniques discussed in implementing the techniques discussed in Sections 2.2 and 2.3.
Sections 2.2 and 2.3.
2.1.1. Basic Pre-Requisites 2.1.1. Basic Prerequisites
An implementation that supports either or both of the techniques An implementation that supports the techniques discussed in Sections
discussed in Sections 2.2 and 2.3: 2.2 and 2.3 must meet certain basic prerequisites.
o SHOULD indicate support for RSVP Refresh Overhead Reduction o It MUST indicate support for RSVP Refresh Overhead Reduction
extensions (as specified in Section 2 of [RFC2961]) by default, extensions (as specified in Section 2 of [RFC2961]).
with the ability to override the default via configuration.
o MUST support reliable delivery of Path/Resv and the corresponding o It MUST support receipt of any RSVP Refresh Overhead Reduction
Tear/Err messages using the procedures specified in [RFC2961]. message as defined in [RFC2961].
o MUST support retransmit of all RSVP-TE messages using exponential- o It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms
backoff, as specified in Section 6 of [RFC2961]. as defined in [RFC2961] (including the SRefresh message) with the
default behavior being to initiate the mechanisms but offering a
configuration override.
2.1.2. Making Acknowledgements mandatory o It MUST support reliable delivery of Path/Resv and the
corresponding Tear/Err messages (as specified in Section 4 of
[RFC2961]).
o It MUST support retransmission of all unacknowledged RSVP-TE
messages using exponential-backoff (as specified in Section 6 of
[RFC2961]).
2.1.2. Making Acknowledgements Mandatory
The reliable message delivery mechanism specified in [RFC2961] states The reliable message delivery mechanism specified in [RFC2961] states
that "Nodes receiving a non-out of order message containing a that "Nodes receiving a non-out of order message containing a
MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with
a MESSAGE_ID_ACK object." a MESSAGE_ID_ACK object."
In an implementation that supports either or both of the techniques In an implementation that supports the techniques discussed in
discussed in Sections 2.2 and 2.3, nodes receiving a non-out of order Sections 2.2 and 2.3, nodes receiving a non-out of order message
message containing a MESSAGE ID object with the ACK-Desired flag set, containing a MESSAGE ID object with the ACK-Desired flag set, MUST
MUST respond with a MESSAGE_ID_ACK object. This improvement to the respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can
predictability of the system in terms of reliable message delivery is be packed along with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects
key for being able to take any action based on a non-receipt of an and sent in an Ack message (or piggy-backed in any other RSVP
ACK. message). This improvement to the predictability of the system in
terms of reliable message delivery is key for being able to take any
action based on a non-receipt of an ACK.
2.1.3. Clarifications on reaching Rapid Retry Limit (Rl) 2.1.3. Clarifications On Reaching Rapid Retry Limit (Rl)
According to section 6 of [RFC2961] "The staged retransmission will According to section 6 of [RFC2961] "The staged retransmission will
continue until either an appropriate MESSAGE_ID_ACK object is continue until either an appropriate MESSAGE_ID_ACK object is
received, or the rapid retry limit, Rl, has been reached." The received, or the rapid retry limit, Rl, has been reached." The
following clarifies what actions, if any, a router should take once following clarifies what actions, if any, a router should take once
Rl has been reached. Rl has been reached.
If it is the retransmission of Tear/Err messages and Rl has been If Rl has been reached for the retransmission of a message that is
reached, the router need not take any further actions. If it is the neither a Path nor a Resv message, then the router need not take any
retransmission of Path/Resv messages and Rl has been reached, then further action. If Rl has been reached for the retransmission of a
the router starts periodic retransmission of these messages. The Path or a Resv message, then the router starts periodic
retransmitted messages MUST carry MESSAGE_ID object with ACK_Desired retransmission of these on a slower timer. The retransmitted
flag set. This periodic retransmission SHOULD continue until an messages MUST carry MESSAGE_ID object with ACK_Desired flag set.
appropriate MESSAGE_ID ACK object is received indicating This periodic retransmission SHOULD continue until an appropriate
acknowledgement of the (retransmitted) Path/Resv message. The MESSAGE_ID_ACK object is received indicating acknowledgement of the
configurable periodic retransmission interval SHOULD be less than the (retransmitted) Path/Resv message. The configurable periodic
retransmission interval for this slower timer SHOULD be less than the
regular refresh interval. A default periodic retransmission interval regular refresh interval. A default periodic retransmission interval
of 30 seconds is RECOMMENDED by this document. interval (for this slower timer) of 30 seconds is RECOMMENDED by this
document.
2.2. Refresh-Interval Independent RSVP 2.2. Refresh-Interval Independent RSVP
The RSVP protocol relies on periodic refreshes for state The RSVP protocol relies on periodic refreshes for state
synchronization between RSVP neighbors and for recovery from lost synchronization between RSVP neighbors and for recovery from lost
RSVP messages. It relies on refresh timeout for stale state cleanup. RSVP messages. It relies on refresh timeout for stale state cleanup.
The primary motivation behind introducing the notion of "Refresh The primary motivation behind introducing the notion of "Refresh
Interval Independent RSVP" (RI-RSVP) is to completely eliminate Interval Independent RSVP" (RI-RSVP) is to completely eliminate
RSVP's reliance on refreshes and refresh timeouts. This is done by RSVP's reliance on refreshes and refresh timeouts. This is done by
simply increasing the refresh interval to a fairly large value. simply increasing the refresh interval to a fairly large value.
skipping to change at page 5, line 43 skipping to change at page 5, line 51
o MUST indicate support for RI-RSVP via the CAPABILITY object in o MUST indicate support for RI-RSVP via the CAPABILITY object in
Hello messages. Hello messages.
2.2.1. Capability Advertisement 2.2.1. Capability Advertisement
An implementation supporting the RI-RSVP recommendations MUST set a An implementation supporting the RI-RSVP recommendations MUST set a
new flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello new flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello
messages. messages.
The new flag that will be introduced to CAPABILITY object is Bit Number TBA1 (TBA2) - RI-RSVP Capable (I-bit):
specified below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |I|T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit
Indicates that the sender supports RI-RSVP. Indicates that the sender supports RI-RSVP.
Any node that sets the new I-bit in its CAPABILITY object MUST also Any node that sets the new I-bit in its CAPABILITY object MUST also
set Refresh-Reduction-Capable bit in common header of all RSVP-TE set Refresh-Reduction-Capable bit in common header of all RSVP-TE
messages. messages. If a peer sets the I-bit in the CAPABILITY object but does
not set the Refresh-Reduction-Capable bit, then the RI-RSVP
functionality MUST NOT be activated for that peer.
2.2.2. Compatibility 2.2.2. Compatibility
The RI-RSVP functionality MUST be activated only between peers that The RI-RSVP functionality MUST NOT be activated with a peer that does
indicate their support for this functionality. not indicate support for this functionality.
2.3. Per-Peer RSVP Flow-Control 2.3. Per-Peer RSVP Flow-Control
The set of recommendations discussed in this section provide an RSVP The set of recommendations discussed in this section provide an RSVP
speaker with the ability to apply back pressure to its peer(s) to speaker with the ability to apply back pressure to its peer(s) to
reduce/eliminate RSVP-TE control plane congestion. reduce/eliminate RSVP-TE control plane congestion.
An implementation that supports "Per-Peer RSVP Flow-Control": An implementation that supports "Per-Peer RSVP Flow-Control":
o MUST support all the recommendations made in Section 2.1 o MUST support all the recommendations made in Sections 2.1 and 2.2.
o MUST use lack of ACKs from a peer as an indication of peer's RSVP- o MUST treat lack of ACKs from a peer as an indication of peer's
TE control plane congestion. If congestion is detected, the local RSVP- TE control plane congestion. If congestion is detected, the
system MUST throttle RSVP-TE messages to the affected peer. This local system MUST throttle RSVP-TE messages to the affected peer.
MUST be done on a per-peer basis. (Per-peer throttling MAY be This MUST be done on a per-peer basis. (Per-peer throttling MAY
implemented by a traffic shaping mechanism that proportionally be implemented by a traffic shaping mechanism that proportionally
reduces the RSVP signaling packet rate as the number of reduces the RSVP signaling packet rate as the number of
outstanding Acks increases. And when the number of outstanding outstanding Acks increases. And when the number of outstanding
Acks decreases, the send rate would be adjusted up again.) Acks decreases, the send rate would be adjusted up again.)
o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of
[RFC2961], suggests using 3). [RFC2961], suggests using 3).
o SHOULD prioritize Hello messages and messages carrying
Acknowledgements over other RSVP messages.
o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that o SHOULD prioritize Tear/Error over trigger Path/Resv (messages that
bring up new LSP state) sent to a peer when the local system bring up new LSP state) sent to a peer when the local system
detects RSVP-TE control plane congestion in the peer. detects RSVP-TE control plane congestion in the peer.
o MUST indicate support for all recommendations in this section via o MUST indicate support for all recommendations in this section via
the CAPABILITY object in Hello messages. the CAPABILITY object in Hello messages.
2.3.1. Capability Advertisement 2.3.1. Capability Advertisement
An implementation supporting the "Per-Peer Flow-Control" An implementation supporting the "Per-Peer Flow-Control"
recommendations MUST set a new flag "Per-Peer Flow-Control Capable" recommendations MUST set a new flag "Per-Peer Flow-Control Capable"
in the CAPABILITY object signaled in Hello messages. in the CAPABILITY object signaled in Hello messages.
The new flag that will be introduced to CAPABILITY object is Bit Number TBA3 (TBA4) - Per-Peer Flow-Control Capable (F-bit):
specified below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |F|I|T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F bit
Indicates that the sender supports Per-Peer RSVP Flow-Control Indicates that the sender supports Per-Peer RSVP Flow-Control.
Any node that sets the new I-bit in its CAPABILITY object MUST also Any node that sets the new F-bit in its CAPABILITY object MUST also
set Refresh-Reduction-Capable bit in common header of all RSVP-TE set Refresh-Reduction-Capable bit in common header of all RSVP-TE
messages. messages. If a peer sets the F-bit in the CAPABILITY object but does
not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow-
Control functionality MUST NOT be activated for that peer.
2.3.2. Compatibility 2.3.2. Compatibility
The "Per-Peer Flow-Control" functionality MUST be activated only if The Per-Peer Flow-Control functionality MUST NOT be activated with a
both peers support it. If a peer hasn't indicated that it is capable peer that does not indicate support for this functionality. If a
of participating in "Per-Peer Flow-Control", then it is risky to peer hasn't indicated that it is capable of participating in "Per-
assume that the peer would always acknowledge a non-out of order Peer Flow-Control", then it is risky to assume that the peer would
message containing a MESSAGE ID object with the ACK-Desired flag set. always acknowledge a non-out of order message containing a MESSAGE ID
object with the ACK-Desired flag set.
3. Acknowledgements 3. Acknowledgements
The authors would like to thank Yakov Rekhter for initiating this The authors would like to thank Yakov Rekhter for initiating this
work and providing valuable inputs. They would like to thank work and providing valuable inputs. They would like to thank
Raveendra Torvi and Chandra Ramachandran for participating in the Raveendra Torvi and Chandra Ramachandran for participating in the
many discussions that led to the recommendations made in this many discussions that led to the recommendations made in this
document. They would also like to thank Adrian Farrel for providing document. They would also like to thank Adrian Farrel and Lou Berger
detailed review comments. for providing detailed review comments.
4. Contributors 4. Contributors
Markus Jork Markus Jork
Juniper Networks Juniper Networks
Email: mjork@juniper.net Email: mjork@juniper.net
Ebben Aries Ebben Aries
Juniper Networks Juniper Networks
Email: exa@juniper.net Email: exa@juniper.net
skipping to change at page 8, line 31 skipping to change at page 8, line 21
http://www.iana.org/assignments/rsvp-parameters/rsvp- http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml). "Capability Object Values" Registry (introduced parameters.xhtml). "Capability Object Values" Registry (introduced
by [RFC5063]) is one of them. by [RFC5063]) is one of them.
IANA is requested to assign two new Capability Object Value bit flags IANA is requested to assign two new Capability Object Value bit flags
as follows: as follows:
Bit Hex Name Reference Bit Hex Name Reference
Number Value Number Value
------------------------------------------------------------------ ------------------------------------------------------------------
TBA TBA RI-RSVP Capable (I) Section 2.2.1 TBA1 TBA2 RI-RSVP Capable (I) Section 2.2.1
TBA TBA Per-Peer Flow-Control Capable (F) Section 2.3.1 TBA3 TBA4 Per-Peer Flow-Control Capable (F) Section 2.3.1
6. Security Considerations 6. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205] and considerations pertaining to the original RSVP protocol [RFC2205] and
RSVP-TE [RFC3209] and those that are described in [RFC5920] remain RSVP-TE [RFC3209] and those that are described in [RFC5920] remain
relevant. relevant.
7. References 7. References
 End of changes. 33 change blocks. 
94 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/