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
