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:[email protected]] 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 <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of [email protected]<mailto:[email protected]> Sent: Tuesday, March 06, 2012 11:01 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
