Return-Path: 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 8C77E21F8AA9 for ; Fri, 16 Nov 2012 09:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 3x4CBV7LTT9h for ; Fri, 16 Nov 2012 09:49:37 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8D121F8A86 for ; Fri, 16 Nov 2012 09:49:37 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2453849lah.31 for ; Fri, 16 Nov 2012 09:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/BdogOw24FAx1yns6dO2Bn5BJtgvaKWBN4mS41GpeGU=; b=xquucEjpwxBlJLNc3ztPCR8xDn0B7KNjBTgM5t+MJedHsLMGI1Kj3OPVvBSVQlgCw6 XNW6r500qk7AdrxGFvm7ej61LbZrr02UtTTmHBzVm4jSWUWXD2doSoOWckuihDquwKzk glb856p84vM1buwuKCN/4iWAtEeyKgA8hbuvTZg9gzgR1j/GBtD2SfusUO8BpUIIYgmz 7v2J5UD8dXc41GxDyUwWblGQQvbl3e2Pc757G71eNkw+4XtPhPtPTgzK+U6TZnWEwlvy mjE9ynWr/8cLnNTI/SZ7Ni4ty4vUOT9WUcZFG26IygqO2jEu60bLf4Iw5Vop/Ic7uZAg j7ew== MIME-Version: 1.0 Received: by 10.152.133.140 with SMTP id pc12mr4870937lab.53.1353088176094; Fri, 16 Nov 2012 09:49:36 -0800 (PST) Received: by 10.114.75.110 with HTTP; Fri, 16 Nov 2012 09:49:36 -0800 (PST) In-Reply-To: <50A58CDB.30402@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> Date: Fri, 16 Nov 2012 09:49:36 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=f46d042dfe9915fe5204cea0644e Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 17:49:38 -0000 --f46d042dfe9915fe5204cea0644e Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, Thanks for the quick reply. Just a few comments prefixed with a "VM>": > > > We can add something in the lines of additional protocols are run over > > the IPsec tunnels and the solution should make an effort to allow for > > additional protocols like OSPF to be run optimally without too many > > changes in configuration. > > > > Infact we have a requirement to the effect in section 4.1 > > yes, this is what I referred to as 4.2 below, and suggested some > replacement text... > > OK got it. > > > > Gateways MUST allow tunnel binding, such that applications like > > Routing using the tunnels can work seamlessly without any updates to > > the higher level application configuration i.e. OSPF configuration. > > > > - In section 4.2, how about: > > (replacement text) > > 3. Gateways MUST allow for the operation of tunneling and > > routing protocols operating over spoke-to-spoke IPsec Tunnels > > with minimal, or no, configuration impact. > VM> Ok will specifically specify tunnels and routing protocols. > > > > > > X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. > > > > If you want, you can make the "SHOULD" a "MUST", and "support" could > be > > "be compatible with". > > > > I do not want to go ahead into details of what other routing solutions > > it should support. > > > > With that said I am not sure what you mean by having BGP MPLS VPN in an > > ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN solution, > > this is a customer provisioned one. > > Ahh, interesting point. When I read the document I was looking to see > if it was scoped purely to CE/customer based solutions. Reading section > 2 (intro) and 2.2, I saw no such restriction. So I think section 2.2 > should be explicit on this point either way. Which is why I proposed the > text "There is also the case when L3VPNs operate over IPsec Tunnels." > (To explicitly include this case.) If the WG wants this case excluded, > that's fine too. > VM> It is not scoped purely as a CE device scenario, and after seeing your comment I see no reason to leave that out of scope (though if I understand your concern better I may feel otherwise). L3VPN can work over GRE tunnels/ L2TP tunnels, which can themselves use IPsec. Again in my view the L3VPN and the IPsec VPN are 2 different layers in the stack if they run on the same device. Do you see a reason to explicitly mention L3VPN in this case? Thanks, Vishwas > > > I see the 2 working in different > > layers, and interacting only in edge gateways where both solutions have > > an edge. > > Sure, but the problem exists for both. > > Thanks, > Lou > > > > > > I also have a few more minor comments: > > > > I am ok with the minor suggestions you have. > > > > Thanks, > > Vishwas > > > > > > > > - In section 2.1, you introduce the term "NAT gateway" and then later > > use just "gateway" when I suspect you mean "NAT gateway". I suggest > > using the term "NAT" and thereby not introduce possible confusion > > between the gateway term defined in section 1.1 and "NAT gateways". > > > > - In section 2.2, s/occupies/requires > > > > - In sections 2.2, and Section 3.2 you say dynamic addresses makes > > static configuration impossible. This doesn't reflect the use of > > dynamic dns to handle this issues (and is currently supported by some > > vendors.) > > > > Let me know what you think, > > Lou > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > --f46d042dfe9915fe5204cea0644e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

