draft-ietf-mpls-residence-time-11.txt   draft-ietf-mpls-residence-time-12.txt 
MPLS Working Group G. Mirsky MPLS Working Group G. Mirsky
Internet-Draft S. Ruffini Internet-Draft Independent
Intended status: Standards Track E. Gray Intended status: Standards Track S. Ruffini
Expires: January 22, 2017 Ericsson Expires: June 16, 2017 E. Gray
Ericsson
J. Drake J. Drake
Juniper Networks Juniper Networks
S. Bryant S. Bryant
Independent Independent
A. Vainshtein A. Vainshtein
ECI Telecom ECI Telecom
July 21, 2016 December 13, 2016
Residence Time Measurement in MPLS network Residence Time Measurement in MPLS network
draft-ietf-mpls-residence-time-11 draft-ietf-mpls-residence-time-12
Abstract Abstract
This document specifies G-ACh based Residence Time Measurement and This document specifies G-ACh based Residence Time Measurement and
how it can be used by time synchronization protocols being how it can be used by time synchronization protocols being
transported over MPLS domain. transported over MPLS domain.
Residence time is the variable part of propagation delay of timing Residence time is the variable part of propagation delay of timing
and synchronization messages and knowing what this delay is for each and synchronization messages and knowing what this delay is for each
message allows for a more accurate determination of the delay to be message allows for a more accurate determination of the delay to be
skipping to change at page 1, line 45 skipping to change at page 1, line 46
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 22, 2017. This Internet-Draft will expire on June 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19
8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19
8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20
8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20
8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21
8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21
8.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 8.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22
8.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22 8.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Time synchronization protocols, e.g., Network Time Protocol version 4 Time synchronization protocols, e.g., Network Time Protocol version 4
(NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2
[IEEE.1588.2008] define timing messages that can be used to [IEEE.1588.2008] define timing messages that can be used to
synchronize clocks across a network domain. Measurement of the synchronize clocks across a network domain. Measurement of the
cumulative time one of these timing messages spends transiting the cumulative time one of these timing messages spends transiting the
nodes on the path from ingress node to egress node is termed nodes on the path from ingress node to egress node is termed
Residence Time and it is used to improve the accuracy of clock Residence Time and it is used to improve the accuracy of clock
synchronization. (I.e., it is the sum of the difference between the synchronization. (I.e., it is the sum of the difference between the
time of receipt at an ingress interface and the time of transmission time of receipt at an ingress interface and the time of transmission
from an egress interface for each node along the path from ingress from an egress interface for each node along the path from ingress
node to egress node.) This document defines a new Generalized node to egress node.) This document defines a new Generic Associated
Associated Channel (G-ACh) value and an associated residence time Channel (G-ACh) value and an associated residence time measurement
measurement (RTM) packet that can be used in a Multi-Protocol Label (RTM) packet that can be used in a Multi-Protocol Label Switching
Switching (MPLS) network to measure residence time over a Label (MPLS) network to measure residence time over a Label Switched Path
Switched Path (LSP). (LSP).
Although it is possible to use RTM over an LSP instantiated using Although it is possible to use RTM over an LSP instantiated using
LDP, that is outside the scope of this document. Rather, this LDP, that is outside the scope of this document. Rather, this
document describes RTM over an LSP signaled using RSVP-TE [RFC3209] document describes RTM over an LSP signaled using RSVP-TE [RFC3209]
because the LSP's path can be either explicitly specified or because the LSP's path can be either explicitly specified or
determined during signaling. determined during signaling.
Comparison with alternative proposed solutions such as Comparison with alternative proposed solutions such as
[I-D.ietf-tictoc-1588overmpls] is outside the scope of this document. [I-D.ietf-tictoc-1588overmpls] is outside the scope of this document.
skipping to change at page 4, line 6 skipping to change at page 4, line 6
G-ACh: Generic Associated Channel G-ACh: Generic Associated Channel
GAL: Generic Associated Channel Label GAL: Generic Associated Channel Label
NTP: Network Time Protocol NTP: Network Time Protocol
ppm: parts per million ppm: parts per million
PTP: Precision Time Protocol PTP: Precision Time Protocol
BC: Boundary Clock
LSP: Label Switched Path LSP: Label Switched Path
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
RRO: Record Route Object RRO: Record Route Object
RTM: Residence Time Measurement RTM: Residence Time Measurement
IGP: Internal Gateway Protocol IGP: Internal Gateway Protocol
skipping to change at page 5, line 10 skipping to change at page 5, line 10
along the path of a particular LSP in Scratch Pad field of an RTM along the path of a particular LSP in Scratch Pad field of an RTM
packet Figure 1. This value can then be used by the egress node to packet Figure 1. This value can then be used by the egress node to
update, for example, the correctionField of the PTP event packet update, for example, the correctionField of the PTP event packet
carried within the RTM packet prior to performing its PTP processing. carried within the RTM packet prior to performing its PTP processing.
3. G-ACh for Residence Time Measurement 3. G-ACh for Residence Time Measurement
RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend
the applicability of the PW Associated Channel (ACH) [RFC5085] to the applicability of the PW Associated Channel (ACH) [RFC5085] to
LSPs. G-ACh provides a mechanism to transport OAM and other control LSPs. G-ACh provides a mechanism to transport OAM and other control
messages over an LSP. Processing of these messages by select transit messages over an LSP. Processing of these messages by selected
nodes is controlled by the use of the Time-to-Live (TTL) value in the transit nodes is controlled by the use of the Time-to-Live (TTL)
MPLS header of these messages. value in the MPLS header of these messages.
The packet format for Residence Time Measurement (RTM) is presented The packet format for Residence Time Measurement (RTM) is presented
in Figure 1 in Figure 1
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | RTM G-ACh | |0 0 0 1|Version| Reserved | RTM G-ACh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 7, line 12 skipping to change at page 7, line 12
where Flags field has format where Flags field has format
0 1 2 0 1 2
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flags field format of PTP Packet Sub-TLV Figure 3: Flags field format of PTP Packet Sub-TLV
o The Type field identifies PTP sub-TLV defined in the Table 19 o The Type field identifies PTP packet sub-TLV and is set 1
Values of messageType field in [IEEE.1588.2008]. according to Section 8.3.
o The Length field of the PTP sub-TLV contains the number of octets o The Length field of the PTP sub-TLV contains the number of octets
of the Value field and MUST be 20. of the Value field and MUST be 20.
o The Flags field currently defines one bit, the S-bit, that defines o The Flags field currently defines one bit, the S-bit, that defines
whether the current message has been processed by a 2-step node, whether the current message has been processed by a 2-step node,
where the flag is cleared if the message has been handled where the flag is cleared if the message has been handled
exclusively by 1-step nodes and there is no follow-up message, and exclusively by 1-step nodes and there is no follow-up message, and
set if there has been at least one 2-step node and a follow-up set if there has been at least one 2-step node and a follow-up
message is forthcoming. message is forthcoming.
skipping to change at page 10, line 31 skipping to change at page 10, line 31
Throughout this document we refer to a node as RTM capable node when Throughout this document we refer to a node as RTM capable node when
at least one of its interfaces is RTM capable. Figure 5 provides an at least one of its interfaces is RTM capable. Figure 5 provides an
example of roles a node may have with respect to RTM capability: example of roles a node may have with respect to RTM capability:
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G |
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Figure 5: RTM capable roles Figure 5: RTM capable roles
o A is a Boundary Clock with its egress port in Master state. Node o A is a Boundary Clock (BC) with its egress port in Master state.
A transmits IP encapsulated timing packets whose destination IP Node A transmits IP encapsulated timing packets whose destination
address is G. IP address is G.
o B is the ingress LER for the MPLS LSP and is the first RTM capable o B is the ingress LER for the MPLS LSP and is the first RTM capable
node. It creates RTM packets and in each it places a timing node. It creates RTM packets and in each it places a timing
packet, possibly encrypted, in the Value field and initializes the packet, possibly encrypted, in the Value field and initializes the
Scratch Pad field with its residence time measurement Scratch Pad field with its residence time measurement
o C is a transit node that is not RTM capable. It forwards RTM o C is a transit node that is not RTM capable. It forwards RTM
packets without modification. packets without modification.
o D is RTM capable transit node. It updates the Scratch Pad filed o D is RTM capable transit node. It updates the Scratch Pad filed
skipping to change at page 12, line 47 skipping to change at page 12, line 47
MUST fail with generation of the ResvErr message with Error Code MUST fail with generation of the ResvErr message with Error Code
Duplicate TLV Section 8.8 and Error Value that contains Type value in Duplicate TLV Section 8.8 and Error Value that contains Type value in
its 8 least significant bits. If no RTM_SET TLV has been found, then its 8 least significant bits. If no RTM_SET TLV has been found, then
the LSP setup MUST fail with generation of the ResvErr message with the LSP setup MUST fail with generation of the ResvErr message with
Error Code RTM_SET TLV Absent Section 8.8. If one RTM_SET TLV has Error Code RTM_SET TLV Absent Section 8.8. If one RTM_SET TLV has
been found the node will use the ID of the first node in the RTM_SET been found the node will use the ID of the first node in the RTM_SET
in conjunction with the RRO to compute the hop count to its in conjunction with the RRO to compute the hop count to its
downstream node with reachable RTM capable interface. If the node downstream node with reachable RTM capable interface. If the node
cannot find matching ID in RRO, then it MUST try to use ID of the cannot find matching ID in RRO, then it MUST try to use ID of the
next node in the RTM_SET until it finds the match or reaches the end next node in the RTM_SET until it finds the match or reaches the end
of RTM_SET TLV. If match have been found, then the calculated value of RTM_SET TLV. If match has been found, the calculated value is
is used by the node as TTL value in outgoing label to reach the next used by the node as TTL value in outgoing label to reach the next RTM
RTM capable node on the LSP. Otherwise, the TTL value MUST be set to capable node on the LSP. Otherwise, the TTL value MUST be set to
255. The node MUST add RTM_SET sub-TLV with the same address it used 255. The node MUST add RTM_SET sub-TLV with the same address it used
in RRO sub-object at the beginning of the RTM_SET TLV in associated in RRO sub-object at the beginning of the RTM_SET TLV in associated
outgoing Resv message before forwarding it upstream. If the outgoing Resv message before forwarding it upstream. If the
calculated TTL value been set to 255, as described above, then the I calculated TTL value been set to 255, as described above, then the I
flag in node RTM_SET TLV MUST be set to 1 before Resv message flag in node RTM_SET TLV MUST be set to 1 before Resv message
forwarded upstream. Otherwise, the I flag MUST be cleared (0). forwarded upstream. Otherwise, the I flag MUST be cleared (0).
The ingress node MAY inspect the I bit flag received in each RTM_SET The ingress node MAY inspect the I bit flag received in each RTM_SET
TLV contained in the LSP_ATTRIBUTES object of a received Resv TLV contained in the LSP_ATTRIBUTES object of a received Resv
message. Presence of the RTM_SET TLV with I bit field set to 1 message. Presence of the RTM_SET TLV with I bit field set to 1
skipping to change at page 16, line 8 skipping to change at page 16, line 8
The identifier assigned to the link by the node specified by the The identifier assigned to the link by the node specified by the
Node ID. Node ID.
Reserved Reserved
Zeroed on initiation and ignored on receipt. Zeroed on initiation and ignored on receipt.
5. Data Plane Theory of Operation 5. Data Plane Theory of Operation
After instantiating an LSP for a path using RSVP-TE [RFC3209] as After instantiating an LSP for a path using RSVP-TE [RFC3209] as
described in Section 4.6 or as described in the second paragraph of described in Section 4.6, ingress node MAY begin sending RTM packets
Section 4 and in Section 4.6, ingress node MAY begin sending RTM to the first downstream RTM capable node on that path. Each RTM
packets to the first downstream RTM capable node on that path. Each packet has its Scratch Pad field initialized and its TTL set to
RTM packet has its Scratch Pad field initialized and its TTL set to
expire on the next downstream RTM-capable node. Each RTM-capable expire on the next downstream RTM-capable node. Each RTM-capable
node on the explicit path receives an RTM packet and records the time node on the explicit path receives an RTM packet and records the time
at which it receives that packet at its ingress interface as well as at which it receives that packet at its ingress interface as well as
the time at which it transmits that packet from its egress interface; the time at which it transmits that packet from its egress interface;
this should be done as close to the physical layer as possible to this should be done as close to the physical layer as possible to
ensure precise accuracy in time determination. The RTM-capable node ensure precise accuracy in time determination. The RTM-capable node
determines the difference between those two times; for 1-step determines the difference between those two times; for 1-step
operation, this difference is determined just prior to or while operation, this difference is determined just prior to or while
sending the packet, and the RTM-capable egress interface adds it to sending the packet, and the RTM-capable egress interface adds it to
the value in the Scratch Pad field of the message in progress. Note, the value in the Scratch Pad field of the message in progress. Note,
skipping to change at page 20, line 37 skipping to change at page 20, line 37
allocated according to the "IETF Review" procedure as specified in allocated according to the "IETF Review" procedure as specified in
[RFC5226] . Code points in the range 128 through 191 in this registry [RFC5226] . Code points in the range 128 through 191 in this registry
shall be allocated according to the "First Come First Served" shall be allocated according to the "First Come First Served"
procedure as specified in [RFC5226]. . This document defines the procedure as specified in [RFC5226]. . This document defines the
following new values RTM sub-TLV types: following new values RTM sub-TLV types:
+-----------+-------------+---------------+ +-----------+-------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+-------------+---------------+ +-----------+-------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1 | PTP 2-step | This document | | 1 | PTP | This document |
| 2-127 | Unassigned | | | 2-127 | Unassigned | |
| 128 - 191 | Unassigned | | | 128 - 191 | Unassigned | |
| 192 - 254 | Private Use | This document | | 192 - 254 | Private Use | This document |
| 255 | Reserved | This document | | 255 | Reserved | This document |
+-----------+-------------+---------------+ +-----------+-------------+---------------+
Table 3: RTM Sub-TLV Type Table 3: RTM Sub-TLV Type
8.4. RTM Capability sub-TLV in OSPFv2 8.4. RTM Capability sub-TLV in OSPFv2
skipping to change at page 23, line 37 skipping to change at page 23, line 37
is therefore the basis for an additional presumed trust model is therefore the basis for an additional presumed trust model
associated with existing LSPs and nodes. associated with existing LSPs and nodes.
The ability for potentially authenticating and/or encrypting RTM and The ability for potentially authenticating and/or encrypting RTM and
PTP data that is not needed by intermediate RTM/PTP-capable nodes is PTP data that is not needed by intermediate RTM/PTP-capable nodes is
for further study. for further study.
Security requirements of time protocols are provided in RFC 7384 Security requirements of time protocols are provided in RFC 7384
[RFC7384]. [RFC7384].
10. Acknowledgements 10. Acknowledgments
Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for
their thorough reviews, thoughtful comments and, most of, patience. their thorough reviews, thoughtful comments and, most of, patience.
11. References 11. References
11.1. Normative References 11.1. Normative References
[IEEE.1588.2008] [IEEE.1588.2008]
"Standard for a Precision Clock Synchronization Protocol "Standard for a Precision Clock Synchronization Protocol
skipping to change at page 25, line 19 skipping to change at page 25, line 19
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <http://www.rfc-editor.org/info/rfc7684>. 2015, <http://www.rfc-editor.org/info/rfc7684>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ospf-ospfv3-lsa-extend] [I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13
(work in progress), May 2016. (work in progress), October 2016.
[I-D.ietf-tictoc-1588overmpls] [I-D.ietf-tictoc-1588overmpls]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-07 (work in Networks", draft-ietf-tictoc-1588overmpls-07 (work in
progress), October 2015. progress), October 2015.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
skipping to change at page 25, line 50 skipping to change at page 25, line 50
DOI 10.17487/RFC6374, September 2011, DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>. <http://www.rfc-editor.org/info/rfc6374>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <http://www.rfc-editor.org/info/rfc7384>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
Ericsson Independent
Email: gregory.mirsky@ericsson.com Email: gregimirsky@gmail.com
Stefano Ruffini Stefano Ruffini
Ericsson Ericsson
Email: stefano.ruffini@ericsson.com Email: stefano.ruffini@ericsson.com
Eric Gray Eric Gray
Ericsson Ericsson
Email: eric.gray@ericsson.com Email: eric.gray@ericsson.com
 End of changes. 17 change blocks. 
33 lines changed or deleted 35 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/