Sounds like a plan. Thanks for the quick response(s). Lou
On 11/16/2012 2:10 PM, Vishwas Manral 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> > > <mailto:[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]>> > > > <mailto:[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]>>>> > > > <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] <mailto:[email protected]>>>>> > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
