Vishwas,
Thanks for the quick response. Please see below.
On 11/15/2012 7:14 PM, Vishwas Manral wrote:
> 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
yes, this is what I referred to as 4.2 below, and suggested some
replacement text...
>
> 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.
4.2 = 4.1
>
>
> 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.
> 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
