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

[Vishwas Manral <[e-mail]>]

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]> 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]>>
> >     >     https://www.ietf.org/mailman/listinfo/ipsec
> >     >
> >     >
> >     >
> >
> >
>