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. > > > > > > 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. Do you see a reason to explicitly mention L3VPN in this case? 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]> > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
