Hi Yaov, Perfect. We are on the same page here.
The way I see it is we treat it as a Mesh topology. The hub spoke tunnels are permanent, with temporary and on-demand (based on data/ time/ activity) spoke to spoke connectivity. This way we do not have the overload of excess configurations on the spoke, while still allowing mesh connectivity. I could specify that as a sub usecase of the Mesh Topology. Thanks, Vishwas On Sat, May 12, 2012 at 1:16 PM, Yoav Nir <y...@checkpoint.com> wrote: > I might have put it like this if it wan't so similar to the way things are > configured on Check Point gateways :-) > > It makes sense to me, but I'm not sure it covers all the use cases. > Imagine a topology that is entirely mesh, except for HTTP(S) traffic that > is routed to a central site because they have some HTTP inspection gateway > there. It's a requirement that came up a while ago. How does that fit the > "either mesh or star" topology? > > Also, a gateway that is part of more than one topologies (at Check Point > we call them "communities") would have to have a different view of the > network in these two contexts. As far as its peers in community A are > concerned, it is protecting all the networks behind any gateways in > community B, but for members on community B, it is protecting all the > addresses behind gateways in community A. > > On May 12, 2012, at 10:53 PM, Vishwas Manral wrote: > > Hi Yaov, > > If I udnerstand correctly, what you seem to be talking about is a > Star-of-meshes or a mesh-of-star topology. > > In my view this would be dealt with in 2 different iterations of the Mesh > VPN topology. So there would be a Mesh VPN for the Star topology and a > separate instance of the Mesh VPN for the mesh topology. > > Let me know if that makes sense. I think we can state that the requirement > should allow for such iterative use cases, however at one instance we only > look at star or mesh topology. Do I make sense? > > Thanks, > Vishwas > > On Sat, May 12, 2012 at 11:34 AM, Yoav Nir <y...@checkpoint.com> wrote: > >> Hi. >> >> I think it should be more complicated than this. The suggested solution >> has a dichotomy of either a full mesh or a start topology. The requirements >> should cover scenarios such as a mesh within an organization connecting to >> a hub to gateways outside the organization, or multiple hubs connected >> among themselves in either a star or a mesh, or even certain "routes" that >> are manually configured along with all the auto-discovery stuff. >> >> Perhaps we can capture the needed complexity by talking about groups of >> nodes, where nodes that belong to a single group attempt to create a mesh >> among them, and packets can travel between nodes that do not belong to the >> same group through group intersection. I'm not sure if this level of detail >> is part of the problem statement, but it's more high level than a solution. >> >> On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: >> >> > Hi, >> > >> > I would like to start off by trying to resolve the issue. The notes >> from the IETF are attached below. >> > >> > Description:Some admins prefer a star topology so they can inspect >> traffic. They may not want to use this technology. >> > >> > Detail arguments: My take is similar to what Yaron and Yaov seem to >> state. There is no reason to exclude star topology at all from the Problem >> statement/ requirements document. In fact both the proprietary solutions I >> know of allow for such a topology. I however understand that some of the >> functionality on the Hub (of the star) could be achieved by using PFP flags >> in the SPD entry. >> > >> > Suggested Resolution: State in the document that Star topology is not >> excluded from the solution. The problem of configuration is however mainly >> limited to the Hub. For every spoke added/ deleted/ modified the >> configuration on the Hub needs to be changed, which is not desirable. May >> be update Section 3.2 with the same too. >> > >> > Thanks, >> > Vishwas >> > =========================================================== >> > Notes from meeting minutes: >> > >> > # 219 Star topology as an admin choice >> > People don't need to use this if they don't >> want to >> > Say this in the security considerations >> > Yoav Nir: >> > Has to be a requirement that any >> solution can >> > implement different policies >> > Yaron Sheffer: >> > Agrees with Yoav, maybe becomes a use >> case >> > Take this to the list >> > _______________________________________________ >> > 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
