draft-ietf-bmwg-sdn-controller-benchmark-term-07.txt   draft-ietf-bmwg-sdn-controller-benchmark-term-08.txt 
Internet-Draft Bhuvaneswaran Vengainathan Internet-Draft Bhuvaneswaran Vengainathan
Network Working Group Anton Basil Network Working Group Anton Basil
Intended Status: Informational Veryx Technologies Intended Status: Informational Veryx Technologies
Expires: June 10, 2018 Mark Tassinari Expires: August 25, 2018 Mark Tassinari
Hewlett-Packard Hewlett-Packard
Vishwas Manral Vishwas Manral
Nano Sec Nano Sec
Sarah Banks Sarah Banks
VSS Monitoring VSS Monitoring
January 10, 2018 February 25, 2018
Terminology for Benchmarking SDN Controller Performance Terminology for Benchmarking SDN Controller Performance
draft-ietf-bmwg-sdn-controller-benchmark-term-07 draft-ietf-bmwg-sdn-controller-benchmark-term-08
Abstract Abstract
This document defines terminology for benchmarking an SDN This document defines terminology for benchmarking an SDN
controller's control plane performance. It extends the terminology controller's control plane performance. It extends the terminology
already defined in RFC 7426 for the purpose of benchmarking SDN already defined in RFC 7426 for the purpose of benchmarking SDN
controllers. The terms provided in this document help to benchmark controllers. The terms provided in this document help to benchmark
SDN controller's performance independent of the controller's SDN controller's performance independent of the controller's
supported protocols and/or network services. A mechanism for supported protocols and/or network services. A mechanism for
benchmarking the performance of SDN controllers is defined in the benchmarking the performance of SDN controllers is defined in the
companion methodology document. These two documents provide a companion methodology document I-D sdn-controller-benchmark-meth.
standard mechanism to measure and evaluate the performance of These two documents provide a standard mechanism to measure and
various controller implementations. evaluate the performance of various controller implementations.
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 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 Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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 June 10, 2018. This Internet-Draft will expire on August 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 31 skipping to change at page 2, line 31
1. Introduction...................................................4 1. Introduction...................................................4
2. Term Definitions...............................................4 2. Term Definitions...............................................4
2.1. SDN Terms.................................................4 2.1. SDN Terms.................................................4
2.1.1. Flow.................................................4 2.1.1. Flow.................................................4
2.1.2. Northbound Interface.................................5 2.1.2. Northbound Interface.................................5
2.1.3. Controller Forwarding Table..........................5 2.1.3. Controller Forwarding Table..........................5
2.1.4. Proactive Flow Provisioning Mode.....................5 2.1.4. Proactive Flow Provisioning Mode.....................5
2.1.5. Reactive Flow Provisioning Mode......................6 2.1.5. Reactive Flow Provisioning Mode......................6
2.1.6. Path.................................................6 2.1.6. Path.................................................6
2.1.7. Standalone Mode......................................6 2.1.7. Standalone Mode......................................7
2.1.8. Cluster/Redundancy Mode..............................7 2.1.8. Cluster/Redundancy Mode..............................7
2.1.9. Asynchronous Message.................................7 2.1.9. Asynchronous Message.................................7
2.1.10. Test Traffic Generator..............................8 2.1.10. Test Traffic Generator..............................8
2.2. Test Configuration/Setup Terms............................8 2.1.11. Leaf-Spine Topology.................................8
2.2.1. Number of Network Devices............................8 2.2. Test Configuration/Setup Terms............................9
2.2.2. Trial Repetition.....................................8 2.2.1. Number of Network Devices............................9
2.2.2. Trial Repetition.....................................9
2.2.3. Trial Duration.......................................9 2.2.3. Trial Duration.......................................9
2.2.4. Number of Cluster nodes..............................9 2.2.4. Number of Cluster nodes.............................10
2.3. Benchmarking Terms.......................................10 2.3. Benchmarking Terms.......................................10
2.3.1. Performance.........................................10 2.3.1. Performance.........................................10
2.3.1.1. Network Topology Discovery Time................10 2.3.1.1. Network Topology Discovery Time................10
2.3.1.2. Asynchronous Message Processing Time...........10 2.3.1.2. Asynchronous Message Processing Time...........11
2.3.1.3. Asynchronous Message Processing Rate...........11 2.3.1.3. Asynchronous Message Processing Rate...........11
2.3.1.4. Reactive Path Provisioning Time................12 2.3.1.4. Reactive Path Provisioning Time................12
2.3.1.5. Proactive Path Provisioning Time...............12 2.3.1.5. Proactive Path Provisioning Time...............13
2.3.1.6. Reactive Path Provisioning Rate................13 2.3.1.6. Reactive Path Provisioning Rate................13
2.3.1.7. Proactive Path Provisioning Rate...............14 2.3.1.7. Proactive Path Provisioning Rate...............14
2.3.1.8. Network Topology Change Detection Time.........14 2.3.1.8. Network Topology Change Detection Time.........15
2.3.2. Scalability.........................................15 2.3.2. Scalability.........................................15
2.3.2.1. Control Sessions Capacity......................15 2.3.2.1. Control Sessions Capacity......................15
2.3.2.2. Network Discovery Size.........................15 2.3.2.2. Network Discovery Size.........................16
2.3.2.3. Forwarding Table Capacity......................16 2.3.2.3. Forwarding Table Capacity......................16
2.3.3. Security............................................16 2.3.3. Security............................................17
2.3.3.1. Exception Handling.............................16 2.3.3.1. Exception Handling.............................17
2.3.3.2. Denial of Service Handling.....................17 2.3.3.2. Denial of Service Handling.....................17
2.3.4. Reliability.........................................17 2.3.4. Reliability.........................................18
2.3.4.1. Controller Failover Time.......................17 2.3.4.1. Controller Failover Time.......................18
2.3.4.2. Network Re-Provisioning Time...................18 2.3.4.2. Network Re-Provisioning Time...................18
3. Test Setup....................................................18 3. Test Setup....................................................19
3.1. Test setup - Controller working in Standalone Mode.......19 3.1. Test setup - Controller working in Standalone Mode.......20
3.2. Test setup - Controller working in Cluster Mode..........20 3.2. Test setup - Controller working in Cluster Mode..........21
4. Test Coverage.................................................21 4. Test Coverage.................................................22
5. References....................................................22 5. References....................................................23
5.1. Normative References.....................................22 5.1. Normative References.....................................23
5.2. Informative References...................................22 5.2. Informative References...................................23
6. IANA Considerations...........................................22 6. IANA Considerations...........................................23
7. Security Considerations.......................................22 7. Security Considerations.......................................23
8. Acknowledgements..............................................23 8. Acknowledgements..............................................24
9. Authors' Addresses............................................23 9. Authors' Addresses............................................24
1. Introduction 1. Introduction
Software Defined Networking (SDN) is a networking architecture in Software Defined Networking (SDN) is a networking architecture in
which network control is decoupled from the underlying forwarding which network control is decoupled from the underlying forwarding
function and is placed in a centralized location called the SDN function and is placed in a centralized location called the SDN
controller. The SDN controller provides an abstraction of the controller. The SDN controller provides an abstraction of the
underlying network and offers a global view of the overall network underlying network and offers a global view of the overall network
to applications and business logic. Thus, an SDN controller provides to applications and business logic. Thus, an SDN controller provides
the flexibility to program, control, and manage network behaviour the flexibility to program, control, and manage network behaviour
dynamically through standard interfaces. Since the network controls dynamically through standard interfaces. Since the network controls
are logically centralized, the need to benchmark the SDN controller are logically centralized, the need to benchmark the SDN controller
performance becomes significant. This document defines terms to performance becomes significant. This document defines terms to
benchmark various controller designs for performance, scalability, benchmark various controller designs for performance, scalability,
reliability and security, independent of northbound and southbound reliability and security, independent of northbound and southbound
protocols. protocols.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Term Definitions 2. Term Definitions
2.1. SDN Terms 2.1. SDN Terms
The terms defined in this section are extensions to the terms The terms defined in this section are extensions to the terms
defined in [RFC7426] "Software-Defined Networking (SDN): Layers and defined in [RFC7426] "Software-Defined Networking (SDN): Layers and
Architecture Terminology". This RFC should be referred before Architecture Terminology". This RFC should be referred before
attempting to make use of this document. attempting to make use of this document.
skipping to change at page 5, line 9 skipping to change at page 5, line 12
Measurement Units: Measurement Units:
N/A N/A
See Also: See Also:
None None
2.1.2. Northbound Interface 2.1.2. Northbound Interface
Definition: Definition:
The definition of northbound interface is same Service Interface The definition of northbound interface is same Service Interface
defined in [RFC7426] . defined in [RFC7426].
Discussion: Discussion:
The northbound interface allows SDN applications and orchestration The northbound interface allows SDN applications and orchestration
systems to program and retrieve the network information through the systems to program and retrieve the network information through the
SDN controller. SDN controller.
Measurement Units: Measurement Units:
N/A N/A
See Also: See Also:
skipping to change at page 8, line 26 skipping to change at page 8, line 29
Discussion: Discussion:
Test Traffic Generator typically connects with Network Devices to Test Traffic Generator typically connects with Network Devices to
send/receive real-time network traffic. send/receive real-time network traffic.
Measurement Units: Measurement Units:
N/A N/A
See Also: See Also:
None None
2.1.11. Leaf-Spine Topology
Definition:
Leaf-Spine is a two layered network topology, where a series of
leaf switches, form the access layer, are fully meshed to a series
of spine switches that form the backbone layer.
Discussion:
In Leaf-Spine Topology, every leaf switch is connected to each of
the spine switches in the topology.
Measurement Units:
N/A
See Also:
None
2.2. Test Configuration/Setup Terms 2.2. Test Configuration/Setup Terms
2.2.1. Number of Network Devices 2.2.1. Number of Network Devices
Definition: Definition:
The number of Network Devices present in the defined test topology. The number of Network Devices present in the defined test topology.
Discussion: Discussion:
The Network Devices defined in the test topology can be deployed The Network Devices defined in the test topology can be deployed
using real hardware or emulated in hardware platforms. using real hardware or emulated in hardware platforms.
skipping to change at page 13, line 26 skipping to change at page 14, line 4
Measurement Units: Measurement Units:
milliseconds. milliseconds.
See Also: See Also:
None None
2.3.1.6. Reactive Path Provisioning Rate 2.3.1.6. Reactive Path Provisioning Rate
Definition: Definition:
The maximum number of independent paths a controller can The maximum number of independent paths a controller can
concurrently establish between source and destination nodes concurrently establish per second between source and destination
reactively, defined as the number of paths provisioned by the nodes reactively, defined as the number of paths provisioned per
controller(s) at its Southbound interface for the flow provisioning second by the controller(s) at its Southbound interface for the flow
requests received for path provisioning at its Southbound interface provisioning requests received for path provisioning at its
between the start of the trial and the expiry of given trial Southbound interface between the start of the trial and the expiry
duration. of given trial duration.
Discussion: Discussion:
For SDN to support agile traffic forwarding, it is important to For SDN to support agile traffic forwarding, it is important to
measure how many end-to-end flows that the controller could setup in measure how many end-to-end flows that the controller could setup in
the dataplane. This benchmark is obtained by sending traffic each the dataplane. This benchmark is obtained by sending traffic each
with unique source and destination pairs from the source Network with unique source and destination pairs from the source Network
Device and determine the number of frames received at the Device and determine the number of frames received at the
destination Network Device. destination Network Device.
Measurement Units: Measurement Units:
Paths provisioned per second. Paths provisioned per second.
See Also: See Also:
None None
2.3.1.7. Proactive Path Provisioning Rate 2.3.1.7. Proactive Path Provisioning Rate
Definition: Definition:
Measure the maximum number of independent paths a controller can Measure the maximum number of independent paths a controller can
concurrently establish between source and destination nodes concurrently establish per second between source and destination
proactively, defined as the number of paths provisioned by the nodes proactively, defined as the number of paths provisioned per
controller(s) at its Southbound interface for the paths provisioned second by the controller(s) at its Southbound interface for the
in its Northbound interface between the start of the trial and the paths provisioned in its Northbound interface between the start of
expiry of given trial duration. the trial and the expiry of given trial duration.
Discussion: Discussion:
For SDN to support pre-provisioning of traffic path for a larger For SDN to support pre-provisioning of traffic path for a larger
network from the application, it is important to measure how many network from the application, it is important to measure how many
end-to-end flows that the controller could setup in the dataplane. end-to-end flows that the controller could setup in the dataplane.
This benchmark is obtained by sending traffic each with unique This benchmark is obtained by sending traffic each with unique
source and destination pairs from the source Network Device. Program source and destination pairs from the source Network Device. Program
the flows on controller's northbound interface for traffic to reach the flows on controller's northbound interface for traffic to reach
from each of the unique source and destination pairs and determine from each of the unique source and destination pairs and determine
the number of frames received at the destination Network Device. the number of frames received at the destination Network Device.
skipping to change at page 17, line 16 skipping to change at page 17, line 38
2.3.3.2. Denial of Service Handling 2.3.3.2. Denial of Service Handling
Definition: Definition:
To determine the effect of handling denial of service (DoS) attacks To determine the effect of handling denial of service (DoS) attacks
on performance and scalability tests. on performance and scalability tests.
Discussion: Discussion:
This benchmark test is to be performed after obtaining the baseline This benchmark test is to be performed after obtaining the baseline
performance of the performance and scalability tests defined in performance of the performance and scalability tests defined in
section 2.3.1 and section 2.3.1.. This benchmark determines the section 2.3.1 and section 2.3.1. This benchmark determines the
deviation from the baseline performance due to the handling of deviation from the baseline performance due to the handling of
denial of service attacks on controller. denial of service attacks on controller.
Measurement Units: Measurement Units:
Deviation of baseline metrics while handling Denial of Service Deviation of baseline metrics while handling Denial of Service
Attacks. Attacks.
See Also: See Also:
None None
skipping to change at page 18, line 17 skipping to change at page 18, line 39
Definition: Definition:
The time taken to re-route the traffic by the Controller, when there The time taken to re-route the traffic by the Controller, when there
is a failure in existing traffic paths, defined as the interval is a failure in existing traffic paths, defined as the interval
starting from the first failure notification message received by the starting from the first failure notification message received by the
controller, ending with the last flow re-provisioning message sent controller, ending with the last flow re-provisioning message sent
by the controller at its Southbound interface . by the controller at its Southbound interface .
Discussion: Discussion:
This benchmark determines the controller's re-provisioning ability This benchmark determines the controller's re-provisioning ability
upon network failures. This benchmark test assumes the following: upon network failures. This benchmark test assumes the following:
i. Network topology supports redundant path between 1. Network topology supports redundant path between source and
source and destination endpoints. destination endpoints.
ii. Controller does not pre-provision the redundant path. 2. Controller does not pre-provision the redundant path.
Measurement Units: Measurement Units:
milliseconds. milliseconds.
See Also: See Also:
None None
3. Test Setup 3. Test Setup
This section provides common reference topologies that are later This section provides common reference topologies that are later
skipping to change at page 19, line 16 skipping to change at page 20, line 16
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Application Plane Test Emulator | | Application Plane Test Emulator |
| | | |
| +-----------------+ +-------------+ | | +-----------------+ +-------------+ |
| | Application | | Service | | | | Application | | Service | |
| +-----------------+ +-------------+ | | +-----------------+ +-------------+ |
| | | |
+-----------------------------+(I2)-------------------------+ +-----------------------------+(I2)-------------------------+
| |
|
| (Northbound interface) | (Northbound interface)
+-------------------------------+ +-------------------------------+
| +----------------+ | | +----------------+ |
| | SDN Controller | | | | SDN Controller | |
| +----------------+ | | +----------------+ |
| | | |
| Device Under Test (DUT) | | Device Under Test (DUT) |
+-------------------------------+ +-------------------------------+
| (Southbound interface) | (Southbound interface)
| |
|
+-----------------------------+(I1)-------------------------+ +-----------------------------+(I1)-------------------------+
| | | |
| +-----------+ +-----------+ | | +-----------+ +-----------+ |
| | Network |l1 ln-1| Network | | | | Network | | Network | |
| | Device 1 |---- .... ----| Device n | | | | Device 2 |--..-| Device n-1| |
| +-----------+ +-----------+ | | +-----------+ +-----------+ |
| |l0 |ln | | / \ / \ |
| | | | | / \ / \ |
| | | | | l0 / X \ ln |
| +---------------+ +---------------+ | | / / \ \ |
| | Test Traffic | | Test Traffic | | | +-----------+ +-----------+ |
| | Generator | | Generator | | | | Network | | Network | |
| | (TP1) | | (TP2) | | | | Device 1 |..| Device n | |
| +---------------+ +---------------+ | | +-----------+ +-----------+ |
| | | |
| +---------------+ +---------------+ |
| | Test Traffic | | Test Traffic | |
| | Generator | | Generator | |
| | (TP1) | | (TP2) | |
| +---------------+ +---------------+ |
| | | |
| Forwarding Plane Test Emulator | | Forwarding Plane Test Emulator |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 1 Figure 1
3.2. Test setup - Controller working in Cluster Mode 3.2. Test setup - Controller working in Cluster Mode
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Application Plane Test Emulator | | Application Plane Test Emulator |
| | | |
| +-----------------+ +-------------+ | | +-----------------+ +-------------+ |
| | Application | | Service | | | | Application | | Service | |
| +-----------------+ +-------------+ | | +-----------------+ +-------------+ |
| | | |
+-----------------------------+(I2)-------------------------+ +-----------------------------+(I2)-------------------------+
| |
|
| (Northbound interface) | (Northbound interface)
+---------------------------------------------------------+ +---------------------------------------------------------+
| | | |
| ------------------ ------------------ | | ------------------ ------------------ |
| | SDN Controller 1 | <--E/W--> | SDN Controller n | | | | SDN Controller 1 | <--E/W--> | SDN Controller n | |
| ------------------ ------------------ | | ------------------ ------------------ |
| | | |
| Device Under Test (DUT) | | Device Under Test (DUT) |
+---------------------------------------------------------+ +---------------------------------------------------------+
| (Southbound interface) | (Southbound interface)
| |
|
+-----------------------------+(I1)-------------------------+ +-----------------------------+(I1)-------------------------+
| | | |
| +-----------+ +-----------+ | | +-----------+ +-----------+ |
| | Network |l1 ln-1| Network | | | | Network | | Network | |
| | Device 1 |---- .... ----| Device n | | | | Device 2 |--..-| Device n-1| |
| +-----------+ +-----------+ | | +-----------+ +-----------+ |
| |l0 |ln | | / \ / \ |
| | | | | / \ / \ |
| | | | | l0 / X \ ln |
| +---------------+ +---------------+ | | / / \ \ |
| | Test Traffic | | Test Traffic | | | +-----------+ +-----------+ |
| | Generator | | Generator | | | | Network | | Network | |
| | (TP1) | | (TP2) | | | | Device 1 |..| Device n | |
| +---------------+ +---------------+ | | +-----------+ +-----------+ |
| | | |
| +---------------+ +---------------+ |
| | Test Traffic | | Test Traffic | |
| | Generator | | Generator | |
| | (TP1) | | (TP2) | |
| +---------------+ +---------------+ |
| | | |
| Forwarding Plane Test Emulator | | Forwarding Plane Test Emulator |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
Figure 2 Figure 2
4. Test Coverage 4. Test Coverage
+ -----------------------------------------------------------------+ + -----------------------------------------------------------------+
| | Speed | Scalability | Reliability | | | Speed | Scalability | Reliability |
skipping to change at page 22, line 22 skipping to change at page 23, line 22
January 2015. January 2015.
[RFC4689] S. Poretsky, J. Perser, S. Erramilli, S. Khurana [RFC4689] S. Poretsky, J. Perser, S. Erramilli, S. Khurana
"Terminology for Benchmarking Network-layer Traffic "Terminology for Benchmarking Network-layer Traffic
Control Mechanisms", RFC 4689, October 2006. Control Mechanisms", RFC 4689, October 2006.
[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, [RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
May 1998. May 1998.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
[I-D.sdn-controller-benchmark-meth] Bhuvaneswaran.V, Anton Basil, [I-D.sdn-controller-benchmark-meth] Bhuvaneswaran.V, Anton Basil,
Mark.T, Vishwas Manral, Sarah Banks "Benchmarking Mark.T, Vishwas Manral, Sarah Banks "Benchmarking
Methodology for SDN Controller Performance", Methodology for SDN Controller Performance",
draft-ietf-bmwg-sdn-controller-benchmark-meth-07 draft-ietf-bmwg-sdn-controller-benchmark-meth-08
(Work in progress), January 10, 2018 (Work in progress), February 25, 2018
5.2. Informative References 5.2. Informative References
[OpenFlow Switch Specification] ONF,"OpenFlow Switch Specification" [OpenFlow Switch Specification] ONF,"OpenFlow Switch Specification"
Version 1.4.0 (Wire Protocol 0x05), October 14, 2013. Version 1.4.0 (Wire Protocol 0x05), October 14, 2013.
6. IANA Considerations 6. IANA Considerations
This document does not have any IANA requests. This document does not have any IANA requests.
skipping to change at page 23, line 12 skipping to change at page 24, line 12
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
8. Acknowledgements 8. Acknowledgements
The authors would like to acknowledge Al Morton (AT&T) for the The authors would like to acknowledge Al Morton (AT&T) for the
significant contributions to the earlier versions of this document. significant contributions to the earlier versions of this document.
The authors would like to thank the following individuals for The authors would like to thank the following individuals for
providing their valuable comments to the earlier versions of this providing their valuable comments to the earlier versions of this
document: Sandeep Gangadharan (HP), M. Georgescu (NAIST), Andrew document: Sandeep Gangadharan (HP), M. Georgescu (NAIST), Andrew
McGregor (Google), Scott Bradner (Harvard University), Jay Karthik McGregor (Google), Scott Bradner , Jay Karthik (Cisco), Ramakrishnan
(Cisco), Ramakrishnan (Dell), Khasanov Boris (Huawei). (Dell), Khasanov Boris (Huawei).
9. Authors' Addresses 9. Authors' Addresses
Bhuvaneswaran Vengainathan Bhuvaneswaran Vengainathan
Veryx Technologies Inc. Veryx Technologies Inc.
1 International Plaza, Suite 550 1 International Plaza, Suite 550
Philadelphia Philadelphia
PA 19113 PA 19113
Email: bhuvaneswaran.vengainathan@veryxtech.com Email: bhuvaneswaran.vengainathan@veryxtech.com
 End of changes. 32 change blocks. 
82 lines changed or deleted 116 lines changed or added

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