draft-ietf-ippm-ioam-ipv6-options-03.txt   draft-ietf-ippm-ioam-ipv6-options-04.txt 
ippm S. Bhandari ippm S. Bhandari
Internet-Draft F. Brockners Internet-Draft Thoughtspot
Intended status: Standards Track C. Pignataro Intended status: Standards Track F. Brockners
Expires: March 22, 2021 Cisco Expires: May 5, 2021 C. Pignataro
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
Huawei Network.IO Innovation Lab 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, an Intel company Barefoot Networks, an Intel company
S. Krishnan S. Krishnan
Kaloom Kaloom
R. Asati R. Asati
Cisco Cisco
M. Smith M. Smith
September 18, 2020 November 1, 2020
In-situ OAM IPv6 Options In-situ OAM IPv6 Options
draft-ietf-ippm-ioam-ipv6-options-03 draft-ietf-ippm-ioam-ipv6-options-04
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 IOAM data fields are encapsulated in IPv6. outlines how IOAM data fields are encapsulated in IPv6.
Status of This Memo Status of This Memo
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 March 22, 2021. This Internet-Draft will expire on May 5, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
4. IOAM Deployment In IPv6 Networks . . . . . . . . . . . . . . 6 4. IOAM Deployment In IPv6 Networks . . . . . . . . . . . . . . 6
4.1. Considerations for IOAM deployment in IPv6 networks . . . 6 4.1. Considerations for IOAM deployment in IPv6 networks . . . 6
4.2. IOAM domains bounded by hosts . . . . . . . . . . . . . . 7 4.2. IOAM domains bounded by hosts . . . . . . . . . . . . . . 7
4.3. IOAM domains bounded by network devices . . . . . . . . . 7 4.3. IOAM domains bounded by network devices . . . . . . . . . 7
4.4. Deployment options . . . . . . . . . . . . . . . . . . . 7 4.4. Deployment options . . . . . . . . . . . . . . . . . . . 7
4.4.1. IPv6-in-IPv6 encapsulation . . . . . . . . . . . . . 7 4.4.1. IPv6-in-IPv6 encapsulation . . . . . . . . . . . . . 7
4.4.2. IP-in-IPv6 encapsulation with ULA . . . . . . . . . . 8 4.4.2. IP-in-IPv6 encapsulation with ULA . . . . . . . . . . 8
4.4.3. x-in-IPv6 Encapsulation that is used Independently . 9 4.4.3. x-in-IPv6 Encapsulation that is used Independently . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 path between two points in the network. This document traverses a path between two points in the network. This document
outlines how IOAM data fields are encapsulated in the IPv6 [RFC8200] outlines how IOAM data fields are encapsulated in the IPv6 [RFC8200]
and discusses deployment options for networks which leverage IOAM and discusses deployment options for networks that use
data fields encapsulated in the IPv6 protocol. Deployment IPv6-encapsulated IOAM data fields. These options have distinct
considerations differ, whether the IOAM domain starts and ends on deployment considerations; for example, the IOAM domain can either be
hosts or whether the IOAM encapsulating and decapsulating nodes are between hosts, or be between IOAM encapsulating and decapsulating
network devices that forward traffic, such as routers. network nodes that forward traffic, such as routers.
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 3, line 44 skipping to change at page 3, line 44
ION: IOAM Overlay Network ION: IOAM Overlay Network
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
POT: Proof of Transit POT: Proof of Transit
3. In-situ OAM Metadata Transport in IPv6 3. In-situ OAM Metadata Transport in IPv6
In-situ OAM in IPv6 is used to enhance diagnostics of IPv6 networks. In-situ OAM in IPv6 is used to enhance diagnostics of IPv6 networks.
It complements other mechanisms proposed to enhance diagnostics of It complements other mechanisms designed to enhance diagnostics of
IPv6 networks, such as the IPv6 Performance and Diagnostic Metrics IPv6 networks, such as the IPv6 Performance and Diagnostic Metrics
Destination Option described in [RFC8250]. Destination Option described in [RFC8250].
IOAM data fields are encapsulated in "option data" fields of two IOAM data fields can be encapsulated in "option data" fields using
types of extension headers in IPv6 packets - either Hop-by-Hop two types of extension headers in IPv6 packets - either Hop-by-Hop
Options header or Destination options header. The selection of a Options header or Destination options header. Deployments select one
particular extension header type depends on IOAM usage, as described of these extension header types depending on how IOAM is used, as
in section 4 of [I-D.ietf-ippm-ioam-data]. Multiple options with the described in section 4 of [I-D.ietf-ippm-ioam-data]. Multiple
same Option Type MAY appear in the same Hop-by-Hop Options or options with the same Option Type MAY appear in the same Hop-by-Hop
Destination Options header, with varying content. Options or Destination Options header, with distinct content.
In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly
enabled per interface on every node within the IOAM domain. Unless a enabled per interface on every node within the IOAM domain. Unless a
particular interface is explicitly enabled (i.e. explicitly particular interface is explicitly enabled (i.e., explicitly
configured) for IOAM, a router MUST drop packets which contain configured) for IOAM, a router MUST drop packets that contain
extension headers carrying IOAM data-fields. This is the default extension headers carrying IOAM data-fields. This is the default
behavior and is independent of whether the Hop-by-Hop options or behavior and is independent of whether the Hop-by-Hop options or
Destination options are used to encode the IOAM data. This ensures Destination options are used to encode the IOAM data. This ensures
that IOAM data does not unintentionally get forwarded outside the that IOAM data does not unintentionally get forwarded outside the
IOAM domain. IOAM domain.
An IPv6 packet carrying IOAM data in an Extension header can have An IPv6 packet carrying IOAM data in an Extension header can have
other extension headers, compliant with [RFC8200]. other extension headers, compliant with [RFC8200].
IPv6 Hop-by-Hop and Destination Option format for carrying in-situ IPv6 Hop-by-Hop and Destination Option format for carrying in-situ
skipping to change at page 6, line 13 skipping to change at page 6, line 13
and Destination Options header. In addition, to maintain IPv6 and Destination Options header. In addition, to maintain IPv6
extension header 8-octet alignment and avoid the need to add or extension header 8-octet alignment and avoid the need to add or
remove padding at every hop, the Trace-Type for Incremental Trace remove padding at every hop, the Trace-Type for Incremental Trace
Option in IPv6 MUST be selected such that the IOAM node data length Option in IPv6 MUST be selected such that the IOAM node data length
is a multiple of 8-octets. is a multiple of 8-octets.
4. IOAM Deployment In IPv6 Networks 4. IOAM Deployment In IPv6 Networks
4.1. Considerations for IOAM deployment in IPv6 networks 4.1. Considerations for IOAM deployment in IPv6 networks
IOAM deployment in an IPv6 network should take the following IOAM deployments in IPv6 networks should take the following
considerations and requirements into account: considerations and requirements into account:
C1 It is desirable that the addition of IOAM data fields neither C1 It is desirable that the addition of IOAM data fields neither
changes the way routers forward the packets, nor the forwarding changes the way routers forward packets nor the forwarding
decision the routers takes. The packet with the added OAM decisions the routers take. Packets with added OAM information
information should follow the same path within the domain that the should follow the same path within the domain that an identical
same packet without the OAM information would follow within the packet without OAM information would follow, even in the presence
domain even in the presence of ECMP. Such a behavior is of ECMP. Such behavior is particularly important for deployments
particularly interesting for deployments where IOAM data fields where IOAM data fields are only added "on-demand", e.g., to
are only added "on-demand", e.g. to provide further insights in provide further insights in case of undesired network behavior for
case of undesired network behavior for certain flows. certain flows. Implementations of IOAM SHOULD ensure that ECMP
Implementations of IOAM should ensure that ECMP behavior for behavior for packets with and without IOAM data fields is the
packets with and without IOAM data fields is the same. same.
C2 Given that IOAM data fields increase the total size of the packet, C2 Given that IOAM data fields increase the total size of a packet,
the size of the packet including the IOAM data could exceed the the size of a packet including the IOAM data could exceed the
PMTU. In particular, the incremental trace IOAM HbH Option, which PMTU. In particular, the incremental trace IOAM Hop-by-Hop (HbH)
is proposed to support hardware implementations of IOAM, changes Option, which is intended to support hardware implementations of
Option Data Length en-route. Operators of an IOAM domain are to IOAM, changes Option Data Length en-route. Operators of an IOAM
ensure that the addition of OAM information does not lead to domain SHOULD ensure that the addition of OAM information does not
fragmentation of the packet, e.g. by configuring the MTU of lead to fragmentation of the packet, e.g., by configuring the MTU
transit routers and switches to a sufficiently high value. of transit routers and switches to a sufficiently high value.
Careful control of the MTU in a network is one of the reasons why Careful control of the MTU in a network is one of the reasons why
IOAM is considered a domain specific feature, see also IOAM is considered a domain-specific feature (see also
[I-D.ietf-ippm-ioam-data]. In addition, the PMTU tolerance range [I-D.ietf-ippm-ioam-data]). In addition, the PMTU tolerance range
in the IOAM domain should be identified (e.g. through in the IOAM domain should be identified (e.g., through
configuration) and IOAM encapsulation operations and/or IOAM data configuration) and IOAM encapsulation operations and/or IOAM data
field insertion (in case of incremental tracing) should not be field insertion (in case of incremental tracing) should not be
performed if it exceeds the packet size beyond PMTU. performed if it exceeds the packet size beyond PMTU.
C3 Packets with IOAM data or associated ICMP errors, should not C3 Packets with IOAM data or associated ICMP errors, should not
arrive at destinations which have no knowledge of IOAM. Consider arrive at destinations that have no knowledge of IOAM. For
using IOAM in transit devices; misleading ICMP errors due to exmample, if IOAM is used in in transit devices, misleading ICMP
addition and/or presence of OAM data in the packet can confuse a errors due to addition and/or presence of OAM data in a packet
source of the packet that did not insert the OAM information. could confuse the host that sent the packet if it did not insert
the OAM information.
C4 OAM data leaks may affect the forwarding behavior and state of C4 OAM data leaks can affect the forwarding behavior and state of
network elements outside an IOAM domain. IOAM domains SHOULD network elements outside an IOAM domain. IOAM domains SHOULD
provide a mechanism to prevent data leaks or be able to assure provide a mechanism to prevent data leaks or be able to ensure
that upon leak network elements outside the domain are not that if a leak occurs, network elements outside the domain are not
affected i.e they continue to process other valid packets. affected (i.e., they continue to process other valid packets).
C5 The source of that inserted and leaked the IOAM data must be easy C5 The source that inserts and leaks the IOAM data needs to be easy
to identify for the purpose of troubleshooting, due to the high to identify for the purpose of troubleshooting, due to the high
complexity of troubleshooting a source that inserted the IOAM data complexity of troubleshooting a source that inserted the IOAM data
and did not remove it when the packet traversed across an AS. and did not remove it when the packet traversed across an
Such a troubleshooting process may require coordination between Autonomous System (AS). Such a troubleshooting process might
multiple operators, complicated configuration verification, packet require coordination between multiple operators, complex
capture analysis, etc. configuration verification, packet capture analysis, etc.
C6 Compliance with [RFC8200] would require OAM data to be C6 Compliance with [RFC8200] requires OAM data to be encapsulated
encapsulated instead of header/option insertion directly into in- instead of header/option insertion directly into in-flight packets
flight packets using the original IPv6 header. using the original IPv6 header.
4.2. IOAM domains bounded by hosts 4.2. IOAM domains bounded by hosts
For deployments where the IOAM domain is bounded by hosts, hosts will For deployments where the IOAM domain is bounded by hosts, hosts will
perform the operation of IOAM data field encapsulation and perform the operation of IOAM data field encapsulation and
decapsulation. IOAM data is carried in IPv6 packets as Hop-by-Hop or decapsulation. IOAM data is carried in IPv6 packets as Hop-by-Hop or
Destination options as specified in this document. Destination options as specified in this document.
4.3. IOAM domains bounded by network devices 4.3. IOAM domains bounded by network devices
skipping to change at page 7, line 41 skipping to change at page 7, line 44
Network devices will perform the operation of IOAM data field Network devices will perform the operation of IOAM data field
encapsulation and decapsulation. encapsulation and decapsulation.
4.4. Deployment options 4.4. Deployment options
This section lists out possible deployment options that can be This section lists out possible deployment options that can be
employed to meet the requirements listed in Section 4.1. employed to meet the requirements listed in Section 4.1.
4.4.1. IPv6-in-IPv6 encapsulation 4.4.1. IPv6-in-IPv6 encapsulation
Leverage an IPv6-in-IPv6 approach: Preserve the original IP packet The "IPv6-in-IPv6" approach preserves the original IP packet and add
and add an IPv6 header including IOAM data fields in an extension an IPv6 header including IOAM data fields in an extension header in
header in front of it, to forward traffic within and across the IOAM front of it, to forward traffic within and across an IOAM domain.
domain. The overlay network formed by the additional IPv6 header The overlay network formed by the additional IPv6 header with the
with the IOAM data fields included in an extension header is referred IOAM data fields included in an extension header is referred to as
to as IOAM Overlay Network (ION) in this document. IOAM Overlay Network (ION) in this document.
1. Perform an IPv6-in-IPv6 approach. The source address of the The following steps should be taken to perform an IPv6-in-IPv6
outer IPv6 header is that of the IOAM encapsulating node. The approach:
destination address of the outer IPv6 header is the same as the
inner IPv6 destination address, i.e. the destination address of
the packet does not change.
2. To simplify debugging in case of leaked IOAM data fields in 1. The source address of the outer IPv6 header is that of the IOAM
packets, consider a new IOAM E2E destination option to identify encapsulating node. The destination address of the outer IPv6
the Source IOAM domain (AS, v6 prefix). Insert this option into header is the same as the inner IPv6 destination address, i.e.,
the IOAM destination options EH attached to the outer IPv6 the destination address of the packet does not change.
header. This additional information would allow for easy
identification of an AS operator that is the source of packets
with leaked IOAM information. Note that leaked packets with IOAM
data fields would only occur in case a router would be
misconfigured.
3. All the IOAM options are defined with type "00 - skip over this 2. To simplify debugging in case of leaked IOAM data fields,
option and continue processing the header. So presence of the consider a new IOAM E2E destination option to identify the Source
options must not cause packet drop in the network elements that IOAM domain (AS, v6 prefix). Insert this option into the IOAM
do not understand the option. In addition destination options EH attached to the outer IPv6 header. This
additional information would allow for easy identification of an
AS operator that is the source of packets with leaked IOAM
information. Note that leaked packets with IOAM data fields
would only occur in case a router would be misconfigured.
3. All the IOAM options are defined with type "00" - skip over this
option and continue processing the header. Presence of these
options must not cause packet drops in network elements that do
not understand the option. In addition,
[I-D.ietf-6man-hbh-header-handling] should be considered. [I-D.ietf-6man-hbh-header-handling] should be considered.
4.4.2. IP-in-IPv6 encapsulation with ULA 4.4.2. IP-in-IPv6 encapsulation with ULA
The "IP-in-IPv6 encapsulation with ULA" [RFC4193] approach can be The "IP-in-IPv6 encapsulation with ULA" [RFC4193] approach can be
used to apply IOAM to an IPv6 as well as an IPv4 network. In used to apply IOAM to either an IPv6 or an IPv4 network. In
addition, it fulfills requirement C4 (avoid leaks) by using ULA for addition, it fulfills requirement C4 (avoid leaks) by using ULA for
the ION. Similar to the IPv6-in-IPv6 encapsulation approach above, the ION. Similar to the IPv6-in-IPv6 encapsulation approach above,
the original IP packet is preserved. An IPv6 header including IOAM the original IP packet is preserved. An IPv6 header including IOAM
data fields in an extension header is added in front of it, to data fields in an extension header is added in front of it, to
forward traffic within and across the IOAM domain. IPv6 addresses forward traffic within and across the IOAM domain. IPv6 addresses
for the ION, i.e. the outer IPv6 addresses are assigned from the ULA for the ION, i.e. the outer IPv6 addresses are assigned from the ULA
space. Addressing and routing in the ION are to be configured so space. Addressing and routing in the ION are to be configured so
that the IP-in-IPv6 encapsulated packets follow the same path as the that the IP-in-IPv6 encapsulated packets follow the same path as the
original, non-encapsulated packet would have taken. This would original, non-encapsulated packet would have taken. This would
create an internal IPv6 forwarding topology using the IOAM domain's create an internal IPv6 forwarding topology using the IOAM domain's
interior ULA address space which is parallel with the forwarding interior ULA address space which is parallel with the forwarding
topology that exists with the non-IOAM address space (the topology topology that exists with the non-IOAM address space (the topology
and address space that would be followed by packets that do not have and address space that would be followed by packets that do not have
supplemental IOAM information). Establishment and maintenance of the supplemental IOAM information). Establishment and maintenance of the
parallel IOAM ULA forwarding topology could be automated, e.g. parallel IOAM ULA forwarding topology could be automated, e.g.,
similar to how LDP [RFC5036] is used in MPLS to establish and similar to how LDP [RFC5036] is used in MPLS to establish and
maintain an LSP forwarding topology that is parallel to the network's maintain an LSP forwarding topology that is parallel to the network's
IGP forwarding topology. IGP forwarding topology.
Transit across the ION could leverage the transit approach for Transit across the ION could leverage the transit approach for
traffic between BGP border routers, as described in [RFC1772], "A.2.3 traffic between BGP border routers, as described in [RFC1772], "A.2.3
Encapsulation". Assuming that the operational guidelines specified Encapsulation". Assuming that the operational guidelines specified
in Section 4 of [RFC4193] are properly followed, the probability of in Section 4 of [RFC4193] are properly followed, the probability of
leaks in this approach will be almost close to zero. If the packets leaks in this approach will be almost close to zero. If the packets
do leak through IOAM egress device misconfiguration or partial IOAM do leak through IOAM egress device misconfiguration or partial IOAM
skipping to change at page 9, line 29 skipping to change at page 9, line 30
the IOAM decapsulating node. the IOAM decapsulating node.
5. Security Considerations 5. Security Considerations
This document describes the encapsulation of IOAM data fields in This document describes the encapsulation of IOAM data fields in
IPv6. Security considerations of the specific IOAM data fields for IPv6. Security considerations of the specific IOAM data fields for
each case (i.e., Trace, Proof of Transit, and E2E) are described and each case (i.e., Trace, Proof of Transit, and E2E) are described and
defined in [I-D.ietf-ippm-ioam-data]. defined in [I-D.ietf-ippm-ioam-data].
As this document describes new options for IPv6, these are similar to As this document describes new options for IPv6, these are similar to
the security considerations of [RFC8200] and the new weakness the security considerations of [RFC8200] and the weakness documented
documented in [RFC8250]. in [RFC8250].
6. IANA Considerations 6. IANA Considerations
This draft requests the following IPv6 Option Type assignments from This draft requests the following IPv6 Option Type assignments from
the Destination Options and Hop-by-Hop Options sub-registry of the Destination Options and Hop-by-Hop Options sub-registry of
Internet Protocol Version 6 (IPv6) Parameters. Internet Protocol Version 6 (IPv6) Parameters.
http://www.iana.org/assignments/ipv6-parameters/ipv6- http://www.iana.org/assignments/ipv6-parameters/ipv6-
parameters.xhtml#ipv6-parameters-2 parameters.xhtml#ipv6-parameters-2
skipping to change at page 11, line 22 skipping to change at page 11, line 26
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
Performance and Diagnostic Metrics (PDM) Destination Performance and Diagnostic Metrics (PDM) Destination
Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
<https://www.rfc-editor.org/info/rfc8250>. <https://www.rfc-editor.org/info/rfc8250>.
Authors' Addresses Authors' Addresses
Shwetha Bhandari Shwetha Bhandari
Cisco Systems, Inc. Thoughtspot
Cessna Business Park, Sarjapura Marathalli Outer Ring Road 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout
Bangalore, KARNATAKA 560 087 Bangalore, KARNATAKA 560 102
India India
Email: shwethab@cisco.com Email: shwetha.bhandari@thoughtspot.com
Frank Brockners Frank Brockners
Cisco Systems, Inc. Cisco Systems, Inc.
Kaiserswerther Str. 115, Kaiserswerther Str. 115,
RATINGEN, NORDRHEIN-WESTFALEN 40880 RATINGEN, NORDRHEIN-WESTFALEN 40880
Germany Germany
Email: fbrockne@cisco.com Email: fbrockne@cisco.com
Carlos Pignataro Carlos Pignataro
 End of changes. 28 change blocks. 
92 lines changed or deleted 95 lines changed or added

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