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