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 <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
