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

[Vishwas Manral <[e-mail]>]

Hi WG-participants,

As its been a week and I have not heard any objections, I will update this
requirement and post the draft across.

Thanks,
Vishwas
On Fri, Nov 16, 2012 at 11:10 AM, Vishwas Manral <[e-mail]>wrote:

> Thanks Lou,
>
> Let me heard back from the WG on this, if they have any opinion. If not we
> can go ahead with your suggestion.
>
> -Vishwas
>
>
> On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger <[e-mail]> wrote:
>
>> Vishwas,
>>
>> On 11/16/2012 1:48 PM, Vishwas Manral wrote:
>> > Hi Lou,
>> >
>> > Got it. Can you suggest some text for this? I will try to incorporate
>> > the same into the document.
>>
>> Assuming you don't like my prior attempt:
>> X.  The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364].
>>
>> How about something like:
>> X. The solution MUST support Provider Edge (PE) based VPNs.
>>
>> Note that this phrasing doesn't indicate a specific solutions which is
>> why I now suggest "MUST" vs "SHOULD".
>>
>> Lou
>>
>> >
>> > Thanks,
>> > Vishwas
>> >
>> > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <[e-mail]
>> > <mailto:[e-mail]>> wrote:
>> >
>> >     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]>
>> >     > <mailto:[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]>>>
>> >     >     <mailto:[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
>> >     >     >     >
>> >     >     >     >
>> >     >     >     >
>> >     >     >
>> >     >     >
>> >     >
>> >     >
>> >
>> >
>>
>
>