Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02

Lou Berger <lberger@labn.net> Fri, 14 December 2012 18:15 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03121F8A9B for <ipsec@ietfa.amsl.com>; Fri, 14 Dec 2012 10:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.464
X-Spam-Level:
X-Spam-Status: No, score=-101.464 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7weReZEUvnD for <ipsec@ietfa.amsl.com>; Fri, 14 Dec 2012 10:15:24 -0800 (PST)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 78C4A21F8A90 for <ipsec@ietf.org>; Fri, 14 Dec 2012 10:15:24 -0800 (PST)
Received: (qmail 31763 invoked by uid 0); 14 Dec 2012 18:15:00 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 14 Dec 2012 18:15:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=2sevO7JFVaOiN8dzpAFQm/3JCGcZE5AmqYckCgAN1/g=; b=yh/n6vO9MXk317zoMmySXqkJqFYnW6qM5HMNYDaF3mf2PE4Wy1PYl9mBEtPjEvLbwPOIrbr1qAlOKEn6aooRUS0H+dWh8FwViDrLjVhJQv2ZCy7XvWY6XSplm8NME2Zr;
Received: from box313.bluehost.com ([69.89.31.113]:55293 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1TjZml-0005h7-Lt; Fri, 14 Dec 2012 11:15:00 -0700
Message-ID: <50CB6CA4.3020806@labn.net>
Date: Fri, 14 Dec 2012 13:15:00 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Brian Weis <bew@cisco.com>
References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <CAOyVPHRk49O0eX3KzCGB6usDW=aQhpe3=cPsQfSQM=sZQOE4Rg@mail.gmail.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com>
In-Reply-To: <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "vishwas.manral@hp.com" <vishwas.manral@hp.com>, Stephen Hanna <shanna@juniper.net>, ipsec@ietf.org
Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2012 18:15:25 -0000

Brian,
	Opps, should have replied to this message (and not the prior).

My previous mail basically said the new requirement is placed on the
ADVPN solution, not a particular implementation.  I think it's important
to ensure that the overall solution provides for Requirement 14, and I'm
not sure how this can be done without a requirement.

See below for additional specific responses.

On 12/13/2012 4:48 PM, Brian Weis wrote:
> Hi Vishwas,
> 
> See a couple of notes inline.
> 
> On Dec 13, 2012, at 9:54 AM, Vishwas Manral <vishwas.ietf@gmail.com
> <mailto:vishwas.ietf@gmail.com>> wrote:
> 
>> Hi Brian,

...
>>     Requirement 14 says "The ADVPN solution MUST support Provider Edge
>>     (PE) based VPN's". This requirement seems unfair to the end point
>>     use cases in 2.1 and 2.3, or even gateway-to-gateway ADVPN
>>     solutions that have nothing to do with L3VPNs! I think you're
>>     trying to say it must be possible to build an ADVPN solution that
>>     meets the requirements of L3VPN, which I have no problem with but
>>     I don't think think this it's a fair requirement to put in Section
>>     4. Is there anything beyond the new text you added in 2.2
>>     regarding L3VPN that needs to be said?
>>
>> VM> No I did not add any extra text for L3VPN besides this one. The
>> idea was that if IPsec over GRE as PE to PE communication tunnels the
>> ADVPN technology should not preclude such a solution.Like I have said
>> earlier I do not have strong opinion regarding this requirement. Lou
>> thought this should be there and I asked the list if there were
>> objections to this, and I did not hear anyone object, so I added it.
>>  
> 
> Thanks for the background. It should be possible to address Lou's
> concern underlying  concern without adding a requirement that is onerous
> for ADVPN use cases where L3VPN doesn't apply. 

I agree there implementation cases where the requirement doesn't apply.
 This is why the requirement was phrased as being a requirement on the
overall solution, not on as an implementation requirement.

> The Section 2.2 text I
> referred to is "There is also the case when L3VPNs operate over IPsec
> Tunnels." Maybe that could be expanded into a new paragraph in lieu of a
> requirement? I notice the use of lower case "must" is used in this section. 
> 


>> Lets try to hear from Lou on this.
> 
> Lou, would something like the following text in Section 2.2 be a
> satisfactory replacement for Requirement 14?
> 
>     There is also the case when L3VPNs operate over IPsec Tunnels, 
>     for example Provider Edge (PE) based VPN's. An AD VPN must
>     support L3VPN as an application protected by the IPsec
>     Tunnels.

it he must was a MUST, sure.

Lou

> 
> Thanks,
> Brian
> 
>>
>>     There's a couple remaining nits:
>>
>>     Section 2.2: s/A fully meshed solution is would/A fully meshed
>>     solution would/
>>     Section 4: s/This sectiondefines/This section defines/
>>
>> VM> Updated.
>>
>> Thanks,
>> Vishwas
>>
>>
>>     Thanks,
>>     Brian
>>
>>     _______________________________________________
>>     IPsec mailing list
>>     IPsec@ietf.org <mailto:IPsec@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
> 
> 
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>