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 <sha...@juniper.net> 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-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org]
> On Behalf Of internet-dra...@ietf.org
> Sent: Tuesday, March 06, 2012 11:01 AM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to