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

[Vishwas Manral <[e-mail]>]

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