draft-ietf-mpls-rsvp-tunnel-applicability-02.txt   rfc3210.txt 
Internet Engineering Task Force Network Working Group D. Awduche
INTERNET-DRAFT Request for Comments: 3210 Movaz Networks
MPLS Working Group Daniel O. Awduche Category: Informational A. Hannan
Expiration Date: October 2001 Movaz Networks Routingloop
X. Xiao
Alan Hannan Photuris
Routingloop December 2001
XiPeng Xiao
Photuris
April, 2001
Applicability Statement for Extensions to RSVP for LSP-Tunnels Applicability Statement for Extensions to RSVP for LSP-Tunnels
draft-ietf-mpls-rsvp-tunnel-applicability-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This memo discusses the applicability of "Extensions to RSVP for LSP This memo discusses the applicability of "Extensions to RSVP
Tunnels" [1]. It highlights the protocol's principles of operation (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the
and describes the network context for which it was designed. protocol's principles of operation and describes the network context
Guidelines for deployment are offered and known protocol limitations for which it was designed. Guidelines for deployment are offered and
are indicated. This document is intended to accompany the submission known protocol limitations are indicated. This document is intended
of "Extensions to RSVP for LSP Tunnels" onto the Internet standards to accompany the submission of "Extensions to RSVP for LSP Tunnels"
track. onto the Internet standards track.
1.0 Introduction 1.0 Introduction
Service providers and users have indicated that there is a great need Service providers and users have indicated that there is a great need
for traffic engineering capabilities in IP networks. These traffic for traffic engineering capabilities in IP networks. These traffic
engineering capabilities can be based on Multiprotocol Label engineering capabilities can be based on Multiprotocol Label
Switching (MPLS) and can be implemented on label switching routers Switching (MPLS) and can be implemented on label switching routers
(LSRs) from different vendors that interoperate using a common (LSRs) from different vendors that interoperate using a common
signaling and label distribution protocol. A description of the signaling and label distribution protocol. A description of the
requirements for traffic engineering in MPLS based IP networks can be requirements for traffic engineering in MPLS based IP networks can be
found in [2]. There is, therefore, a requirement for an open, non- found in [2]. There is, therefore, a requirement for an open, non-
proprietary, standards based signaling and label distribution proprietary, standards based signaling and label distribution
protocol for the MPLS traffic engineering application that will allow protocol for the MPLS traffic engineering application that will allow
label switching routers from different vendors to interoperate. label switching routers from different vendors to interoperate.
The "Extensions to RSVP for LSP tunnels" (RSVP-TE) specification [1] The "Extensions to RSVP for LSP tunnels" (RSVP-TE) specification [1]
was developed by the IETF MPLS working group to address this was developed by the IETF MPLS working group to address this
requirement. RSVP-TE is a composition of several related proposals requirement. RSVP-TE is a composition of several related proposals
submitted to the IETF MPLS working group. It contains all the submitted to the IETF MPLS working group. It contains all the
necessary objects, packet formats, and procedures required to necessary objects, packet formats, and procedures required to
establish and maintain explicit label switched paths (LSPs). Explicit establish and maintain explicit label switched paths (LSPs).
LSPs are foundational to the traffic engineering application in MPLS Explicit LSPs are foundational to the traffic engineering application
based IP networks. Besides the traffic engineering application, the in MPLS based IP networks. Besides the traffic engineering
RSVP-TE specification may have other uses within the Internet. application, the RSVP-TE specification may have other uses within the
Internet.
This memo describes the applicability of the RSVP-TE specifications This memo describes the applicability of the RSVP-TE specifications
[1]. The protocol's principles of operation are highlighted, the [1]. The protocol's principles of operation are highlighted, the
network context for which it was developed is described, guidelines network context for which it was developed is described, guidelines
for deployment are offered, and known protocol limitations are for deployment are offered, and known protocol limitations are
indicated. indicated.
This applicability statement concerns only the use of RSVP to set up This applicability statement concerns only the use of RSVP to set up
unicast LSP-tunnels. It is noted that not all of the features unicast LSP-tunnels. It is noted that not all of the features
described in RFC2205 [3] are required to support the instantiation described in RFC2205 [3] are required to support the instantiation
and maintenance of LSP-tunnels. Aspects related to the support of and maintenance of LSP-tunnels. Aspects related to the support of
other features and capabilities of RSVP by an implementation that other features and capabilities of RSVP by an implementation that
also supports LSP-tunnels are beyond the scope of this document. also supports LSP-tunnels are beyond the scope of this document.
However, support of such additional features and capabilities should However, support of such additional features and capabilities should
not introduce new security vulnerabilities in environments that only not introduce new security vulnerabilities in environments that only
use RSVP to set up LSP-tunnels. use RSVP to set up LSP-tunnels.
This applicability statement does not preclude the use of other This applicability statement does not preclude the use of other
signaling and label distribution protocols for the traffic signaling and label distribution protocols for the traffic
engineering application in MPLS based networks. Service providers engineering application in MPLS based networks. Service providers
are free to deploy whatever signaling protocol that meets their are free to deploy whatever signaling protocol that meets their
needs. needs.
In particular, CR-LDP [7] and RSVP-TE [1] are two signaling protocols In particular, CR-LDP [6] and RSVP-TE [1] are two signaling protocols
that perform similar functions in MPLS networks. There is currently that perform similar functions in MPLS networks. There is currently
no consensus on which protocol is technically superior. Therefore, no consensus on which protocol is technically superior. Therefore,
network administrators should make a choice between the two based network administrators should make a choice between the two based
upon their needs and particular situation. upon their needs and particular situation.
2.0 Technical Overview of Extensions to RSVP for LSP Tunnels 2.0 Technical Overview of Extensions to RSVP for LSP Tunnels
The RSVP-TE specification extends the original RSVP protocol by The RSVP-TE specification extends the original RSVP protocol by
giving it new capabilities that support the following functions in an giving it new capabilities that support the following functions in an
MPLS domain: MPLS domain:
skipping to change at page 3, line 20 skipping to change at page 3, line 4
The RSVP-TE specification extends the original RSVP protocol by The RSVP-TE specification extends the original RSVP protocol by
giving it new capabilities that support the following functions in an giving it new capabilities that support the following functions in an
MPLS domain: MPLS domain:
(1) downstream-on-demand label distribution (1) downstream-on-demand label distribution
(2) instantiation of explicit label switched paths (2) instantiation of explicit label switched paths
(3) allocation of network resources (e.g., bandwidth) to (3) allocation of network resources (e.g., bandwidth) to
explicit LSPs explicit LSPs
(4) rerouting of established LSP-tunnels in a smooth fashion (4) rerouting of established LSP-tunnels in a smooth fashion
using the concept of make-before-break using the concept of make-before-break
(5) tracking of the actual route traversed by an LSP-tunnel (5) tracking of the actual route traversed by an LSP-tunnel
(6) diagnostics on LSP-tunnels (6) diagnostics on LSP-tunnels
(7) the concept of nodal abstraction (7) the concept of nodal abstraction
(8) preemption options that are administratively controllable (8) preemption options that are administratively controllable
The RSVP-TE specification introduces several new RSVP objects, The RSVP-TE specification introduces several new RSVP objects,
including the LABEL-REQUEST object, the RECORD-ROUTE object, the including the LABEL-REQUEST object, the RECORD-ROUTE object, the
LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects. New LABEL object, the EXPLICIT-ROUTE object, and new SESSION objects.
error messages are defined to provide notification of exception New error messages are defined to provide notification of exception
conditions. All of the new objects defined in RSVP-TE are optional conditions. All of the new objects defined in RSVP-TE are optional
with respect to the RSVP protocol, except the LABEL-REQUEST and LABEL with respect to the RSVP protocol, except the LABEL-REQUEST and LABEL
objects, which are both mandatory for the establishment of LSP- objects, which are both mandatory for the establishment of LSP-
tunnels. tunnels.
Two fundamental aspects distinguish the RSVP-TE specification [1] Two fundamental aspects distinguish the RSVP-TE specification [1]
from the original RSVP protocol [3]. from the original RSVP protocol [3].
The first distinguishing aspect is the fact that the RSVP-TE The first distinguishing aspect is the fact that the RSVP-TE
specification [1] is intended for use by label switching routers (as specification [1] is intended for use by label switching routers (as
well as hosts) to establish and maintain LSP-tunnels and to reserve well as hosts) to establish and maintain LSP-tunnels and to reserve
network resources for such LSP-tunnels. The original RSVP network resources for such LSP-tunnels. The original RSVP
specification [3], on the other hand, was intended for use by hosts specification [3], on the other hand, was intended for use by hosts
to request and reserve network resources for micro-flows. to request and reserve network resources for micro-flows.
The second distinguishing aspect is the fact that the RSVP-TE The second distinguishing aspect is the fact that the RSVP-TE
specification generalizes the concept of "RSVP flow." The RSVP-TE specification generalizes the concept of "RSVP flow." The RSVP-TE
specification essentially allows an RSVP session to consist of an specification essentially allows an RSVP session to consist of an
arbitrary aggregation of traffic (based on local policies) between arbitrary aggregation of traffic (based on local policies) between
the originating node of an LSP-tunnel and the egress node of the the originating node of an LSP-tunnel and the egress node of the
tunnel. To be definite, in the original RSVP protocol [3], a session tunnel. To be definite, in the original RSVP protocol [3], a session
was defined as a data flow with a particular destination and was defined as a data flow with a particular destination and
transport layer protocol. In the RSVP-TE specification, however, a transport layer protocol. In the RSVP-TE specification, however, a
session is implicitly defined as the set of packets that are assigned session is implicitly defined as the set of packets that are assigned
the same MPLS label value at the originating node of an LSP-tunnel. the same MPLS label value at the originating node of an LSP-tunnel.
The assignment of labels to packets can be based on various criteria, The assignment of labels to packets can be based on various criteria,
and may even encompass all packets (or subsets thereof) between the and may even encompass all packets (or subsets thereof) between the
endpoints of the LSP-tunnel. Because traffic is aggregated, the endpoints of the LSP-tunnel. Because traffic is aggregated, the
number of LSP-tunnels (hence the number of RSVP sessions) does not number of LSP-tunnels (hence the number of RSVP sessions) does not
increase proportionally with the number of flows in the network. increase proportionally with the number of flows in the network.
Therefore, the RSVP-TE specification [1] addresses a major scaling Therefore, the RSVP-TE specification [1] addresses a major scaling
issue with the original RSVP protocol [3], namely the large amount of issue with the original RSVP protocol [3], namely the large amount of
system resources that would otherwise be required to manage system resources that would otherwise be required to manage
reservations and maintain state for potentially thousands or even reservations and maintain state for potentially thousands or even
millions of RSVP sessions at the micro-flow granularity. millions of RSVP sessions at the micro-flow granularity.
The reader is referred to [1] for a technical description of the The reader is referred to [1] for a technical description of the
RSVP-TE protocol specification. RSVP-TE protocol specification.
3.0 Applicability of Extensions to RSVP for LSP Tunnels 3.0 Applicability of Extensions to RSVP for LSP Tunnels
Use of RSVP-TE is appropriate in contexts where it is useful to Use of RSVP-TE is appropriate in contexts where it is useful to
establish and maintain explicit label switched paths in an MPLS establish and maintain explicit label switched paths in an MPLS
network. LSP-tunnels may be instantiated for measurement purposes network. LSP-tunnels may be instantiated for measurement purposes
and/or for routing control purposes. They may also be instantiated and/or for routing control purposes. They may also be instantiated
for other administrative reasons. for other administrative reasons.
For the measurement application, an LSP-tunnel can be used to capture For the measurement application, an LSP-tunnel can be used to capture
various path statistics between its endpoints. This can be various path statistics between its endpoints. This can be
accomplished by associating various performance management and fault accomplished by associating various performance management and fault
management functions with an LSP-tunnel, such as packet and byte management functions with an LSP-tunnel, such as packet and byte
counters. For example, an LSP-tunnel can be instantiated, with or counters. For example, an LSP-tunnel can be instantiated, with or
without bandwidth allocation, solely for the purpose of monitoring without bandwidth allocation, solely for the purpose of monitoring
traffic flow statistics between two label switching routers. traffic flow statistics between two label switching routers.
For the routing control application, LSP-tunnels can be used to For the routing control application, LSP-tunnels can be used to
forward subsets of traffic through paths that are independent of forward subsets of traffic through paths that are independent of
routes computed by conventional Interior Gateway Protocol (IGP) routes computed by conventional Interior Gateway Protocol (IGP)
Shortest Path First (SPF) algorithms. This feature introduces Shortest Path First (SPF) algorithms. This feature introduces
significant flexibility into the routing function and allows policies significant flexibility into the routing function and allows policies
to be implemented that can result in the performance optimization of to be implemented that can result in the performance optimization of
operational networks. For example, using LSP-tunnels, traffic can be operational networks. For example, using LSP-tunnels, traffic can be
routed away from congested network resources onto relatively routed away from congested network resources onto relatively
underutilized ones. More generally, load balancing policies can be underutilized ones. More generally, load balancing policies can be
actualized that increase the effective capacity of the network. actualized that increase the effective capacity of the network.
To further enhance the control application, RSVP-TE may be augmented To further enhance the control application, RSVP-TE may be augmented
with an ancillary constraint-based routing entity. This entity may with an ancillary constraint-based routing entity. This entity may
compute explicit routes based on certain traffic attributes, while compute explicit routes based on certain traffic attributes, while
taking network constraints into account. Additionally, IGP link state taking network constraints into account. Additionally, IGP link
advertisements may be extended to propagate new topology state state advertisements may be extended to propagate new topology state
information. This information can be used by the constraint-based information. This information can be used by the constraint-based
routing entity to compute feasible routes. Furthermore, the IGP routing entity to compute feasible routes. Furthermore, the IGP
routing algorithm may itself be enhanced to take pre-established routing algorithm may itself be enhanced to take pre-established
LSP-tunnels into consideration while building the routing table. All LSP-tunnels into consideration while building the routing table. All
these augmentations are useful, but not mandatory. In fact, the these augmentations are useful, but not mandatory. In fact, the
RSVP-TE specification may be deployed in certain contexts without any RSVP-TE specification may be deployed in certain contexts without any
of these additional components. of these additional components.
The capability to monitor point to point traffic statistics between The capability to monitor point to point traffic statistics between
two routers and the capability to control the forwarding paths of two routers and the capability to control the forwarding paths of
subsets of traffic through a given network topology together make the subsets of traffic through a given network topology together make the
RSVP-TE specifications applicable and useful for traffic engineering RSVP-TE specifications applicable and useful for traffic engineering
within service provider networks. within service provider networks.
These capabilities also make the RSVP-TE applicable, in some These capabilities also make the RSVP-TE applicable, in some
skipping to change at page 5, line 39 skipping to change at page 5, line 21
explicit LSPs and traffic engineering in MPLS networks. explicit LSPs and traffic engineering in MPLS networks.
4.0 Deployment and Policy Considerations 4.0 Deployment and Policy Considerations
When deploying RSVP-TE, there should be well defined administrative When deploying RSVP-TE, there should be well defined administrative
policies governing the selection of nodes that will serve as policies governing the selection of nodes that will serve as
endpoints for LSP-tunnels. Furthermore, when devising a virtual endpoints for LSP-tunnels. Furthermore, when devising a virtual
topology for LSP-tunnels, special consideration should be given to topology for LSP-tunnels, special consideration should be given to
the tradeoff between the operational complexity associated with a the tradeoff between the operational complexity associated with a
large number of LSP-tunnels and the control granularity that large large number of LSP-tunnels and the control granularity that large
numbers of LSP-tunnels allow. Stated otherwise, a large number of numbers of LSP-tunnels allow. Stated otherwise, a large number of
LSP-tunnels allows greater control over the distribution of traffic LSP-tunnels allows greater control over the distribution of traffic
across the network, but increases network operational complexity. In across the network, but increases network operational complexity. In
large networks, it may be advisable to start with a simple LSP-tunnel large networks, it may be advisable to start with a simple LSP-tunnel
virtual topology and then introduce additional complexity based on virtual topology and then introduce additional complexity based on
observed or anticipated traffic flow patterns. observed or anticipated traffic flow patterns.
Administrative policies may also guide the amount of bandwidth to be Administrative policies may also guide the amount of bandwidth to be
allocated (if any) to each LSP-tunnel. Policies of this type may take allocated (if any) to each LSP-tunnel. Policies of this type may
into consideration empirical traffic statistics derived from the take into consideration empirical traffic statistics derived from the
operational network in addition to other factors. operational network in addition to other factors.
5.0 Limitations 5.0 Limitations
The RSVP-TE specification supports only unicast LSP-tunnels. The RSVP-TE specification supports only unicast LSP-tunnels.
Multicast LSP-tunnels are not supported. Multicast LSP-tunnels are not supported.
The RSVP-TE specification supports only unidirectional LSP- tunnels. The RSVP-TE specification supports only unidirectional LSP-tunnels.
Bidirectional LSP-tunnels are not supported. Bidirectional LSP-tunnels are not supported.
The soft state nature of RSVP remains a source of concern because of The soft state nature of RSVP remains a source of concern because of
the need to generate refresh messages periodically to maintain the the need to generate refresh messages periodically to maintain the
state of established LSP-tunnels. This issue is addressed in several state of established LSP-tunnels. This issue is addressed in several
proposals that have been submitted to the RSVP working group (see proposals that have been submitted to the RSVP working group (see
e.g. [6]). e.g. [5]).
6.0 Conclusion 6.0 Conclusion
The applicability of the "Extensions to RSVP for LSP Tunnels" The applicability of the "Extensions to RSVP for LSP Tunnels"
specification has been discussed in this document. The specification specification has been discussed in this document. The specification
introduced several enhancements to the RSVP protocol, which make it introduced several enhancements to the RSVP protocol, which make it
applicable in contexts in which the original RSVP protocol would have applicable in contexts in which the original RSVP protocol would have
been inappropriate. One context in which the RSVP-TE specification is been inappropriate. One context in which the RSVP-TE specification
particularly applicable is in traffic engineering in MPLS based IP is particularly applicable is in traffic engineering in MPLS based IP
networks. networks.
7.0 Security Considerations 7.0 Security Considerations
This document does not introduce new security issues. The RSVP-TE This document does not introduce new security issues. The RSVP-TE
specification adds new opaque objects to RSVP. Therefore, the specification adds new opaque objects to RSVP. Therefore, the
security considerations pertaining to the original RSVP protocol security considerations pertaining to the original RSVP protocol
remain relevant. When deployed in service provider networks, it is remain relevant. When deployed in service provider networks, it is
mandatory to ensure that only authorized entities are permitted to mandatory to ensure that only authorized entities are permitted to
initiate establishment of LSP-tunnels. initiate establishment of LSP-tunnels.
8.0 Acknowledgments 8.0 Acknowledgments
The authors gratefully acknowledge the useful comments received from The authors gratefully acknowledge the useful comments received from
the following individuals during initial review of this memo in the the following individuals during initial review of this memo in the
MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow. MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow.
9.0 References 9.0 References
[1] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, [1] Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V.
V. Srinivasan, "Extensions to RSVP for LSP Tunnels," Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC
Work in Progress. 3209, December 2001.
[2] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
"Requirements for Traffic Engineering Over MPLS,"
RFC 2702, September 1999.
[3] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- [2] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
Version 1, Functional Specification", RFC 2205, September 1997. McManus, "Requirements for Traffic Engineering Over MPLS," RFC
2702, September 1999.
[4] E. Rosen, A. Viswanathan, R. Callon, "A Proposed Architecture [3] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
for MPLS", RFC-3031, January 2001. "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC 2205, September 1997.
[5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, [4] Rosen, E., Viswanathan, A. and R. Callon, "A Proposed
A. Viswanathan, "A Framework for Multiprotocol Label Architecture for MPLS", RFC 3031, January 2001.
Switching", Work in Progress.
[6] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, [5] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
S. Molendini, "RSVP Refresh Reduction Extensions," Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
Work in Progress. 2961, April 2001.
[7] B. Jamoussi et al, "Constraint-Based LSP Setup using [6] Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP,"
LDP," Work in Progress Work in Progress.
10.0 AUTHORS' ADDRESSES 10.0 Authors' Addresses
Daniel O. Awduche Daniel O. Awduche
Movaz Networks Movaz Networks
7926 Jones Branch Drive, Suite 615 7926 Jones Branch Drive, Suite 615
McLean, VA 22102 McLean, VA 22102
Email: awduche@movaz.com
Voice: +1 703-847-7350 EMail: awduche@movaz.com
Voice: +1 703-298-5291
Alan Hannan Alan Hannan
RoutingLoop RoutingLoop
112 Falkirk Court 112 Falkirk Court
Sunnyvale, CA 94087 Sunnyvale, CA 94087
Email: alan@routingloop.com
EMail: alan@routingloop.com
Voice: +1 408 666-2326 Voice: +1 408 666-2326
XiPeng Xiao XiPeng Xiao
Photuris Inc. Photuris Inc.
2025 Stierlin Ct. 2025 Stierlin Ct.
Mountain View, CA 94043 Mountain View, CA 94043
Email: xxiao@photuris.com
EMail: xxiao@photuris.com
Voice: +1 650-919-3215 Voice: +1 650-919-3215
11.0 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 47 change blocks. 
102 lines changed or deleted 87 lines changed or added

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