Thanks for the quick reply. Just a few comments prefixed wit= h a "VM>":

>
> We can add something in the lines of additional protocols are run over=
> the IPsec tunnels and the solution should make an effort to allow for<= br> > additional protocols like OSPF to be run optimally without too many > changes in configuration.
>
> Infact we have a requirement to the effect in section 4.1

yes, this is what I referred to as 4.2 below, and suggested som= e
replacement text...

OK got it.=A0
>
> =A0 =A0 Gateways MUST allow tunnel binding, such that applications lik= e
> =A0 =A0Routing using the tunnels can work seamlessly without any updat= es to
> =A0 =A0the higher level application configuration i.e. =A0OSPF configu= ration.
>
> =A0 =A0 - In section 4.2, how about:
> =A0 =A0 =A0 =A0(replacement text)
> =A0 =A0 =A0 =A03. =A0Gateways MUST allow for the operation of tunnelin= g and
> =A0 =A0 =A0 =A0routing protocols operating over spoke-to-spoke IPsec T= unnels
> =A0 =A0 =A0 =A0with minimal, or no, configuration impact.
VM> Ok will specifically specify tunnels and routing prot= ocols.
=A0
>
>
> =A0 =A0 =A0 =A0X. =A0The solution SHOULD support BGP/MPLS IP VPNs, see= [RFC4364].
>
> =A0 =A0 If you want, you can make the "SHOULD" a "MUST&= quot;, and "support" could be
> =A0 =A0 "be compatible with".
>
> I do not want to go ahead into details of what other routing solutions=
> it should support.
>
> With that said I am not sure what you mean by having BGP MPLS VPN in a= n
> ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN solution, > this is a customer provisioned one.

Ahh, interesting point. =A0When I read the document I was looking to = see
if it was scoped purely to CE/customer based solutions. =A0Reading section<= br> 2 (intro) and 2.2, I saw no such restriction. =A0So I think section 2.2
should be explicit on this point either way. Which is why I proposed the text "There is also the case when L3VPNs operate over IPsec Tunnels.&q= uot;
(To explicitly include this case.) =A0If the WG wants this case excluded, that's fine too.
VM> It is not scoped purely as= a CE device scenario, and after seeing your comment I see no reason to lea= ve that out of scope (though if I understand your concern better I may feel= otherwise). L3VPN can work over GRE tunnels/ L2TP tunnels, which can thems= elves use IPsec. Again in my view the L3VPN and the IPsec VPN are 2 differe= nt layers in the stack if they run on the same device. Do you see a reason = to explicitly mention L3VPN in this case?

Thanks,
Vishwas
=A0

> I see the 2 working in different
> layers, and interacting only in edge gateways where both solutions hav= e
> an edge.

Sure, but the problem exists for both.

Thanks,
Lou
>
>
> =A0 =A0 I also have a few more minor comments:
>
> I am ok with the minor suggestions you have.
>
> Thanks,
> Vishwas
>
>
>
> =A0 =A0 - In section 2.1, you introduce the term "NAT gateway&quo= t; and then later
> =A0 =A0 use just "gateway" when I suspect you mean "NAT= gateway". =A0I suggest
> =A0 =A0 using the term "NAT" and thereby not introduce possi= ble confusion
> =A0 =A0 between the gateway term defined in section 1.1 and "NAT = gateways".
>
> =A0 =A0 - In section 2.2, s/occupies/requires
>
> =A0 =A0 - In sections 2.2, and Section 3.2 you say dynamic addresses m= akes
> =A0 =A0 static configuration impossible. =A0This doesn't reflect t= he use of
> =A0 =A0 dynamic dns to handle this issues (and is currently supported = by some
> =A0 =A0 vendors.)
>
> =A0 =A0 Let me know what you think,
> =A0 =A0 Lou
> =A0 =A0 _______________________________________________
> =A0 =A0 IPsec mailing list
> =A0 =A0 IPsec@ietf.org <= ;mailto:IPsec@ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/ipsec
>
>
>

--f46d042dfe9915fe5204cea0644e--