< draft-weis-ippm-ioam-eth-00.txt   draft-weis-ippm-ioam-eth-01.txt >
ippm B. Weis ippm B. Weis
Internet-Draft F. Brockners Internet-Draft Independent
Intended status: Standards Track C. Hill Intended status: Standards Track F. Brockners
Expires: April 25, 2019 S. Bhandari Expires: September 11, 2019 C. Hill
S. Bhandari
V. Govindan V. Govindan
C. Pignataro C. Pignataro
Cisco Cisco
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Leddy J. Leddy
Comcast Comcast
S. Youell S. Youell
JMPC JMPC
T. Mizrahi T. Mizrahi
Marvell Huawei Network.IO Innovation Lab
A. Kfir A. Kfir
B. Gafni B. Gafni
Mellanox Technologies, Inc. Mellanox Technologies, Inc.
P. Lapukhov P. Lapukhov
Facebook Facebook
M. Spiegel M. Spiegel
Barefoot Networks Barefoot Networks
October 22, 2018 March 10, 2019
Ethernet Encapsulation for In-situ OAM Data EtherType Protocol Identification of In-situ OAM Data
draft-weis-ippm-ioam-eth-00 draft-weis-ippm-ioam-eth-01
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document traverses a path between two points in the network. This document
outlines how encapsulations using an EtherType to identify IOAM data defines an EtherType that identifies IOAM data fields as being the
fields as the next header in a packet. next protocol in a packet, and a header that encapsulates the IOAM
data fields.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on September 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. IOAM Ethertype . . . . . . . . . . . . . . . . . . . . . . . 3 3. IOAM EtherType . . . . . . . . . . . . . . . . . . . . . . . 3
4. Usage Examples of the IOAM Ethertype . . . . . . . . . . . . 4 4. Usage Examples of the IOAM EtherType . . . . . . . . . . . . 4
4.1. Example: GRE Encapsulation of In-situ OAM Date Fields . . 5 4.1. Example: GRE Encapsulation of IOAM Data Fields . . . . . 4
4.2. Example: Geneve Encapsulation of IOAM Data Fields . . . . 5 4.2. Example: Geneve Encapsulation of IOAM Data Fields . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
In-situ Operations, Administration, and Maintenance (IOAM) records In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a particular network domain. The term "in-situ" refers to traverses a particular network domain. The term "in-situ" refers to
the fact that the IOAM data fields are added to the data packets the fact that the IOAM data fields are added to the data packets
rather than being sent within packets specifically dedicated to OAM. rather than being sent within packets specifically dedicated to OAM.
This document defines how IOAM data fields are carried as part of This document defines how IOAM data fields are carried as part of
encapsulations where the IOAM data follows a header that uses an encapsulations where the IOAM data follows a header that uses an
EtherType to denote the next protocol in the packet. Examples of EtherType to denote the next protocol in the packet. Examples of
these protocols are GRE [RFC2784] and Geneve [I-D.ietf-nvo3-geneve]). these protocols are GRE [RFC2890] and Geneve [I-D.ietf-nvo3-geneve]).
This document outlines how IOAM data fields are encoded in these This document outlines how IOAM data fields are encoded in these
protocols. protocols.
2. Conventions 2. Conventions
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 3, line 34 skipping to change at page 3, line 35
Geneve: Generic Network Virtualization Encapsulation Geneve: Generic Network Virtualization Encapsulation
GRE: Generic Routing Encapsulation GRE: Generic Routing Encapsulation
IOAM: In-situ Operations, Administration, and Maintenance IOAM: In-situ Operations, Administration, and Maintenance
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
POT: Proof of Transit POT: Proof of Transit
3. IOAM Ethertype 3. IOAM EtherType
When the IOAM data fields are included within an encapsulation that When the IOAM data fields are included within an encapsulation that
identifies the next protocol using an EtherType (e.g., GRE or Geneve) identifies the next protocol using an EtherType (e.g., GRE or Geneve)
the presence of IOAM data fields are identified with TBD_IOAM. When the presence of IOAM data fields are identified with TBD_IOAM. When
the Ethernet Encapsulation for In-situ OAM Data is used, an this EtherType is used, an additional IOAM header is also included.
additional IOAM header is also included. This header indicates the This header indicates the type of IOAM data that follows, and the
type of IOAM data that follows, and the next protocol that follows next protocol that follows the IOAM data.
the IOAM data.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Type | IOAM HDR len| Next Protocol | | IOAM-Type | IOAM HDR len| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! | ! |
! | ! |
~ IOAM Option and Data Space ~ ~ IOAM Option and Data Space ~
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IOAM encapsulation is defined as follows. The IOAM encapsulation is defined as follows.
IOAM Type: 8-bit field defining the IOAM Option type, as defined in IOAM Type: 8-bit field defining the IOAM Option type, as defined in
Section 7.2 of [I-D.ietf-ippm-ioam-data]. Section 7.2 of [I-D.ietf-ippm-ioam-data].
IOAM HDR Len: 8 bits Length field contains the length of the IOAM HDR Len: 8 bit Length field contains the length of the IOAM
variable IOAM data octets in 4-octet units. header in 4-octet units.
Next Protocol: 16 bits Next Protocol Type field contains the Next Protocol: 16 bits Next Protocol Type field contains the
protocol type of the packet following IOAM protocol header. When protocol type of the packet following IOAM protocol header.
the most significant octet is 0x00, the Protocol Type is taken to
be an IP Protocol Number as defined in [IP-PROT]. Otherwise, the
Protocol Type is defined to be an EtherType value from [ETYPES]. Protocol Type is defined to be an EtherType value from [ETYPES].
An implementation receiving a packet containing a Protocol Type An implementation receiving a packet containing a Protocol Type
which is not listed in one of those registries SHOULD discard the which is not listed in one of those registries SHOULD discard the
packet. packet.
IOAM Option and Data Space: IOAM option header and data is present IOAM Option and Data Space: IOAM option header and data is present
as specified by the IOAM-Type field, and is defined in Section 4 as specified by the IOAM-Type field, and is defined in Section 4
of [I-D.ietf-ippm-ioam-data]. of [I-D.ietf-ippm-ioam-data].
Multiple IOAM options MAY be included within the IOAM Option and Data Multiple IOAM options MAY be included within the IOAM Option and Data
Space. For example, if two IOAM options are included, the Next Space. For example, if two IOAM options are included, the Next
Protocol field of the first IOAM option will contain the value of Protocol field of the first IOAM option will contain the value of
TBD_IOAM, while the Next Protocol field of the second IOAM option TBD_IOAM, while the Next Protocol field of the second IOAM option
will contain the Ethertype or IP protocol Number indicating the type will contain the EtherType indicating the type of the data packet.
of the data packet.
4. Usage Examples of the IOAM Ethertype 4. Usage Examples of the IOAM EtherType
The Ethernet Encapsulation for In-situ OAM Data can be used with many The IOAM EtherType can be used with many encapsulations. The
encapsulations. The following sections show how it can be used with following sections show how it can be used with GRE and Geneve.
GRE and Geneve.
4.1. Example: GRE Encapsulation of In-situ OAM Date Fields 4.1. Example: GRE Encapsulation of IOAM Data Fields
When IOAM data fields are carried in GRE, the IOAM encapsulation When IOAM data fields are carried in GRE, the IOAM encapsulation
defined above follows the GRE header, as shown in Figure 1. defined above follows the GRE header, as shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|C| Reserved0 | Ver | Protocol Type = <TBD_IOAM> | G |C| |K|S| Reserved0 | Ver | Protocol Type = <TBD_IOAM> | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Checksum (optional) | Reserved1 (Optional) | G
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
| Checksum (optional) | Reserved1 (Optional) | E | Key (optional) | E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number (Optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| IOAM-Type | IOAM HDR len| Next Protocol | | | IOAM-Type | IOAM HDR len| Next Protocol | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
! | O ! | O
! | A ! | A
~ IOAM Option and Data Space ~ M ~ IOAM Option and Data Space ~ M
| | | | | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | | |
| Payload + Padding (L2/L3/ESP/...) | | Payload + Padding (L2/L3/ESP/...) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: GRE Encapsulation Example Figure 1: GRE Encapsulation Example
The GRE header and fields are defined in [RFC2784]. The GRE Protocol The GRE header and fields are defined in [RFC2890]. The GRE Protocol
Type value is TBD_IOAM. Type value is TBD_IOAM.
4.2. Example: Geneve Encapsulation of IOAM Data Fields 4.2. Example: Geneve Encapsulation of IOAM Data Fields
When IOAM data fields are carried in Geneve, the IOAM encapsulation When IOAM data fields are carried in Geneve, the IOAM encapsulation
defined above follows the Geneve header, as shown in Figure 2. defined above follows the Geneve header, as shown in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
skipping to change at page 6, line 41 skipping to change at page 6, line 41
5. Security Considerations 5. Security Considerations
This document describes the encapsulation of IOAM data fields in GRE. This document describes the encapsulation of IOAM data fields in GRE.
Security considerations of the specific IOAM data fields for each Security considerations of the specific IOAM data fields for each
case (i.e., Trace, Proof of Transit, and E2E) are described in case (i.e., Trace, Proof of Transit, and E2E) are described in
defined in [I-D.ietf-ippm-ioam-data]. defined in [I-D.ietf-ippm-ioam-data].
As this document describes new protocol fields within the existing As this document describes new protocol fields within the existing
GRE encapsulation, these are similar to the security considerations GRE encapsulation, these are similar to the security considerations
of [RFC2784]. of [RFC2890].
IOAM data transported in an OAM E2E header SHOULD be integrity IOAM data transported in an OAM E2E header SHOULD be integrity
protected (e.g., with IPsec ESP [RFC4303]) to detect changes made by protected (e.g., with IPsec ESP [RFC4303]) to detect changes made by
a device between the sending and receiving OAM endpoints. a device between the sending and receiving OAM endpoints.
6. IANA Considerations 6. IANA Considerations
A new EtherType value is requested to be added to the [ETYPES] IANA A new EtherType value is requested to be added to the [ETYPES] IANA
registry. The description should be "In-situ OAM (IOAM)". registry. The description should be "In-situ OAM (IOAM)".
skipping to change at page 7, line 18 skipping to change at page 7, line 18
[ETYPES] "IANA Ethernet Numbers", [ETYPES] "IANA Ethernet Numbers",
<https://www.iana.org/assignments/ieee-802-numbers/ <https://www.iana.org/assignments/ieee-802-numbers/
ieee-802-numbers.xhtml>. ieee-802-numbers.xhtml>.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-03 (work in progress), June 2018. data-04 (work in progress), October 2018.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-08 (work in progress), October 2018. nvo3-geneve-11 (work in progress), March 2019.
[IP-PROT] "IANA Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, RFC 2890, DOI 10.17487/RFC2890, September 2000,
DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2890>.
<https://www.rfc-editor.org/info/rfc2784>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
Authors' Addresses Authors' Addresses
Brian Weis Brian Weis
Cisco Systems, Inc. Independent
170 W. Tasman Drive
San Jose, California 95134-1706
USA USA
Phone: +1-408-526-4796 Email: bew.stds@gmail.com
Email: bew@cisco.com
Frank Brockners Frank Brockners
Cisco Systems, Inc. Cisco Systems, Inc.
Hansaallee 249, 3rd Floor Hansaallee 249, 3rd Floor
DUESSELDORF, NORDRHEIN-WESTFALEN 40549 DUESSELDORF, NORDRHEIN-WESTFALEN 40549
Germany Germany
Email: fbrockne@cisco.com Email: fbrockne@cisco.com
Craig Hill Craig Hill
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 9, line 31 skipping to change at page 9, line 18
Stephen Youell Stephen Youell
JP Morgan Chase JP Morgan Chase
25 Bank Street 25 Bank Street
London E14 5JP London E14 5JP
United Kingdom United Kingdom
Email: stephen.youell@jpmorgan.com Email: stephen.youell@jpmorgan.com
Tal Mizrahi Tal Mizrahi
Marvell Huawei Network.IO Innovation Lab
6 Hamada St.
Yokneam 20692
Israel Israel
Email: talmi@marvell.com Email: tal.mizrahi.phd@gmail.com
Aviv Kfir Aviv Kfir
Mellanox Technologies, Inc. Mellanox Technologies, Inc.
350 Oakmead Parkway, Suite 100 350 Oakmead Parkway, Suite 100
Sunnyvale, CA 94085 Sunnyvale, CA 94085
U.S.A. U.S.A.
Email: avivk@mellanox.com Email: avivk@mellanox.com
Barak Gafni Barak Gafni
Mellanox Technologies, Inc. Mellanox Technologies, Inc.
350 Oakmead Parkway, Suite 100 350 Oakmead Parkway, Suite 100
Sunnyvale, CA 94085 Sunnyvale, CA 94085
U.S.A. U.S.A.
Email: gbarak@mellanox.com Email: gbarak@mellanox.com
Petr Lapukhov Petr Lapukhov
Facebook Facebook
 End of changes. 30 change blocks. 
58 lines changed or deleted 48 lines changed or added

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