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