Vishwas,
See below.
On 12/5/2012 3:06 PM, Vishwas Manral wrote:
> Hi Lou,
>
> > Thanks for your close reading of the document. I am attaching the
> > changed document. Please let me know if it looks good.
> >
> > On 11/15/2012 7:14 PM, Vishwas Manral wrote:
> > > - 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.
> >
>
> I don't see any changes in 2.2 related to this (old) comment on routing
> implications, am I missing something?
>
> I am a bit confused here.
>
> You said
> " I think this text is closer, but I think a few additional changes are
> needed:
> - GRE and OSPF are examples, so "i.e." should be replaced with "e.g."
> - I think the final sentence is likely to be incorrect in many / most
> real world cases, so would drop the sentence (from "Routing using
> the tunnels can work...")"
>
> I performed the changes you asked for. For the second part I have told
> you the reason below. What am I missing?
I think we're getting changes in section 2 and 4 mixed up. Let me try
again. WRT the new section *2.2* I think mentioning something about the
routing implications is worthwhile. How about before the last paragraph
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.
>
>
> >
> >
> > In section 4.1 we had discussed replacement text for 3:
> > On 11/16/2012 12:49 PM, Vishwas Manral wrote:
> > >>On 11/15/2012 5:44 PM, Lou Berger wrote:
> > >> - 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.
> >
> > You have the following alternate / revised text:
> > 3. In many cases additional tunneling protocols (i.e. GRE) or
> > Routing protocols (i.e. OSPF) are run over the IPsec tunnels.
> > Gateways MUST allow for the operation of tunneling and Routing
> > protocols operating over spoke-to-spoke IPsec Tunnels with
> minimal or
> > no, configuration impact. Routing using the tunnels can work
> > seamlessly without any updates to the higher level application
> > configuration i.e. OSPF configuration, when the tunnel
> parameter
> > changes.
> >
> > I think this text is closer, but I think a few additional
> changes are
> > needed:
> > - GRE and OSPF are examples, so "i.e." should be replaced
> with "e.g."
> > - I think the final sentence is likely to be incorrect in
> many / most
> > real world cases, so would drop the sentence (from "Routing
> using
> > the tunnels can work...")
> >
> > I changed the "can" to a SHOULD for the second part. The idea is no
> > changes should happen in configuration and our current solution allows
> > that for most cases (hence SHOULD).
>
> I think this is worse. Now you're placing requirements on routing
> protocols which IMO should not care if (or be aware of when) the tunnel
> they are running on is IPsec or carried via IPsec.
>
> What additional point are you trying to make in the following sentence?
> Routing using the tunnels SHOULD work
> seamlessly without any updates to the higher level application
> configuration i.e. OSPF configuration, when the tunnel parameter
> changes.
>
> Can the sentence just be dropped?
>
> VM> I think this is an important requirement. A tunnel should be able to
> provide an interface by which when tunnel IP parameters change we do not
> have to change any configuration for higher application like Routing. I
> had earlier mentioned in more generic terms earlier but changed to the
> terms provided based on feedback from the list.
What higher level protocols like most routing protocols that use the
tunnel interface IP addresses in operation?
>
> The entire idea is the with scale configuration needs to be reduced and
> that needs to happen across layers, so every layer needs to provide the
> service. Let me know what it is I am unable to convey.
sure, but I think you're placing new requirements on the routing &
tunneling protocols.
>
>
>
> I've seen this supported on some firewall products in conjunction with
> dynamic DNS. I used one for a couple of years (the spoke used a dynamic
> address + DDNS.) I certainly deffer to the WG on if such usage should
> be referenced in this document. You are, after all, the experts on this
> and I'm just an occasional user...
>
> some possible text for section 2.2. could be:
> OLD
> The gateways can themselves come up and down, getting different IP
> addresses in the process, making static configuration impossible.
> NEW
> The solution should also address the case where gateways use dynamic
> IP addresses.
>
> I am not sure how to 2 sentences mean the same thing, with DDNS inputs
> you have given. Are you saying keep the old text as well as add the new
> text.
Nope. I was trying to capture the use case in a way that avoided the
problematic text. Does the latter cover your use case? If not, we can
go into what I see as problematic with the old text.
>
>
> and section 3.2, perhaps something like:
> OLD
> This solution however does not work when the spokes get dynamic IP
> address which the "hub gateways" cannot be configured with.
> NEW
> This solution however is complicated by the case when the spokes
> use dynamic IP addresses and DNS with dynamic updates must be used.
>
> Same comment as above.
Well these sentences are much closer. The latter implies that the hubs
are configured with the spokes FQDNs. We can add something to that
effect if you think it helps.
Thanks,
Lou
>
> Thanks,
> Vishwas
>
> Thanks,
> Lou
>
> >
> > Thanks,
> > Vishwas
> >
> >
> >
> > _______________________________________________
> > IPsec mailing list
> > 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
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
