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 <[email protected]
> <mailto:[email protected]>> 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
> > > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>>
> > > https://www.ietf.org/mailman/listinfo/ipsec
> > >
> > >
> > >
> >
> >
>
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
