< draft-ietf-rtgwg-net2cloud-problem-statement-10.txt   draft-ietf-rtgwg-net2cloud-problem-statement-11.txt >
Network Working Group L. Dunbar Network Working Group L. Dunbar
Internet Draft Futurewei Internet Draft Futurewei
Intended status: Informational Andy Malis Intended status: Informational Andy Malis
Expires: November 1, 2020 Independent Expires: January 26, 2021 Malis Consulting
C. Jacquenet C. Jacquenet
Orange Orange
M. Toy M. Toy
Verizon Verizon
May 1, 2020 July 26, 2020
Dynamic Networks to Hybrid Cloud DCs Problem Statement Dynamic Networks to Hybrid Cloud DCs Problem Statement
draft-ietf-rtgwg-net2cloud-problem-statement-10 draft-ietf-rtgwg-net2cloud-problem-statement-11
Abstract Abstract
This document describes the problems that enterprises face today This document describes the problems that enterprises face today
when interconnecting their branch offices with dynamic workloads in when interconnecting their branch offices with dynamic workloads in
third party data centers (a.k.a. Cloud DCs). There can be many third party data centers (a.k.a. Cloud DCs). There can be many
problems associated with network connecting to or among Clouds, many problems associated with network connecting to or among Clouds, many
of which probably are out of the IETF scope. The objective of this of which probably are out of the IETF scope. The objective of this
document is to identify some of the problems that need additional document is to identify some of the problems that need additional
work in IETF Routing area. Other problems are out of the scope of work in IETF Routing area. Other problems are out of the scope of
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 1, 2020. This Internet-Draft will expire on January 26, 2009.
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
(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 40 skipping to change at page 2, line 40
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Key Characteristics of Cloud Services:....................3 1.1. Key Characteristics of Cloud Services:....................3
1.2. Connecting to Cloud Services..............................3 1.2. Connecting to Cloud Services..............................3
1.3. The role of SD-WAN in connecting to Cloud Services........4 1.3. Reaching App instances in the optimal Cloud DC locations..4
2. Definition of terms............................................4 2. Definition of terms............................................5
3. High Level Issues of Connecting to Multi-Cloud.................6 3. High Level Issues of Connecting to Multi-Cloud.................6
3.1. Security Issues...........................................6 3.1. Security Issues...........................................6
3.2. Authorization and Identity Management.....................6 3.2. Authorization and Identity Management.....................6
3.3. API abstraction...........................................7 3.3. API abstraction...........................................7
3.4. DNS for Cloud Resources...................................8 3.4. DNS for Cloud Resources...................................8
3.5. NAT for Cloud Services....................................9 3.5. NAT for Cloud Services....................................9
3.6. Cloud Discovery...........................................9 3.6. Cloud Discovery...........................................9
4. Interconnecting Enterprise Sites with Cloud DCs...............10 4. Interconnecting Enterprise Sites with Cloud DCs...............10
4.1. Sites to Cloud DC........................................10 4.1. Sites to Cloud DC........................................10
4.2. Inter-Cloud Interconnection..............................12 4.2. Inter-Cloud Interconnection..............................12
5. Problems with MPLS-based VPNs extending to Hybrid Cloud DCs...14 5. Problems with MPLS-based VPNs extending to Hybrid Cloud DCs...14
6. Problem with using IPsec tunnels to Cloud DCs.................15 6. Problem with using IPsec tunnels to Cloud DCs.................15
6.1. Scaling Issues with IPsec Tunnels........................15 6.1. Scaling Issues with IPsec Tunnels........................15
6.2. Poor performance over long distance......................16 6.2. Poor performance over long distance......................16
7. Problems of Using SD-WAN to connect to Cloud DCs..............16 7. End-to-End Security Concerns for Data Flows...................16
7.1. More Complexity to Edge Nodes............................17 8. Requirements for Dynamic Cloud Data Center VPNs...............17
7.2. Edge WAN Port Management.................................17 9. Security Considerations.......................................17
7.3. Forwarding based on Application..........................18 10. IANA Considerations..........................................18
8. End-to-End Security Concerns for Data Flows...................18 11. References...................................................18
9. Requirements for Dynamic Cloud Data Center VPNs...............18 11.1. Normative References....................................18
10. Security Considerations......................................19 11.2. Informative References..................................18
11. IANA Considerations..........................................19 12. Acknowledgments..............................................18
12. References...................................................19
12.1. Normative References....................................19
12.2. Informative References..................................19
13. Acknowledgments..............................................20
1. Introduction 1. Introduction
1.1. Key Characteristics of Cloud Services: 1.1. Key Characteristics of Cloud Services:
Key characteristics of Cloud Services are on-demand, scalable, Key characteristics of Cloud Services are on-demand, scalable,
highly available, and usage-based billing. Cloud Services, such as, highly available, and usage-based billing. Cloud Services, such as,
compute, storage, network functions (most likely virtual), third compute, storage, network functions (most likely virtual), third
party managed applications, etc. are usually hosted and managed by party managed applications, etc. are usually hosted and managed by
third parties Cloud Operators. Here are some examples of Cloud third parties Cloud Operators. Here are some examples of Cloud
skipping to change at page 4, line 29 skipping to change at page 4, line 25
- Global reachability from different geographical zones, thereby - Global reachability from different geographical zones, thereby
facilitating the proximity of applications as a function of the facilitating the proximity of applications as a function of the
end users' location, to improve latency. end users' location, to improve latency.
- Elasticity: prompt connection to newly instantiated - Elasticity: prompt connection to newly instantiated
applications at Cloud DCs when usages increase and prompt applications at Cloud DCs when usages increase and prompt
release of connection after applications at locations being release of connection after applications at locations being
removed when demands change. removed when demands change.
- Scalable security management. - Scalable security management.
1.3. The role of SD-WAN in connecting to Cloud Services 1.3. Reaching App instances in the optimal Cloud DC locations
Some of the characteristics of SD-WAN [SDWAN-BGP-USAGE], such as
network augmentation and forwarding based on application IDs instead
of based on destination IP addresses, are very essential for
connecting to on-demand Cloud services.
Issues associated with using SD-WAN for connecting to Cloud services Many applications have multiple instances instantiated in different
are also discussed in this document. Cloud DCs. The current state of the art solutions are typically
based on DNS assisted with load balancer by responding a FQDN (Fully
Qualified Domain Name) inquiry with an IP address of the closest or
lowest cost DC that can reach the instance. Here are some problems
associated with DNS based solutions:
- Dependent on client behavior
- Client can cache results indefinitely
- Client may not receive service even though there are
servers available (before cache timeout) in other Cloud
DCs.
- No inherent leverage of proximity information present in the
network (routing) layer, resulting in loss of performance
- Client on the west coast can be mapped to a DC on the east
coast
- Inflexible traffic control:
- Local DNS resolver become the unit of traffic management
2. Definition of terms 2. Definition of terms
Cloud DC: Third party Data Centers that usually host applications Cloud DC: Third party Data Centers that usually host applications
and workload owned by different organizations or and workload owned by different organizations or
tenants. tenants.
Controller: Used interchangeably with SD-WAN controller to manage Controller: Used interchangeably with SD-WAN controller to manage
SD-WAN overlay path creation/deletion and monitoring the SD-WAN overlay path creation/deletion and monitoring the
path conditions between two or more sites. path conditions between two or more sites.
skipping to change at page 5, line 23 skipping to change at page 5, line 33
router. router.
Heterogeneous Cloud: applications and workloads split among Cloud Heterogeneous Cloud: applications and workloads split among Cloud
DCs owned or managed by different operators. DCs owned or managed by different operators.
Hybrid Clouds: Hybrid Clouds refers to an enterprise using its own Hybrid Clouds: Hybrid Clouds refers to an enterprise using its own
on-premises DCs in addition to Cloud services provided on-premises DCs in addition to Cloud services provided
by one or more cloud operators. (e.g. AWS, Azure, by one or more cloud operators. (e.g. AWS, Azure,
Google, Salesforces, SAP, etc). Google, Salesforces, SAP, etc).
SD-WAN: Software Defined Wide Area Network. In this document,
"SD-WAN" refers to the solutions of pooling WAN
bandwidth from multiple underlay networks to get better
WAN bandwidth management, visibility & control. When the
underlay networks are private networks, traffic can
traverse without additional encryption; when the
underlay networks are public, such as Internet, some
traffic needs to be encrypted when traversing through
(depending on user provided policies).
VPC: Virtual Private Cloud is a virtual network dedicated to VPC: Virtual Private Cloud is a virtual network dedicated to
one client account. It is logically isolated from other one client account. It is logically isolated from other
virtual networks in a Cloud DC. Each client can launch virtual networks in a Cloud DC. Each client can launch
his/her desired resources, such as compute, storage, or his/her desired resources, such as compute, storage, or
network functions into his/her VPC. Most Cloud network functions into his/her VPC. Most Cloud
operators' VPCs only support private addresses, some operators' VPCs only support private addresses, some
support IPv4 only, others support IPv4/IPv6 dual stack. support IPv4 only, others support IPv4/IPv6 dual stack.
3. High Level Issues of Connecting to Multi-Cloud 3. High Level Issues of Connecting to Multi-Cloud
skipping to change at page 13, line 12 skipping to change at page 13, line 12
software such as strongSwan, you create an IPSec connection to the software such as strongSwan, you create an IPSec connection to the
Azure gateway using a shared key. The StrongSwan instance within AWS Azure gateway using a shared key. The StrongSwan instance within AWS
not only can connect to Azure but can also be used to facilitate not only can connect to Azure but can also be used to facilitate
traffic to other nodes within the AWS VPC by configuring forwarding traffic to other nodes within the AWS VPC by configuring forwarding
and using appropriate routing rules for the VPC. and using appropriate routing rules for the VPC.
Most Cloud operators, such as AWS VPC or Azure VNET, use non- Most Cloud operators, such as AWS VPC or Azure VNET, use non-
globally routable CIDR from private IPv4 address ranges as specified globally routable CIDR from private IPv4 address ranges as specified
by RFC1918. To establish IPsec tunnel between two Cloud DCs, it is by RFC1918. To establish IPsec tunnel between two Cloud DCs, it is
necessary to exchange Public routable addresses for applications in necessary to exchange Public routable addresses for applications in
different Cloud DCs. [BGP-SDWAN] describes one method. Other methods different Cloud DCs.
are worth exploring.
In summary, here are some approaches, available now (which might In summary, here are some approaches, available now (which might
change in the future), to interconnect workloads among different change in the future), to interconnect workloads among different
Cloud DCs: Cloud DCs:
a) Utilize Cloud DC provided inter/intra-cloud connectivity a) Utilize Cloud DC provided inter/intra-cloud connectivity
services (e.g., AWS Transit Gateway) to connect workloads services (e.g., AWS Transit Gateway) to connect workloads
instantiated in multiple VPCs. Such services are provided with instantiated in multiple VPCs. Such services are provided with
the cloud gateway to connect to external networks (e.g., AWS the cloud gateway to connect to external networks (e.g., AWS
DirectConnect Gateway). DirectConnect Gateway).
b) Hairpin all traffic through the customer gateway, meaning all b) Hairpin all traffic through the customer gateway, meaning all
workloads are directly connected to the customer gateway, so workloads are directly connected to the customer gateway, so
that communications among workloads within one Cloud DC must that communications among workloads within one Cloud DC must
traverse through the customer gateway. traverse through the customer gateway.
c) Establish direct tunnels among different VPCs (AWS' Virtual c) Establish direct tunnels among different VPCs (AWS' Virtual
Private Clouds) and VNET (Azure's Virtual Networks) via Private Clouds) and VNET (Azure's Virtual Networks) via
client's own virtual routers instantiated within Cloud DCs. client's own virtual routers instantiated within Cloud DCs.
DMVPN (Dynamic Multipoint Virtual Private Network) or DSVPN DMVPN (Dynamic Multipoint Virtual Private Network) or DSVPN
(Dynamic Smart VPN) techniques can be used to establish direct (Dynamic Smart VPN) techniques can be used to establish direct
Multi-point-to-Point or multi-point-to multi-point tunnels Multi-point-to-Point or multi-point-to multi-point tunnels
among those client's own virtual routers. among those client's own virtual routers.
Approach a) usually does not work if Cloud DCs are owned and managed Approach a) usually does not work if Cloud DCs are owned and managed
by different Cloud providers. by different Cloud providers.
skipping to change at page 14, line 12 skipping to change at page 14, line 12
standardized NHRP for connection-oriented NBMA network (such as ATM) standardized NHRP for connection-oriented NBMA network (such as ATM)
network address resolution more than two decades ago. network address resolution more than two decades ago.
There are many differences between virtual routers in Public Cloud There are many differences between virtual routers in Public Cloud
DCs and the nodes in an NBMA network. NHRP cannot be used for DCs and the nodes in an NBMA network. NHRP cannot be used for
registering virtual routers in Cloud DCs unless an extension of such registering virtual routers in Cloud DCs unless an extension of such
protocols is developed for that purpose, e.g. taking NAT or dynamic protocols is developed for that purpose, e.g. taking NAT or dynamic
addresses into consideration. Therefore, DMVPN and/or DSVPN cannot addresses into consideration. Therefore, DMVPN and/or DSVPN cannot
be used directly for connecting workloads in hybrid Cloud DCs. be used directly for connecting workloads in hybrid Cloud DCs.
Other protocols such as BGP can be used, as described in [BGP-
SDWAN].
5. Problems with MPLS-based VPNs extending to Hybrid Cloud DCs 5. Problems with MPLS-based VPNs extending to Hybrid Cloud DCs
Traditional MPLS-based VPNs have been widely deployed as an Traditional MPLS-based VPNs have been widely deployed as an
effective way to support businesses and organizations that require effective way to support businesses and organizations that require
network performance and reliability. MPLS shifted the burden of network performance and reliability. MPLS shifted the burden of
managing a VPN service from enterprises to service providers. The managing a VPN service from enterprises to service providers. The
CPEs attached to MPLS VPNs are also simpler and less expensive, CPEs attached to MPLS VPNs are also simpler and less expensive,
because they do not need to manage routes to remote sites; they because they do not need to manage routes to remote sites; they
simply pass all outbound traffic to the MPLS VPN PEs to which the simply pass all outbound traffic to the MPLS VPN PEs to which the
CPEs are attached (albeit multi-homing scenarios require more CPEs are attached (albeit multi-homing scenarios require more
skipping to change at page 16, line 37 skipping to change at page 16, line 37
measurement for paths over the Internet is passive and past measurement for paths over the Internet is passive and past
measurements may not represent future performance. measurements may not represent future performance.
Many cloud providers can replicate workloads in different available Many cloud providers can replicate workloads in different available
zones. An App instantiated in a cloud DC closest to clients may have zones. An App instantiated in a cloud DC closest to clients may have
to cooperate with another App (or its mirror image) in another to cooperate with another App (or its mirror image) in another
region or database server(s) in the on-premises DC. This kind of region or database server(s) in the on-premises DC. This kind of
coordination requires predicable networking behavior/performance coordination requires predicable networking behavior/performance
among those locations. among those locations.
7. Problems of Using SD-WAN to connect to Cloud DCs 7. End-to-End Security Concerns for Data Flows
SD-WAN lets enterprises augment their current VPN network with cost-
effective, readily available Broadband Internet connectivity,
enabling some traffic offloading to paths over the Internet
according to differentiated, possibly application-based traffic
forwarding policies, or when the MPLS VPN connection between the two
locations is congested, or otherwise undesirable or unavailable.
7.1. More Complexity to Edge Nodes
Augmenting transport path is not as simple as it appears. For an
enterprise with multiple sites, CPE managed overlay paths among
sites requires each CPE to manage all the addresses that local hosts
have potential to reach, i.e., map internal VPN addresses to
appropriate Overlay paths. This is similar to the complexity of
Frame Relay based VPNs, where each CPE needed to maintain mesh
routing for all destinations if they were to avoid an extra hop
through a hub router. Even with the assistance from a central
controller (instead of running a routing protocol) to resolve the
mapping between destinations and SD-WAN paths, SD-WAN CPEs are still
responsible for routing table maintenance as remote destinations
change their attachments, e.g., the dynamic workload in other DCs
are de-commissioned or added.
In addition, overlay path for interconnecting branch offices are
different from connecting to Cloud DCs:
- Overlay path interconnecting branch offices usually have two
end-points (e.g. CPEs) controlled by one entity (e.g.
controllers or management systems operated by the enterprise).
- Connecting to Cloud DC may consists of CPEs owned or managed by
the enterprise, and the remote end-points being managed or
controlled by Cloud DCs.
7.2. Edge WAN Port Management
An SDWAN edge node can have WAN ports connected to different
networks or public internet managed by different operators.
There is therefore a need to propagate WAN port property to
remote authorized peers in third party network domains in
addition to route propagation. Such an exchange cannot happen
before communication between peers is properly secured.
7.3. Forwarding based on Application
Forwarding based on application IDs instead of based on
destination IP addresses is often referred to as Application based
Segmentation. If the Applications have unique IP addresses, then
the Application Based Segmentation can be achieved by propagating
different BGP UPDATE messages to different nodes, as described in
[BGP-SDWAN-USAGE]. If the Application cannot be uniquely
identified by the IP addresses, more work is needed.
8. End-to-End Security Concerns for Data Flows
When IPsec tunnels established from enterprise on-premises CPEs When IPsec tunnels established from enterprise on-premises CPEs
are terminated at the Cloud DC gateway where the workloads or are terminated at the Cloud DC gateway where the workloads or
applications are hosted, some enterprises have concerns regarding applications are hosted, some enterprises have concerns regarding
traffic to/from their workload being exposed to others behind the traffic to/from their workload being exposed to others behind the
data center gateway (e.g., exposed to other organizations that data center gateway (e.g., exposed to other organizations that
have workloads in the same data center). have workloads in the same data center).
To ensure that traffic to/from workloads is not exposed to To ensure that traffic to/from workloads is not exposed to
unwanted entities, IPsec tunnels may go all the way to the unwanted entities, IPsec tunnels may go all the way to the
workload (servers, or VMs) within the DC. workload (servers, or VMs) within the DC.
9. Requirements for Dynamic Cloud Data Center VPNs 8. Requirements for Dynamic Cloud Data Center VPNs
In order to address the aforementioned issues, any solution for In order to address the aforementioned issues, any solution for
enterprise VPNs that includes connectivity to dynamic workloads or enterprise VPNs that includes connectivity to dynamic workloads or
applications in cloud data centers should satisfy a set of applications in cloud data centers should satisfy a set of
requirements: requirements:
- The solution should allow enterprises to take advantage of the - The solution should allow enterprises to take advantage of the
current state-of-the-art in VPN technology, in both traditional current state-of-the-art in VPN technology, in both traditional
MPLS-based VPNs and IPsec-based VPNs (or any combination MPLS-based VPNs and IPsec-based VPNs (or any combination
thereof) that run over the public Internet. thereof) that run over the public Internet.
skipping to change at page 19, line 12 skipping to change at page 17, line 30
- The solution needs to support easy and fast, on-the-fly, VPN - The solution needs to support easy and fast, on-the-fly, VPN
connections to dynamic workloads and applications in third connections to dynamic workloads and applications in third
party data centers, and easily allow these workloads to migrate party data centers, and easily allow these workloads to migrate
both within a data center and between data centers. both within a data center and between data centers.
- Allow VPNs to provide bandwidth and other performance - Allow VPNs to provide bandwidth and other performance
guarantees. guarantees.
- Be a cost-effective solution for enterprises to incorporate - Be a cost-effective solution for enterprises to incorporate
dynamic cloud-based applications and workloads into their dynamic cloud-based applications and workloads into their
existing VPN environment. existing VPN environment.
10. Security Considerations 9. Security Considerations
The draft discusses security requirements as a part of the problem The draft discusses security requirements as a part of the problem
space, particularly in sections 4, 5, and 8. space, particularly in sections 4, 5, and 8.
Solution drafts resulting from this work will address security Solution drafts resulting from this work will address security
concerns inherent to the solution(s), including both protocol concerns inherent to the solution(s), including both protocol
aspects and the importance (for example) of securing workloads in aspects and the importance (for example) of securing workloads in
cloud DCs and the use of secure interconnection mechanisms. cloud DCs and the use of secure interconnection mechanisms.
11. IANA Considerations 10. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove This document requires no IANA actions. RFC Editor: Please remove
this section before publication. this section before publication.
12. References 11. References
12.1. Normative References 11.1. Normative References
12.2. Informative References 11.2. Informative References
[RFC2735] B. Fox, et al "NHRP Support for Virtual Private [RFC2735] B. Fox, et al "NHRP Support for Virtual Private
networks". Dec. 1999. networks". Dec. 1999.
[RFC8192] S. Hares, et al "Interface to Network Security Functions [RFC8192] S. Hares, et al "Interface to Network Security Functions
(I2NSF) Problem Statement and Use Cases", July 2017 (I2NSF) Problem Statement and Use Cases", July 2017
[ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation, [ITU-T-X1036] ITU-T Recommendation X.1036, "Framework for creation,
storage, distribution and enforcement of policies for storage, distribution and enforcement of policies for
network security", Nov 2007. network security", Nov 2007.
[RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec) and [RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", Feb 2011. Internet Key Exchange (IKE) Document Roadmap", Feb 2011.
[RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", Feb 2006 Networks (VPNs)", Feb 2006
[RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", Sept 2006. Private Networks (L2VPNs)", Sept 2006.
[BGP-SDWAN] L. Dunbar, et al. "BGP Extension for SDWAN Overlay 12. Acknowledgments
Networks", draft-dunbar-idr-bgp-sdwan-overlay-ext-03,
work-in-progress, Nov 2018.
13. Acknowledgments
Many thanks to Alia Atlas, Chris Bowers, Paul Vixie, Paul Ebersman, Many thanks to Alia Atlas, Chris Bowers, Paul Vixie, Paul Ebersman,
Timothy Morizot, Ignas Bagdonas, Michael Huang, Liu Yuan Jiao, Timothy Morizot, Ignas Bagdonas, Michael Huang, Liu Yuan Jiao,
Katherine Zhao, and Jim Guichard for the discussion and Katherine Zhao, and Jim Guichard for the discussion and
contributions. contributions.
Authors' Addresses Authors' Addresses
Linda Dunbar Linda Dunbar
Futurewei Futurewei
Email: Linda.Dunbar@futurewei.com Email: Linda.Dunbar@futurewei.com
Andrew G. Malis Andrew G. Malis
Independent Malis Consulting
Email: agmalis@gmail.com Email: agmalis@gmail.com
Christian Jacquenet Christian Jacquenet
Orange Orange
Rennes, 35000 Rennes, 35000
France France
Email: Christian.jacquenet@orange.com Email: Christian.jacquenet@orange.com
Mehmet Toy Mehmet Toy
Verizon Verizon
 End of changes. 23 change blocks. 
109 lines changed or deleted 45 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/