Hi Steve,
** ** > > 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. > Great. This is a critical factor for even smaller deployments and not just about the amount of configuration but the fact the configuration cannot be done. **** > > ** ** > > 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. > I meant 2.2 is most important from our perspective as HP. I agree 2.1 and 2.3 are important too and could be realized the same way, where an IPsec tunnel could terminate on a gateway/ load balancer. > **** > > ** ** > > 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.**** > > ** > In a simple use case we want hub and spoke topology for say the DC and the branches. This would also be true of ATM's connecting to their DC. However for scalability reasons we would not want all traffic to go through the hub. In the ATM example we could want VoIP session to bypass the DC and have a direct connectivity between themselves. There are multiple other uses cases for the same. These new sessions however are temporary, when compared to permanent branch to hub connections. > ** > > SH> And thanks for volunteering to participate in formulating the problem > statement and the solutions. That’s great! > Absolutely. Let me know if you need the exact text for the same and I can help provide it. Thanks, Vishwas > **** > > 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]> 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]] > On Behalf Of [email protected] > Sent: Tuesday, March 06, 2012 11:01 AM > To: [email protected] > Cc: [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] > https://www.ietf.org/mailman/listinfo/ipsec**** > > ** ** >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
