Hi Lou,
Thanks a lot for your detailed comments. I have just started to change the
document today, based on feedback I got on the list, so your comments come
at a good time. My answers are inline:
In section 1.1, you define the term gateway. I'm assuming that you are
> using the term in the normal IPsec context, and that it includes IPsec
> enabled routers. Is this correct? If not, the text should make this
> clear, and you can ignore the rest of my mail!
>
Yes, the idea is an IPsec gateway will have Routing functionality too. Now
whether its a tunnel gateway with routing embedded or the otehr way around
is debatable. I also agree Routing is a big part of the functionality to be
optimized, though I would consider it a different sub-part of the solution.
>
> Assuming such routers are within scope, there are some complicating
> issues with IPsec enabled routers that I think should be called out. I
> don't think much text is needed to cover this case. I'm not sure the
> best way to address these, but I have some suggestions to get the
> conversation started (and yes, I expect that you'll edit the text):
>
> - In section 2.2, I think mentioning something about the routing
> implications is worthwhile. How about at the end of the section adding
> something along the lines of :
>
> Additionally, the routing implications of gateway-to-gateway
> communication must be addressed. In the simple case,
> selectors provide sufficient information for a gateway to
> forward traffic appropriately. In other cases, additional
> tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are
> run over IPsec tunnels, and the configuration impact on those
> protocols must be considered. There is also the case when
> L3VPNs operate over IPsec Tunnels.
>
> 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
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.
>
> and (new text)
>
> I cannot find Section 4.2 in the document
http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00 is there
more context you can provide for the same.
> 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. I see the 2 working in different layers, and
interacting only in edge gateways where both solutions have an edge.
> 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]
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
