Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ipsecme-ad-vpn-problem-07.txt

"Manral, Vishwas" <vishwas.manral@hp.com> Tue, 09 July 2013 22:00 UTC

Return-Path: <vishwas.manral@hp.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A42C11E818F for <gen-art@ietfa.amsl.com>; Tue, 9 Jul 2013 15:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtO2X-j9VPVY for <gen-art@ietfa.amsl.com>; Tue, 9 Jul 2013 14:59:52 -0700 (PDT)
Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id EE34A11E8195 for <gen-art@ietf.org>; Tue, 9 Jul 2013 14:58:55 -0700 (PDT)
Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id F16932C4B2; Tue, 9 Jul 2013 21:58:54 +0000 (UTC)
Received: from G5W5499.americas.hpqcorp.net (16.201.144.179) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 9 Jul 2013 21:58:05 +0000
Received: from G5W2732.americas.hpqcorp.net ([169.254.4.124]) by G5W5499.americas.hpqcorp.net ([16.201.144.179]) with mapi id 14.03.0123.003; Tue, 9 Jul 2013 21:58:06 +0000
From: "Manral, Vishwas" <vishwas.manral@hp.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>, "draft-ietf-ipsecme-ad-vpn-problem.all@tools.ietf.org" <draft-ietf-ipsecme-ad-vpn-problem.all@tools.ietf.org>, General Area Review Team <gen-art@ietf.org>
Thread-Topic: Gen-ART Telechat review of draft-ietf-ipsecme-ad-vpn-problem-07.txt
Thread-Index: AQHOcQ84fjwvVmfREk63wI1zJUppw5lc9xew
Date: Tue, 09 Jul 2013 21:58:04 +0000
Message-ID: <5A9E892C56FD5842856290BDA06E12A00B7338F7@G5W2732.americas.hpqcorp.net>
References: <51C89A1D.10404@ericsson.com>
In-Reply-To: <51C89A1D.10404@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [16.201.12.21]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 09 Jul 2013 15:02:16 -0700
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ipsecme-ad-vpn-problem-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2013 22:00:09 -0000

Hi Suresh,

Good comments.

* Section 2.3

The following sentence is a bit confusing. How does a mobile user
connect to a new gateway without reinitiating a connection? Can you
please clarify or reword.

"The mobile user ought to be able to discover and then connect to the
current most efficient gateway without having to reinitiate the connection."
VM> The idea here is that the connection doesn't get reinitiated and is never down, we move the connection between 2 IPsec gateways. I have changed the text as I see where you are coming from.

VM> A mobile user roaming on the Internet may connect to a gateway, which because of roaming is no longer the most efficient gateway to use (reasons could be cost/ efficiency/ latency or some other factor). The mobile user ought to be able to discover and then connect to the current most efficient gateway in a seamless way          without having to bring down the connection.

* Section 4.1. Requirement 5

Shouldn't there be a requirement here that states what kind of damage is
allowed and prohibited in case a hub node is compromised?
VM> The Hub is the central point in my view, which leads to the single point of failure. I think the solution will allow for multiple hubs (HP DVPN solution already does) and it uses AES-256 encryption etc. I think these however are elements of the implementation, not requirements. 

VM> I added the following as a requirement:
     There ADVPN solution SHOULD take care of now letting the Hub to be a single point of failure

* Section 4.1. Requirement 12

It is unclear what this requirement means. Is the requirement for the
solution to integrate with multicast routing protocols to come up with a
different (and optimized) multicast ADVPN topology or to simply allow
the advpn to carry (flattened out) multicast traffic?
VM> General solutions uses Multiple unicast as broadcast and that does not scale. What we are mentioning here is that the solution for traffic does not scale. The document that's why says:

VM>       The ADVPN solution SHOULD be able to scale for multicast traffic.

* Section 4.1. Requirement 14

Are there any special requirements that L3VPN poses on top of what is
required for carrying generic IP traffic? If so, can you elaborate here.
VM> No there are no special requirements. We got the comment from Lou Berger who felt we should explicitly state the same as the solution will be used in L3VPN use cases too. This is so that we do not exclude a use case when thinking of the solution.

Thanks,
Vishwas