Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

[Lou Berger <[e-mail]>]

Vishwas,
	Sure, but it's the BGP information that indicates what IPsec tunnels
are needed / when the SAs get established...

Again, I just asking for language that points to this use case, not
implementation details.

Thanks,
Lou

On 11/16/2012 1:34 PM, Vishwas Manral wrote:
> Hi Lou,
> 
>> I'm not sure I agree with this statement.  Let's say you have
>> a BGP VPN that uses IPsec tunnels between the PEs (which
>> was described in a couple of expired drafts and can be supported
>> using RFC5566), and then wants to be able to use dynamic PE
>> to PE IPsec tunnels.  Does this fit your "2 different layer"
>> perspective?
> IPsec with ADVPN secures the tunnel and creates the mesh underlay on
> need basis/ or automatically. L3VPN creates the overlay, identifies the
> tenant/ customer a packet belongs to and passes the packet on.
> 
> Where do we see the need for tighter integration here? Is it allowing
> the ability to create groups of ADVPN instances?
> 
> Thanks,
> Vishwas
> 
> On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     Vishwas,
> 
>     Please see below.
> 
>     On 11/16/2012 12:49 PM, Vishwas Manral wrote:
>     > 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.
>     >
> 
>     Great.
> 
>     >
>     >     >
>     >     >
>     >     >        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.
> 
>     I'm not sure I agree with this statement.  Let's say you have a BGP VPN
>     that uses IPsec tunnels between the PEs (which was described in a couple
>     of expired drafts and can be supported using RFC5566), and then wants to
>     be able to use dynamic PE to PE IPsec tunnels.  Does this fit your "2
>     different layer" perspective?
> 
>     Either way, I think such usage should be explicitly in scope as it is a
>     very different model / use case from CE-based IPsec VPNs.
> 
>     > Do you see a reason to explicitly
>     > mention L3VPN in this case?
> 
>     I'm open to different ways to cover the above.
> 
>     Much thanks,
>     Lou
>     >
>     > 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
>     >     >     [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     <mailto:[e-mail] <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >     >     https://www.ietf.org/mailman/listinfo/ipsec
>     >     >
>     >     >
>     >     >
>     >
>     >
> 
>