draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-05.txt   draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-06.txt 
Internet Engineering Task Force R. Kunze, Ed. Internet Engineering Task Force R. Kunze, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational G. Grammel, Ed. Intended status: Informational G. Grammel, Ed.
Expires: December 18, 2017 Juniper Expires: January 1, 2018 Juniper
D. Beller D. Beller
Nokia Nokia
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
June 16, 2017 J. Meuric
France Telecom Orange
June 30, 2017
A framework for Management and Control of DWDM optical interface A framework for Management and Control of DWDM optical interface
parameters parameters
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-05 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-06
Abstract Abstract
To ensure an efficient data transport, meeting the requirements To ensure an efficient data transport, meeting the requirements
requested by today's IP-services the control and management of DWDM requested by today's IP-services the control and management of DWDM
interfaces are a precondition for enhanced multilayer networking and interfaces are a precondition for enhanced multilayer networking and
for a further automation of network provisioning and operation. This for a further automation of network provisioning and operation. This
document describes use cases, requirements and solutions for the document describes use cases, requirements and solutions for the
control and management of optical interfaces parameters according to control and management of optical interfaces parameters according to
different types of single channel DWDM interfaces. The focus is on different types of single channel DWDM interfaces. The focus is on
skipping to change at page 1, line 47 skipping to change at page 2, line 4
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 January 1, 2018.
This Internet-Draft will expire on December 18, 2017.
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 34 skipping to change at page 2, line 35
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Comparison of approaches for transverse compatibility . . 5 3.1. Comparison of approaches for transverse compatibility . . 5
3.1.1. Multivendor DWDM line system with transponders . . . 5 3.1.1. Multivendor DWDM line system with transponders . . . 5
3.1.2. Integrated single channel DWDM deployments on the 3.1.2. Integrated single channel DWDM deployments on the
client site . . . . . . . . . . . . . . . . . . . . . 6 client site . . . . . . . . . . . . . . . . . . . . . 6
4. Solutions for managing and controlling single channel optical 4. Solutions for managing and controlling single channel optical
interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8 interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Separate Operation and Management Approaches . . . . . . 9 4.1. Separate Operation and Management Approaches . . . . . . 9
4.1.1. Direct connection to the management system . . . . . 9 4.1.1. Direct connection to the management system . . . . . 9
4.1.2. Direct connection to the DWDM management system 4.1.2. Indirect connection to the DWDM management system
(first optical node) . . . . . . . . . . . . . . . . 10 (first optical node) . . . . . . . . . . . . . . . . 11
4.2. Control Plane Considerations . . . . . . . . . . . . . . 12 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13
4.2.1. Considerations using GMPLS UNI . . . . . . . . . . . 13 4.2.1. Considerations using GMPLS signaling . . . . . . . . 14
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Link monitoring Use Cases . . . . . . . . . . . . . . . . 15 5.2. Link monitoring Use Cases . . . . . . . . . . . . . . . . 16
5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 17 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 18
5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 20 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The usage of the single channel DWDM interfaces (e.g. in routers) The usage of the single channel DWDM interfaces (e.g. in routers)
connected to a DWDM Network (which include ROADMs and optical connected to a DWDM Network (which include ROADMs and optical
amplifiers) adds a further networking option for operators allowing amplifiers) adds a further networking option for operators allowing
new scenarios but require harmonised control and management plane new scenarios but require harmonised control and management plane
interaction between different network domains. interaction between different network domains.
Carriers deploy their networks today based on transport und packet Carriers deploy their networks today based on transport und packet
skipping to change at page 7, line 20 skipping to change at page 7, line 20
one or more OADMs. one or more OADMs.
|==================== Black Link =======================| |==================== Black Link =======================|
+-------------------------------------------------+ +-------------------------------------------------+
Ss | | DWDM Network Elements | | Rs Ss | | DWDM Network Elements | | Rs
+---+ | | | \ / | | | +---+ +---+ | | | \ / | | | +---+
Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1 Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1
+---+ | | | | | +------+ | | | | | +---+ +---+ | | | | | +------+ | | | | | +---+
+---+ | | | | | | | | | | | | +---+ +---+ | | | | | | | | | | | | +---+
Tx L2---|->| OM |-|>|------|->| OADM |--|------|->| OD |--|-->Rx L2 Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2
+---+ | | | | | | | | | | | | +---+ +---+ | | | | | | | | | | | | +---+
+---+ | | | | | +------+ | | | | | +---+ +---+ | | | | | +------+ | | | | | +---+
Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3
+---+ | | / | Link +----|--|----+ Link | \ | | +---+ +---+ | | / | Link +----|--|----+ Link | \ | | +---+
+-----------+ | | +----------+ +-----------+ | | +----------+
+--+ +--+ +--+ +--+
| | |==== Black Link ====| | |
v | v |
+---+ +---+ +---+ +---+
RxLx TxLx RxLx TxLx
+---+ +---+ +---+ +---+
Ss = Reference point at the DWDM network element tributary output Ss = Reference point at the DWDM network element tributary output
Rs = Reference point at the DWDM network element tributary input Rs = Reference point at the DWDM network element tributary input
Lx = Lambda x Lx = Lambda x
OM = Optical Mux OM = Optical Mux
OD = Optical Demux OD = Optical Demux
OADM = Optical Add Drop Mux ROADM = Reconfigurable Optical Add Drop Mux
Linear DWDM network as per ITU-T G.698.2 Linear DWDM network as per ITU-T G.698.2
Figure 2: Linear Black Link Figure 2: Linear Black Link
The single administrative domain may consist of several vendor The single administrative domain may consist of several vendor
domains. Even in that case a common network management and control domains. Even in that case a common network management and control
is required to ensure a consistent operation and provisioning of the is required to ensure a consistent operation and provisioning of the
entire connection. entire connection.
skipping to change at page 9, line 48 skipping to change at page 10, line 39
+------+ | | / \| \ | | +------+ +------+ | | / \| \ | | +------+
| |/ \| | | |/ \| |
| + + | | + + |
+------------------------------+ +------------------------------+
CL = Client Device CL = Client Device
/C = Single Channel Optical Interface /C = Single Channel Optical Interface
OM = Optical Mux OM = Optical Mux
OD = Optical Demux OD = Optical Demux
EMS = Element Management System EMS = Element Management System
MI= Management Interface MI = Management Interface
DCN = Data Control Network
Figure 3: Connecting Single Channel optical interfaces to the Figure 3: Connecting Single Channel optical interfaces to the
Transport Management system Transport Management system
The exchange of management information between client device and the The exchange of management information between client device and the
management system assumes that some form of a direct management management system assumes that some form of a direct management
communication link exists between the client device and the DWDM communication link exists between the client device and the DWDM
management system (e.g. EMS). This may be an Ethernet Link or a DCN management system (e.g. EMS). This may be an Ethernet Link or a DCN
connection (management communication channel MCC). connection (management communication channel MCC).
skipping to change at page 10, line 27 skipping to change at page 11, line 21
Therefore an extension to this MIB for the optical interface has been Therefore an extension to this MIB for the optical interface has been
drafted in [DWDM-interface-MIB]. SNMP is used to read parameters and drafted in [DWDM-interface-MIB]. SNMP is used to read parameters and
get notifications and alarms, netconf and yang models are needed to get notifications and alarms, netconf and yang models are needed to
easily provision the interface with the right parameter set as easily provision the interface with the right parameter set as
described in [YANG] described in [YANG]
Note that a software update of the optical interface components of Note that a software update of the optical interface components of
the client nodes must not lead obligatory to an update of the the client nodes must not lead obligatory to an update of the
software of the EMS and vice versa. software of the EMS and vice versa.
4.1.2. Direct connection to the DWDM management system (first optical 4.1.2. Indirect connection to the DWDM management system (first optical
node) node)
An alternative as shown in Figure 4 can be used in cases where a more An alternative as shown in Figure 4 can be used in cases where a more
integrated relationship between transport node (e.g. OM or OD) and integrated relationship between transport node (e.g. OM or OD or
client device is aspired. In that case a combination of control ROADM) and client device is aspired. In that case a combination of
plane features and manual management will be used. control plane features and manual management will be used.
+-----+ +-----+
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
| |
| |
+---+---+ +---+---+
| EMS | | EMS |
| | | |
skipping to change at page 12, line 4 skipping to change at page 13, line 4
For information exchange between the client node and the direct For information exchange between the client node and the direct
connected node of the optical transport network LMP as specified in connected node of the optical transport network LMP as specified in
RFC 4209 [RFC4209] should be used. This extension of LMP may be used RFC 4209 [RFC4209] should be used. This extension of LMP may be used
between a peer node and an adjacent optical network node as depicted between a peer node and an adjacent optical network node as depicted
in Figure 4. in Figure 4.
The LMP based on RFC 4209 does not yet support the transmission of The LMP based on RFC 4209 does not yet support the transmission of
configuration data (information). This functionality must be added configuration data (information). This functionality must be added
to the existing extensions of the protocol. The use of LMP-WDM to the existing extensions of the protocol. The use of LMP-WDM
assumes that some form of a control channel exists between the client assumes that some form of a control channel exists between the client
node and the WDM equipment. This may be a dedicated lambda, an node and the WDM equipment. This may be a dedicated lambda or an
Ethernet Link. Ethernet Link.
4.2. Control Plane Considerations 4.2. Control Plane Considerations
The concept of integrated single channel DWDM interfaces equally The concept of integrated single channel DWDM interfaces equally
applies to management and control plane mechanisms. GMPLS control applies to management and control plane mechanisms. GMPLS control
plane protocols have been extended for WSON, e.g. [RFC7689] for plane protocols have been extended for WSON, e.g. [RFC7689] for
fixed grid signal and for flexi-grid [RFC7792]. One important aspect fixed grid signal and for flexi-grid [RFC7792]. One important aspect
of the [G.698.2] is the fact that it includes the wavelength that is of the [G.698.2] is the fact that it includes the wavelength that is
supported by the given link. Therefore, the link can logically be supported by the given link. Therefore, the link can logically be
skipping to change at page 13, line 6 skipping to change at page 14, line 6
for a given wavelength, then the interfaces need to be switched for a given wavelength, then the interfaces need to be switched
on and further power tuning takes place. The sequencing of on and further power tuning takes place. The sequencing of
enabling the link needs to be covered as well. enabling the link needs to be covered as well.
The preferred way to address these in a Control Plane enabled network The preferred way to address these in a Control Plane enabled network
is neighbour discovery including exchange of link characteristics and is neighbour discovery including exchange of link characteristics and
link property correlation. The general mechanisms are covered in link property correlation. The general mechanisms are covered in
RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary
protocol framework to exchange those characteristics between client protocol framework to exchange those characteristics between client
and black link. LMP-WDM is not intended for exchanging routing or and black link. LMP-WDM is not intended for exchanging routing or
signaling information but covers: signaling information nor to provision the lambda in the transceiver
but covers:
1. Control channel management 1. Control channel management
2. Link property correlation 2. Link property correlation
3. Link verification 3. Link verification
4. Fault management 4. Fault management
Extensions to LMP/LMP-WDM covering the parameter sets (application Extensions to LMP/LMP-WDM covering the parameter sets (application
codes) are needed. Additionally, when client and server side are codes) are needed. Additionally, when client and server side are
managed by different operational entities, link state exchange is managed by different operational entities, link state exchange is
required to align the management systems. required to align the management systems.
4.2.1. Considerations using GMPLS UNI 4.2.1. Considerations using GMPLS signaling
The deployment of single channel optical interfaces is leading to The deployment of single channel optical interfaces is leading to
some functional changes related to the control plane models and has some functional changes related to the control plane models and has
therefore some impact on the existing interfaces especially in the therefore some impact on the existing interfaces especially in the
case of an overlay model where the edge node requests resources from case of a model where the edge node requests resources from the core
the core node and the edges node do not participate in the routing node and the edges node do not participate in the routing protocol
protocol instance that runs among the core nodes. RFC 4208 [RFC4208] instance that runs among the core nodes. RFC 4208 [RFC4208] defines
defines the GMPLS UNI that can be used between edge and core node. the GMPLS UNI that can be used between edge and core node. In case
In case of integrated interfaces deployment additional of integrated interfaces deployment additional functionalities are
functionalities are needed to setup a connection. needed to setup a connection.
It is necessary to differentiate between topology/signalling It is necessary to differentiate between topology/signalling
information and configuration parameters that are needed to setup a information and configuration parameters that are needed to setup a
wavelength path. RSVP-TE could be used for the signalling and the wavelength path. RSVP-TE could be used for the signalling and the
reservation of the wavelength path. But there are additional reservation of the wavelength path. But there are additional
information needed before RSVP-TE can start the signalling process. information needed before RSVP-TE can start the signalling process.
There are three possibilities to proceed: There are three possibilities to proceed:
a. Using RSVP-TE only for the signalling and LMP as described above a. Using RSVP-TE only for the signalling and LMP as described above
to exchange information to configure the optical interface within to exchange information to configure the optical interface within
the edge node or the edge node or
b. RSVP-TE will be used to transport additional information b. RSVP-TE (typically with loose ERO) to transport additional
information
c. Leaking IGP information instead of exchanging this information c. Leaking IGP information instead of exchanging this information
needed from the optical network to the edge node (overlay will be needed from the optical network to the edge node (UNI will be
transformed to a border-peer model) transformed to a border-peer model, see RFC 5146)
Furthermore following issues should be addressed: Furthermore following issues should be addressed:
a) The Communication between peering edge nodes using an out of band a) The Communication between peering edge nodes using an out of band
control channel. The two nodes sould exchange their optical control channel. The two nodes should exchange their optical
capabilities. An extended version of LMP is needed to exchange FEC capabilities. An extended version of LMP is needed to exchange FEC
Modulation scheme, etc. that must be the same. It would be helpful Modulation scheme, etc. that must be the same. It would be helpful
to define some common profiles that will be supported. Only if the to define some common profiles that will be supported. Only if the
profiles match with both interface capabilities it is possible start profiles match with both interface capabilities it is possible start
signaling. signaling.
b) Due to the bidirectional wavelength path that must be setup it is b) Due to the bidirectional wavelength path that must be setup, the
obligatory that the upstream edge node inserts a wavelength value upstream edge node must include a wavelength value into the RSVP-TE
into the path message for the wavelength path towards the upstream Path message. But in the case of a UNI model the client device may
node itself. But in the case of an overlay model the client device not have full information about which wavelength must/should be
may not have full information which wavelength must/should be selected, whereas this information must be exchanged between the edge
selectedand this information must be exchanged between the edge and and the core node. The special value defined in
the core node. [Network-Assigned-Upstream-Label] allows the optical network to
assign the actual wavelength to be used by the upstream transponder,
which is a simple and efficient solution to this issue.
5. Use cases 5. Use cases
A Comparison with the traditional operation scenarios provides an A Comparison with the traditional operation scenarios provides an
insight of similarities and distinctions in operation and management insight of similarities and distinctions in operation and management
of DWDM interfaces. The following use cases provide an overview of DWDM interfaces. The following use cases provide an overview
about operation and maintenance processes. about operation and maintenance processes.
5.1. Service Setup 5.1. Service Setup
skipping to change at page 15, line 33 skipping to change at page 16, line 37
The use cases described below are assuming that power monitoring The use cases described below are assuming that power monitoring
functions are available in the ingress and egress network element of functions are available in the ingress and egress network element of
the DWDM network, respectively. By performing link property the DWDM network, respectively. By performing link property
correlation it would be beneficial to include the current transmit correlation it would be beneficial to include the current transmit
power value at reference point Ss and the current received power power value at reference point Ss and the current received power
value at reference point Rs. For example if the Client transmitter value at reference point Rs. For example if the Client transmitter
power has a value of 0dBm and the ROADM interface measured power is power has a value of 0dBm and the ROADM interface measured power is
-6dBm the fiber patch cord connecting the two nodes may be pinched or -6dBm the fiber patch cord connecting the two nodes may be pinched or
the connectors are dirty. As discussed before, the actual route or the connectors are dirty. As discussed before, the actual route or
selection of a specific wavelength within the allowed set is outside selection of a specific wavelength within the allowed set is outside
the scope of LMP. In GMPLS, the parameter selection (e.g. central the scope of LMP. The computing entities (e.g. the first optical
frequency) is performed by RSVP-TE, routing is performed by IGP. ???? node originating the circuit) can rely on GMPLS IGP (OSPF) to
retrieve all the information related to the network, calculate the
path to reach the endpoint and signal the path implementation through
the network via RSVP-TE.
G.698.2 defines a single channel optical interface for DWDM systems G.698.2 defines a single channel optical interface for DWDM systems
that allows interconnecting network-external optical transponders that allows interconnecting network-external optical transponders
across a DWDM network. The optical transponders are external to the across a DWDM network. The optical transponders are external to the
DWDM network. This so-called 'black link' approach illustrated in DWDM network. This so-called 'black link' approach illustrated in
Figure 5-1 of G.698.2 and a copy of this figure is provided below. Figure 5-1 of G.698.2 and a copy of this figure is provided below.
The single channel fiber link between the Ss/Rs reference points and The single channel fiber link between the Ss/Rs reference points and
the ingress/egress port of the network element on the domain boundary the ingress/egress port of the network element on the domain boundary
of the DWDM network (DWDM border NE) is called access link in this of the DWDM network (DWDM border NE) is called access link in this
contribution. Based on the definition in G.698.2 it is part of the contribution. Based on the definition in G.698.2 it is part of the
skipping to change at page 27, line 33 skipping to change at page 28, line 33
[ITU-TG.957] [ITU-TG.957]
ITU-T, "Optical interfaces for equipments and systems ITU-T, "Optical interfaces for equipments and systems
relating to the synchronous digital hierarchy", relating to the synchronous digital hierarchy",
ITU-T Recommendation ITU-T G.957, 2006. ITU-T Recommendation ITU-T G.957, 2006.
[ITU-TG.959.1] [ITU-TG.959.1]
ITU-T, "Optical transport network physical layer ITU-T, "Optical transport network physical layer
interfaces", ITU-T Recommendation ITU-T G.959.1, 2009. interfaces", ITU-T Recommendation ITU-T G.959.1, 2009.
[Network-Assigned-Upstream-Label]
Internet Engineering Task Force, "Generalized Multi-
Protocol Label Switching (GMPLS) Resource reSerVation
Protocol with Traffic Engineering (RSVP- TE) mechanism
that enables the network to assign an upstream label for a
bidirectional LSP", draft-ietf-teas-network-assigned-
upstream-label draft-ietf-teas-network-assigned-upstream-
label, June 2017.
Authors' Addresses Authors' Addresses
Ruediger Kunze (editor) Ruediger Kunze (editor)
Deutsche Telekom Deutsche Telekom
Winterfeldtstr. 21-27 Winterfeldtstr. 21-27
10781 Berlin 10781 Berlin
Germany Germany
Phone: +491702275321 Phone: +491702275321
Email: RKunze@telekom.de Email: RKunze@telekom.de
skipping to change at line 1150 skipping to change at page 29, line 30
Email: Dieter.Beller@nokia.com Email: Dieter.Beller@nokia.com
Gabriele Galimberti (editor) Gabriele Galimberti (editor)
Cisco Cisco
Via S. Maria Molgora, 48 Via S. Maria Molgora, 48
20871 - Vimercate 20871 - Vimercate
Italy Italy
Phone: +390392091462 Phone: +390392091462
Email: ggalimbe@cisco.com Email: ggalimbe@cisco.com
Julien Meuric
France Telecom Orange
2, Avenue Pierre Marzin
22307 Lannion Cedex
France
Phone: +33 2 96 05 28 28
Email: julien.meuric@orange.com
 End of changes. 22 change blocks. 
53 lines changed or deleted 72 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/