Again, this issue was based on Michael Richardson's March 12 email, which said:
The dual trunk scenario should perhaps be further motivated and clarified. Are there some situations where a spoke should not contact another spoke directly, but in fact should contact a hub closer to the other spoke. I can see some solutions where a hub would not have complete knowledge of the mesh, and so would in fact simply punt a connection closer. I hope this clarifies the issue for you. I think that Michael is asking an important question. There are many ways to solve the P2P VPN problem. One way is to have satellites with little configuration that connect to core gateways with lots of dynamic information. A core gateway (a "hub" in Michael's parlance) can download things to a satellite (maybe a new SPD and PAD, credentials, etc.), thus causing some traffic from the satellite to be sent to a different core gateway or satellite. In that circumstance, I think Michael's question is about whether the core gateway that a satellite initially connects (which I'll call the "initial core gateway") to should be expected to have or obtain all the information needed to configure the satellite or whether the initial core gateway can send the satellite to another core gateway where it can get more information. At least, that's how I understand Michael's question. Perhaps he can affirm or deny this interpretation. Personally, I think that this question is premature. It presupposes too much about the eventual solution. That's why I think it should be answered in the solution not included in the problem statement. Apparently, Yaron doesn't agree with me. I'd like to hear more from him on this matter. Does he believe that all solutions to this problem (or at least all the good ones) must necessarily employ the model that I described above? What about a solution that doesn't rely on core gateways to refer satellites but instead has satellites querying for the information that they need? Or one that has some external entity (not the core gateway) configuring the satellites? In my view, there may be many possible P2P VPN solutions. However, I'm not an IPsec expert. Maybe this is the only practical approach. I'd like to hear views from Yaron and from others on this topic. Thanks, Steve From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Vishwas Manral Sent: Wednesday, March 21, 2012 3:18 PM To: Stephen Hanna Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Hi Steve, This is unclear to me. Isn't it routing that we send a packet across to a closer gateway/ router? What does everything mean in the question below? If we are talking about say security and routing, I think that is true. The "logical" gateway (could be multiple interactions and devices) should be able to provide the functionality. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna <sha...@juniper.net<mailto:sha...@juniper.net>> wrote: Please comment on Suggested Resolution. Note that Yaron has already supplied his comment below. Steve -----Original Message----- From: ipsecme issue tracker [mailto:t...@tools.ietf.org<mailto:t...@tools.ietf.org>] Sent: Tuesday, March 20, 2012 6:59 PM To: yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org<mailto:draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org> Subject: [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Suggested Resolution: We should not specify this in the problem statement. It should be specified in the solution. YS: sounds like a requirements-level question to me. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@... | problem@... Type: defect | Status: new Priority: normal | Milestone: Component: p2p-vpn- | Severity: - problem | Keywords: Resolution: | -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/214#comment:1> ipsecme <http://tools.ietf.org/ipsecme/> _______________________________________________ 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
