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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> > > <mailto:[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]>>> > > <mailto:[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
