« Return to Thread: Please Comment on New P2P VPN Problem Statement

Re: Please Comment on New P2P VPN Problem Statement

by Stephen Hanna :: Rate this Message:

| View in Thread

Some parts of this message have been removed. Learn more about Nabble's security policy.

Vishwas,

 

Thanks for your comments. I’ll respond inline below.

 

1. I guess the problem statement is not just about lessening the number of configuration commands but also the fact that static configuration may not work in some cases. The spokes may get new addresses every time they come up (using DHCP/ PPPoE) and hence the communication end point identifiers change.

SH> Yes, the dynamic nature of configuration data is as much a problem as the size of that data.

 

2. I am not sure but the use cases do not come out very clearly to me. The most important part of the communication is of end-sites communicating to the gateway hub router. In a typical enterprise deployment that would mean a branches connected to the campus/ data center. This tunnel is permanent. Mainly to access resources at the back end. There could be redundancy here to provide HA.


3. We then optionally require communication between end sites and such communication may be temporary or permanent. For such cases we want to be able to unburden the gateway so as to not cause overload.

4. We could have multiple gateways work in a cluster mode to serve a set of end-sites and to provide HA.

5. The clusters may in turn communicate with each other.

SH> I’m sorry that the use cases are not clear. However, I’m sure we can and will improve them.

 

SH> Your description of “The most important part of the communication” seems to be focused only on use case 2.2 in the draft. In your example, several “end-sites” need to establish a direct connection to each other instead of going through a “gateway hub router”. To use the terminology defined in the draft, that’s a gateway-to-gateway use case. I understand that you consider that to be the most important use case but others have previously spoken out about the importance of use cases 2.1 and 2.3.

 

SH> So I do agree with your description of use case 2.2. Maybe we should add another example under use case 2.2, based on your example. Could you provide more details about why a direct connection between two “end-sites” might be needed? I can add that as an example in the next version of the draft.

 

SH> And thanks for volunteering to participate in formulating the problem statement and the solutions. That’s great!

 

Take care,

 

Steve

 

From: Vishwas Manral [mailto:vishwas.ietf@...]
Sent: Tuesday, March 06, 2012 5:23 PM
To: Stephen Hanna
Cc: IPsecme WG
Subject: Re: [IPsec] Please Comment on New P2P VPN Problem Statement

 

Hi Steve,

I agree to the need of standardization for a large scale point-to-point solution.

1. I guess the problem statement is not just about lessening the number of configuration commands but also the fact that static configuration may not work in some cases. The spokes may get new addresses every time they come up (using DHCP/ PPPoE) and hence the communication end point identifiers change.

2. I am not sure but the use cases do not come out very clearly to me. The most important part of the communication is of end-sites communicating to the gateway hub router. In a typical enterprise deployment that would mean a branches connected to the campus/ data center. This tunnel is permanent. Mainly to access resources at the back end. There could be redundancy here to provide HA.

3. We then optionally require communication between end sites and such communication may be temporary or permanent. For such cases we want to be able to unburden the gateway so as to not cause overload.

4. We could have multiple gateways work in a cluster mode to serve a set of end-sites and to provide HA.

5. The clusters may in turn communicate with each other.

We as HP would love to participate in this draft as well as any solution document that is produced.

Thanks,
Vishwas

On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna <shanna@...> wrote:

In case you didn't notice, I have posted the -00 version
of the P2P VPN problem statement. The URL is below.
Please review and comment.

I'm especially interested in getting feedback on the
use cases in this document. As previously agreed, they
are based on the use cases in section 2.2 of the
previous problem statement draft. I have tried to
clarify those use cases, especially by providing
definitions of terms and using those terms consistently
throughout the document.

After we reach consensus on the use cases, we can move
on to defining requirements derived from those use cases.
But I see no point in talking about requirements before
we've agreed on a clear description of the problems
that we are trying to solve.

So please review this short document and send comments.

Thanks,

Steve

-----Original Message-----
From: i-d-announce-bounces@... [mailto:i-d-announce-bounces@...] On Behalf Of Internet-Drafts@...
Sent: Tuesday, March 06, 2012 11:01 AM
To: i-d-announce@...
Cc: ipsec@...
Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

   Title         : Point to Point VPNs Problem Statement
   Author(s)     : S. Hanna
   Filename      : draft-ietf-ipsecme-p2p-vpn-problem
   Pages         : 13
   Date          : March 6, 2012

  This document describes the problem of enabling a large number of
  systems to communicate directly using IPsec to protect the traffic
  between them.  Manual configuration of all possible tunnels is too
  cumbersome in such cases, so an automated method is needed.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
IPsec mailing list
IPsec@...
https://www.ietf.org/mailman/listinfo/ipsec

 


_______________________________________________
IPsec mailing list
IPsec@...
https://www.ietf.org/mailman/listinfo/ipsec

 « Return to Thread: Please Comment on New P2P VPN Problem Statement